[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster-devel] Getting Cluster Information ...



Haytham Mohtasseb Billah wrote:
Thanx Marcel,
But that isn't clear enough for me, moreover I search also about reconfigure a started plugin on-fly wihout restarting xmlblaster. So can you give me more details.
The plugins have no fixed schema that or what they shall provide
configurable.
So you need to check each plugin in the jconsole and see
what it offers AND test if changing a property really has
the desired effect.
After that, you can send any change you make by jconsole also as a JMX script
via a administrative message or over our status HTML access.
Some feedback about what you have found out is very welcome
and can be added to the requirements page of the related plugin.


regards

Marcel
Haytham.

----- Original Message ----- From: "Marcel Ruff" <mr at marcelruff.info>
To: <xmlblaster-devel at server.xmlblaster.org>
Sent: Sunday, April 23, 2006 11:17 PM
Subject: Re: [xmlblaster-devel] Getting Cluster Information ...


Arghad Arnaout wrote:
OK Marcel:
nodeInfo.getConnectQosData();
the visibility of this method is not public, it is with default visibility, so I could not use it from outside of the package org.xmlBlaster.engine.cluster
so can we put it as public, or it should stay with the default visibility ...
It is now public,

Marcel
Thanx again
ARGHAD


On 4/22/06, *Marcel Ruff* <mr at marcelruff.info <mailto:mr at marcelruff.info>> wrote:


    Arghad Arnaout wrote:
    > Hallo Marcel:
    >
    > Would you please to tell me how I can use NodeInfo Class to get
    the IP
    > and the Port of the node ??
    nodeInfo.getConnectQosData().getAddress().getRawAddress();

    should return something like

      socket://192.168.1.1:7607

regards
Marcel
>
> Regards
> ARGHAD
>
>
> On 4/20/06, * Marcel Ruff* < mr at marcelruff.info
<mailto:mr at marcelruff.info>
> <mailto:mr at marcelruff.info <mailto:mr at marcelruff.info>>> wrote:
>
> Hmm,
>
> if you look at the cluster configuration:
>
> ==============
> cluster.node.id=heron.mycomp.com
> ==============
> This defines the unique name of a cluster node.
>
> (see
> http://www.xmlblaster.org/xmlBlaster/doc/requirements/cluster.html)
>
> The following configuration could be easily a message content.
> The few classes in org/xmlBlaster/engine/cluster do all cluster
> specific
> processing.
>
> <clusternode id='heron.mycomp.com <http://heron.mycomp.com>
<http://heron.mycomp.com>'>
> <connect><qos>
> <address type='IOR'>
> IOR:09456087000
> </address>
> <address type='XMLRPC'>
> http://www.mycomp.com/XMLRPC/
> </address>
> <callback type='SOCKET'>
> socket://mycomp.com:7604
> </callback>
> </qos><connect>
>
> <master type='DomainToMaster' version='0.9'>
> <![CDATA[
> <key domain='RUGBY'/>
> <key type='XPATH'>//STOCK</key>
> ]]>
> </master>
> <master stratum='1' refId='frodo' type='MyOwnMapperPlugin'
> version='2.0'>
> <![CDATA[My own rule]]>
> </master>
>
> <state>
> <cpu id='0' idle='40'/>
> <cpu id='1' idle='44'/>
> <ram free='12000'/>
> </state>
> </clusternode>
>
>
> The NodeParser.java class parses this xml:
> - NodeInfo.java parses the above <connect> address informations,
> - NodeDomainInfo.java parses the <master> part
> - NodeStateInfo.java parses the <state> part (is currently
not used)
>
> ClusterManager.java:221 starts parsing the above XML given from
> xmlBlaster.properties .
> We could now as well send the XML with a message, say to topic
>
> <key oid='__sys__cluster.node[heron.mycomp.com
<http://heron.mycomp.com>
> <http://heron.mycomp.com>]'>
>
> and the ClusterManager could subscribe on topics starting
> with '__sys__cluster.node' (or easier just intercept it in
> RequestBroker.java)
> and reconfigure itself.
> This needs to be looked at in more detail and there are
certainly some
> subtle issues popping up during coding but generally it
should work.
>
> If you gonna code it you are welcome to contribute
> it to xmlBlaster,
>
> regards
> Marcel
>
>
>
> Arghad Arnaout wrote:
> > Hallo Marcel:
> > you wrote
> > " In fact it was/is planned that each cluster node
information is a
> > message so we
> > can dynamically reconfigure cluster nodes, but this approach
> needs some
> > lines of code to be added, "
> >
> > So would you please to explain that ??!!
> > How we can implement that to configure the cluster node
dynamically
> > ... ????
> >
> > Thank you ..
> >
> > ARGHAD
> >
> > On 4/17/06, *Marcel Ruff* < mr at marcelruff.info
<mailto:mr at marcelruff.info>
> <mailto:mr at marcelruff.info <mailto:mr at marcelruff.info>>
> > <mailto: mr at marcelruff.info <mailto:mr at marcelruff.info>
<mailto:mr at marcelruff.info <mailto:mr at marcelruff.info>>>> wrote:
> >
> > Arghad Arnaout wrote:
> > > Hallo everybody:
> > >
> > > OK .. regarding to the business requirements, we
need to know
> > and see
> > > the information of all xmlBlaster nodes in
xmlBlaster Cluster,
> > > so my design to solve this issue in xmlBlaster
Environment is
> > like the
> > > following:
> > >
> > > I designed such a plugin that runs at each node of the
> cluster and
> > > this plugin publishes the information about the current
> node under a
> > > specific topic, so what I need to do from the client
side
> just
> > to get
> > > the messages under this topic (using get() or
subscribe()).
> > >
> > > So .. is that the right way to implement such things ???
> > Yes, this way is OK.
> >
> > In fact it was/is planned that each cluster node
information
> is a
> > message so we
> > can dynamically reconfigure cluster nodes, but this
approach
> needs
> > some
> > lines of code to be added,
> >
> > regards
> > Marcel
> > > All the comments are welcomed...
> > >
> > > Thank you
> > > ARGHAD
> > >
> >
> >
>
>