December 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2573) Make the default expiration flags in the HotRod client hidden from the API

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2573: ------------------------------------- Summary: Make the default expiration flags in the HotRod client hidden from the API Key: ISPN-2573 URL: https://issues.jboss.org/browse/ISPN-2573 Project: Infinispan Issue Type: Enhancement Reporter: Tristan Tarrant Assignee: Mircea Markus Also take the opportunity to introduce a DecoratedRemoteCache to avoid using ThreadLocal access for the flags -- 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

11 years, 4 months

2
3
0 / 0

[JBoss JIRA] (ISPN-2568) Javadoc: Missing some documentations

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2568: ---------------------------------- Summary: Javadoc: Missing some documentations Key: ISPN-2568 URL: https://issues.jboss.org/browse/ISPN-2568 Project: Infinispan Issue Type: Enhancement Components: Core API Affects Versions: 5.2.0.Beta4 Reporter: Thomas Fromm Assignee: Mircea Markus Priority: Minor When browsing ajavdoc of infinispan I miss following stuff: Important for the Overview: 1) Package description of org.infinispan.config should contain information that this is deprecated. 2) org.infinispan.configuration package description in general and hints where to start with (e.g. at the Builder classes). Also the link to the generated configuration reference. 3) The configuration reference is missing in general. e.g. http://docs.jboss.org/infinispan/5.2/apidocs/config.html#ce_infinispan_de... -- 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

11 years, 4 months

2
1
0 / 0

[JBoss JIRA] (ISPN-2435) Cache#replace(key, old, new) method doesn't check old value on non-local invocations

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2435: ------------------------------------- Summary: Cache#replace(key, old, new) method doesn't check old value on non-local invocations Key: ISPN-2435 URL: https://issues.jboss.org/browse/ISPN-2435 Project: Infinispan Issue Type: Bug Components: Core API, Distributed Cache Affects Versions: 5.1.8.Final, 5.2.0.Beta2 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Critical Fix For: 5.2.0.CR1 -- 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

11 years, 4 months

2
8
0 / 0

[JBoss JIRA] (ISPN-2581) StateTransferManagerImpl.waitForInitialStateTransferToComplete() returns too soon

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2581: ---------------------------------- Summary: StateTransferManagerImpl.waitForInitialStateTransferToComplete() returns too soon Key: ISPN-2581 URL: https://issues.jboss.org/browse/ISPN-2581 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Beta5 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 5.2.0.CR1 StateTransferManagerImpl.waitForInitialStateTransferToComplete() returns as soon as a joining node confirmed to the coordinator that it received all the data it needed (see STMI.notifyEndOfTopologyUpdate()). It should return only after the coordinator has confirmed the end of the rebalance with a new topology update (see STMI.doTopologyUpdate()). This should make it more likely for the tests suite clusters to be in a stable state by the time the test starts, and should help with the random state transfer-related failures in non-state transfer tests. Instead we should make sure that we do have tests that check forwarding behaviour explicitly. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2561) RejectedExecutionException thrown from StaleTransactionCleanupService during cache shutdown

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2561: ----------------------------------- Summary: RejectedExecutionException thrown from StaleTransactionCleanupService during cache shutdown Key: ISPN-2561 URL: https://issues.jboss.org/browse/ISPN-2561 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.2.0.Beta4 Reporter: Adrian Nistor Assignee: Mircea Markus Priority: Minor Fix For: 5.2.0.Final We should not submit stale transaction cleanup tasks after we started shutdown. This exception is now caught and logged. It does not impact functionality but it clutters the logs a lot. {noformat} 2012-11-26 17:49:07,855 ERROR [org.infinispan.transaction.StaleTransactionCleanupService] (OOB-2,ISPN,NodeB-36237) Unable to submit task to executor java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:215) at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:397) at java.util.concurrent.ScheduledThreadPoolExecutor.submit(ScheduledThreadPoolExecutor.java:470) at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:600) at org.infinispan.transaction.StaleTransactionCleanupService.cleanTxForWhichTheOwnerLeft(StaleTransactionCleanupService.java:91) at org.infinispan.transaction.StaleTransactionCleanupService.onTopologyChange(StaleTransactionCleanupService.java:80) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200) at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:44) at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:221) at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyTopologyChanged(CacheNotifierImpl.java:356) at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:191) at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:60) at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:119) at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:194) at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165) at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:252) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:604) at org.jgroups.JChannel.up(JChannel.java:688) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) at org.jgroups.protocols.FC.up(FC.java:479) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432) at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721) at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574) at org.jgroups.protocols.Discovery.up(Discovery.java:359) at org.jgroups.protocols.TP.passMessageUp(TP.java:1294) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1857) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1830) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) {noformat} -- 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

11 years, 4 months

2
1
0 / 0

[JBoss JIRA] (ISPN-2384) Entry lost after Eviction/Passivation

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2384: ---------------------------------- Summary: Entry lost after Eviction/Passivation Key: ISPN-2384 URL: https://issues.jboss.org/browse/ISPN-2384 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 5.2.0.Beta1 Reporter: Thomas Fromm Assignee: Mircea Markus Attachments: eviction.log Cache is LOCAL, eviction + passivation enabled. After put the entry gets passivated, shortly after an other thread tries to get() the entry, but get null. Attached a log file. The key is "50b2c9e7-0a38-0043-01fc-76cdf49fa2ce". Tried JDBC and File store with same results, also sync/async store tested. It happens under some load. -- 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

11 years, 4 months

4
15
0 / 0

[JBoss JIRA] (ISPN-2362) Potential inconsistency during NBST

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2362: ----------------------------------- Summary: Potential inconsistency during NBST Key: ISPN-2362 URL: https://issues.jboss.org/browse/ISPN-2362 Project: Infinispan Issue Type: Feature Request Components: State transfer Affects Versions: 5.2.0.Alpha3 Reporter: Mircea Markus Assignee: Dan Berindei Priority: Critical Fix For: 5.2.0.CR1 The NBST functionality leaves place to inconsistencies during removals: 1. the joiner first requests transaction data 2. after all transaction data is integrated (i.e. tx is prepared on the state receiver node) it requests the rest of the data (from data container) 3. in order not to override the data from transactions which is more recent (transactions at step 1 might have been committed during step 2), the data at 2 inserts data in the cache with putIfAbsent. Whilst this prevents from overriding newer values as written by transactions, it doesn't guard against the situation in which the tx removed data. So it is possible for deleted data a to resurrect. A possible solution to this inconsistency issue is by using tombstones for the duration of the state transfer. -- 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

11 years, 4 months

2
11
0 / 0

[JBoss JIRA] (ISPN-2469) lock() producing timeout exceptions after nodes have left

by Carsten Lohmann (JIRA)

Carsten Lohmann created ISPN-2469: ------------------------------------- Summary: lock() producing timeout exceptions after nodes have left Key: ISPN-2469 URL: https://issues.jboss.org/browse/ISPN-2469 Project: Infinispan Issue Type: Bug Components: Locking and Concurrency Affects Versions: 5.2.0.Beta3 Reporter: Carsten Lohmann Assignee: Mircea Markus Attachments: LockAfterNodesLeftTest.java I have a replicated cache with locking mode set to PESSIMISTIC on which I use explicit locking before putting some value. After nodes have left the cluster, this does not work anymore and I get TimeoutExceptions like: {noformat} 2012-11-02 11:14:12,057 ERROR [InvocationContextInterceptor] (LockAfterNodesLeftTest.Putter-0) ISPN000136: Execution error org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on key on behalf of transaction GlobalTransaction:<NodeA-31597>:4:local. Lock is being held by GlobalTransaction:<NodeA-31597>:4:local at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.newTimeoutException(AbstractTxLockingInterceptor.java:230) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.waitForTransactionsToComplete(AbstractTxLockingInterceptor.java:210) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:175) at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPutKeyValueCommand(PessimisticLockingInterceptor.java:120) {noformat} This can be reproduced with the attached unit test. (Use NUM_NODES_TO_STOP_FOR_TEST=0 to not stop any nodes - the test succeeds in that 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

11 years, 4 months

3
17
0 / 0

[JBoss JIRA] (ISPN-2502) State transfer can lead to inconsitencies because it applies data using putIfAbsent without locking

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2502: ----------------------------------- Summary: State transfer can lead to inconsitencies because it applies data using putIfAbsent without locking Key: ISPN-2502 URL: https://issues.jboss.org/browse/ISPN-2502 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Beta3 Reporter: Adrian Nistor Assignee: Adrian Nistor Priority: Critical Fix For: 5.2.0.Final -- 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

11 years, 4 months

2
7
0 / 0

[JBoss JIRA] (ISPN-2483) State transfer issue with the transactions for which the originator has crashed

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2483: ----------------------------------- Summary: State transfer issue with the transactions for which the originator has crashed Key: ISPN-2483 URL: https://issues.jboss.org/browse/ISPN-2483 Project: Infinispan Issue Type: Feature Request Components: State transfer, Transactions Affects Versions: 5.1.8.Final, 5.2.0.Beta3 Reporter: Mircea Markus Assignee: Mircea Markus Priority: Critical Fix For: 5.2.0.CR1, 5.2.0.Final State transfer migrates and prepares the transactions for which the originator has left. On the receiving node, this results in the transaction being prepared and acquiring backup locks which are never released (unless manual intervention). This should behave as follows: - if there's no recovery enabled, the state producer should not send such transactions but drop them - if recovery is enabled these transactions should be sent across. They shouldn't be prepared/acquire backup locks, but be placed in the recovery cache (see RecoveryManagerImpl.inDoubtTransactions) -- 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

11 years, 4 months

2
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2012