Compression broken in Openfire 3.6.0

Hi, is it possible that the compression is broken in ´Verison 3.6.0?

I fond the following behaviour:

When i tried to connect to the ingiterealtime community-chat the connection to my server was closed.

I used psi 0.12 and turned compression in psi and openfire on

When i tried to connect to my server with spark 2.5.8 the first attempt to connect failed - the second attempt worked.

If i switch off compression all is working fine :slight_smile:

My error-log is attatched.
error.log (463377 Bytes)

Yes, I think compression has not been working for quite some time. We offer a mobile IM client to our customers and just now that we wanted to implement compression into our client discovered that compression does not work.

Our client is using the same jzlib library that Openfire is using. Sometimes connection does work, but more often, especially on connect and with a large roster we receive an exception from jzlib

com.jcraft.jzlib.ZStreamException: inflating: invalid stored block lengths

Somehow Openfire seems to create invalid zlib compressed data.

The same happens with Psi-0.12 and Spark.

This seems to be covered by JM-1115 in the issues database and is open since 09/12/07. It’s actually a pity that such an important feature is being neglected…

We have tried fixing it ourselves but have not succeeded so far. Openfire seems to simply open a ZOutputStream and ZInputStream and writing to/reading from it instead of writing/reading directly to/from a SocketInputStream. Nothing magic, so there does not seem to be a place where corruption of the data should happen?

Hello Hendrik,

according to Gaston Domiak the Jive team was not able to reproduce the bug. Are you able to reproduce the error ? I do see the same in our company installation and really would like to get that one gone before we put 20.000 users on it.

Kind regards,

Walter (also located in Hamburg)

Hey guys,

If you found a way to consistently reproduce this problem just let me know and I can take it from there.


– Gato

We are not really able to constantly reproduce this error.

What I have observerd so far is that it usually happens during logon of an account. When the error happens once I can usually reproduce it right away by logging in again several times in a row. During other times though the error would not happen even when trying to force it by logging in several times.

I therefore assume it somehow depends on the presence of one or more of the contacts on the user’s roster.

I will try to instrument the ZLib.deflate function to see how the buffer looks like that triggers the exception and report back as soon as I find something.

I added instrumentation to MINA’s file and right after starting Openfire the error occurred again. There was nothing suspicious about the buffer that triggered the exception. Every buffer after that one triggered another exception. So I assume it is not a problem with the buffer itself but that the state of the compressor is being corrupted.

I also noticed that my instrumentation logs (output to StdErr > nohup.out) was outputting the exceptions intermixed. I am not very fit neither with MINA nor with Openfire’s networking core but could it be that the same Zlib instance is being called from multiple threads? This would also explain why this bug is so hard to track down.

I added a ‘synchronized’ to Zlib’s deflate method declaration and have not experienced the error since two days now.

Now running on production server for more than 10 days without any further problems.

So the fix to seems to be as simple as adding ‘synchronized’ to MINA’s Zlib.deflate method.

— C:\develop\instango\openfire_src\mina\mina-1.1.7\filter-compression\src\main\ja va\org\apache\mina\filter\support\ Sat Apr 19 14:32:28 2008 UTC
+++ C:\develop\instango\openfire_src\mina\mina-1.1.7\filter-compression\src\main\ja va\org\apache\mina\filter\support\ Tue Oct 14 18:38:08 2008 UTC
@@ -152,7 +152,7 @@
* released manually.
* @throws IOException if the compression of teh buffer failed for some reason

  • public ByteBuffer deflate(ByteBuffer inBuffer) throws IOException {
  • synchronized public ByteBuffer deflate(ByteBuffer inBuffer) throws IOException {
    if (mode == MODE_INFLATER) {
    throw new IllegalStateException(“not initialized as DEFLATER”);

Can anybody confirm this?

Hey Henrik,

Excellent finding. I will analyze and give the fix a test. I will also post it in the MINA mailing list.


– Gato