dev@grizzly.java.net

Re: moving to grizzly 2.x

From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Date: Thu, 29 Sep 2011 08:39:14 -0700

Hi Tigran,

> we started to evaluate migration of our code from 1.9.x to 2.x.
> While new filter implementation looks like more natural some
> low-level functionality get lost or become more difficult to use.
>
>
> in org.glassfish.grizzly.SocketBinder
>
> bind(String host, PortRange portRange, int backlog)
>
> takes String hostname as argument. This makes impossible to bind to any
> interface. InetAddress instead of String will probably more useful.
Have you tried "0.0.0.0"? Pls. file an issue - we'll fix it asap.

> We run our service on tcp and udp connections at the same time.
> with grizzly 1.9 it's easy to do:
>
>
> final Controller controller = new Controller();
> ...
> controller.addSelectorHandler(udp_handler);
> controller.addSelectorHandler(tcp_handler);
> ...
> controller.start();
>
> I cant find any similar way in 2.x.
You need to start TCP and UDP transports separately.

> org.glassfish.grizzly.Transport does not have a reliable way to
> find out underling protocol ( well, instanceof is not a best way to go).
Hmm... Can you pls. share your code related to this problem? Pretty sure
we can find solution for it.

> if I did not get complete message in handleRead(FilterChainContext
> ctx) will grizzly append incoming bytes to the existing bytes and
> extend internal buffer if required?
If you return ctx.getStopAction(incompleteBuffer); then next time
handleRead is invoked, the message Buffer represents aggregated Buffer
(CompositeBuffer), which contains the incompleteBuffer + newDataBuffer.

>
> And the last point - it looks like I got a 10% performance increase
> with 2.1.3 over 1.9.19.
Sounds good :))

If you need more info - just let us know.

Thanks.

WBR,
Alexey.

>
> Thanks,
> Tigran.
>