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

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



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>> 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>'>
       <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>]'>

    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>>> 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
    >     >
    >
    >