Hi guys,
I know that my question is most likely beyond the scope of this mailing
list, but let me try ;-)
I've been using Glassfish together with Grizzly, Atmosphere, JAX-WS, etc.
Most of these technologies support at least some form of server-side
asynchronous request processing. And this is very important for development
of scalable server-side applications.
For my current project, I'd like to use RMI for communication between
clients and servers. BTW, servers are standalone Java applications (using
embedded GF, Grizzly, Jetty and many other things), as they need explicit
control over multi-threading which is prohibited by some JavaEE specs like
EJB, etc. And I of course know that RMI is a synchronous invocation, as it
was envisioned. But I'd like to benefit from asynchronous
non-thread-blocking request processing approach if possible and I'd like to
do it in a transparent way for a client (i.e. it should look like a usual
local/library call). I think, it should be possible in principle, even
though I couldn't find anything like this yet. After all, there is a socket
listening to requests and then triggering server-side stubs. If requests
could be intercepted at this point, then suspended, and the task for their
processing could be put on the thread pool or something similar, then after
their processing is over and response is prepared, requests could wake up
and response could be sent. But it is not clear for me, if such hooks are
exposed by the JDK and if it is possible at all.
BTW, the reason for going for RMI and not JMS, REST or WS, is that clients
are created by 3rd parties, not by me, and I cannot force them to follow a
certain design pattern. Plus I need a very good scalability, I need to serve
e.g. 10000 requests simultaneously. With JMS, clients would need to write
their apps using an explicitlty asynchronous design pattern and they are
restricted to Java. For WS, clients may do invocations almost transparently,
but overhead introduced by JAX-WS and XML parsing is pretty big. REST is
almost the same. Therefore I thought that asynchronous RMI could be the best
solutuion, if such thing would exist, of course. But may be I also
overcomplicate things? May be there are much simpler scalable and (almost)
client-transparent solutions?
What do you think about the idea? Have you ever heard about such a thing?
Would it be possible to implement such a solution on top of Grizzly and how
much effort it would need? And as many of Grizzly contributors are also
Glassfish experts: Is it possible to customize and overload default RMI
mechanims in JDK and/or in GF?
Thanks in advance for any help!
Leo
--
View this message in context: http://old.nabble.com/Asynchronous-request-processing-for-...-RMI-tp29073621p29073621.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.