[infinispan-dev] 2 questions , may be have one bug

Manik Surtani manik at jboss.org
Tue Jun 29 11:50:48 EDT 2010


Hi Fang.  

In future please use the user forums for such questions; this list is for people developing on/extending Infinispan.

Re: the NPE, please see http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/Cache.html

	"Also, like many ConcurrentMap implementations, Cache does not support the use of null keys or values."

although the NPE should be more consistent and the null check should happen much earlier on.

Regarding eager locking, this new entry is created just to hold on to the lock.  The entry is discarded if the replace call should fail.

Cheers
Manik

On 20 Jun 2010, at 08:42, FangYuan wrote:

> Hi guys:
>        I met two problem . Could someone help me?
>        The first problme is NullPointerException when using replaceAsync
> function . The stacks like :
> java.lang.NullPointerException
>         at
> org.infinispan.util.concurrent.locks.containers.AbstractStripedLockContainer.hash(AbstractStripedLockContainer.java:65)
>         at
> org.infinispan.util.concurrent.locks.containers.AbstractStripedLockContainer.hashToIndex(AbstractStripedLockContainer.java:54)
>         at
> org.infinispan.util.concurrent.locks.containers.OwnableReentrantStripedLockContainer.getLock(OwnableReentrantStripedLockContainer.java:62)
>         at
> org.infinispan.util.concurrent.locks.containers.OwnableReentrantStripedLockContainer.ownsLock(OwnableReentrantStripedLockContainer.java:66)
>         at
> org.infinispan.util.concurrent.locks.LockManagerImpl.ownsLock(LockManagerImpl.java:122)
>         at
> org.infinispan.util.concurrent.locks.DeadlockDetectingLockManager.localVsLocalDld(DeadlockDetectingLockManager.java:94)
>         at
> org.infinispan.util.concurrent.locks.DeadlockDetectingLockManager.lockAndRecord(DeadlockDetectingLockManager.java:78)
>         at
> org.infinispan.container.EntryFactoryImpl.acquireLock(EntryFactoryImpl.java:205)
>         at
> org.infinispan.container.EntryFactoryImpl.wrapEntryForWriting(EntryFactoryImpl.java:148)
>         at
> org.infinispan.container.EntryFactoryImpl.wrapEntryForWriting(EntryFactoryImpl.java:106)
>         at
> org.infinispan.interceptors.LockingInterceptor.visitLockControlCommand(LockingInterceptor.java:146)
>         at
> org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
>         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.visitLockControlCommand(AbstractVisitor.java:147)
>         at
> org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
>         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.visitLockControlCommand(AbstractVisitor.java:147)
>         at
> org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
>         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.visitLockControlCommand(AbstractVisitor.java:147)
>         at
> org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
>         at
> org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
>         at
> org.infinispan.interceptors.ImplicitEagerLockingInterceptor.lockEagerly(ImplicitEagerLockingInterceptor.java:96)
>         at
> org.infinispan.interceptors.ImplicitEagerLockingInterceptor.visitReplaceCommand(ImplicitEagerLockingInterceptor.java:61)
>         at
> org.infinispan.commands.write.ReplaceCommand.acceptVisitor(ReplaceCommand.java:58)
>         at
> org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
>         at
> org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:183)
>         at
> org.infinispan.interceptors.TxInterceptor.visitReplaceCommand(TxInterceptor.java:142)
>         at
> org.infinispan.commands.write.ReplaceCommand.acceptVisitor(ReplaceCommand.java:58)
>         at
> org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
>         at
> org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:48)
>         at
> org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:34)
>         at
> org.infinispan.commands.AbstractVisitor.visitReplaceCommand(AbstractVisitor.java:65)
>         at
> org.infinispan.commands.write.ReplaceCommand.acceptVisitor(ReplaceCommand.java:58)
>         at
> org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:269)
>         at
> org.infinispan.CacheDelegate.replaceAsync(CacheDelegate.java:590)
>         at
> org.infinispan.CacheDelegate.replaceAsync(CacheDelegate.java:579)
> 
> 
> 
> I have checked the source code of infinispan . The reason is the key
> value is null, when using null to get hash value jvm will throw a
> nullpointerexcetpoin. But I have check the input value from our log and
> infinispan's log (trace level). It seems this case will only happened in
> multi-thread environment. I think the problem is in lockAndRecord
> function of DeadlockDetectingLockManager class.
> lockOwnerTx.getLockIntention is null.
> 
> I don't know the reason why intention is null and how to fix this
> problem . My temp solution is adding a judgement that when only
> intention is not null localVsLocalDld function will be called . Is that
> ok?
> 
> 
> The second problem is replaceAsync function will create a new entry when
> cache is in eager locking mode. I think replaceAsync should not have two
> different behaviors in different mode . And also I think the eager
> locking is only used for get global lock when infinispan run in cluster
> mode . I don't know why replaceAsync function related to it . Also I
> have check the code .
> 
> if (cacheEntry != null) {
>            if (trace) log.trace("Retrieved from container.");
>            // exists in cache! Just acquire lock if needed, and wrap.
>            // do we need a lock?
>            boolean needToCopy = alreadyLocked || lockAcquired ||
> ctx.hasFlag(Flag.SKIP_LOCKING); // even if we do not acquire a lock, if
> skip-locking is enabled we should copy
>            mvccEntry = createWrappedEntry(key, cacheEntry.getValue(),
> false, false, cacheEntry.getLifespan());
>            ctx.putLookedUpEntry(key, mvccEntry);
>            if (needToCopy) mvccEntry.copyForUpdate(container,
> writeSkewCheck);
>         } else if (createIfAbsent) {
>            // this is the *only* point where new entries can be
> created!!
>            if (trace) log.trace("Creating new entry.");
>            // now to lock and create the entry. Lock first to prevent
> concurrent creation!
>            notifier.notifyCacheEntryCreated(key, true, ctx);
>            mvccEntry = createWrappedEntry(key, null, true, false, -1);
>            mvccEntry.setCreated(true);
>            ctx.putLookedUpEntry(key, mvccEntry);
>            mvccEntry.copyForUpdate(container, writeSkewCheck);
>            notifier.notifyCacheEntryCreated(key, false, ctx);
>         } else {
>            releaseLock(key);
>         }
> 
> Thanks .
> 
> 
> The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org







More information about the infinispan-dev mailing list