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. 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. But for
IIOP, would we simply not offer clustering to people using CORBA to
interop with clients in other languages or on other platforms?
-David
