Hi Doychin, Thank you for looking into this problem. "doychin" wrote : | The problem comes from some extra bytes put in the output stream from compression and not read from decompression. | Comparing the version of CompressingMarshaller on the 2.2 branch (from which release 2.2.2.SP8 was derived) with the version on the 2.x branch (from which 2.4/2.5 releases are derived) I see that there's a problem which I fixed only on the 2.x branch. In particular, CompressingMarshaller.write() ends | gzos.finish(); | oos.flush(); | on the 2.2 branch and it ends | oos.flush(); | bos.flush(); | gzos.flush(); | gzos.finish(); | on the 2.x branch. I suspect that calling gzos.finish() before oos.flush() is what leaves extra bytes unwritten. Could you try running with the 2.x version and see if that fixes the problem? "doychin" wrote : | Also another problem I found with current solution is that it leaks lots of memory when it is used to transfer big amounts of data for short period of time. The reason is that GZip streams depend on some native code routines in JVM and to release the resources used by these routines streams depend on the garbage collector to call their finalize methods. | I did not know that. I see that David Lloyd made a suggestion on thread "Compression marshalling" (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=134557&a...). Perhaps his suggestion is directed at this issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4199010#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...