[infinispan-issues] [JBoss JIRA] Updated: (ISPN-635) NPE on acquire lock LockManagerImpl.lockAndRecord

[Galder Zamarreño (JIRA)]

     [ https://jira.jboss.org/browse/ISPN-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galder Zamarreño updated ISPN-635:
----------------------------------

    Attachment: More_sophisticated_fix_with_lock_per_cache_name.patch


Here's a more sophisticated approach with a lock container for different cache names which allows for distinctly named caches to be created in paralel. One doubt I have is whether the following code should be inside or outside the lock acquisition:

      if (caches.containsKey(cacheName))
         return caches.get(cacheName);

If it's outside, as within the patch, the downside is that if two requests come for the same cache, there will be two attempts to create a cache via InternalCacheFactory().createCache but only one of those caches will be started cos the second will use the cache already put in caches. Creating caches, which primarily requires wiring AdvancedCache and CacheJmxRegistration components does not appear to be that expensive.

If these statements are moved into the lock section, the major downside is that requests to retrieve already started caches require unnecessary lock acquisition and hence, concurrent requests like this would be serialized. This seems to me a bigger performance hit compared to the other option, so I'm sticking with this.

Thoughts?

> NPE on acquire lock LockManagerImpl.lockAndRecord
> -------------------------------------------------
>
>                 Key: ISPN-635
>                 URL: https://jira.jboss.org/browse/ISPN-635
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Locking and Concurrency
>    Affects Versions: 4.1.0.Final
>            Reporter: Sanne Grinovero
>            Assignee: Galder Zamarreño
>             Fix For: 4.2.0.BETA1
>
>         Attachments: ConcurrentCacheStartupTest.java, More_sophisticated_fix_with_lock_per_cache_name.patch, Too_restrictive_fix.patch
>
>
> I've seen this happening only once, still it's quite puzzling. Maybe proper visiblity of the variables is not guaranteed?
> java.lang.NullPointerException
> 	at org.infinispan.util.concurrent.locks.LockManagerImpl.lockAndRecord(LockManagerImpl.java:83)
> 	at org.infinispan.container.EntryFactoryImpl.acquireLock(EntryFactoryImpl.java:210)
> 	at org.infinispan.container.EntryFactoryImpl.wrapEntryForWriting(EntryFactoryImpl.java:153)
> 	at org.infinispan.container.EntryFactoryImpl.wrapEntryForWriting(EntryFactoryImpl.java:106)
> 	at org.infinispan.interceptors.LockingInterceptor.visitPutKeyValueCommand(LockingInterceptor.java:197)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> 	at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:183)
> 	at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:132)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> 	at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:113)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:57)
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:38)
> 	at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:273)
> 	at org.infinispan.CacheDelegate.put(CacheDelegate.java:429)
> 	at org.infinispan.CacheSupport.put(CacheSupport.java:28)
> 	at com.atlassian.jira.propertyset.PropertySetCache.setObject(PropertySetCache.java:205)
> 	at com.atlassian.jira.propertyset.JiraCachingPropertySet.getString(JiraCachingPropertySet.java:647)
> 	at com.opensymphony.user.User.getFullName(User.java:86)
> 	at com.atlassian.jira.user.util.UserUtilImpl.getDisplayableNameSafely(UserUtilImpl.java:573)
> 	at com.atlassian.jira.plugin.profile.ProfileLinkUserFormat.getInitialParams(ProfileLinkUserFormat.java:47)
> 	at com.atlassian.jira.plugin.profile.ProfileLinkUserFormat.format(ProfileLinkUserFormat.java:32)
> 	at com.atlassian.jira.plugin.profile.DefaultUserFormatManager.formatUser(DefaultUserFormatManager.java:62)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira