XMPP connection closed "java.lang.IllegalStateException: Parser should never return 'null' on getText() here"

Hi Smack Devs,

I’m developing an Android messaging application that is connected to a server running ejabberd.

My Android app is running aSmack 4.0.0, so far aSmack is helping a lot in my project, the mobile app is able to connect, authenticate, extent for custom features and send/receive packages as expected but, I’ve a weird problem in some scenarios that is causing an unexpected connection shutdown. I’ve researched about the exception but there is no information about it, so hope that someone can help me to find the problem.

Basically what it is happening is that after sent some kind of packets the smack client is trying to send this packet “</stream:stream>” causing an IllegalStateException and start the reconnection process. Please take a look into the following logs:

D/SMACK (11370): SENT (0): </stream:stream>

W/XMPPConnection(11370): Connection closed with error

W/XMPPConnection(11370): java.lang.IllegalStateException: Parser should never return ‘null’ on getText() here

W/XMPPConnection(11370): at org.jivesoftware.smack.util.PacketParserUtils.parseContentDepth(PacketParserUti ls.java:161)

W/XMPPConnection(11370): at org.jivesoftware.smack.tcp.PacketReader.parsePackets(PacketReader.java:174)

W/XMPPConnection(11370): at org.jivesoftware.smack.tcp.PacketReader.access$000(PacketReader.java:48)

W/XMPPConnection(11370): at org.jivesoftware.smack.tcp.PacketReader$1.run(PacketReader.java:82)

D/SMACK (11370): Connection closed due to an exception (0)

D/dalvikvm( 2213): GC_CONCURRENT freed 379K, 4% free 17966K/18548K, paused 1ms+2ms, total 19ms

D/MyApp (11370): MyAppMessagingService: Reconnecting to XMPP in, 5, seconds,

D/SMACK (11370): Connection (0) will reconnect in 5

D/MyApp (11370): MyAppMessagingService: Reconnecting to XMPP in, 4, seconds,

D/SMACK (11370): Connection (0) will reconnect in 4

D/MyApp (11370): MyAppMessagingService: Reconnecting to XMPP in, 3, seconds,

D/SMACK (11370): Connection (0) will reconnect in 3

D/MyApp (11370): MyAppMessagingService: Reconnecting to XMPP in, 2, seconds,

D/SMACK (11370): Connection (0) will reconnect in 2

D/MyApp (11370): MyAppMessagingService: Reconnecting to XMPP in, 1, seconds,

D/SMACK (11370): Connection (0) will reconnect in 1

D/MyApp (11370): MyAppMessagingService: Reconnecting to XMPP in, 0, seconds,

D/SMACK (11370): Connection (0) will reconnect in 0

I’m aware of two scenarios where this is happening 1) After request time using EntityTimeManager 2) After send a message to any chat

As extra information, I’m using the PingManager to keep connection alive and that works ok until I try to send one of the packets mentioned previously.

Please help and thanks in advance!

is trying to send this packet “</stream:stream>” causing an IllegalStateException
I think the order of events is different: The client parses some incoming stanza, which is causing the IllegalStateException, which then leads to the client sending the terminating stream stanza.

I’m aware of two scenarios where this is happening 1) After request time using EntityTimeManager 2) After send a message to any chat
Are you saying that you are able to reproduce this behavior with 1. or 2.? 2. would be odd, since sending a message could not trigger this, only receiving.a stanza.

What we need in order to diagnose the cause of the ISE is the received stanza that is causing this. I’ve added the so far content to the message with bd6346b4d1. But it will take a while until the 4.0.1 release, so it would be great if you are able to reproduce this and create some sort of stanza trace e.g. with a packet sniffer.

After digging into some source, it’s possible that this is caused by Androids KXmlParser not supporting xml-roundtrip. Stay tuned for an 4.0.1-SNAPSHOT version which a potential fix.

Please try http://asmack.freakempire.de/SNAPSHOTS/4.0.1-SNAPSHOT-2014-06-18/

and report back if it fixes the issue for you.

1 Like

Thanks, you are right the order of events are different and this is not aSmack problem.

Our server sends some custom stanzas back to client as an ack to let it know that what client sent was received by the server (e.g request time, send message). I was not aware of that custom stuff on our server until now. Probably I need to add a custom IQ provider to solve this problem.

BTW, I’ve tried the 4.0.1-SNAPSHOT but same thing happens.

Thanks for the help!

Could you show me the stacktrace of the ISE with 4.0.1-SNAPSHOT?

Thanks, you are right the order of events are different and this is not aSmack problem.
AFAIKT this is a (a)Smack problem.

BTW, I’ve tried the 4.0.1-SNAPSHOT but same thing happens.
I’ve just noticed a missing negation in the code of the 2014-06-18 Snapshot. Please try the aSmack 2014-06-19 Snapshot (or newer) and report back.

aSmack 4.0.1-SNAPSHOT 2014-06-21 released. Please report back if particular this version fixes the issue, since the fix is different from the previous snapshot versions.

Hi Flow:

The problem still exists after I update to 4.0.1. Below are the detail xml stanza.

D/SMACK (21811): RCV (0): 0

D/SMACK (21811): SENT (0):

D/SMACK (21811): RCV (0): 27a16c8164b1494da83e99a417ee7ab0-327987022</i q>

W/System.err(21811): java.lang.IllegalStateException: Parser should never return ‘null’ on getText() here. Content so far"27a16c8164b1494da83e99a417ee7ab0-327987022"

W/System.err(21811): at org.jivesoftware.smack.util.PacketParserUtils.parseContentDepth(PacketParserUti ls.java:200)

W/System.err(21811): at org.jivesoftware.smack.tcp.PacketReader.parsePackets(PacketReader.java:173)

W/System.err(21811): at org.jivesoftware.smack.tcp.PacketReader.access$0(PacketReader.java:146)

W/System.err(21811): at org.jivesoftware.smack.tcp.PacketReader$1.run(PacketReader.java:81)

D/SMACK (21811): SENT (0): </stream:stream>

W/XMPPConnection(21811): Connection closed with error

It seems asmack failed to parse the getsessionkey stanza.

Judging from the linenumbers of the stacktrace, you are not using the latest available snapshot of aSmack 4.0.1. Please do so.