[OF-471]
Created: 09/07/11 Updated: 07/07/14 Resolved:
04/28/14
Status: Resolved
Project: Openfire
Component/s: Core
Affects
Version/s:
3.7.1
Fix Version/s: 3.9.2
Type: Bug
Reporter: Alexandr Kondratenko
Resolution: Duplicate
None Labels:
Attachments:
Description
Priority:
Votes:
Assignee: openfire_compression_consistency.patch
Major
Tom Evans
0
Packets from server to client can be sent in wrong order, or even can be corrupted if too many
(50-100) users at the same time send message (or any other packet type) to the same user.
This issue reproduces only if compression is active.
As I understand, compressed stream integrity may be compromised (multiple threads tries to send packets simultaneously), and as a result, client after decompression will have invalid data
(often even invalid xml structure, mixed from two or more packets in a random way).
In attached file I made quick fix. It works fine for me, and I think should help in writing more right solution.
Comments
Comment by Guus der Kinderen
[ 09/20/11 ]
Hello Alexandr,
Thank you for identifying and addressing this bug!
I am a little concerned about one aspect of your fix: there appears to be a lot of locking going on. I'm wondering how this will affect performance on a high-volume domain.
The patched code affects all session objects - even those that are not using compression. The mutex that you use locks quite a bit of call references - I'm concerned that this might be to much and will cause high-volume servers to grind to a halt. Then again, the mutex is the local session only... Did you do some kind of performance tests?
Can you explain how this locking prevents the problem from occurring? Or, put differently: what is the root cause of the problem in the first place? Perhaps this problem can be fixed in compression-specific code, rather than in the higher-level session code. If something like that

would be possible, it'd be preferable - as any performance hit will be limited to sessions that use compression only (and we will have less chance on unwanted side-effects).
What are your thoughts on this? Would you care to dig a little deeper?
Comment by Alexandr Kondratenko
[ 09/21/11 ]
Hello Guus der Kinderen,
That was only quickfix, not general solution. My tests (about 300 users in one room that was chatting) have not showed big difference in performance. And actually I don't think, that difference can be really significant.
I found, that actually this is not an issue of openfire server. Rather - mina's compression filter issue.
We have issue very looks like https://issues.apache.org/jira/browse/DIRMINA-653 .
So, when we use mutex on session write - no any problems.
Mina's fix based on the same idea - mutex lock for compression (data processing).
So, I think we have to use new library for compression filter to fix this issue.
Comment by Tom Evans
[ 10/25/12 ]
I believe this may be a duplicate of .
Comment by Guus der Kinderen
[ 02/06/13 ]
Removing the 'fix version' for all unresolved issues that were scheduled for version 7.8.2. We're releasing this version today - the remaining issues should be rescheduled later.
Comment by Daryl Herzmann
[ 02/13/14 ]
Is this issue still happening on a current release (3.9.1)?
Comment by Daryl Herzmann
[ 04/27/14 ]
Hi Tom, you still think this is a duplicate of ? Perhaps we can close it then.
Comment by Tom Evans
[ 04/28/14 ]
Closing as duplicate; assume the MINA synchronization-related compression issue(s) is/are resolved.
Comment by Brian Clements
[ 07/07/14 ]
I still have this issue on 3.9.3. It only happens when compression is on and there is a lot of activity. The application I'm using openfire for sends packet extensions with a wide range of sizes (the largest being 16KB). When there are many packets being sent, the clients get disconnected with a stream corruption error.
Generated at Tue Feb 09 20:25:58 CST 2016 using JIRA 7.0.10#70120sha1:37e3d7a6fc4d580639533e7f7c232c925e554a6a.