[jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-1170) Leakage of marshalling region stored in ThreadLocal causes partial state transfer to fail when multiple regions present

Brian Stansberry (JIRA) jira-events at lists.jboss.org
Mon Mar 17 12:18:01 EDT 2008


     [ http://jira.jboss.com/jira/browse/JBCACHE-1170?page=all ]

Brian Stansberry reopened JBCACHE-1170:
---------------------------------------

             
Still seeing this problem with 2.1.0.GA. Logging from a partial state transfer recipient:

2008-03-14 12:11:34,871 DEBUG [org.jboss.cache.remoting.jgroups.CacheMessageListener] (Multiplexer,tcp,192.168.1.145:7601) Setting received partial state for subroot /JSESSION/localhost/http-scoped
2008-03-14 12:11:34,872 DEBUG [org.jboss.cache.remoting.jgroups.CacheMessageListener] (Multiplexer,tcp,192.168.1.145:7601) org.jboss.cache.marshall.InactiveRegionException: Cannot unmarshall message for region /JSESSION/localhost/http-field. By default region /JSESSION/localhost/http-field is inactive.

In the 2nd statement, the region is the incorrect  /JSESSION/localhost/http-field.  Looking at the code, that tells me the state sender wrote the wrong region Fqn value to the stream.

I don't see this all the time, which makes me think maybe it is still a ThreadLocal issue. JGroups uses a thread pool, so you can get different behavior from different state transfer requests.

> Leakage of marshalling region stored in ThreadLocal causes partial state transfer to fail 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.

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

        



More information about the jboss-jira mailing list