geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Clustering
Date Mon, 17 Oct 2005 09:34:11 GMT
Bruce Snyder wrote:

>On 10/15/05, Jules Gosnell <> wrote:
>>Jeff Genender wrote:
>>>Thanks for the update.  I like whats been done.  Do you think WADI is
>>>ready begin becoming a part of Geronimo? (i.e ready for prime time)
>>I have lots more to do, but I would certainly be interesting in starting
>>integration work with Geronimo. I always had Geronimo in mind whilst
>>working on WADI, it has just been that, until certification, simply
>>implementing specs correctly has been foremost on the G agenda. Now that
>>we have reached this goal, the next one becomes enterprise-readiness. I
>>hope that WADI can help with this. Would you, or anyone else on the
>>list, be interested in taking a look at it and getting involved in the
>>integration ?
>I'm definitely interested in getting involved with this, Jules. In
>fact, I've already typed in the JCache interfaces and only need to
>commit them to the Geronimo repo (and then work on converting OpenEJB
>2 to use them, of course). This spec will most certainly help out any
>mechanism needing caching.
Glad to hear we will have a JCache API done - good work.

I have a few provisos about assuming that JCache is THE solution to this 
range of problems and this is the reason why I rejected the JCache API 
on my last redesign of WADI (although I think that the next one will 
have to incorporate it and extend it).

JCache focusses (as far as my understanding goes), simply on the 
location of the state required by a process and not the location of the 
process itself. WADI tries to be neutral in this respect and should be 
equally at home relocating state to process or process to state. e.g. I 
can migrate a session in underneath an incoming request, or 
redirect/proxy a request to the node holding the state (and then 'stick' 
the client to this node so that subsequent requests travel directly to 
the session's location). The latter solution has distinct advantages :

1. Http requests are often much smaller than Http sessions. (the same 
would hold true for an EJB invocation and a SFSB)

2. Many Http requests may run through an HttpSession concurrently, but 
an HttpSession may only be in one place at once. i.e., if a number of 
nodes all receive an http request for the same session it is quicker for 
them to all relocate their requests to the session in question, where 
they may run concurrently, than to relocate the session from request to 
request which may only be done serially. This is not an issue with an 
SFSB (I assume) since only one thread is allowed access to an SFSB at 
any one time anyway (I think?).

3. [de]serialisation is expensive and error prone (may tickle bugs in 
application code). HttpSessions may have activation/passivation 
listeners registered (is there an equivalent for SFSBs?) which could be 
expensive to call. If we can avoid moving a session, it is a good thing.

4. The optimal location for a session is on the same node as its bucket 
owner. If the two can be colocated, notifications about creation, 
relocation and destruction can be run locally instead of remotely. So 
once this colocation is achieved (which it should be from the start, 
since each node can restrict itself to only generating session ids which 
map to buckets of which it is the owner), we want to avoid moving the 
session again, perhaps even if a request for it lands elsewhere.

So, I guess, whilst you have your head in the JCache API and are looking 
at JCache and OpenEJB, these would be very useful facts to consider. 
What is going to be the best way to fit these requirements into an 
architecture that sits around a JCache ? Perhaps we define an additional 
API which allows the relocation of an 'invocation' to a given 
CacheEntry, rather than the other way around. If the JCache instance 
that we are using implements this interface, then we enable the 
request-relocation functionality. Then we will be able to run our stuff 
with other jcache impls (which is bound to be a requirement), or our 
own, in which case you get the extra fn-ality....

Sound like a good idea ?


>perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>The Castor Project
>Apache Geronimo

"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * Open Source Training & Support.

View raw message