[JBoss JIRA] (ISPN-4956) Task Management
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4956?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4956:
----------------------------------
Description:
Task Management:
- running jobs metadata (type, start, subject, caches involved, status)
- see running jobs and allow cancelling them
was:
Task Management:
- job metadata (type, start, elapsed time, subject, caches involved, status: RUNNING, FINISHED, CANCELLED)
- see running jobs and allow cancelling them
- maintain a history of executed jobs
- once we have a repository of named tasks, allow launching them
> Task Management
> ---------------
>
> Key: ISPN-4956
> URL: https://issues.jboss.org/browse/ISPN-4956
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 8.1.0.Beta2, 8.1.0.Final
>
>
> Task Management:
> - running jobs metadata (type, start, subject, caches involved, status)
> - see running jobs and allow cancelling them
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5955) FAIL_SILENTLY doesn't always prevent rollback with pessimistic transactions
by Dan Berindei (JIRA)
Dan Berindei created ISPN-5955:
----------------------------------
Summary: FAIL_SILENTLY doesn't always prevent rollback with pessimistic transactions
Key: ISPN-5955
URL: https://issues.jboss.org/browse/ISPN-5955
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.1.0.Beta1, 8.0.1.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 8.1.0.Beta2
The {{FAIL_SILENTLY}} should "prevent a failing operation from affecting any ongoing JTA transactions", but sometimes this doesn't work properly.
{{FlagsReplicationTest}} has a transaction using both {{FAIL_SILENTLY}} and {{SKIP_LOCKING}} in the same transaction:
# A {{lock(FAIL_SILENTLY)(key)}} operation fails.
Both on the primary owner and on the originator, PessimisticLockingInterceptor sends a TxCompletionNotificationCommand to all the nodes affected by the tx so far, to release the locks. This marks the transaction as completed, but doesn't mark it as rolled back.
# A {{remove(SKIP_LOCKING)(key)}} operation should then succeed.
But the operation will invoke a {{ClusteredGetCommand(key, acquireRemoteLock=true, SKIP_LOCKING)}} on both owners, which will in turn invoke locally a {{LockControlCommand(key, SKIP_LOCKING)}}.
At this point, {{TxInterceptor}} sees that the transaction is already completed, and invokes a {{RollbackCommand}} to mark it as rolled back, then remove it from the transaction table. The command still succeeds.
# The test then tries to commit the transaction. Usually, the {{PrepareCommand}} doesn't find the remote transaction in the transaction table, and it succeeds.
But some of the time, because the {{ClusteredGetCommand}} command only uses the first response, the remote transaction is not removed from the transaction table by the time the {{PrepareCommand}} is executed on one of the owners.
If that happens, the {{PrepareCommand}} executes with a remote transaction instance that's already marked for rollback, and fails when trying to put the key in the context.
{noformat}
15:42:56,736 ERROR (remote-thread-NodeF-p1112-t5:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] ISPN000136: Error executing command LockControlCommand, writing keys []
org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 0 milliseconds for key replication.FlagsReplicationTest and requestor GlobalTx:NodeG-6318:216. Lock is held by GlobalTx:NodeG-6318:215
15:42:56,802 TRACE (OOB-1,NodeF-64741:) [NonTotalOrderTxPerCacheInboundInvocationHandler] Calling perform() on ClusteredGetCommand{key=replication.FlagsReplicationTest, flags=[SKIP_LOCKING]}
15:42:56,803 TRACE (OOB-1,NodeF-64741:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] Invoked with command LockControlCommand{cache=dist, keys=[replication.FlagsReplicationTest], flags=[SKIP_LOCKING], unlock=false, gtx=GlobalTx:NodeG-6318:216} and InvocationContext [org.infinispan.context.impl.RemoteTxInvocationContext@75bf6da7]
15:42:56,822 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] Invoked with command PrepareCommand {modifications=[RemoveCommand{key=replication.FlagsReplicationTest, value=null, flags=[SKIP_LOCKING], valueMatcher=MATCH_ALWAYS}], onePhaseCommit=true, gtx=GlobalTx:NodeG-6318:216, cacheName='dist', topologyId=6} and InvocationContext [org.infinispan.context.impl.RemoteTxInvocationContext@75bf6da7]
15:42:56,832 TRACE (OOB-1,NodeF-64741:GlobalTx:NodeG-6318:216) [TxInterceptor] Rolling back remote transaction GlobalTx:NodeG-6318:216 because either already completed (true) or originator no longer in the cluster (false).
15:42:56,864 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [EntryFactoryImpl] Creating new entry for key replication.FlagsReplicationTest
15:42:56,864 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [BaseSequentialInvocationContext] Interceptor class org.infinispan.interceptors.EntryWrappingInterceptor threw exception org.infinispan.transaction.xa.InvalidTransactionException: This remote transaction GlobalTx:NodeG-6318:216 is already rolled back
15:42:56,873 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [TxInterceptor] invokeNextInterceptorAndVerifyTransaction :: originatorMissing=false, alreadyCompleted=true
15:42:56,873 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [TxInterceptor] Rolling back remote transaction GlobalTx:NodeG-6318:216 because either already completed (true) or originator no longer in the cluster (false).
{noformat}
Possible actions:
* Never try to release locks from a {{LockControlCommand}}, wait for the {{RollbackCommand}} instead. This could cause problems if the primary owner dies, the transaction tries to lock the same entry again, and the backup owner that became primary wrongfully assumes that it is a proper owner.
* Use a {{LockControlCommand(unlock=true)}} instead of a {{TxCompletionNotificationCommand}} to release the backup locks after an operation with {{FAIL_SILENTLY}} failed.
* Don't set {{acquireRemoteLock=true}} when the {{SKIP_LOCKING}} flag has been set.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5955) FAIL_SILENTLY doesn't always prevent rollback with pessimistic transactions
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5955?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5955:
-------------------------------
Status: Open (was: New)
> FAIL_SILENTLY doesn't always prevent rollback with pessimistic transactions
> ---------------------------------------------------------------------------
>
> Key: ISPN-5955
> URL: https://issues.jboss.org/browse/ISPN-5955
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.1.Final, 8.1.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 8.1.0.Beta2
>
>
> The {{FAIL_SILENTLY}} should "prevent a failing operation from affecting any ongoing JTA transactions", but sometimes this doesn't work properly.
> {{FlagsReplicationTest}} has a transaction using both {{FAIL_SILENTLY}} and {{SKIP_LOCKING}} in the same transaction:
> # A {{lock(FAIL_SILENTLY)(key)}} operation fails.
> Both on the primary owner and on the originator, PessimisticLockingInterceptor sends a TxCompletionNotificationCommand to all the nodes affected by the tx so far, to release the locks. This marks the transaction as completed, but doesn't mark it as rolled back.
> # A {{remove(SKIP_LOCKING)(key)}} operation should then succeed.
> But the operation will invoke a {{ClusteredGetCommand(key, acquireRemoteLock=true, SKIP_LOCKING)}} on both owners, which will in turn invoke locally a {{LockControlCommand(key, SKIP_LOCKING)}}.
> At this point, {{TxInterceptor}} sees that the transaction is already completed, and invokes a {{RollbackCommand}} to mark it as rolled back, then remove it from the transaction table. The command still succeeds.
> # The test then tries to commit the transaction. Usually, the {{PrepareCommand}} doesn't find the remote transaction in the transaction table, and it succeeds.
> But some of the time, because the {{ClusteredGetCommand}} command only uses the first response, the remote transaction is not removed from the transaction table by the time the {{PrepareCommand}} is executed on one of the owners.
> If that happens, the {{PrepareCommand}} executes with a remote transaction instance that's already marked for rollback, and fails when trying to put the key in the context.
> {noformat}
> 15:42:56,736 ERROR (remote-thread-NodeF-p1112-t5:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] ISPN000136: Error executing command LockControlCommand, writing keys []
> org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 0 milliseconds for key replication.FlagsReplicationTest and requestor GlobalTx:NodeG-6318:216. Lock is held by GlobalTx:NodeG-6318:215
> 15:42:56,802 TRACE (OOB-1,NodeF-64741:) [NonTotalOrderTxPerCacheInboundInvocationHandler] Calling perform() on ClusteredGetCommand{key=replication.FlagsReplicationTest, flags=[SKIP_LOCKING]}
> 15:42:56,803 TRACE (OOB-1,NodeF-64741:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] Invoked with command LockControlCommand{cache=dist, keys=[replication.FlagsReplicationTest], flags=[SKIP_LOCKING], unlock=false, gtx=GlobalTx:NodeG-6318:216} and InvocationContext [org.infinispan.context.impl.RemoteTxInvocationContext@75bf6da7]
> 15:42:56,822 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [InvocationContextInterceptor] Invoked with command PrepareCommand {modifications=[RemoveCommand{key=replication.FlagsReplicationTest, value=null, flags=[SKIP_LOCKING], valueMatcher=MATCH_ALWAYS}], onePhaseCommit=true, gtx=GlobalTx:NodeG-6318:216, cacheName='dist', topologyId=6} and InvocationContext [org.infinispan.context.impl.RemoteTxInvocationContext@75bf6da7]
> 15:42:56,832 TRACE (OOB-1,NodeF-64741:GlobalTx:NodeG-6318:216) [TxInterceptor] Rolling back remote transaction GlobalTx:NodeG-6318:216 because either already completed (true) or originator no longer in the cluster (false).
> 15:42:56,864 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [EntryFactoryImpl] Creating new entry for key replication.FlagsReplicationTest
> 15:42:56,864 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [BaseSequentialInvocationContext] Interceptor class org.infinispan.interceptors.EntryWrappingInterceptor threw exception org.infinispan.transaction.xa.InvalidTransactionException: This remote transaction GlobalTx:NodeG-6318:216 is already rolled back
> 15:42:56,873 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [TxInterceptor] invokeNextInterceptorAndVerifyTransaction :: originatorMissing=false, alreadyCompleted=true
> 15:42:56,873 TRACE (remote-thread-NodeF-p1112-t6:GlobalTx:NodeG-6318:216) [TxInterceptor] Rolling back remote transaction GlobalTx:NodeG-6318:216 because either already completed (true) or originator no longer in the cluster (false).
> {noformat}
> Possible actions:
> * Never try to release locks from a {{LockControlCommand}}, wait for the {{RollbackCommand}} instead. This could cause problems if the primary owner dies, the transaction tries to lock the same entry again, and the backup owner that became primary wrongfully assumes that it is a proper owner.
> * Use a {{LockControlCommand(unlock=true)}} instead of a {{TxCompletionNotificationCommand}} to release the backup locks after an operation with {{FAIL_SILENTLY}} failed.
> * Don't set {{acquireRemoteLock=true}} when the {{SKIP_LOCKING}} flag has been set.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-4956) Task Management
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4956?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4956:
----------------------------------
Fix Version/s: 8.1.0.Beta2
8.1.0.Final
> Task Management
> ---------------
>
> Key: ISPN-4956
> URL: https://issues.jboss.org/browse/ISPN-4956
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 8.1.0.Beta2, 8.1.0.Final
>
>
> Task Management:
> - job metadata (type, start, elapsed time, subject, caches involved, status: RUNNING, FINISHED, CANCELLED)
> - see running jobs and allow cancelling them
> - maintain a history of executed jobs
> - once we have a repository of named tasks, allow launching them
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5950) Parser sets transaction().useSynchronization to non-default value
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-5950?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-5950:
-----------------------------------
Generally speaking, Parser should parse the XML, but it should *not* contain any logic. If we can't make the configuration straight, any steps like 'this combo of attributes implies these defaults for other attributes' should get into xConfigurationBuilder.build().
> Parser sets transaction().useSynchronization to non-default value
> -----------------------------------------------------------------
>
> Key: ISPN-5950
> URL: https://issues.jboss.org/browse/ISPN-5950
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 8.0.1.Final
> Reporter: Radim Vansa
>
> Default value for transaction().useSynchronization() is false, so when the configuration is build programmatically, it is set to false. However, if I configure a non-transactional cache in XML and read the configuration, it is set to true.
> This complicates testing, when I want to compare programmatic and XML configurations, and generally it is inconsistent.
> When doing equals() operation on configurations. transaction-only attributes should not be compared if transactionMode == NONE, since they actually don't matter.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5704) Enhancements for Functional Map API
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5704?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5704:
-----------------------------------
Description:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
* Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
* Test compatibility mode
* Add more listener events: activation, passivation and expiration.
* Use check isLocal instead of `e == null` in command impls
* Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571)
* Add externalizers for primitive versions of Optional.
* ValueMatcherMode indexes in MarshallableFunctionExternalizers should be based on {{ordinal()}} calls to annotation. Also, could the core's enumeration use the annotations defined in commons?
* Add AdvancedExternalizer version for functions that takes value matcher
* Complete support for MetaCreated and MetaLastUsed (which should be separated into MetaLastModified and MetaLastAccessed)
was:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
* Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
* Test compatibility mode
* Add more listener events: activation, passivation and expiration.
* Use check isLocal instead of `e == null` in command impls
* Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571)
* Add externalizers for primitive versions of Optional.
* ValueMatcherMode indexes in MarshallableFunctionExternalizers should be based on {{ordinal()}} calls to annotation. Also, could the core's enumeration use the annotations defined in commons?
* Add AdvancedExternalizer version for functions that takes value matcher
> Enhancements for Functional Map API
> -----------------------------------
>
> Key: ISPN-5704
> URL: https://issues.jboss.org/browse/ISPN-5704
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.1.0.Final
>
>
> List of enhancements that didn't make it into 8.0:
> * Transaction support.
> * Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
> * Complete persistence support (remove many returning previous, put many returning previous, remove many)
> * Replication of per-invocation parameters.
> * Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
> * Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
> * Test compatibility mode
> * Add more listener events: activation, passivation and expiration.
> * Use check isLocal instead of `e == null` in command impls
> * Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571)
> * Add externalizers for primitive versions of Optional.
> * ValueMatcherMode indexes in MarshallableFunctionExternalizers should be based on {{ordinal()}} calls to annotation. Also, could the core's enumeration use the annotations defined in commons?
> * Add AdvancedExternalizer version for functions that takes value matcher
> * Complete support for MetaCreated and MetaLastUsed (which should be separated into MetaLastModified and MetaLastAccessed)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (ISPN-5613) Replication timeouts should show more information of the affected entries
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5613?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5613:
-----------------------------------------------
Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1243953|https://bugzilla.redhat.com/show_bug.cgi?id=1243953] from ON_QA to VERIFIED
> Replication timeouts should show more information of the affected entries
> -------------------------------------------------------------------------
>
> Key: ISPN-5613
> URL: https://issues.jboss.org/browse/ISPN-5613
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Wolf-Dieter Fink
> Assignee: Dan Berindei
> Fix For: 8.1.0.Beta1, 8.1.0.Final, 8.0.2.Final
>
>
> Typical timeouts for replication are
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread-595) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Replication timeout for jboss####-#####
> and
> ERROR ....
> Caused by: org.infinispan.util.concurrent.TimeoutException: Node jboss####-##### timed out
> The issue is that it is not possible to check what key/entry is affected.
> The cache can become inconsistent between nodes.
> There should be an information which key is affected.
> For some operations it is not possible at all as there is no information about the entries (i.e. commit) or the key is binary or custom without a valid toString() method.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months