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://
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 :-)
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
agree.
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...
Jules
-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.
**********************************/
