[ https://jira.jboss.org/browse/JBAS-8655?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz updated JBAS-8655: -------------------------------------- Summary: Caches in session-based tests not correctly initialised (e.g. org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedInterval) (was: CLONE - twiddle does not correctly handle IPv6 addresses) Description: Here is what happens when we execute org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedInterval: (i) CacheConfigTestSetup, a wrapper for the test case, sets up two Infinispan caches by calling SessionTestUtil.createCacheContainer. Before these calls, Brian used JGroupsSystemPropertySupport to temporarily set jgroups.bind_addr, jgroups.udp.mcast_addr and jgroups.udp.mcast_port to values associated with the testsuite's jbosstest.cluster.node1 system property and jbosstest.udpGroup property. He restores the original values after the caches have been created. (ii) once the test starts, it calls SessionTestUtil.createManager() to create two instances of org.jboss.web.tomcat.service.session.JBossCacheManager, the session managers used in clustering. These are passed the cahces which were created earlier. The calls to createManager are not preceeded and followed by calls to JGroupsSystemPropertySupport. The tests then run. The bug is that the caches are not actually started when CacheConfigTestSetup is called, but they are started when SessionTestUtil.createManager is called. So the correct system properties are not getting picked up. I'm guessing that this is a change from JBC behaviour. If I preceed the calls to createManager with JGroupsSystemPropertySupport calls, the caches get intilaised correctly and the tests pass on QA lab hosts which they did not previously. Looking at the logs, I can see the correct addresses. I can't explain why the test passed on my machine and not on the QA lab machines. was: The test cases org.jboss.test.util.test.TwiddleUnitTestCase.{testGet, testInvoke} are failing. One problem is that the twiddle option -o is not correctly handling IPv6 addresses; for example: [rachmatowicz@soa3 bin]$ ./twiddle.sh -o fec0:0:a16:ffff::13 get "jboss.system:type=Server" Started 15:17:53,066 ERROR [Twiddle] Exec failed org.jboss.util.NestedRuntimeException: For input string: "0:a16:ffff::13:1090"; - nested throwable: (java.lang.NumberFormatException: For input string: "0:a16:ffff::13:1090") at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:208) at org.jboss.console.twiddle.command.MBeanServerCommand.getMBeanServer(MBeanServerCommand.java:64) at org.jboss.console.twiddle.command.GetCommand.execute(GetCommand.java:149) at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:357) Caused by: java.lang.NumberFormatException: For input string: "0:a16:ffff::13:1090" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:458) at java.lang.Integer.parseInt(Integer.java:499) at com.sun.jndi.url.rmi.rmiURLContext.getRootURLContext(rmiURLContext.java:86) at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:182) at javax.naming.InitialContext.lookup(InitialContext.java:392) at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1886) at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1856) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at org.jboss.console.twiddle.Twiddle.createMBeanServerConnection(Twiddle.java:309) at org.jboss.console.twiddle.Twiddle.connect(Twiddle.java:318) at org.jboss.console.twiddle.Twiddle.access$400(Twiddle.java:60) at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:204) ... 3 more This is a typical IPv6 URL creation issue, as the issue can be fixed by surrouning the IPv6 address literal in square brackets: [rachmatowicz@soa3 bin]$ ./twiddle.sh -o [fec0:0:a16:ffff::13] get "jboss.system:type=Server" Started Started=true -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-8655?page=com.atlassian.jira.plugin.sy... ] Richard Achmatowicz commented on JBAS-8655: ------------------------------------------- Comment from e-mail message from Paul Ferraro: At root, the issue is that channels are not started until the 1st cache is started within a given cache manager - so, as you've witnessed, any test utilizing CacheConfigTestSetup won't use the correct jgroups system properties. The easiest workaround is to simply request the default cache within CacheConfigTestSetup.setup(), which will start the default cache. I'm verifying that this solves the issue without breaking anything and will commit to trunk shortly, assuming all goes well. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira