the problem is simple. the flush-function of the std. GZIPOutputStream isnt working. it simply doesnt do anything if i call it (i guess it has its own buffer, and writes the compressed data only if that buffer is full, so the flush, which is directly passed the super OutputStream has no chance to "flush" the data).
there is already a bug-report, and it will be (hopefully) fixed with java7, but at the moment (java6) i cant find a way to get that working.
i've already tried jzlib and jazzlib, where both of them are re-implementations of the original GZIP-In/Out-putStream, but i cant get them working.
the jazzlib just does exactly what the original does - nothing oO
the jzlib throws me an exception on startup ...
so i dont know if im doing something wrong (false init / call of some functions) or if it is simply not possible before java7?
btw - i sadly have some reasons why i cant wait to java7 and need to get this work on java6 :(
hope someone can help me here.
What you expected? Why you need a flush()?
On my usage of the GZIPOutputStream it writes chunks to the underlaying stream. If you are finish then you call close().
The bug report exist since 2003 and has only 11 votes. I think not that this will fix in Java 7.
Well - i expect the same functionallity as from Outputstream, so that if im writting data, and want to flush them, that these data really will be send, and not that my call to the flush-function will simply be ignored.
i need this because i want to send many data-packets, like "authentication package". if this package will not be flushed, the server / client waits endless time for the answer.
but on the other hand, i want to save traffic, because i want to send -really- many packets.
but never mind - i already solved this problem by overriding the flush function, "deactivating" the compression, filling up with 0's and reactivating the compression again.. this is not really good / performant, i know, but at least i can use flush.
and by the way - i installed the java7 jdk (which is still unstable as i had to experience, or eclipse is just not ready for it, however eclipse freezes after ~ 5 mins using it), looked in the source-codes and saw that the GZIPOutputStream will have additional constructor-parameters, which will be passed through to native functions. so it WILL BE fixed in Java7
but thanks for your answer anyway,
If you have finish a packed then a flush will not help. You need to close the stream. A zip stream is not a linear stream where you can flush on a random place. If you not close the stream the client can not read completely hand will hang.
Your eclipse problem sound like known memory problem. Because Oracle has change the vendor from Sun to Oracle that Eclipse can not detect Java VM. By default Eclipse use more max perm memory for the Sun VM. Use the switch -XX:MaxPermSize=128m
More can you find with Google.
But Java 7 will not be available before 2012. This is Oracle new time frame.
hmm... sounds somehow creepy...
just why has gzipoutputstream then the flush function, if it ignores it, and do not flush my data?
the bad thing is, that i cant just close the stream, because i want to be able to send more packets... finishing the stream would work, but to be able to send another packet i would have to make a new gzipoutputstream with the still open underlaying outputstream... thats really weird... and i guess its also quite slow..
anyway, the workaround i found works quite good, its doing his job, if anyone has a better way of doing it, please tell me.
and thanks for explaining the eclipse-bug. but i still prefer to wait until java7 is really out, not trying with betas or something ^^