geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: clustering... web/ejb/jms etc.. - a common impl
Date Thu, 11 Sep 2003 13:51:10 GMT
Jules Gosnell wrote:

> James,
> I've done some thinking about the chat we had about integrating web, 
> ejb and jms clustering strategies. Here is a gross simplification of 
> some of the stuff we covered. Hopefully you can fit JMS into the 
> picture....
> let's assume that the lb/replication strategies are combined and have 
> two values: dumb and sticky.
> 'dumb' means the next request (web or ejb) can fall anywhere
> 'sticky' means it will fall wherever the last request in the same 
> conversation fell
> 'dumb' involves synchronous replication to avoid a client request 
> racing and beating a replication request to a node (although you could 
> use asynchronous and cross your fingers if your LAN was fast).
> 'sticky' allows the luxury of asynchronous replication at a slight 
> risk (in the case of failure), since we know subsequent requests will 
> al fall on the same node.
> 'dumb' is not an environment that EJBs generally have to survive in, 
> since their container is usually in charge of the client side proxy lb 
> strategy. Web components, however, do need to be able to live happily 
> in a dumb environment.
> The fun occurs when a call needs to cross over between the two tiers:
> (a) web-dumb/ejb-dumb : cross-over is local, but ejb tier must use 
> synchronous replication like web-tier
> (b) web-dumb/ejb-sticky: cross-over is probably remote, but ejb tier 
> may use asynchronous replication
> (c) web-sticky/ejb-dumb: cross-over is local -  ejb-tier gains nothing 
> by synchronous replication - inefficient -it might as well be sticky
> (d) web-sticky/ejb-sticky: cross-over is local - both tiers are able 
> to replicate asynchrously - maximum efficiency
> (a) and (b) are where the current Jetty distributable httpsession impl 
> is with JB*ss, since integration between web and ejb tiers is still 
> not perfect.

oops - what I meant was (b) and (d) - although (d) only works with 
mod_jk provided that the initial node remains up, if you take it down, 
mod_jk reverts to a 'dumb' strategy (or at least one where the next 
request is not garanteed to land where the last one in the same 
conversation did), so you are back to (b). What I want in Geronimo, is a 
solution where we can run continually at (d), whilst popping nodes up 
and down with no ill effect...

> (d) is where I want to see Geronimo go.
> This of course means that in a partitioned/subclustered cluster the 
> web and ejb deployments must be arranged, load-balanced and replicated 
> identically so that their resources can pair up properly.
> given that we have to support (IMHO) both dumb and sticky web 
> environments, and the underlying replication layer will hopefully be 
> reused underneath all tiers, I think it makes sense to support 
> ejb-dumb, for cases where in a web-dumb environment many reads are 
> made between the web tier and ejb tier for each web request. This 
> would ensure that all reads are local, whilst causing no additional 
> ejb replications.... etc...
> There are many other issues that will impact on this, such as the 
> different ways stickiness is implemented in different lbs and 
> replication is implemented under different tiers, but I'm hoping that 
> the overall classifications and optimisations deriving therefrom will 
> survive....
> So, over to you, how does JMS fit into this picture ? Are the same 
> abstractions meaningful in the JMS world ? If I put a topic or queue 
> into my httpsession and then wake up on a different node, will I 
> always end up talking through them to a remote resource, or might 
> these components be replicated locally?
> and then there is JNDI :-) any JNDI experts out there ?
> Jules

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)

View raw message