users@grizzly.java.net

Re: Grizzly 2.0 .unbind() , threads and filter chain

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 12 May 2009 18:02:59 +0200

Hi,
>
>
> I am starting to using Grizzly 2.0 and I have few questions.
>
> First, I see TCPNIOTransport.bind ... but where is .unbind() ? Do I
> really have to do transport.close every time I want to unbind ? In
> that case what about my other connections and binding ? :(
Just added Transport.unbind() :)


> Or maybe for every new binding I should get new transport
> TransportFactory.getInstance.createTCPTransport ??
No.

> Does every new TcpNioTransport needs at least one thread for
> Selector ?
Each selector runner has to have own thread.

> I also see that whole transport has its own filter chain, but what
> about connections ? Why we can not have personalized filter chains
> for every connection ? (for example one connection can be a
> streaming, other can be messages based).
Who said we can not have it personalized? :)
connection.setProcessor(....);


> What I do is to use as low threads for Grizzly as it can be because
> sending out every event to Scala Actors world and process it there.
> I am using tcpNioTransport.setStrategy( new SameThreadStrategy ) and
> tcpNioTransport
> .setWorkerThreadPool( Executors.newSingleThreadExecutor ) ... but
> can I use this one executor (Executors.newSingleThreadExecutor) to
> all TcpNioTransports if I have to create new TcpNioTransport for
> every local binding ???
You can set common ExecutorService to
TransportFactory.getInstance().setDefaultWorkerThreadPool(...), and
all Transports, which will be initialized from that Factory will share
same ThreadPool.

> I want to hear what is best practice :
> - how to open many local bindings and many connections
if you want to use several bindings at the same time - you need to
create a transport for each one.
Client connections could be associated with any Transport.

>
> - always have a possibility to unbind local port and
done.

>
> - keep whole Grizzly use only one thread (just one is required for
> Selector)
that's possible (see above).

Thank you for feedback!

WBR,
Alexey.

>
>
> Thank you for your help and time,
> Arthur.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>