geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
Date Thu, 04 May 2006 22:55:26 GMT
David Blevins wrote:

> On May 4, 2006, at 12:57 AM, Jules Gosnell wrote:
>> David Blevins wrote:
>>> On May 3, 2006, at 8:51 AM, Jules Gosnell wrote:
>>>> I'd like to kick off a thread about the monitoring of clustered   
>>>> deployments...
>>>> There is a section in the 1,000ft Clustering Overview (http://  
>>>> Clustering), but little content, due to the fact that there has   
>>>> been little discussion about this subject on the list...
>>>> Obviously we can use standard tools etc to monitor individual  
>>>> nodes  in a cluster - but, if you want to aggregate all the  stats  
>>>> together, for a clusterwide view of what is going on in  your  
>>>> deployment, life becomes a little more complicated....
>>>> I have a few ideas, but I haven't done much reading around this   
>>>> area, so it may be that there are already specs and standard  ways  
>>>> of achieving all of this. if there are and you know of  them, 
>>>> please  shout. If not, lets throw it open to discussion....
>>>> thanks for your time,
>>> Nice looking doc, Jules!
>>> I asked this question last time and you said you wanted to  compile  
>>> the info into 1000ft document, so I'm guessing this is my  queue :)
>>> On Mar 11, 2006, at 12:23 PM, David Blevins wrote:
>>>> I like the concept that clients can be made smarter or store   
>>>> information that will make the cluster that much more  efficient.   
>>>> But I'm not sure what you'd need me to do for  clients that are 
>>>> out  of our control and potentially written in  an entirely 
>>>> different  language, i.e. CORBA and Web Services.
>>>> Can you describe what considerations I'd have to add on my side  
>>>> of  the fence to make that work?
>> The considerations are :
>> (a) storing and accepting updates to a record of cluster membership  
>> and endpoints
>> (b) deciding by pluggable strategy, to which of these nodes to  
>> submit each request
>> (c) transparently failing over to the next node, if the node  
>> selected for a request is down
>> (a) the record would be initially populated via e.g. either a  
>> hardcoded list initialised from the file, or by  
>> autodiscovery of the clusterdirectly. It would be kept up to date  by 
>> piggy-backing deltas on the return leg of invocations.
>> (b) this strategy would be responsible for implementing load- 
>> balancing policies - i.e. round-robin or random for SLSBs and  sticky 
>> for SFSBs and probably Entities....
>> (c) this allows a client to continue its conversation through the  
>> stub, without needing to know that the server that it was talking  to 
>> has died and been replaced by another...
>> Re: RMI/IIOP - These considerations are dealt with in an  intelligent 
>> client-side java stub. I talked to Kresten of Trifork  some time ago 
>> about this - it seems that they have a CORBA client- side impl for 
>> clustering that maps quite closely to the sort of  thing that I 
>> envisage OpenEJB using for its own protocol... Ideally  we would want 
>> to share the same code between both transport impls -  I don't know 
>> enough about how they are plugged in to the stub to  decide whether 
>> this is practical... - we really need an OpenEJB  client-side 
>> clustering volunteer here.  Gianny might be interested,  or someone 
>> else ?
>> Re: WS - I am working on an Axis2/WADI integration with Rajith at  
>> the moment. I believe that WS invocations on OpenEJBs come via  
>> Axis2? - if we are talking SOAP/HTTP then, I guess responsibility  
>> for the intelligence that would be bundled into the java client  stub 
>> in the other two cases would fall upon the HTTP load- balancer... - 
>> i.e. this would be responsible for maintaining  session affinity for 
>> stateful requests (there are apparently a  couple of competing 
>> session marking specs for WS) and managing fail- over between nodes. 
>> Other WS transports would require other  solutions - have you any in 
>> particular in mind ?
>> I may have picked up the wrong end of the stick here, or ommitted  
>> stuff that you were angling for - if so, push straight back at me :-)
> Sort of.  Both your explanations involve smartening the java clients  
> on the other end of WS or CORBA to play nice.


smart java stubs for RMI over OpenEJB-protocol (what is it called?) or IIOP.

for WS, the load-balancer will do it.

> The goal of those  protocols is to interop in a language agnostic 
> fashion.  WS are all  stateless for EJB, so there is nothing to 
> cluster anyway.

stateless calls are still clustered - the load-balancing and failover 
considerations still exist - you just do not require session affinity 
(stickiness). If you are talking about server-side requirements, then I 

> But for  IIOP, would we simply not offer clustering to people using 
> CORBA to  interop with clients in other languages or on other platforms?

to tell the truth, these cases have escaped my radar - My CORBA 
knowledge is pretty thin and I have only really considered it in a 
java/java environment - I am sure that Kresten would be much better 
positioned to answer this question... I will CC this to him, in case he 
would like to pick it up...


> -David

"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