-
I found the cause of the issue.
In ZLibWrapper.compress, this loop:
while ( !compresser.needsInput()) { result_arr = deflate(result_arr); }
is executed just once (accumulating 512 bytes of compressed data). After that, you can find this:
result_arr = deflate(result_arr);
which puts another 512 bytes to the output buffer. But then nothing. The remaining 30 bytes are lost. Well, not forever though: they will be sent with the next packet.
-
This resize is done only for buffer of data which are after compression but before they are written to socket, so there is no need for protection as this compressed data is in fact serialized and compressed stanza which needs to be send by server and not received by server. Also this output buffer is just array of bytes and is not cached anywhere so it will be released when data is sent by server.
Type |
Bug
|
Priority |
Major
|
Assignee | |
RedmineID |
2632
|
Spent time |
0
|
Issue Votes (0)
Watchers (0)
Sometimes during a compressed TLS stream I got stuck receiving data from the client. The situation unlocks only when new data must be sent to the socket.
I've tested the packet with Deflater, compressed size should be 1054 bytes, however only 1024 bytes get through.
What do you think?