[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
Misha H. Ali <mhusnain(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Technical note updated. If any revisions are required, please edit the "Technical
Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services
team.
Diffed Contents:
@@ -1,10 +1 @@
-Cause: This happens when the lock is denied immediately as a result of state transfer
being started with different delays on different nodes, to prevent deadlock.
+Previously, when state transfer was started with different relays on different nodes, the
lock was denied and a StateTransferInProgressException occurred to prevent a deadlock.
Despite the timeout not expiring, a "??:??:??,??? ERROR
[org.infinispan.interceptors.InvocationContextInterceptor] (undefined) ISPN000136:
Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out
waiting for the state transfer lock, state transfer in progress for view ?" error
appeared on the server. This is fixed and the StateTransferInProgressException no longer
displays when a cluster starts up.-
-Consequence: It results to this ERROR message in the server:
-"??:??:??,??? ERROR [org.infinispan.interceptors.InvocationContextInterceptor]
(undefined) ISPN000136: Execution error:
org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the
state transfer lock, state transfer in progress for view ?"
-even though timeout hasn't expired.
-
-This however doesn't prevent normal cache operation and the errors cease after the
cluster stabilises.
-
-Fix: This issue is still open
-Resolution: N/A
We should avoid using exceptions for flow control when acquiring
state transfer lock
------------------------------------------------------------------------------------
Key: ISPN-1799
URL:
https://issues.jboss.org/browse/ISPN-1799
Project: Infinispan
Issue Type: Task
Components: State transfer
Affects Versions: 5.1.0.FINAL
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.1.4.FINAL
We currently use `StateTransferInProgressException` as a marker that a write command
failed to acquire the state transfer lock and it should be retried. With ISPN-1704 I added
another exception, StateTransferLockReacquisitionException, to signal that a write command
failed to re-acquire the state transfer lock after it had already acquired it.
These exceptions often appear in the logs and confuse users (see ISPN-1610), so it would
be best to use special return values. We may also need a flag in the InvocationContext for
StateTransferLockReacquisitionException.
--
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