[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years