April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5192) infinispan-remote uber jar contains 2x versions of shaded javassist packages

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5192?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5192: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1185271|https://bugzilla.redhat.com/show_bug.cgi?id=1185271] from POST to MODIFIED > infinispan-remote uber jar contains 2x versions of shaded javassist packages > ----------------------------------------------------------------------------- > > Key: ISPN-5192 > URL: https://issues.jboss.org/browse/ISPN-5192 > Project: Infinispan > Issue Type: Bug > Components: Build process, Remote Protocols > Affects Versions: 7.1.0.CR2 > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 7.2.0.Final > > > Both the shaded protostream library and the infinispan-remote uberjar package javassist. The latter should be removed. The package should be relocated to avoid conflict with containers which expose the library (i.e. weblogic) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4450) RemoteStore uses wrong classloader with rawValues

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4450?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4450: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1213834|https://bugzilla.redhat.com/show_bug.cgi?id=1213834] from POST to MODIFIED > RemoteStore uses wrong classloader with rawValues > ------------------------------------------------- > > Key: ISPN-4450 > URL: https://issues.jboss.org/browse/ISPN-4450 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.2.Final > Reporter: Dennis Reed > Assignee: Tristan Tarrant > Fix For: 7.2.0.Beta1, 7.2.0.Final > > > RemoteStore uses the wrong classloader (Infinispan's classloader instead of the caller's classloader) during deserialization when rawValues=true is set. > It uses a GenericJBossMarshaller, which is hard-coded to only look in Infinispan's classloader). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[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} >  > <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 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)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5407) DefaultDataContainer is not passing eviction algorithm properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5407?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5407: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1214889|https://bugzilla.redhat.com/show_bug.cgi?id=1214889] from NEW to CLOSED > 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)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5022) Create a cachestore archetype

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5022?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-5022. ----------------------------------- Resolution: Done https://github.com/infinispan/custom-cache-store-archetype/ > Create a cachestore archetype > ----------------------------- > > Key: ISPN-5022 > URL: https://issues.jboss.org/browse/ISPN-5022 > Project: Infinispan > Issue Type: Feature Request > Components: Demos and Tutorials, Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > > We should have an AdvancedCacheWriter archetype which describes how to implement a proper cache store. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4442) Package remoting jars for the embedded cli client

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4442?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4442: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Package remoting jars for the embedded cli client > ------------------------------------------------- > > Key: ISPN-4442 > URL: https://issues.jboss.org/browse/ISPN-4442 > Project: Infinispan > Issue Type: Bug > Components: CLI > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[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)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4999) Introduce a Listener interface

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4999?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4999: ----------------------------------------------- Ion Savin <isavin(a)redhat.com> changed the Status of [bug 1214694|https://bugzilla.redhat.com/show_bug.cgi?id=1214694] from NEW to POST > Introduce a Listener interface > ------------------------------ > > Key: ISPN-4999 > URL: https://issues.jboss.org/browse/ISPN-4999 > Project: Infinispan > Issue Type: Feature Request > Reporter: Jim Crossley > > The notifications API is strictly annotations-based, which is awkward for more dynamic, non-Java JVM languages. I think a Listener interface with a single method taking an Event parameter would be a far simpler approach. It wouldn't have to replace the current API, merely complement it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5407) DefaultDataContainer is not passing eviction algorithm properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5407?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5407: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1214889 > 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)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5407) DefaultDataContainer is not passing eviction algorithm properly

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5407?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5407: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3415 > 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)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2015