clustering... web/ejb/jms etc.. - a common impl

[Jules Gosnell <ju...@coredevelopers.net>]

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.

(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)
 **********************************/

Re: clustering... web/ejb/jms etc.. - a common impl

[Jules Gosnell <ju...@coredevelopers.net>]

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)
 **********************************/