[JBoss JIRA] (ISPN-1556) Ablity to test and acquire lock if available, without aborting the txn if not available
5:23 p.m.
Ablity to test and acquire lock if available, without aborting the txn if not available
---------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Manik Surtani
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results in
the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other
tasks.
--
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
5:23 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Gary Brown updated ISPN-1556:
-----------------------------
Summary: Ability to test and acquire lock if available, without aborting the txn if
not available (was: Ablity to test and acquire lock if available, without aborting the
txn if not available)
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Manik Surtani
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
5:33 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Gary Brown commented on ISPN-1556:
----------------------------------
Sorry just found ISPN-664 which suggests atleast part of this functionality is there - I
must have consulted an older version of the API before.
However in my experiments I had tried FAIL_SILENT flag, but the xa transaction was
aborted.
I'll double check again, and close the issue if works - otherwise I guess it should be
a bug rather than feature request.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Manik Surtani
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
9:41 a.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1556:
----------------------------------------
Well, the lock timeout will only abort the transaction if you rollback the transaction
yourself? I mean, if you're managing the transaction, you can catch the exception, do
something about it, and then let the transaction carry on if needed?
Infinispan will only rollback the transaction if you're running with autoCommit on,
which result, if no tx are running, for each cache operation to start a brand new tx and
commit/rollback when the cache operation finishes.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Manik Surtani
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
11:03 a.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Gary Brown commented on ISPN-1556:
----------------------------------
Probably best if I provide more information, to see where the problem may be.
This is the cache configuration in AS7.1.0.Alpha2:
{code:xml}
<local-cache name="conversationDetails">
<eviction strategy="NONE" max-entries="10000"/>
<locking acquire-timeout="10000"/>
</local-cache>
{code}
In the code I obtain the cache and set the flags:
{code}
org.infinispan.Cache<ConversationId,ConversationDetails> conversationDetails=
_container.getCache("conversationDetails");
_conversationDetails = conversationDetails.getAdvancedCache()
.withFlags(Flag.FAIL_SILENTLY, Flag.ZERO_LOCK_ACQUISITION_TIMEOUT);
{code}
I then test the lock before doing the replace ....
{code}
try {
if (_conversationDetails.lock(result.getConversationId())) {
_conversationDetails.replace(result.getConversationId(), details);
} else {
// Trigger retry for this event
....
}
} catch(org.infinispan.util.concurrent.TimeoutException te) {
// Trigger retry for this event
....
}
{code}
First problem is that the TimeoutException is being thrown - according to ISPN-664 if the
fail silent flag was set, it shouldn't throw an exception. But also the zero ms
timeout flag is set, but as you will see from the logs, it is timing out after 10 seconds,
which is the parameter in the config file - so looks like the flags are being ignored?
As you will also see from the log, after the exception occurs, subsequent 'get'
operations fail due to an IllegalState exception on the transaction.
{code}
09:32:52,863 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Thread-21
(group:HornetQ-client-global-threads-5114937)) ISPN000136: Execution error:
org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds]
on key [id-2401891321040471266] for requestor [GlobalTransaction:<null>:91:local]!
Lock held by [GlobalTransaction:<null>:81:local]
at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:207)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:190)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:111)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeysForLockCommand(AbstractTxLockingInterceptor.java:133)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitLockControlCommand(AbstractTxLockingInterceptor.java:118)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:142)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:154)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:142)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:181)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:137)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:142)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:154)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:142)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:104)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:69)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:142)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:318)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at org.infinispan.CacheImpl.lock(CacheImpl.java:456)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at org.infinispan.CacheImpl.lock(CacheImpl.java:443)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.AbstractDelegatingAdvancedCache.lock(AbstractDelegatingAdvancedCache.java:145)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.savara.sam.ams.conversations.ConversationManager.processActivity(ConversationManager.java:187)
[activity-monitor-server.jar:]
at
org.savara.sam.ams.conversations.ConversationManager.processActivity(ConversationManager.java:45)
[activity-monitor-server.jar:]
at org.savara.sam.aqs.JEEActiveQueryManager.onMessage(JEEActiveQueryManager.java:310)
[active-query-server.jar:]
{code}
followed by
{code}
09:32:52,913 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Thread-25
(group:HornetQ-client-global-threads-5114937)) ISPN000136: Execution error:
java.lang.IllegalStateException: Transaction TransactionImple < ac, BasicAction:
0:ffffc0a80175:38b79c02:4ece0f24:16f status: ActionStatus.ABORT_ONLY > is not in a
valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:205)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:177)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:172)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:61)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:84)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:61)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:104)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:90)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:61)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:318)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at org.infinispan.CacheImpl.get(CacheImpl.java:260)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at org.infinispan.CacheImpl.get(CacheImpl.java:252)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:250)
[infinispan-core-5.1.0.BETA2.jar:5.1.0.BETA2]
at
org.savara.sam.ams.conversations.ConversationManager.processActivity(ConversationManager.java:105)
[activity-monitor-server.jar:]
at
org.savara.sam.ams.conversations.ConversationManager.processActivity(ConversationManager.java:45)
[activity-monitor-server.jar:]
at org.savara.sam.aqs.JEEActiveQueryManager.onMessage(JEEActiveQueryManager.java:310)
[active-query-server.jar:]
{code}
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Manik Surtani
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
4:37 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño reassigned ISPN-1556:
--------------------------------------
Assignee: Galder Zamarreño (was: Manik Surtani)
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
4:39 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1556:
-----------------------------------
Fix Version/s: 5.1.0.CR1
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Fix For: 5.1.0.CR1
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
9:42 a.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño resolved ISPN-1556.
------------------------------------
Fix Version/s: (was: 5.1.0.CR1)
Resolution: Cannot Reproduce Bug
I cannot replicate this issue in master, which is very close to recently release
Infinispan 5.1.0.BETA5. Gary, can you try with Infinispan 7.1.0.BETA1 (it uses Infinispan
5.1.0.BETA5) ?
Feel free to re-open if the issue is still present and attach a test case.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
1:07 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Gary Brown commented on ISPN-1556:
----------------------------------
Hi Galder
In 7.1.0.beta1 there is a different issue, so at the moment cannot confirm whether issue
is fixed - problem is my lack of knowledge of Infinispan, so may be simple solution, but
haven't been able to find an answer.
I am using the standalone-full.xml configuration, but now getting:
{code}
11:46:27,845 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Thread-1
(group:HornetQ-client-global-threads-15658959)) ISPN000136: Execution error:
org.infinispan.CacheException: Explicit locking is not allowed with optimistic caches!
at
org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitLockControlCommand(OptimisticLockingInterceptor.java:163)
[infinispan-core-5.1.0.BETA5.jar:]
at
org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:129)
[infinispan-core-5.1.0.BETA5.jar:]
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
[infinispan-core-5.1.0.BETA5.jar:]
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
[infinispan-core-5.1.0.BETA5.jar:]
...
{code}
which then results in further exceptions of the type:
{code}
11:46:27,879 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Thread-1
(group:HornetQ-client-global-threads-15658959)) ISPN000136: Execution error:
java.lang.IllegalStateException: Transaction TransactionImple < ac, BasicAction:
0:ffffc0a80175:3c514c1:4ed4c603:111 status: ActionStatus.ABORT_ONLY > is not in a valid
state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:234)
[infinispan-core-5.1.0.BETA5.jar:]
at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:197)
[infinispan-core-5.1.0.BETA5.jar:]
at
org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:191)
[infinispan-core-5.1.0.BETA5.jar:]
at
org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:187)
[infinispan-core-5.1.0.BETA5.jar:]
...
{code}
I tried changing the locking isolation, but had no effect. So this appears to be a change
in behaviour between AS7.1 alpha2 and beta1, but not sure how to configure the cache so
not optimistic, as according to docs there is no explicit way to set this:
https://docs.jboss.org/author/pages/viewpage.action?pageId=5832814 (I guess because it is
implicit).
Any help appreciated.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
3:28 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1556:
----------------------------------------
The FAQ link refers to the JBoss Cache optimistic/pessimistic locking difference, which is
different to Infinispan's optimistic/pessimistic stuff we've added. We're
working on fixing that FAQ to be more clear. Please read
http://infinispan.blogspot.com/2011/10/transaction-remake-in-infinispan-5... to
understand what the new optimistic/pessimistic locking stuff means for Infinispan.
Finally, I don't think AS7 based Infinispan caches have their transactionMode
configurable yet, so you cannot change that yet. The best is probably to deploy your own
cache manager with your own configuration instead of relying on AS7's Infinispan cache
config here so that you can configure pessimistic transactionMode.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
6:37 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Gary Brown commented on ISPN-1556:
----------------------------------
Updated the code to create the cache manager with pessimistic lock mode:
{code}
Configuration config = manager.getDefaultConfiguration().clone().fluent()
.locking()
.concurrencyLevel(10000).isolationLevel(IsolationLevel.REPEATABLE_READ)
.lockAcquisitionTimeout(12000L).useLockStriping(false).writeSkewCheck(true)
.transaction()
.lockingMode(LockingMode.PESSIMISTIC)
.recovery()
.transactionManagerLookup(new GenericTransactionManagerLookup())
.build();
String newCacheName = "conversationDetails";
manager.defineConfiguration(newCacheName, config);
org.infinispan.Cache<ConversationId,ConversationDetails> conversationDetails=
manager.getCache("conversationDetails");
_conversationDetails = conversationDetails.getAdvancedCache()
.withFlags(Flag.FAIL_SILENTLY, Flag.ZERO_LOCK_ACQUISITION_TIMEOUT);
{code}
Now able to explicitly lock and get result as to whether lock succeeded - but if false,
then subsequent get() is still failing with same transaction exception. Is this cache
configuration ok?
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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:36 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1556:
----------------------------------------
Gary, can you attach the configuration with which the cache manager is being created?
Could you attach the rest of code dealing with _conversationDetails? including lock+get
operations that you execute.
Finally, can you post the entire stacktrace for the get() operation error?
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
1:01 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Gary Brown commented on ISPN-1556:
----------------------------------
Hi Galder
The code is:
https://github.com/objectiser/savara-sam/blob/ISPN-1556/integration/activ...
The init method creates the cache manager - uses the default constructor so does not load
any external config file.
The processActivity method has the lock test and also the get method that subsequently
fails. I'll try to get the stack trace added soon.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
1:05 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Gary Brown updated ISPN-1556:
-----------------------------
Attachment: CacheTxStackTrace.log
Stack trace for get() operation following attempt to lock.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Attachments: CacheTxStackTrace.log
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
6:31 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1556:
-----------------------------------
Attachment: SampleTest.java
A unit test that tries to replicate this issue.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Attachments: CacheTxStackTrace.log, SampleTest.java
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
6:33 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño commented on ISPN-1556:
----------------------------------------
@Gary, I still cannot replicate this. Find attached a unit test I've been building
based on some existing ones we have in our source code.
I dunno why you're transaction is in ABORT_ONLY status. Can you repeat the test
enabling TRACE for org.infinispan package and attach the log file to the JIRA?
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Attachments: CacheTxStackTrace.log, SampleTest.java
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
5:38 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Gary Brown updated ISPN-1556:
-----------------------------
Attachment: serverISPNTrace.log.zip
Sorry for the delay - this trace was produced with 7.1.beta1 and I had to snip the middle
a bit due to the 10Mb limit, but hopefully you should still have all the info you need.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Attachments: CacheTxStackTrace.log, SampleTest.java, serverISPNTrace.log.zip
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
2:55 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1556:
-----------------------------------
Attachment: Sample2Test.java
@Gary, the reason for such a big log file is that each HTTP request is being logged, which
makes the whole log file rather difficult to read. If you can remove that in the future
it will make the log more readable. Anyway, I've managed to grep by the thread name
and pipe it to a different file and that gets rid of all the HTTP requests.
Thanks to it I've been able to finally replicate the issue. Please find attached a 2nd
version of the test that replicates the issue.
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Attachments: CacheTxStackTrace.log, Sample2Test.java, SampleTest.java,
serverISPNTrace.log.zip
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
2:55 p.m.
New subject: [JBoss JIRA] (ISPN-1556) Ability to test and acquire lock if available, without aborting the txn if not available
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño reopened ISPN-1556:
------------------------------------
Ability to test and acquire lock if available, without aborting the
txn if not available
----------------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Feature Request
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Attachments: CacheTxStackTrace.log, Sample2Test.java, SampleTest.java,
serverISPNTrace.log.zip
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
2:57 p.m.
New subject: [JBoss JIRA] (ISPN-1556) An operation that fails but it's silent shouldn't abort the transaction internally
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Work on ISPN-1556 started by Galder Zamarreño.
An operation that fails but it's silent shouldn't abort the
transaction internally
----------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Priority: Critical
Fix For: 5.1.0.CR2
Attachments: CacheTxStackTrace.log, Sample2Test.java, SampleTest.java,
serverISPNTrace.log.zip
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
2:57 p.m.
New subject: [JBoss JIRA] (ISPN-1556) An operation that fails but it's silent shouldn't abort the transaction internally
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1556:
-----------------------------------
Summary: An operation that fails but it's silent shouldn't abort the
transaction internally (was: Ability to test and acquire lock if available, without
aborting the txn if not available)
Issue Type: Bug (was: Feature Request)
Fix Version/s: 5.1.0.CR2
Priority: Critical (was: Major)
Imagine 2nd level cache use case. A put for external read that fails due to a concurrent
load of data in the database shouldn't force the transaction to rollback. The point of
put for external read is that with fail silently, it's assuming it can fail but
it's fine and should not have an impact in the transaction outcome.
An operation that fails but it's silent shouldn't abort the
transaction internally
----------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Priority: Critical
Fix For: 5.1.0.CR2
Attachments: CacheTxStackTrace.log, Sample2Test.java, SampleTest.java,
serverISPNTrace.log.zip
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
4:58 p.m.
New subject: [JBoss JIRA] (ISPN-1556) An operation that fails but it's silent shouldn't abort the transaction internally
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1556:
-----------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/719
An operation that fails but it's silent shouldn't abort the
transaction internally
----------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Priority: Critical
Fix For: 5.1.0.CR2
Attachments: CacheTxStackTrace.log, Sample2Test.java, SampleTest.java,
serverISPNTrace.log.zip
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
3:31 p.m.
New subject: [JBoss JIRA] (ISPN-1556) An operation that fails but it's silent shouldn't abort the transaction internally
[
https://issues.jboss.org/browse/ISPN-1556?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-1556:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
An operation that fails but it's silent shouldn't abort the
transaction internally
----------------------------------------------------------------------------------
Key: ISPN-1556
URL: https://issues.jboss.org/browse/ISPN-1556
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.0.BETA2
Environment: AS7.1.0.alpha2
Reporter: Gary Brown
Assignee: Galder Zamarreño
Priority: Critical
Fix For: 5.1.0.CR2
Attachments: CacheTxStackTrace.log, Sample2Test.java, SampleTest.java,
serverISPNTrace.log.zip
I have a system that performs a large number of tasks in a single transaction for
efficiency. Some of those tasks access infinispan caches.
I found that occasionally I have been getting lock timeouts for the default 15 second
period.
Lock contention is not a problem - but the impact of failing to obtain the lock results
in the whole transaction being aborted, which aborts the work also carried out for
potentially a large number of other tasks, resulting in all of the work being retried.
I was wondering if it would be possible to provide an alternative lock implementation the
AdvancedCache that allowed a client app to test whether the lock was available and acquire
it - returning 'true', but if the lock was not available, simply returning false,
allowing the client code to make a decision about how to proceed.
In my case, I could then add the specific task to a retry queue, and move onto the next
task, committing all of the work that had been successfully completed for the other tasks.
--
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
4526
days inactive
4547
days old
infinispan-issues@lists.jboss.org
22 comments
10 participants
participants (10)
-
Galder Zamarreño (Assigned) (JIRA) -
Galder Zamarreño (Commented) (JIRA)
-
Galder Zamarreño (Reopened) (JIRA)
-
Galder Zamarreño (Resolved) (JIRA)
-
Galder Zamarreño (Updated) (JIRA)
-
Galder Zamarreño (Work started) (JIRA)
-
Gary Brown (Commented) (JIRA)
-
Gary Brown (Created) (JIRA)
-
Gary Brown (Updated) (JIRA)
-
Mircea Markus (Updated) (JIRA)