Netty 3.x to 4.0 porting

[Arnab Biswas]

Hi,

I am porting a Netty based application from Netty 3.x to 4.x. I have few questions :

1. As per this answer in SO, sslHandler.setEnableRenegotiation (in 3.x) should be replaced with "-Djdk.tls.rejectClientInitiatedRenegotiation". But in our product, we have four interfaces (ServerBootstrap) within the same JVM process. SSL renegotiation may not be enabled on all the interfaces, hence depending on the same system property may not work here. Any suggestion?

2. In Netty 4.x, WriteTimeoutHandler, ReadTimeoutHandler and IdleStateHandler does not accept Timer any more. In Netty 3.x version of our product, we used use HashedWheelTimer with these handlers. Is there any way to integrate WriteTimeoutHandler (or others) & HashedWheelTimer OR it's just not needed in Netty 4?

3. In Netty 3 we used to use OrderedMemoryAwareThreadPoolExecutor. 

             pipeline.addLast("NorthBoundExecutionHandler", new ExecutionHandler(

          new OrderedMemoryAwareThreadPoolExecutor(100, 0, 10485760, 

          60000L, TimeUnit.MILLISECONDS, customThreadFactory)));

             pipeline.addLast("NorthBoundRequestHandler", new NbApiRequestHandler());

             pipeline.addLast("NorthBoundBadRequestHandler", new HttpBadRequestHandler());

   In Netty 4, I have replaced, it with DefaultEventExecutorGroup :

    EventExecutorGroup executorGroup = new DefaultEventExecutorGroup(

                          100, customThreadFactory);

                pipeline.addLast(executorGroup, "NorthBoundRequestHandler", new NbApiRequestHandler());

                pipeline.addLast(executorGroup, "NorthBoundBadRequestHandler", new HttpBadRequestHandler());

Since I am using same instance of DefaultEventExecutorGroup for both the handlers, I am assuming that ordering of the events across multiple handlers on per channel basis is taken care (The job OrderedMemoryAwareThreadPoolExecutor used to do). Please confirm if my assumption is correct. 

4. For Junit test cases, I am using EmbeddedChannel along with IdleStateHandler. As per this thread, this doesn't work. I am trying to find out sample usage of LocalChannel for Junits but I have not been able to. Any pointer will be appreciated.

EmbeddedChannel embedder = new EmbeddedChannel(

           new SessionContextHandler(),

           new IdleStateHandler(0, 0, 1000, TimeUnit.MILLISECONDS),

           handler, new MockChannelFutureHandler(true)); 

Please let me know your thoughts.

Thanks,

Arnab

[Norman Maurer]

Comments inline…

On 24 May 2016, at 16:16, Arnab Biswas <arnabb...@gmail.com> wrote:

Hi,

I am porting a Netty based application from Netty 3.x to 4.x. I have few questions :

1. As per this answer in SO, sslHandler.setEnableRenegotiation (in 3.x) should be replaced with "-Djdk.tls.rejectClientInitiatedRenegotiation". But in our product, we have four interfaces (ServerBootstrap) within the same JVM process. SSL renegotiation may not be enabled on all the interfaces, hence depending on the same system property may not work here. Any suggestion?

I think there is not much else we can do as this is the only thing that recent java allow us to do.

2. In Netty 4.x, WriteTimeoutHandler, ReadTimeoutHandler and IdleStateHandler does not accept Timer any more. In Netty 3.x version of our product, we used use HashedWheelTimer with these handlers. Is there any way to integrate WriteTimeoutHandler (or others) & HashedWheelTimer OR it's just not needed in Netty 4?

You just not need a Timer anymore for these handlers as these will just use the EventExecutor that is tied to the ChannelHandlerContext.

3. In Netty 3 we used to use OrderedMemoryAwareThreadPoolExecutor. 

             pipeline.addLast("NorthBoundExecutionHandler", new ExecutionHandler(

          new OrderedMemoryAwareThreadPoolExecutor(100, 0, 10485760, 

          60000L, TimeUnit.MILLISECONDS, customThreadFactory)));

             pipeline.addLast("NorthBoundRequestHandler", new NbApiRequestHandler());

             pipeline.addLast("NorthBoundBadRequestHandler", new HttpBadRequestHandler());

   In Netty 4, I have replaced, it with DefaultEventExecutorGroup :

    EventExecutorGroup executorGroup = new DefaultEventExecutorGroup(

                          100, customThreadFactory);

                pipeline.addLast(executorGroup, "NorthBoundRequestHandler", new NbApiRequestHandler());

                pipeline.addLast(executorGroup, "NorthBoundBadRequestHandler", new HttpBadRequestHandler());

Since I am using same instance of DefaultEventExecutorGroup for both the handlers, I am assuming that ordering of the events across multiple handlers on per channel basis is taken care (The job OrderedMemoryAwareThreadPoolExecutor used to do). Please confirm if my assumption is correct. 

Correct.

4. For Junit test cases, I am using EmbeddedChannel along with IdleStateHandler. As per this thread, this doesn't work. I am trying to find out sample usage of LocalChannel for Junits but I have not been able to. Any pointer will be appreciated.

EmbeddedChannel embedder = new EmbeddedChannel(

           new SessionContextHandler(),

           new IdleStateHandler(0, 0, 1000, TimeUnit.MILLISECONDS),

           handler, new MockChannelFutureHandler(true)); 

Maybe this helps:

https://github.com/netty/netty/blob/4.0/transport/src/test/java/io/netty/channel/local/LocalChannelTest.java

Please let me know your thoughts.

Thanks,

Arnab

Bye

Norman

--
You received this message because you are subscribed to the Google Groups "Netty discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netty+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netty/CAOG5%2B9%3DkPrBArBJkXLs6MJYoFDZWAn1JW%3D2KsRSS62-h%3DhGGhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Arnab Biswas]

Thanks Norman!

Arnab

To view this discussion on the web visit https://groups.google.com/d/msgid/netty/F572326D-7002-40B6-B4A0-D7BDABDE83DE%40googlemail.com.

[Arnab Biswas]

Hi Norman,

One more question! According to "Netty In Action" : 

1. Bootstrap.option() : Sets a ChannelOption to apply to the ChannelConfig of a newly created Channel. These options will be set on the Channel by bind() or connect(), whichever is called first. This method has no effect after Channel creation.

2. ServerBootstrap.option() : Specifies a ChannelOption to apply to the ChannelConfig of a newly created ServerChannel. Those options will be set on the Channel by bind() or connect(), depending on which is called first. Setting or changing a ChannelOption after those methods have been called has no effect.

Here are my understanding/questions :

a) #1 gives an impression that after bind()/connect(), invoking Bootstrap.option() does not have any impact on ChannelConfig of the created channel. Does ChannelConfig.setOption() or ChannelConfig.setOptions() has any impact on ChannelConfig after boot()/connect()?

b) #2 gives an impression that bind()/connect(), ChannelConfig can't be modified for a server channel using ChannelConfig.setOption() or using ServerBootstrap.option().

c) Is #b applicable for ServerBootstrap.childOption() as well? 

d) If #a, #b, #c are true, i.e. the ChannelConfig can't be changed once created (through BootStrap or ServerBootstrap -> boot()/connect()), then what is the use of ChannelConfig.setOption() or ChannelConfig.setOptions()?

Please let me know your thoughts.

Thanks,

Arnab

On Tue, May 24, 2016 at 10:09 PM, 'Norman Maurer' via Netty discussions <ne...@googlegroups.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/netty/F572326D-7002-40B6-B4A0-D7BDABDE83DE%40googlemail.com.

[Norman Maurer]

Comments inline….

On 25 May 2016, at 07:31, Arnab Biswas <arnabb...@gmail.com> wrote:

Hi Norman,

One more question! According to "Netty In Action" : 

1. Bootstrap.option() : Sets a ChannelOption to apply to the ChannelConfig of a newly created Channel. These options will be set on the Channel by bind() or connect(), whichever is called first. This method has no effect after Channel creation.

yes… Actually it is done during registration of the channel.

2. ServerBootstrap.option() : Specifies a ChannelOption to apply to the ChannelConfig of a newly created ServerChannel. Those options will be set on the Channel by bind() or connect(), depending on which is called first. Setting or changing a ChannelOption after those methods have been called has no effect.

Actually this is an error in the book I would say. See above.

Here are my understanding/questions :

a) #1 gives an impression that after bind()/connect(), invoking Bootstrap.option() does not have any impact on ChannelConfig of the created channel. Does ChannelConfig.setOption() or ChannelConfig.setOptions() has any impact on ChannelConfig after boot()/connect()?

Yes if you call ChannelConfig.setOption(…) will change something for the Channel that belongs to it.

b) #2 gives an impression that bind()/connect(), ChannelConfig can't be modified for a server channel using ChannelConfig.setOption() or using ServerBootstrap.option().

It can...

c) Is #b applicable for ServerBootstrap.childOption() as well? 

Like I said no..

d) If #a, #b, #c are true, i.e. the ChannelConfig can't be changed once created (through BootStrap or ServerBootstrap -> boot()/connect()), then what is the use of ChannelConfig.setOption() or ChannelConfig.setOptions()?

See above.

To view this discussion on the web visit https://groups.google.com/d/msgid/netty/CAOG5%2B9%3D4jZGU16Mv_c8OvBQSK6B%2BPKhbUrYDfhe-JQp%3D3XuDtg%40mail.gmail.com.

[Arnab Biswas]

Thanks Norman!

Just to summarize (to make sure that I am not missing things in between), be it server channel or client channel, ChannelConfig.setOption() or ChannelConfig.setOptions() will modify the ChannelConfig even after BootStrap/BootStrap connect()/bind().

Thanks,

Arnab

To view this discussion on the web visit https://groups.google.com/d/msgid/netty/A7AF416B-C6FA-440E-848A-24D2DEEBF31A%40googlemail.com.

[Norman Maurer]

Yes.

To view this discussion on the web visit https://groups.google.com/d/msgid/netty/CAOG5%2B9%3DdH7ZKwgsdSVZ-EHLsMWwbvkyM00LawRyDPQw-isB%2BUQ%40mail.gmail.com.