Discussion of ongoing problems with http://jira.jboss.org/jira/browse/JBCACHE-1170 . Possible cause, from org.jgroups.blocks.RequestCorrelator.handleRequest() through which all RPCs come: | try { | retval=request_handler.handle(req); | } | catch(Throwable t) { | if(log.isErrorEnabled()) log.error("error invoking method", t); | retval=t; | } | | if(!hdr.rsp_expected) // asynchronous call, we don't need to send a response; terminate call here | return; | | if(transport == null) { | if(log.isErrorEnabled()) log.error("failure sending response; no transport available"); | return; | } | | // changed (bela Feb 20 2004): catch exception and return exception | try { // retval could be an exception, or a real value | rsp_buf=marshaller != null? marshaller.objectToByteBuffer(retval) : Util.objectToByteBuffer(retval); | The first try block calls into the JBC code and ends up calling into the code that sets the CacheMarshaller200.regionForRemoteCall ThreadLocal. Last try block again calls into the JBC response marshalling code, which clears the ThreadLocal. Problem is the 2 return calls in between, particularly the 1st which will cause the method to return for every ASYNC RPC w/o clearing the ThreadLocal. This is a private method, so there's no clean way to override it to ensure the TL is cleared. Perhaps InactiveRegionAwareRpcDispatcher can clear the TL if the return value is null. That's a fragile mechanism to try to guesstimate what returns are possibly async. Mostly just a cleanup attempt. A separate question is why the partial state transfer call isn't setting the TL to the correct value. Ah, right, it's not RPC based so the state transfer request doesn't go through the marshaller. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137144#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...