MUC joining issue on

When I had already entered the multi-user chat in this instance from Android application and it began to load the list of users with presence, a rather strange problem arose with parsing replies and at that moment the connection was interrupted.

I have no idea what is special about Smack’s MUC feature (or maybe custom QIP client presence), since this instance caused an parsing error.

  • Smack ver. 4.4.0 (Gradle)
  • Full exception in file and first screenshot.


UPD: I tried with Smack 4.4.6, nothing has changed.

I don’t think we see the exception that was thrown during parsing in the screenshot. I think the NotConnectedException is probably a consequence the previous parsing exception.

Only the parsing exception will tell us what caused it.

I think the NotConnectedException is probably a consequence the previous parsing exception

The only catch is that Smack displays this exception in the logs, which led to the disconnection.

mucm = MultiUserChatManager.getInstanceFor(
); // <-- ok
muc = mucm.getMultiUserChat(JidCreate.entityBareFrom((String) id)); // <-- ok
muc.join(Resourcepart.from(nickname)); //<-- disconnected due to parsing error and throwing NotConnectedException
// origin of exception, no specifics
Caused by: java.lang.NumberFormatException: Value out of range. Value:"128" Radix:10
at java.lang.Byte.parseByte(
at java.lang.Byte.valueOf(
at java.lang.Byte.valueOf(
at org.jivesoftware.smack.util.ParserUtils.getByteAttributeFromNextText(
at org.jivesoftware.smack.util.PacketParserUtils.parsePresence(
at org.jivesoftware.smack.util.PacketParserUtils.parseStanza(
at org.jivesoftware.smack.AbstractXMPPConnection.parseAndProcessStanza(
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1000( 
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets( 
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$700( 
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$ 

For detailed debugging, it may be necessary to monitor stanzas entering the client input.

Not sure if I understand, but the original exception should either be logged and/or thrown. I am pretty sure it is made available to the “user”. If not, then this is something that should be fixed in Smack. How did you obtain the exception below?

I am pretty sure that this is caused by a presence stanza with an invalid priority value (128).

  1. I logged into my account, which is located in the instance.
  2. I checked the list of chatrooms in the services provided by the instance.
  3. I joined to the chatroom.
  4. At the entrance, Smack receives an incorrect priority number in the occupations’ presences and disconnects at this point.


The screenshot that’s provided in the first post in this thread shows that a <priority>128</priority> is being sent.

This is an invalid value. The value MUST be an integer between -128 and +127, as specified here: RFC 6121 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence

It appears that someone is sending an invalid presence stanza to a chatroom, and the server on is not rejecting this, but instead broadcasts it.

It may be worth setting Stanzas processing to a correct priority value if initially this priority number is outside this range?

The problem here isn’t Smack. It is strict in what it accepts, but the data that it gets to parse is obviously invalid. There’s a valid argument to be made for Smack to simply drop data that is invalid, and that’s the design choice that was made here.

This topic was automatically closed 62 days after the last reply. New replies are no longer allowed.