[JBoss JIRA] (ISPN-2478) PutMapCommand not correctly removing previous types from indexes
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-2478:
-------------------------------------
Summary: PutMapCommand not correctly removing previous types from indexes
Key: ISPN-2478
URL: https://issues.jboss.org/browse/ISPN-2478
Project: Infinispan
Issue Type: Bug
Components: Querying
Affects Versions: 5.1.8.Final
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 5.2.0.CR1, 5.2.0.Final
We need to perform certain cleanup operations - potentially - on the return types of commands such as put and remove. In case of a putAll command, we're ignoring this requirement.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2454) The current SQL query that checks table existence is under optimized on big database
by Nicolas Filotto (JIRA)
Nicolas Filotto created ISPN-2454:
-------------------------------------
Summary: The current SQL query that checks table existence is under optimized on big database
Key: ISPN-2454
URL: https://issues.jboss.org/browse/ISPN-2454
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Affects Versions: 5.1.0.FINAL
Reporter: Nicolas Filotto
Assignee: Mircea Markus
Last year I proposed an enhancement allowing to use the implicit db schema to ease life of end-user, unfortunately it seems that it affects the startup time of the product when the tables contain a lot of rows. Indeed the query can take several seconds to return a result.
The idea of this task would be to optimize this query for all supported databases in order to avoid this drawback.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2431) Default task failover policy enhancements
by Erik Salter (JIRA)
Erik Salter created ISPN-2431:
---------------------------------
Summary: Default task failover policy enhancements
Key: ISPN-2431
URL: https://issues.jboss.org/browse/ISPN-2431
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Execution and Map/Reduce
Affects Versions: 5.2.0.Beta2
Reporter: Erik Salter
Assignee: Vladimir Blagojevic
The new failover policy enhancements behave differently than the 5.1 release. The default is a random failover, which causes problems in my environment due to pessimistic locks being acquired. The default policy should be "none"
Secondly, if a user specifies a key set, the failover policy should respect that. Using pessimistic locks as an example, a valid optimization would be to submit on the local data owner to avoid additional RPCs. A random node failover policy really doesn't fit in this case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2460) Allow 1PCs for synchronous xsite replication
by Erik Salter (JIRA)
Erik Salter created ISPN-2460:
---------------------------------
Summary: Allow 1PCs for synchronous xsite replication
Key: ISPN-2460
URL: https://issues.jboss.org/browse/ISPN-2460
Project: Infinispan
Issue Type: Feature Request
Components: Cross-Site Replication
Affects Versions: 5.2.0.Beta3
Reporter: Erik Salter
Assignee: Mircea Markus
We should allow a 1PC optimization for xsite synchronous replication. Since synchronous replication is performed in the originating site's transactional context and the remote locks are acquired at prepare time, we can still guarantee consistency of data.
The default should be to use 1PC. However, this feature will require a new configuration option. <backup ... use2PC="true"/> to allow the traditional 2PC to be enabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2523) NPE in BDB Store
by Vitalii Tymchyshyn (JIRA)
Vitalii Tymchyshyn created ISPN-2523:
----------------------------------------
Summary: NPE in BDB Store
Key: ISPN-2523
URL: https://issues.jboss.org/browse/ISPN-2523
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 5.1.6.FINAL
Reporter: Vitalii Tymchyshyn
Assignee: Mircea Markus
Currently org.infinispan.loaders.bdbje.BdbjeCacheStore#prepare does next things:
1) Create transaction in currentTransaction
2) Retrieve it from currentTransaction
3) Remove all transactions from currentTransaction.
This leads to race condition when one thread can do (3) between (1) and (2) in another thread. This produces:
org.infinispan.loaders.CacheLoaderException: Problem preparing transaction
at org.infinispan.loaders.bdbje.BdbjeCacheStore.convertToCacheLoaderException(BdbjeCacheStore.java:589)
at org.infinispan.loaders.bdbje.BdbjeCacheStore.prepare(BdbjeCacheStore.java:315)
at org.infinispan.loaders.bdbje.BdbjeCacheStore.prepare(BdbjeCacheStore.java:274)
at org.infinispan.interceptors.CacheStoreInterceptor.prepareCacheLoader(CacheStoreInterceptor.java:289)
at org.infinispan.interceptors.CacheStoreInterceptor.visitPrepareCommand(CacheStoreInterceptor.java:199)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:120)
at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPrepareCommand(OptimisticLockingInterceptor.java:131)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:58)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:106)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:213)
at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:85)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:132)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:91)
at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:140)
at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:120)
at org.apache.geronimo.transaction.manager.TransactionImpl.commitResource(TransactionImpl.java:688)
at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:304)
at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:250)
at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:616)[:1.6.0_24]
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:58)[73:org.springframework.osgi.core:1.2.1]
at org.springframework.osgi.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:62)[73:org.springframework.osgi.core:1.2.1]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.osgi.service.util.internal.aop.ServiceTCCLInterceptor.invokeUnprivileged(ServiceTCCLInterceptor.java:56)[73:org.springframework.osgi.core:1.2.1]
at org.springframework.osgi.service.util.internal.aop.ServiceTCCLInterceptor.invoke(ServiceTCCLInterceptor.java:39)[73:org.springframework.osgi.core:1.2.1]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.osgi.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:59)[73:org.springframework.osgi.core:1.2.1]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)[71:org.springframework.aop:3.0.6.RELEASE]
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)[71:org.springframework.aop:3.0.6.RELEASE]
at $Proxy57.commit(Unknown Source)[:]
at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1016)[808:org.infinispan.core:5.1.6.FINAL]
at org.infinispan.CacheImpl.put(CacheImpl.java:702)[808:org.infinispan.core:5.1.6.FINAL]
at org.infinispan.CacheImpl.put(CacheImpl.java:694)[808:org.infinispan.core:5.1.6.FINAL]
at org.infinispan.CacheSupport.put(CacheSupport.java:53)[808:org.infinispan.core:5.1.6.FINAL]
at com.ubs.ace.quickfix.store.InfinispanStore.updateNextTargetMsgSeqNum(InfinispanStore.java:89)[807:com.ubs.ace.quickfix-engine:1.0.0]
at com.ubs.ace.quickfix.store.InfinispanStore.incrNextTargetMsgSeqNum(InfinispanStore.java:85)[807:com.ubs.ace.quickfix-engine:1.0.0]
at quickfix.SessionState.incrNextTargetMsgSeqNum(SessionState.java:368)[811:org.apache.servicemix.bundles.quickfix:1.5.2.1]
at quickfix.Session.next(Session.java:974)[811:org.apache.servicemix.bundles.quickfix:1.5.2.1]
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)[811:org.apache.servicemix.bundles.quickfix:1.5.2.1]
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)[811:org.apache.servicemix.bundles.quickfix:1.5.2.1]
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)[811:org.apache.servicemix.bundles.quickfix:1.5.2.1]
at java.lang.Thread.run(Thread.java:679)[:1.6.0_24]
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:909)[:1.6.0_24]
at org.infinispan.loaders.bdbje.BdbjeCacheStore.prepare(BdbjeCacheStore.java:312)
... 73 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2485) DefaultExecutorService.DistributedTaskBuilder timeout(long to, TimeUnit u) doesn't use the passed to timeout
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-2485:
-----------------------------------
Summary: DefaultExecutorService.DistributedTaskBuilder timeout(long to, TimeUnit u) doesn't use the passed to timeout
Key: ISPN-2485
URL: https://issues.jboss.org/browse/ISPN-2485
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce
Reporter: Anna Manukyan
Assignee: Vladimir Blagojevic
Hi,
the issue is the following:
1. DistributedTaskBuilder is created with callable which sleeps for 10 seconds.
2. The timeout is set to DistributedTaskBuilder for 10 milliseconds.
3. Then the built DistributedTask is executed with DefaultExecutorService on the different node rather than the executorservice was attached to.
4. In 10 milliseconds, the TimeoutException should be thrown, but it doesn't.
The thing is, that although timeout is passed to timeout(long timeout, TimeUnit unit) method of DefaultExecutorService.DistributedTaskBuilder class, but the method parses and sets not the passed value, but the one which was given to task builder during initialization.
Please find the reproducing test here:
https://github.com/andyuk1986/infinispan/blob/DIST_EXEC_TESTS/core/src/te...
Please find the proposed fix here:
https://github.com/andyuk1986/infinispan/blob/DIST_EXEC_TESTS/core/src/ma... (line 734)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-1965) Some entries not available during view change
by Michal Linhard (JIRA)
Michal Linhard created ISPN-1965:
------------------------------------
Summary: Some entries not available during view change
Key: ISPN-1965
URL: https://issues.jboss.org/browse/ISPN-1965
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.3.FINAL
Reporter: Michal Linhard
Assignee: Manik Surtani
In the 4 node, dist mode, num-owners=2, elasticity test
http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/
there is a cca 90 sec period of time where clients get null responses to GET
requests on entries that should exist in the cache.
first occurence:
hyperion1139.log 05:31:01,202 286.409
last occurence:
hyperion1135.log 05:32:45,441 390.648
total occurence count: (in all 19 driver nodes)
152241
(this doesn't mean it happens for 152K keys, because each key is retried after
erroneous attempt)
data doesn't seem to be lost, because these errors cease after a while and
number of entries returns back to normal (see cache_entries.csv)
this happens approximately in the period between node0001 is killed and cluster
{node0002 - node0004} is formed (and shortly after).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month