Avoid dependency on JZlib about protobuf-rpc-pro

[GoogleCodeExporter]

Original comment by [email protected] on 19 Jun 2013 at 5:03

• Changed state: Accepted

[GoogleCodeExporter]

i agree that deps should be kept to a minimum - and this could be removed.

Original comment by [email protected] on 19 Jun 2013 at 5:04

[GoogleCodeExporter]

I don't see a possibility using Netty to NOT use  JZlib for decompression.

See 
io.netty.handler.codec.compression.JZlibDecoder.<init>(JZlibDecoder.java:26) 
~[netty-all-4.0.0.CR5.jar:na]

There's no JDK alternative for decompression like there is for compression. 
Maybe i'm just stupid - what do you think? Is Netty needing to provide 
something here first?

Original comment by [email protected] on 19 Jun 2013 at 6:08

[GoogleCodeExporter]

I see your point about Netty not providing a JdkZlibDecoder.  

This is clearly seen from their factory:
http://netty.io/4.0/xref/io/netty/handler/codec/compression/ZlibCodecFactory.htm
l

I would have been nice with just a small comment in that file as to why.  :-(

I'll try to ask some questions to Netty people. Let's put this one on hold for 
now.

Original comment by [email protected] on 23 Jun 2013 at 11:13

[GoogleCodeExporter]

The issue is now logged with Netty team as:
https://github.com/netty/netty/issues/1481

Tentatively accepted for Netty 4.1.

Original comment by [email protected] on 26 Jun 2013 at 9:51

[GoogleCodeExporter]

The Netty people outdid themselves on this one. It was implemented in Netty 
v4.0.8 and further bug-fixed in Netty v4.0.9. It means the protobuf-rpc-pro 
library can finally get rid of the JZlib dependency.

Note that Netty still supports JZlib implementation but you would have to 
actively choose it as the JDK zlib encode/decode is now the default.

Original comment by [email protected] on 6 Sep 2013 at 5:09

[GoogleCodeExporter]

I took netty 4.0.9 and replaced 1:1 the ZLibEncoder/Decoder with the JDK 
"equivalent". Unfortunately i think there is still a bug in the netty 
implementation somewhere - since the client/server tests hang after a few 
messages have been exchanged. It looks like the server expects more bytes to be 
incoming which the client doesnt send. I couldnt find anything on the netty doc 
to think that the encoder/decoder would be used any differently than the JLib 
equivalent. 

Can you do some investigation here - or should i just raise an incident against 
netty?

Original comment by [email protected] on 16 Sep 2013 at 7:32

[GoogleCodeExporter]

Sorry for long reply on this one. Yes I believe the two implementations are 
interchangable. Indeed you can have a look at 
https://github.com/netty/netty/blob/master/codec/src/main/java/io/netty/handler/
codec/compression/ZlibCodecFactory.java. 

What is a bit interesting here is that - as far as I can tell from the above 
code - is that if you get your Decoder from this factory then you actually 
ACTIVELY have to set system property 'io.netty.noJdkZlibDecoder' to false to 
get the JDK decoder even if using Java 7. I don't know what the thinking behind 
that is. Perhaps they believe that the JDK Decoder is still not tested enough 
to be the default one?

Original comment by [email protected] on 28 Sep 2013 at 6:27

[GoogleCodeExporter]

Further to my comments. I found this commit message in Netty code: "Disable 
usage of JdkZlibDecoder by default, will be enabled in 4.1.0.Final".
(this is the 'io.netty.noJdkZlibDecoder' system property)

Original comment by [email protected] on 28 Sep 2013 at 6:33

[GoogleCodeExporter]

I've made an open issue with Netty because their JDK compression alternative 
doesn't quite work just yet. 

https://github.com/netty/netty/issues/1893

Nevertheless i've made the JZLib dependency also optional in protobuf-rpc-pro 
to "match" how they do it in netty, and use now the "ZlibCodecFactory" to 
create the handlers. So you can start to switch (using system property etc) 
between either at your leisure.

Fixed with 3.0.8.

Original comment by [email protected] on 6 Oct 2013 at 4:18

• Changed state: Fixed

[GoogleCodeExporter]

Splendid!

Original comment by [email protected] on 7 Oct 2013 at 8:49

[GoogleCodeExporter]

The Netty guys say the've made a fix for 4.0.11.

Original comment by [email protected] on 12 Oct 2013 at 9:38