>>> It would certainly be possible to implement async RMI-IIOP directly at
the
>>> level of
>>> the ORB, using syntax similar to that supported by the async EJB
>>> feature.
>>> A good implementation should avoid blocking threads while waiting for a
>>> response
>>> (even an internal implementation thread is probably too much in some
>>> cases).
>>> The basic need here is to modify the dynamic stub generator slightly,
>>> introducing a new
>>> API for the async case.
>>
>>> The hard part is modifying the client ORB code to save and restore the
>>> per-request state.
>>
>> Can you elaborate a bit more on this? I'm not so deep into RMI
>> implementations (yet ;-) to understand the problem that you describe
>> here.
> Actually I was thinking about the client side above, which is interesting,
> but
> the server side is much more important for scalability considerations.
> But I'm not sure how to do this: what is your long-running server method
> doing?
> Is it computing something expensive, in which case a thread is required
> anyway?
> Or is it making further remote requests (perhaps expensive database
> queries?)
In my case, it mostly makes further remote requests.
But, IMHO, it does not and should not matter. Even if it would compute
something expensive, I'd like to do it on a different thread pool which is
under my control. So, yes, the thread will be still occupied, but it would
my thread behaving according to my policy, which in my case is a big
advantage over e.g. (EJB) container managed threads. What I want to stress
is that it is not only pure optimization. It is also about who controls
multi-threading and processing.
> Essentially it seems that you want to capture the state of your
> computation
> at the point of suspension (remote communications, IO, etc) so that it can
> be
> restored later. This either requires significant restrictions or a
> general
> continuation implementation.
Right.
> But I'm not sure whether the state saved by a full continuation
> implementation is significantly smaller
> than that saved in a thread.
Hmm. I'm not sure as well. But my impression after reading some papers about
Kilim and some other implementations is that full continuation may be
smaller. Mainly because parts of saved continuations can be "shared" between
multiple continuations taken at suspension points deep in the call stack, as
many of them can have a long common execution path prefix leading to them.
>> Obviously a general
>> continuation mechanism would make this easy, but failing that,
>> the basic state to capture is in several ThreadLocals.
>> Then it't a matter of unwinding the method return code so it can be
>> called
>> directly.
>>
>> There are some attempts to support general continuations in Java (Maxine
>> JVM
>> and some others), but it will take a while before it becomes mainstream.
> I've seen some of this, but I think they generally require extensive
> bytecode
> transformation across the entire execution path, which may be impractical,
Well, those transformations are usually done just once (sometimes even
statically) and then re-used. So, I'd assume it is somewhat comparable to
run-time stub generation. But of course some performance testing would be
useful here.
> There is also Javaflow, which could be good enough eventually.
Javaflow is a pure java library. It does all its byte-code instrumentation
at run-time, more precisely at class loading time, AFAIK. It's performance
is probably not the best for very computing intensive tasks, but for remote
invocations it could be eventually OK. Plus, it is not optimized at all yet
(i.e. it instruments too many call sites, even if it is not necessary). One
day, I tried to optimize it just for fun, and by the end of the day, the
overhead was reduced by at least 50%. And I'm sure it can be improved even
further.
Kilim uses static instrumentation at the moment. But it does very good
analysis of control and data flow and really optimizes the amount of data to
be stored for a full continuation. It also delivers quite impressive
performance.
>> BTW, Scala has a nice support for continuations out of the box in the
>> recent releases.
> Scala is interesting, but re-writing part of the ORB in Scala may not be
> practical
> (though it would be interesting!).
I guess so. It would be quite an undertaking ;-)
> I'll need to check on the Scala continuation support: can it capture a
> full continuation from Scala code
> that both is called by and calls into Java code?
Interesting question. I have not played with Java continuations yet to
provide answer to this question. This is something to ask on Scala mailing
lists, I guess.
-Leo
--
View this message in context: http://old.nabble.com/Asynchronous-request-processing-for-...-RMI-tp29073621p29083473.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.