[JBoss JIRA] (ISPN-5356) Transactional, optimistic-locked caches do not honour Flag.FAIL_SILENTLY
by Mitchell Archibald (JIRA)
[ https://issues.jboss.org/browse/ISPN-5356?page=com.atlassian.jira.plugin.... ]
Mitchell Archibald commented on ISPN-5356:
------------------------------------------
[~galder.zamarreno] sorry it's taken me so long to get to this. I noticed there was a new release, 7.2.0.CR1 since your comment, so I have reproduced using this release instead of Beta2. The way I reproduced was to set a breakpoint on {{LockManagerImpl.java:52}} and then double-submitted the request to my application once I had seen the first request had acquired the lock. This reliably produced the Exception with both 6.0.2.Final and 7.2.0.CR1.
Exception for 7.2.0.CR1:
{code}
12:07:58.740 ERROR impl.TransactionCoordinator - ISPN000255: Error while processing prepare
org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 0 milliseconds for key sql: select ...; parameters: ; named parameters: {...}; transformer: org.hibernate.transform.CacheableResultTransformer@110f2 and requestor GlobalTransaction:<null>:37:local. Lock is held by GlobalTransaction:<null>:30:local, while request came from local
at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198)
at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:178)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:111)
at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.lockAndRecord(OptimisticLockingInterceptor.java:202)
at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.visitSingleKeyCommand(OptimisticLockingInterceptor.java:197)
at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:190)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.acquireLocksVisitingCommands(OptimisticLockingInterceptor.java:261)
at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPrepareCommand(OptimisticLockingInterceptor.java:79)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:123)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:123)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:137)
at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:124)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:123)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:111)
at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:123)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:123)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:123)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:123)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:121)
at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:104)
at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:44)
at com.metiom.core.transaction.TransactionImpl.lambda$commit$2(TransactionImpl.java:115)
at com.metiom.core.transaction.TransactionImpl$$Lambda$2/13103576.accept(Unknown Source)
at com.metiom.core.transaction.TransactionImpl.forEachSynchronisation(TransactionImpl.java:264)
at com.metiom.core.transaction.TransactionImpl.commit(TransactionImpl.java:114)
at com.metiom.core.transaction.TransactionManagerImpl.commit(TransactionManagerImpl.java:142)
...
{code}
> Transactional, optimistic-locked caches do not honour Flag.FAIL_SILENTLY
> ------------------------------------------------------------------------
>
> Key: ISPN-5356
> URL: https://issues.jboss.org/browse/ISPN-5356
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.2.Final
> Environment: Infinispan 6.0.2
> Hibernate ORM 4.3.6
> Apache Tomcat 8
> JDK 1.8.0_25
> Reporter: Mitchell Archibald
> Assignee: Galder Zamarreño
> Fix For: 7.2.0.Final
>
>
> There is a related issue in the Hibernate JIRA, which can be found at:
> https://hibernate.atlassian.net/browse/HHH-7898
> However, I believe this to be an Infinispan issue, as per my analysis below.
> The following Exception is thrown when two threads are simultaneously committing a JTA transaction in which an entry has been written to Hibernate's "replicated-query" cache using the same key.
> {code}
> 10:55:02.238 ERROR saction.TransactionCoordinator - ISPN000255: Error while processing prepare
> org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [0 milliseconds] on key [sql: select ...; parameters: ...; named parameters: {...}; transformer: org.hibernate.transform.CacheableResultTransformer@110f2] for requestor [GlobalTransaction:<null>:197882:local]! Lock held by [null]
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:198)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:171)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:169)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:98)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.lockAndRecord(OptimisticLockingInterceptor.java:211)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.visitSingleKeyCommand(OptimisticLockingInterceptor.java:206)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:199)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:70)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.acquireLocksVisitingCommands(OptimisticLockingInterceptor.java:270)
> at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPrepareCommand(OptimisticLockingInterceptor.java:75)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114)
> at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:119)
> at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:101)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:44)
> at com.metiom.core.transaction.TransactionImpl.lambda$commit$0(TransactionImpl.java:115)
> at com.metiom.core.transaction.TransactionImpl$$Lambda$2/330107372.accept(Unknown Source)
> at com.metiom.core.transaction.TransactionImpl.forEachSynchronisation(TransactionImpl.java:264)
> at com.metiom.core.transaction.TransactionImpl.commit(TransactionImpl.java:114)
> at com.metiom.core.transaction.TransactionManagerImpl.commit(TransactionManagerImpl.java:142)
> at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1021)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:757)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:726)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:497)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:277)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> ...
> {code}
> The configuration for Hibernate's "replicated-query" cache is as follows (from Hibernate's infinispan-configs.xml)
> {code}
> <!-- An alternative configuration for entity/collection caching that uses replication instead of invalidation -->
> <namedCache name="replicated-entity">
> <clustering mode="replication">
> <stateTransfer fetchInMemoryState="false" timeout="20000"/>
> <sync replTimeout="20000"/>
> </clustering>
> <locking isolationLevel="READ_COMMITTED" concurrencyLevel="1000"
> lockAcquisitionTimeout="15000" useLockStriping="false"/>
> <!-- Eviction configuration. WakeupInterval defines how often the eviction thread runs, in milliseconds.
> 0 means the eviction thread will never run. A separate executor is used for eviction in each cache. -->
> <eviction maxEntries="10000" strategy="LRU"/>
> <expiration maxIdle="100000" wakeUpInterval="5000"/>
> <lazyDeserialization enabled="true"/>
> <transaction transactionMode="TRANSACTIONAL" autoCommit="false"
> lockingMode="OPTIMISTIC"/>
> </namedCache>
> {code}
> Additionally, the cache is configured programmatically with:
> * {{Flag.ZERO_LOCK_ACQUISITION_TIMEOUT}}; and
> * {{Flag.FAIL_SILENTLY}}
> The situation is that two threads are concurrently attempting to lock the same key on commit.
> * During a JTA transaction, a Hibernate query is executed, and Hibernate places a result in the query cache.
> * On commit, the {{SynchronizationAdaptor}} creates a {{PrepareCommand}}, which contains one or more "modifications", one of which is a {{PutKeyValueCommand}}. The {{SynchronizationAdapter}} invokes the {{PrepareCommand}}.
> * When visited, the {{OptimisticLockingInterceptor}} loops through the modifications held by the {{PrepareCommand}} and visits each one.
> * When the {{PutKeyValueCommand}} is visited, {{LockManagerImpl}} discovers that the key is locked, and throws {{TimeoutException}}.
> * The Exception is caught by {{InvocationContextInterceptor}}, and attempts to find out whether the command it was invoking is affected by {{Flag.FAIL_SILENTLY}}. {{PrepareCommand}} does not implement {{FlagAffectedCommand}}, so this test fails and the Exception is propagated.
> It is important to note here that the {{PutKeyValueCommand}} _does_ implement {{FlagAffectedCommand}}, and _does_ have the {{Flag.FAIL_SILENTLY}} flag set. So the problem seems to be that {{OptimisticLockingInterceptor}} is unaware that the modifications to the {{PrepareCommand}} could throw Exceptions which can be suppressed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (ISPN-1094) Map/Reduce over HotRod
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-1094?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant resolved ISPN-1094.
-----------------------------------
Resolution: Done
> Map/Reduce over HotRod
> ----------------------
>
> Key: ISPN-1094
> URL: https://issues.jboss.org/browse/ISPN-1094
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Execution and Map/Reduce, Remote Protocols
> Affects Versions: 5.0.0.FINAL
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Labels: HotRod, Map/Reduce
> Fix For: 7.2.0.Final
>
>
> Map/Reduce over HotRod. Most probably we'll settle on portable javascript code to be executable remotely.
> More info in the discussion thread.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (ISPN-5407) DefaultDataContainer is not passing eviction algorithm properly
by William Burns (JIRA)
William Burns created ISPN-5407:
-----------------------------------
Summary: DefaultDataContainer is not passing eviction algorithm properly
Key: ISPN-5407
URL: https://issues.jboss.org/browse/ISPN-5407
Project: Infinispan
Issue Type: Bug
Components: Core, Eviction
Affects Versions: 7.2.0.CR1
Reporter: William Burns
Assignee: William Burns
Priority: Critical
Fix For: 7.2.0.Final
There was a typo that is preventing the eviction algorithm from being passed in properly to the actual concurrent map underneath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month