Salut,
Survivant 00 wrote:
>
> I find it a very interresting question to try to avoid
> blocking of for example jdbc calls. Has anybody done
> any code?
>
>
> I had the same problem when simulate a 3th party request. In my demo,
> the server receive request for a quote, so the server need to ask a
> quote to a 3th party and when I receive the quote from the 3th party, I
> send to response back to the client.
>
> but I don,t want it to by blocking so I use a callback method that will
> receive the response from the 3th party.
I think this can be achieved at two levels. The SuspendableFilter
https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/suspendable/SuspendableFilter.html
https://grizzly.dev.java.net/nonav/xref-test/com/sun/grizzly/SuspendableTest.html
can probably be used (I still needs to document that one an give an
example) to suspend the connection after spawning a thread which execute
the jdbc connection. Once the jdbc connection gets the response, the
spawned thread can always call then resume the connection.
An alternative is to use the Asynchronous Request Processing (ARP)
mechanism the http module is offering:
http://kasparov.skife.org/blog/src/java/grizzly-arp-basic.html
http://weblogs.java.net/blog/jfarcand/archive/2006/02/grizzly_part_ii.html
But that one only support the HTTP protocol.
One thing I need to do is to blog on SuspendableFilter and update the
Grizzly ARP isage (because more and more peoples are using it). Any
blogger contribution welcomed!
A+
-- Jeanfrancois
>
>
> 2008/6/26 John ROM <snake-john_at_gmx.de <mailto:snake-john_at_gmx.de>>:
>
> Hi Matteo,
>
> >
> > The Selector thread (N+1 threads per N Cpu) handles the ACCEPT
> operation
> > for
> I think this is configurable.
> if you start one controller out of the box
> it is only one thread.
> > each new connection, stores the connection reference (selector
> key) then
> > passes it to a new thread for the protocol filtering (which is
> the parsing
> > action in the case of a text based protocol like an xml-based one,
> > right?).
> > At this point, say the client sent a command "doSomething", which
> results
> > in
> > several operations to be performed by the server (eg. Querying a db,
> > creating some object instances and so on). Are these operations
> done by
> > that
> > same thread or is it a new thread different from the one that
> filtered the
> > protocol?
>
> These operations are done by "the same thread that filtered the
> protocol"
>
> Of course you often then end up blocking on jdbc calls.
> So you loose some of the "Threading" advantages you gained by NIO.
>
> I find it a very interresting question to try to avoid
> blocking of for example jdbc calls. Has anybody done
> any code?
>
> Many Greetings
> John
>
> --
> Psssst! Schon vom neuen GMX MultiMessenger gehört?
> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> <mailto:users-help_at_grizzly.dev.java.net>
>
>