powered by Jive Software

Smack 4.2.0 is not handling the stream resumption error correctly


We are using Smack 4.2.0 with stream management enable on the server side(Using Ejabbered). At the client side when user trying to resume the previous stream after stream resumption timeout we are getting resume failed error stating previous session timeout.

SENT (0):

RECV (0): <?xml version='1.0'?><stream:stream id=‘17224807743219834289’ version=‘1.0’ xml:lang=‘en’ xmlns:stream=‘http://etherx.jabber.org/streams’ from=‘xmppalpha.livecare.ca’ xmlns=‘jabber:client’>

RECV (0): stream:features</stream:features>

RECV (0): Previous session timed out

Smack is giving us some parsing error for this:

Connection XMPPTCPConnection[155@xmppalpha.livecare.ca/9039] (0) closed with error

java.lang.IllegalStateException: Could not transform string ‘text’ to XMPPErrorCondition

at org.jivesoftware.smack.packet.XMPPError$Condition.fromString(XMPPError.java:414 )

at org.jivesoftware.smack.sm.provider.ParseStreamManagement.failed(ParseStreamMana gement.java:56)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPC onnection.java:1130)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPCon nection.java:980)

at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnecti on.java:996)

at java.lang.Thread.run(Thread.java:818)

We are unable to recognize the exception to perform any further action. For creating a new session when previous session has been expired, we should get a specified stream resumption error from smack.

Strictly speaking the XML which is sent by ejabbered is not conform to the specification.

It includes a text element, which is neither described in XEP-0198 (Stream Management) nor specified in its XML schema, which only references the “stanzaErrorGroup”, but not the text element:

<xs:element name=‘failed’>
<xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas’
<xs:group ref=‘err:stanzaErrorGroup’/>
<xs:attribute name='h’

I think Smack is correct here, although it probably should simply ignore unknown elements (here: text), so that you get the resumption failure.

I think Smack is correct here
There is a recent opinion within the XMPP community that schemas do not restrict the existence of things they don’t describe. They only impose restrictions on things they describe. I share that opinion.

Thus this will likely get fixed in Smack 4.2.1.

Hm, I recall, there was a similar discussion here:

Seems to bug while parsing presense stanzas - Smack 4.1.0-rc4

The value “online” is not described, so it may exist?

In both cases I think the “online” show-value and the text element should be ignored by clients, due to:

Clients are advised not to rely on the ability to send data that does not conform to the schemas, and SHOULD ignore any non-conformant elements or attributes on the incoming XML stream.

and XEP-0198 should get clear about the usage of the text element.

1 Like

Hm, I recall, there was a similar discussion here:

Seems to bug while parsing presense stanzas - Smack 4.1.0-rc4

The value “online” is not described, so it may exist?

I don’t think that this is a similar case. The RFC is pretty clear on which values the element can carry.

The XML character data MUST be one of the following (additional availability states could be defined through extended content elements):

  • away – The entity or resource is temporarily away.
  • chat – The entity or resource is actively interested in chatting.
  • dnd – The entity or resource is busy (dnd = “Do Not Disturb”).
  • xa – The entity or resource is away for an extended period (xa = “eXtended Away”).

Created [SMACK-760] Smack does not allow custom extension elements in SM’s - IgniteRealtime JIRA to track this.

Hi Flow,

One more thing related to this is i am getting ‘No response received within reply timeout’ for login request. After reply timeout(20 second in my case), getting the ‘text’ parsing error. I think, it should immediately return exception related to stream resumption after getting ‘previous session timeout’ error from server.