geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
Date Thu, 04 May 2006 07:57:27 GMT
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:// 
>> opensource.atlassian.com/confluence/oss/display/GERONIMO/ 
>> 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 jndi.properties 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 :-)

Jules

>
> Thoughts?
>
> -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)
 *
 *    www.coredevelopers.net
 *
 * Open Source Training & Support.
 **********************************/


Mime
View raw message