[ http://jira.jboss.com/jira/browse/JBAS-4939?page=comments#action_12386080 ] Aleksandar Kostadinov commented on JBAS-4939: --------------------------------------------- I think it is more than misconfiguration. Here is all information I have. NOTE: JBoss 4.2 cluster tests pass even when one node is bound to localhost So when JGroups joins a multicast group it creates a socket bound to the interface where the "-b" option argument resides. So running a server as "run -c all -b localhost" will bind the multicast socket to the local loopback interface and running with "run -c all -b `hostname`" will bind the socket to the eth0 interface (if we talk about a hudson slave). It appears that if multicast socket is bound to a network interface (being lo or eth#) which multicast route is not set through, then it cannot receive multicast messages. What was confusing and took much time to understand is that RHEL4 pre update 5 (<= RHEL 4U4) doesn't regard multicast routing and a listener to any interface receives multicast messages. RHEL 4U5 and RHEL5 however regard the multicast route and don't pass the message to the listener on any interface but that the multicast route goes through. Solutions: 1. Use only IPs on the same interface that multicast route goes through 2. Disable the default behavior to bind the socket to an interface but let OS choose the default one. If user forces the socket to be bound to specific interface, then bind to it. IMHO that is how things should work. And we will avoid the need user to mess with multicast configuration and adding IPs to be able to run the test suite. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4939?page=comments#action_12386084 ] Aleksandar Kostadinov commented on JBAS-4939: --------------------------------------------- And no, setting multicast route through lo is not a solution because that way mcast messages will be seen on the local loopback listener but not by the listener on eth# Currently mcast route on all hudson slaves is through eth0 where MYTESTIP_# reside on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4939?page=comments#action_12386314 ] Aleksandar Kostadinov commented on JBAS-4939: --------------------------------------------- Ok, I did some more investigation and have some conclusions. 1. The initial issue of JBoss not seeing its own sent mcast messages appears to be that dev90 needed a restart for unknown reason. 2. AFAICT there is no issue with the noip JBoss AS 5 hudson job. It fails but for other reasons. 3. The mcast receiver test is reliable. We were misleaded by it failing on RHEL 4U5 and above but clustering when one node is localhost and the other whatever IP works. Well taht works because of the linux mcast behavior when 2 processes join the same mcast group/port and on different interfaces. Effectively both receivers get mcast messages received through both interfaces. So in this situatuin one node listens to localhost, one to eth0 thus both seeing each other. Since this configuration is only a case when running the test suite we should not consider mcast receiver test unreliable. To see what I'm talking about do: a> start a reveiver on lo b> start a sender on lo c> send a message (will be received on RHEL 4U4 but not on RHEL 4U5 and above) d> start a receiver on eth0 e> send a message from the initial sender (will be received on both receiver ends) I think that's all about this issue. Let me know if you want any additional information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4939?page=all ] Dimitris Andreadis updated JBAS-4939: ------------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta3) Priority: Optional (was: Critical) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4939?page=comments#action_12387214 ] Dimitris Andreadis commented on JBAS-4939: ------------------------------------------ I believe you can trigger a run yourself, anytime. Click on "build now" (I just did): http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira