dev@grizzly.java.net

Re: wired idea :)

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Wed, 28 Jan 2009 14:42:12 -0500

Salut,

rama wrote:
> Hello :D
>
> i have a bad piece of code, and i need some idea to move it to grizzly.
>
>
> the code basically work like this
>
>
> sock = ss.accept();
> String msg = sock.read.blablalba;
>
> if ("cd".equals(msg))
> new thread1(sock);
> if ("bla".equals(msg))
> new thread2(sock)
>
> and so on...
>
>
> suppose that thread1 need to be blocking and do
> sock.read
> blabla
> sock.write
>
> with blocking (means that he will wait for a connection indefinetly)
>
>
> the thread2 will do the same, but the difference is
> that i expect only 2 threads(1) and many thread(2).
>
> for this reason thread2 could be reduced to a pool of worker, using
> nonblocking,
> while thread1 could stay the same.
>
> Can grizzly help me in some way?
>
>
> The easy solution that come into my mind is to split the problem in 2
> part
>
> 1) thread1 will listen on port X
> 2) thread2 will listen on port X+1
>
> Thread1 will use the normal thread on connection approach
> while thread2 will use nio (with grizzly) approach.

Why not using a blocking approach on top of Grizzly NIO?
InputReader/OutputWriter are blocking I/O utilities:

https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/util/InputReader.html
https://grizzly.dev.java.net/nonav/apidocs/com/sun/grizzly/util/OutputWriter.html


>
> But with this impl i need to change a lot of stuff, and probably i can
> do it a bit better.
>
> The second idea, that i want to share with you, is
> when a socket go to thread1, it's managed with blocking read/write
> when a socket go to thread2, it's added to a pool of connection, set as
> nonblocking, and then managed in this way.
> can i use grizzly to achive this result?

Yes you can do that by adding a ProtocolFilter that can read somes bytes
and decide which thread pool to use. Or better, you can use grizzly-rcm
modules. What this modules does is described here:

http://weblogs.java.net/blog/jfarcand/archive/2008/10/preventing_rogu.html

Mainly, you just need to dispatch to the proper thread pool based on
some request information.

The ProtocolFilter we are using is describing here

https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/rcm/ResourceAllocationFilter.html

And some http unit test can be looked under the http modules:

https://grizzly.dev.java.net/nonav/xref-test/com/sun/grizzly/portunif/PUBasicTest.html

You can either extend it or do something similar. Let us know how it goes.

-- Jeanfrancois


>
> best regards
> Rama
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>