geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
Subject Re: Clustering
Date Mon, 17 Oct 2005 18:51:35 GMT
On 10/17/05, Jules Gosnell <jules@coredevelopers.net> wrote:

> >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).

I'm not saying that JCache is *the* solution for the problem set, I
simply threw that out there to let you know that work is done, I just
need to check it in. I was actually waiting to write some tests for it
before I did so, but after speaking to Dain, he reminded me that I
should just put it in the sandbox until I feel it's ready to be moved
to the specs module.

> 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.

Yes, that's correct. JCache is simply about the data and nothing more.
How you associate that back to the process is up to you. ;-)

> 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 ?

Yes, a very good idea. I'll keep these questions in mind as I read
through the JCache spec docs again.

Bruce
--
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
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Mime
View raw message