[jboss-jira] [JBoss JIRA] Updated: (JBAS-8655) Caches in session-based tests not correctly initialised (e.g. org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedInterval)

Richard Achmatowicz (JIRA) jira-events at lists.jboss.org
Mon Nov 22 16:15:54 EST 2010 

     [ https://jira.jboss.org/browse/JBAS-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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 at 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 at soa3 bin]$ ./twiddle.sh -o [fec0:0:a16:ffff::13] get "jboss.system:type=Server" Started
Started=true
 



> Caches in session-based tests not correctly initialised (e.g. org.jboss.test.cluster.defaultcfg.simpleweb.test.SessionBasedMaxUnreplicatedInterval)
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8655
>                 URL: https://jira.jboss.org/browse/JBAS-8655
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Integration
>    Affects Versions: 6.0.0.M4
>            Reporter: Richard Achmatowicz
>            Assignee: Shelly McGowan
>             Fix For: TBD-6.x
>
>
> 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. 

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

More information about the jboss-jira mailing list