[
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.
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