[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1170) Partial state transfer fails when multiple regions present

Partial state transfer fails when multiple regions present ---------------------------------------------------------- Key: JBCACHE-1170 URL: http://jira.jboss.com/jira/browse/JBCACHE-1170 Project: JBoss Cache Issue Type: Bug Security Level: Public(Everyone can see) Affects Versions: 2.0.0.GA Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.1.0.GA, 2.1.0.CR1 The partial state transfer mechanism is getting confused about the Fqn of the region being transferred. Following is logging from the AS test org.jboss.test.multicfg.web.field.test.StateTransferUnitTestCase. Test is trying to activate region /JSESSION/localhost/http-scoped; logging is from the the node that is generating and returning the state: 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.VersionAwareMarshaller] Wrote version 20 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Region based call. Using region /JSESSION/localhost/http-field 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Marshalling object true 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.marshall.CacheMarshaller200] Writing region /JSESSION/localhost/http-field to stream 2007-08-23 17:02:21,162 DEBUG [org.jboss.cache.statetransfer.StateTransferManager] locking the /JSESSION/localhost/http-scoped subtree to return the in-memory (transient) state The second line shows the problem -- "/JSESSION/localhost/http-field" is written to the stream; it should be "/JSESSION/localhost/http-scoped", or perhaps nothing at all. Tracing this, the problem seems to be in CacheMarshaller200.objectToObjectStream(Object o, ObjectOutputStream out). Method is treating 'o' as a return value from a MethodCall and pulling the Fqn to write to the stream from a ThreadLocal. Two problems: 1) This shows that a value is being leaked to the ThreadLocal. We need to clean up the ThreadLocal properly. 2) Need to ensure that the right Fqn gets written. In the logging above, the object being written is actually boolean 'true' so I think no Fqn at all is needed. Need to check if just not writing an Fqn affects anything. If not, just cleaning up the ThreadLocal should work.