Hi Manu, Willie and community: JGroups is a fine piece of software but really inscrutable when it does not work. Several of us have been talking about putting together a little utility to check the group communications and help diagnose low-level problems. This is generally interesting so it would make sense for us to implement it as a simple hedera-based utility that is in the Hedera library, hence is usable from any hedera-based product.
I have logged HEDERA-42 to described the proposed utility and plan to implement this week. Please post comments for additional ideas on what you would like to check. Cheers, Robert On 5/28/08 1:21 AM, "Emmanuel Cecchet" <[EMAIL PROTECTED]> wrote: Hi Willie, Thanks for the feedback. Could you check that there is not another sequencer.xml file in the jgroups jar file in the lib/ directory or in any other directory or jar file in the controller classpath? Another way to see if JGroups is really using the file that you are updating is to try to break its syntax and it should fail at loading time. If it does not, it is using another one! Not that according to http://docs.jboss.org/jbossas/guides/clusteringguide/r2/en/html/jbosscache.chapt.html, FD_SOCK also takes a srv_sock_bind_addr. It looks like the bind address can be specified through -D bind.addr on the java command line. This could also be worth a shot. We are making progress! Emmanuel > Thank you for your research! > I have added your request to the config/sequencer.xml file like so: > > <config> > <UDP bind_addr="192.168.64.131" > mcast_port="45566" > mcast_addr="228.8.8.9" > > (192.168.64.131 is the ip address of the one machine that I am testing > this on). > > I tried to restart the controller, however I got the same output: > Caused by: java.lang.Exception: problem creating sockets > (bind_addr=/192.168.5.1, mcast_addr=null) > at org.jgroups.protocols.UDP.start(UDP.java:372) > at > org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:571) > > It seems as if it did not take the bind_addr parameter I passed.. I > grepped in the whole sequoia directory for 5.1, and no results where > returned. Could it be that the sequencer.xml file is not being read ? (or > properly read). > > Just for the kicks of it, I changed the ip address of eth0 to 192.168.5.1, > and started the controller, and it started up successfully :D So I think > we just need to figure out why is it not using the bind_addr I specify in > config/sequencer.xml. > > Regards > Willie > > > >> Hi Willie, >> >>> Caused by: java.lang.Exception: problem creating sockets >>> (bind_addr=/192.168.5.1, mcast_addr=null) >>> at org.jgroups.protocols.UDP.start(UDP.java:372) >>> at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:571) >>> ... 71 more >>> >>> >> I was looking on the web where this 192.168.5.1 could come from. >> I found http://wiki.jboss.org/wiki/Probe and there might be a hardcoded >> default value in JGroups if bind_addr is not specified on multi-homed >> machines. >> Could you try in config/sequencer.xml to add a bind_addr like this: >> >> <*UDP* bind_addr="your IP address here" >> mcast_port="45566" >> mcast_addr="228.8.8.9" ... >> >> Keep us posted with your progress, >> Emmanuel >> >> -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: [EMAIL PROTECTED] Skype: emmanuel_cecchet _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia -- Robert Hodges, CTO, Continuent, Inc. Email: [EMAIL PROTECTED] Mobile: +1-510-501-3728 Skype: hodgesrm
_______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
