[ http://jira.jboss.com/jira/browse/EJBTHREE-880?page=all ] Aleksandar Kostadinov updated EJBTHREE-880: ------------------------------------------- Attachment: ejb3-4.0-testsuite Build Completed With Testsuite Errors.eml -- 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/EJBTHREE-880?page=all ] Carlo de Wolf reassigned EJBTHREE-880: -------------------------------------- Assignee: (was: Carlo de Wolf) -- 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

[ https://jira.jboss.org/jira/browse/EJBTHREE-880?page=com.atlassian.jira.p... ] Juraci Paixao Krohling commented on EJBTHREE-880: ------------------------------------------------- This is happening in branch JBPAPP_4_2_0_GA_CP. As I'm testing it right now, I'll fix all the places which have problems caused by this and will backport the changes to other branches when needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/EJBTHREE-880?page=com.atlassian.jira.p... ] Juraci Paixao Krohling resolved EJBTHREE-880. --------------------------------------------- Resolution: Won't Fix I talked to Carlo about it, and there *are* valid test cases which requires the node0 to be localhost. As an example, there is a test which compares the hostname (localhost) with the expected IP (127.0.0.1). I don't think we can easily achieve this without using localhost. At most, we can change some tests to use node0 instead of localhost, but some of them will still be localhost, still requiring the test to set node0 to localhost . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/EJBTHREE-880?page=com.atlassian.jira.p... ] Juraci Paixao Krohling commented on EJBTHREE-880: ------------------------------------------------- I tried different setups locally. I'm by no means an expert in clustering/network configuration, so, maybe you can give a try to get a working environment in some Hudson/QA machine, using lo/eth0 as node0/node1? I don't really like the idea of having some specific configuration on some machines just for EJB3, but after talking to EJB3 guys, it is pretty clear to me that there are some valid *test cases*. As I said, there is one which checks the consistency of hostname and IP address. The only pair of hostname/ip known for sure is localhost/127.0.0.1. We are talking about tests, right? I suppose that customers have a network setup specially configured to the clustering of their JBoss test instances, so they don't affect SIT/UAT/Production instances. That's basically what I'm looking for here. Isolated environment, to test everything related to EJB3 in a regular basis, without the need to take some machine(s) down or manually configure on every run. If we have two interfaces, lo and eth0, with one JBoss instance in each, multi-casting will still be affected by other JBoss instances accessible through eth0. In some tests, I noticed that some external instances were able to join the cluster whose master was on eth0, but lo was denied to join the cluster. So, even if they are on the same machine, lo is not in the same group as eth0, causing failures. No, it is not. We are talking about only EJB3 here, not the entire JBoss AS test suite. So, node0 and node1 are still being used in other parts. If you still have doubts about it, please join us at #ejb3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/EJBTHREE-880?page=com.atlassian.jira.p... ] Aleksandar Kostadinov reopened EJBTHREE-880: -------------------------------------------- +1 That's one thing I tried to suggest above. Yes, it does, because you can never know if these problematic tests will not run at the same time Do you use the special MCAST_ADDR environment variable to specify a multicast group? Go you use to change HA partition name for extra insurance? I'd guess not. Anyways what I have suggested is for the tests, where node0 needs to be localhost, to force mcast outgoing messages to 127.0.0.1 interface and listener join that mcast group on the loopback interface as well. I believe there are jgroups properties for the matter. I can see in http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Cl... how to tell jgroups use a particular interface and not the default one. For more properties see http://www.jboss.org/community/docs/DOC-12352, I think you need the mping mcast address as well. You could ask the jgroups guys as well. I wonder if this is something that really matters or just a random check put there long ago. I've no idea what the test is trying to prove but I hope it is not java hostname resolution :) Well our lab setup was carefully prepared for JBoss AS test suite then jgroups, messaging and cache were able to use the same. How does ejb3 has so specific needs not allowing it to run in the same environment? Please try the suggested solutions listed above before deciding it is unfixable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/EJBTHREE-880?page=com.atlassian.jira.p... ] Juraci Paixao Krohling commented on EJBTHREE-880: ------------------------------------------------- Thanks Alex for the tips. The original setup was already passing the $MCAST_ADDR to the builds as "udpGroup" system property. I understood (incorrectly) that it was the only thing needed, but I figured out that I need to use jgroups.udp.mcast_addr too, with the same address. I'll investigate if udpGroup should be translated to jgroups.udp.mcast_addr all the times and take the necessary actions. Just as an status: the tests *can* be completed with the current environment setup. Adding both "udpGroup" and "jgroups.udp.mcast_addr" as system properties makes them finish. For now, this item will remain open. I'll change the tests which have hardcoded localhost wherever it is possible and will list the places where I'm not sure it should be changed, for further discussion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/EJBTHREE-880?page=com.atlassian.jira.plug... ] Ondrej Zizka closed EJBTHREE-880. --------------------------------- Resolution: Out of Date 2009... and Juca left Red Hat. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira