JGroups Configuration With XML Element

[jiwils]

I am programatically reading/parsing the cluster-service.xml file from JBoss 3.2.4 in order to get the configuration information for a standalone JGroups program (I want it to be in the same "group" as the JBoss instance).

I am then passing the XML Element that is the "Config" element object to JChannel's constructor (the JGroups source indicates that I can do this).

By stepping through the JGroups 2.2.5 source code with a debugger, I can see that my Object parameter is correctly interpreted as an Element, but it does not appear to be able to parse it. Just for kicks, I tried recompiling the same code with the jgroups.jar that shipped with JBoss 3.2.4, but I get the same result. Further inspection seems to indicate that the XMLConfigurator class might be looking for the wrong thing (a "protocol" tag) that does not exist in my (or JBoss's) XML.

Printing the XML Element instance outputs the following:

<Config>
 <!-- UDP: if you have a multihomed machine,
 set the bind_addr attribute to the appropriate NIC IP address -->
 <!-- UDP: On Windows machines, because of the media sense feature
 being broken with multicast (even after disabling media sense)
 set the loopback attribute to true -->
 <UDP mcast_addr="228.1.2.3" mcast_port="45566" ip_ttl="32" ip_mcast="true" mcast_send_buf_size="800000" mcast_recv_buf_size="150000" ucast_send_buf_size="800000" ucast_recv_buf_size="150000" loopback="false" />
 <PING timeout="2000" num_initial_members="3" up_thread="true" down_thread="true" />
 <MERGE2 min_interval="10000" max_interval="20000" />
 <FD shun="true" up_thread="true" down_thread="true" timeout="2500" max_tries="5" />
 <VERIFY_SUSPECT timeout="3000" num_msgs="3" up_thread="true" down_thread="true" />
 <pbcast.NAKACK gc_lag="50" retransmit_timeout="300,600,1200,2400,4800" max_xmit_size="8192" up_thread="true" down_thread="true" />
 <UNICAST timeout="300,600,1200,2400,4800" window_size="100" min_threshold="10" down_thread="true" />
 <pbcast.STABLE desired_avg_gossip="20000" up_thread="true" down_thread="true" />
 <FRAG frag_size="8192" down_thread="true" up_thread="true" />
 <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true" />
 <pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />
 </Config>

Any ideas? Can I pass this element to JChannel on instantiation and expect it to be able to parse it or did I misunderstand?

[belaban]

My bad - XmlConfigurator.parse(Element) was still using the old format. I changed it, essentially copied XmlConfigurator.parse(InputStream).
Try it out now, need to get JGroups from the CVS.

Bela

[jiwils]

Your XMLConfigurator changes added a bug, and it makes your changes unlikely to work.

The try block at line 323 in the parse method that takes an Element as a parameter starts like this:

try {
 Node root=null;

 NodeList roots=root_element.getChildNodes();
 for(int i =0; i < roots.getLength(); i++) {
 root=roots.item(i);
 if(root.getNodeType() != Node.ELEMENT_NODE)
 continue;
 }

 String root_name=root.getNodeName();

Considering that the Element passed is likely the "config" element, this code would not work, and since the root node is always assigned regardless of its node type in the for loop, who knows what node you will end up with.

I made the following changes in order to get the expected behavior:

try {
 Node root=root_element;

// NodeList roots=root_element.getChildNodes();
// for(int i =0; i < roots.getLength(); i++) {
// root=roots.item(i);
// if(root.getNodeType() != Node.ELEMENT_NODE)
// continue;
// }

 String root_name=root.getNodeName();

Can you commit this change (or something like it) to CVS?

[jiwils]

Could I also get the source for JGroups 2.2.4? What tag (if any) could I pull from CVS? I would like to apply these changes to that version (they seem unlikely to affect any other part of the code) since we are using JBoss 3.2.4 and my seperate client code (JGroups 2.2.5+) throws an exception when it sees the 2.2.4 version.

[belaban]

Done (in CVS). If you happen to have some spare time, you could merge the 2 parse methods into 1, I think we could easily extract a common method used by the 2 parse() methods...
Bela

"jiwils" wrote:
Your XMLConfigurator changes added a bug, and it makes your changes unlikely to work.

The try block at line 323 in the parse method that takes an Element as a parameter starts like this:

try {
 Node root=null;

 NodeList roots=root_element.getChildNodes();
 for(int i =0; i < roots.getLength(); i++) {
 root=roots.item(i);
 if(root.getNodeType() != Node.ELEMENT_NODE)
 continue;
 }

 String root_name=root.getNodeName();

Considering that the Element passed is likely the "config" element, this code would not work, and since the root node is always assigned regardless of its node type in the for loop, who knows what node you will end up with.

I made the following changes in order to get the expected behavior:

try {
 Node root=root_element;

// NodeList roots=root_element.getChildNodes();
// for(int i =0; i < roots.getLength(); i++) {
// root=roots.item(i);
// if(root.getNodeType() != Node.ELEMENT_NODE)
// continue;
// }

 String root_name=root.getNodeName();

Can you commit this change (or something like it) to CVS?

[belaban]

"jiwils" wrote:
Could I also get the source for JGroups 2.2.4? What tag (if any) could I pull from CVS? I would like to apply these changes to that version (they seem unlikely to affect any other part of the code) since we are using JBoss 3.2.4 and my seperate client code (JGroups 2.2.5+) throws an exception when it sees the 2.2.4 version.

- Look into jboss-3.2/thirdparty/javagroups/lib/README. The tag used to create JGroups is in there (possibly JG_2_2_4).
- Check out JGroups (co -r JG_2_2_4 JGroups)

Bela

[jiwils]

Great!!

I am taking a closer look at XMLConfigurator now in order to try to make the changes you alluded to. Is there a unit test out there for this stuff? I would feel more comfortable with my changes if there was (though I will test them regardless).

Given that this change is likely to be larger than the other (too big for a diff in a forum), how should I submit this?

[jiwils]

Nevermind my unit test question, they were right there in front of me (and the tests for XML have their own Ant target)!

[jiwils]

The XML unit tests passed (and my test did too).

Basically, I ended up making the XMLConfigurator parse(InputStream) method call the parse(Element) method, fixed a possible ClassCastException causing situation in ConfiguratorFactory (I caused one), and added File as a possible parameter for the JChannel constructor that is used in ConfiguratorFactory.

So, how should I get these changes to you: post forums diffs (like last time, but longer), via CVS checkin ("jiwils" is my sourceforge account name), or some other method?

One other question: why does the JChannel constructor takes one Object parameter rather than having overloaded constructors?

[belaban]

"jiwils" wrote:

Basically, I ended up making the XMLConfigurator parse(InputStream) method call the parse(Element) method, fixed a possible ClassCastException causing situation in ConfiguratorFactory (I caused one), and added File as a possible parameter for the JChannel constructor that is used in ConfiguratorFactory.

So, how should I get these changes to you: post forums diffs (like last time, but longer), via CVS checkin ("jiwils" is my sourceforge account name), or some other method?

I gave you CVS r/w, could you check in your changes ? Please read the RULES file for all new developers.

One other question: why does the JChannel constructor takes one Object parameter rather than having overloaded constructors?

Because most args ars String, which can mean:
- old style plain string configuration
- filename
- URL
- filename on classpath

So I have to have some logic to handle these in the same method anyway. Also, I don't want to have 5 constructors for JChannel. 2-3 maybe, but you have to convince me first :-)

Bela

[jiwils]

I will check in the changes after work tonight. I do not have a copy of my private key at work currently.

[jiwils]

My changes have been checked in.

Is our JChannel "constructor" discussion something to have in this forum? Another topic maybe? Or the JGroups mailing list?

[belaban]

JGroups dev list