powered by Jive Software

Compression enabled: more harm than benefit


since recently we had a lot of problems with our XMPP client.

There were a lot of connection losses (triggering the reconnection manager) and lot of exceptions in the log, similar to:

org.xmlpull.v1.XmlPullParserException: expected = after attribute name (position: END_TAG seen …y>

In the Openfire log we had many exceptions as well:

org.jivesoftware.openfire.IQRouter - Error or result packet could not be delivered

Approximately every second login failed and generally the connection was very unstable.

After some research, it turned out, that compression had been enabled for Smack recently:


So, I reverted this change, and everything went fine again.

I am not sure, if this is a Smack or Openfire problem, but maybe somebody had similar issues or comments!?

(Using Smack 3.3.1 on Windows 7 with Java 7)

Same here. Major headaches with XmlPullParserException that suddenly went away after disabling compression on the server and/or clients.

I’m so glad I found your message, it pointed me in the right direction.


Smack supports zlib compression either by javax’s deflate APIs or by jzlilb. I never had problems with both of them, as we first used jzlib on Android and then switched over to the deflate APIs. It could be possible that those have broken implementations, so you guys could try to use jzlib for compression.

Do you think, this is more likely an Openfire bug rather than Smack?

I saw this OF-471, which looks like it might cause the problems.

Can I tell Smack to explicitly use jzlib for testing purposes?

If I had to guess, I would suspect this to be a problem originating in Smack.

You can configure Smack to use jzlib as CompressionHandler. But how this is done depends on your used Smack version. And the API was not designed so that users can easily modify the compression handlers (which I may change in the future).

Have a look at SmackConfiguration and how the compressionHandlers list is initialized.