You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jules Gosnell <ju...@coredevelopers.net> on 2006/05/03 17:51:53 UTC
Clustering: Monitoring...
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,
Jules
--
"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.
**********************************/
Re: Was: Clustering: Monitoring... - Now: Clustering:
OpenEJB...
Posted by Andy Piper <an...@bea.com>.
At 10:39 PM 5/4/2006, David Blevins wrote:
>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?
Some ORBs support multiple profiles for clustering (Borland is one)
the IOR format is standard but the client still has to know what to
do. WLS has its own clustered IOR format which we have published to some ISVs.
andy
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
Posted by David Blevins <da...@visi.com>.
On May 4, 2006, at 8:37 PM, Filip Hanik - Dev Lists wrote:
> Jules Gosnell wrote:
>> David Blevins wrote:
>>
>>>
>>> On May 4, 2006, at 12:57 AM, Jules Gosnell wrote:
>>>
>>>>
>>>
>>> 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...
> corba is not far from RMI, and the corba implementation that you
> use, create their own stubs, and those stubs can do the same stuff
> as smart RMI stubs. I'm sure that corba could even do dynamic
> proxies in some sort of sense, they werent able to when I used it a
> long time ago, but if the technology has kept up, then yes, you
> should be able to build in significant logic in the clients.
>
All true. My curiosity is more about the interop side of CORBA where
it's not the same vendor or language on both ends of the pipe.
Not much of a CORBA guy either, so I'm not sure what can be done in
that scenario.
-David
Re: Was: Clustering: Monitoring... - Now: Clustering:
OpenEJB...
Posted by Andy Piper <an...@bea.com>.
The weblogic thin-client works this way - clustering is built into
the client using portable interceptors and the JDK ORB.
andy
At 04:37 AM 5/5/2006, Filip Hanik - Dev Lists wrote:
>Jules Gosnell wrote:
>>David Blevins wrote:
>>
>>>
>>>On May 4, 2006, at 12:57 AM, Jules Gosnell wrote:
>>>
>>>
>>>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...
>corba is not far from RMI, and the corba implementation that you
>use, create their own stubs, and those stubs can do the same stuff
>as smart RMI stubs. I'm sure that corba could even do dynamic
>proxies in some sort of sense, they werent able to when I used it a
>long time ago, but if the technology has kept up, then yes, you
>should be able to build in significant logic in the clients.
>
>Filip
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Jules Gosnell wrote:
> David Blevins wrote:
>
>>
>> On May 4, 2006, at 12:57 AM, Jules Gosnell wrote:
>>
>>>
>>
>> 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...
corba is not far from RMI, and the corba implementation that you use,
create their own stubs, and those stubs can do the same stuff
as smart RMI stubs. I'm sure that corba could even do dynamic proxies in
some sort of sense, they werent able to when I used it a long time ago,
but if the technology has kept up, then yes, you should be able to build
in significant logic in the clients.
Filip
Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
Posted by David Blevins <da...@visi.com>.
On May 4, 2006, at 3:55 PM, Jules Gosnell wrote:
> David Blevins wrote:
>
>> 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.
Right, I always forget there is a world outside the server state :)
>> 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...
Same here. Maybe Kresten has some ideas.
-David
Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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.
**********************************/
Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
Posted by David Blevins <da...@visi.com>.
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
Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
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.
**********************************/
Re: Clustering: Monitoring...
Posted by David Blevins <da...@visi.com>.
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?
Thoughts?
-David
Re: Clustering: Monitoring...
Posted by James Strachan <ja...@gmail.com>.
On 5/3/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
>
> its a neat solution, I like it.
>
> one would still need to build the "aggregate" view, so that summaries
> etc can be reported on,
Agreed. FWIW Lingo does this too right now - though I'm sure we might want
to get more clever in how the aggregation works; the current defaults are
fairly simplistic.
--
James
-------
http://radio.weblogs.com/0112098/
Re: Clustering: Monitoring...
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
its a neat solution, I like it.
one would still need to build the "aggregate" view, so that summaries
etc can be reported on,
otherwise you only view a server at a time, which can be achieved by
just connecting to the server itself.
by aggregate I mean the sum of the nodes in the cluster, for example,
number of active sessions in the cluster, would be an aggregate view
Filip
James Strachan wrote:
> BTW I'm not necessarily saying that the Lingo JMX connector is *the*
> solution, just *a* solution - but I think the general approach of
> using distributed JMX connectors seems like a good, standards based
> approach to monitoring and controlling clusters of POJOs. Then folks
> can choose the JMX connector that suits their needs. Already today
> there are JMX connectors for HTTP, RMI and JMS and I'm sure folks
> could implement it on top of other things too like Jabber,
> WS-Notification or JBI etc.
>
> On 5/3/06, *Jules Gosnell* <jules@coredevelopers.net
> <ma...@coredevelopers.net>> wrote:
>
> James Strachan wrote:
>
> > Distributed JMX sounds like a simple way to monitor a cluster of any
> > Java stuff. Details on using clustered JMX over JMS here...
> >
> > http://lingo.codehaus.org/JMX+over+JMS
> >
> > which lets you monitor the cluster in a single MBeanServer
> >
> cool - sounds like exactly the sort of thing that I am looking for,
>
> thanks,
>
> Jules
>
> >
> > On 5/3/06, Jules Gosnell <jules@coredevelopers.net
> <ma...@coredevelopers.net>> 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
> <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,
> >>
> >>
> >> Jules
> >>
> >> --
> >> "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 <http://www.coredevelopers.net>
> >> *
> >> * Open Source Training & Support.
> >> **********************************/
> >>
> >>
> >
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
>
>
>
> --
> "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 <http://www.coredevelopers.net>
> *
> * Open Source Training & Support.
> **********************************/
>
>
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
Re: Clustering: Monitoring...
Posted by James Strachan <ja...@gmail.com>.
BTW I'm not necessarily saying that the Lingo JMX connector is *the*
solution, just *a* solution - but I think the general approach of using
distributed JMX connectors seems like a good, standards based approach to
monitoring and controlling clusters of POJOs. Then folks can choose the JMX
connector that suits their needs. Already today there are JMX connectors
for HTTP, RMI and JMS and I'm sure folks could implement it on top of other
things too like Jabber, WS-Notification or JBI etc.
On 5/3/06, Jules Gosnell <ju...@coredevelopers.net> wrote:
>
> James Strachan wrote:
>
> > Distributed JMX sounds like a simple way to monitor a cluster of any
> > Java stuff. Details on using clustered JMX over JMS here...
> >
> > http://lingo.codehaus.org/JMX+over+JMS
> >
> > which lets you monitor the cluster in a single MBeanServer
> >
> cool - sounds like exactly the sort of thing that I am looking for,
>
> thanks,
>
> Jules
>
> >
> > On 5/3/06, Jules Gosnell <ju...@coredevelopers.net> 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,
> >>
> >>
> >> Jules
> >>
> >> --
> >> "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.
> >> **********************************/
> >>
> >>
> >
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
>
>
>
> --
> "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.
> **********************************/
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Clustering: Monitoring...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
James Strachan wrote:
> Distributed JMX sounds like a simple way to monitor a cluster of any
> Java stuff. Details on using clustered JMX over JMS here...
>
> http://lingo.codehaus.org/JMX+over+JMS
>
> which lets you monitor the cluster in a single MBeanServer
>
cool - sounds like exactly the sort of thing that I am looking for,
thanks,
Jules
>
> On 5/3/06, Jules Gosnell <ju...@coredevelopers.net> 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,
>>
>>
>> Jules
>>
>> --
>> "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.
>> **********************************/
>>
>>
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
--
"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.
**********************************/
Re: Clustering: Monitoring...
Posted by James Strachan <ja...@gmail.com>.
Distributed JMX sounds like a simple way to monitor a cluster of any
Java stuff. Details on using clustered JMX over JMS here...
http://lingo.codehaus.org/JMX+over+JMS
which lets you monitor the cluster in a single MBeanServer
On 5/3/06, Jules Gosnell <ju...@coredevelopers.net> 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,
>
>
> Jules
>
> --
> "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.
> **********************************/
>
>
--
James
-------
http://radio.weblogs.com/0112098/