[
https://issues.jboss.org/browse/ISPN-1384?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1384:
----------------------------------------
Hmmm, this could be two problems. Michal, in the scenario you present above, which thread
would throw the NPE and where? According to JBPAPP-7173, the NPE is thrown by Thread1
(it's logged by InvocationContextInterceptor) but your scenario above does not explain
how the NPE could be thrown by Thread1.
If anything, it would explain how Thread2 could potentially throw an NPE because it can
send a request to the cache when it's defined and not started.
InboundInvocationHandlerImpl could wait for the component registry to be started, rather
than just wait for it to be defined, but it'd need some thought cos this code is key
for command handling. Also, the code in InboundInvocationHandlerImpl is likely to change
as a result of ISPN-1324, which should at least result in no NPEs by Thread2. So, I would
not worry about Thread2 too much here.
What's more important is figuring out how Thread1 could throw an NPE.
Remote processes can access cache before it's started
-----------------------------------------------------
Key: ISPN-1384
URL:
https://issues.jboss.org/browse/ISPN-1384
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.0.1.FINAL
Reporter: Michal Linhard
Assignee: Galder Zamarreño
Fix For: 5.1.0.ALPHA2 , 5.1.0.FINAL
Attachments: edg-thread-problem.zip
version:
Infinispan 5.1.0-SNAPSHOT last commit fc94449eec33469057614a13cbfe59e4f4e855fd Author:
Michal Linhard <michal(a)linhard.sk> Date: Wed Sep 7 13:42:32 2011 +0200
The mechanism that locks cache while it is being created and started is not in effect
when accessing the cache remotely.
The problem happens in this scenario:
1. Thread1 does DefaultCacheManager.getCache and starts the cache to the point where
ComponentRegistry for that cache exists, but the cache is not yet started
2. Thread2 (originating in JGroups layer) does call via InboundInvocationHandlerImpl and
gets hold of the ComponentRegistry for the cache and calls perform() on the command
(note that the Thread2 doesn't obtain the cache via DefaultCacheManager.getCache and
therefore it doesn't have to wait on the cacheCreateLock or CacheWrapper lock)
the problem manifests itself in JBPAPP-7173 where using unstarted CacheLoaderInterceptor
leads to NPE.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira