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.
Environment
None
Attachments
1
Activity
Show:
brian@clementscode.com July 7, 2014 at 3:54 PM
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.
Tom Evans April 28, 2014 at 4:57 PM
Closing as duplicate; assume the MINA synchronization-related compression issue(s) is/are resolved.
Daryl Herzmann April 27, 2014 at 5:22 PM
Hi Tom, you still think this is a duplicate of OF-567? Perhaps we can close it then.
Daryl Herzmann February 13, 2014 at 9:56 PM
Is this issue still happening on a current release (3.9.1)?
Guus der Kinderen February 6, 2013 at 7:57 PM
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.
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.