[JBoss JIRA] (ISPN-1799) We should avoid using exceptions for flow control when acquiring state transfer lock
6:59 a.m.
Dan Berindei created ISPN-1799:
----------------------------------
Summary: 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.2.0.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
5:47 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration updated ISPN-1799:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=765759
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.2.0.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
5:47 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration updated ISPN-1799:
------------------------------------------
Bugzilla Update: Perform
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.2.0.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
5:47 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Adding link to ISPN-1799 which formulates the problem in terms of previous comment.
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.2.0.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
12:15 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
Prabhat Jha commented on ISPN-1799:
-----------------------------------
Can this be fixed so that it gets fixed in next ER build for JDG?
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.2.0.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
11:46 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
JBoss JIRA Server <jira-update(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Prabhat Jha <prabhat.jha(a)jboss.com> made a comment on jira ISPN-1799
Can this be fixed so that it gets fixed in next ER build for JDG?
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.2.0.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
11:46 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
As this is marked to be fixed in Infinispan 5.2.0.FINAL, we'll be treating this as a
known bug for JDG.6.0.0.ER6 (Beta)
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.2.0.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
3:32 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-1799:
------------------------------------
Prabhat, I did try to get it into 5.1.3.FINAL, but it needs more polish and tests, so
I'm not trying to push it in right now.
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.2.0.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
9:29 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
JBoss JIRA Server <jira-update(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Dan Berindei <dberinde(a)redhat.com> made a comment on jira ISPN-1799
Prabhat, I did try to get it into 5.1.3.FINAL, but it needs more polish and tests, so
I'm not trying to push it in right now.
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.2.0.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
10:21 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
Tristan Tarrant commented on ISPN-1799:
---------------------------------------
Dan could you please try and get it in 5.1.4.CR1 ?
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.2.0.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
10:23 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
Tristan Tarrant edited comment on ISPN-1799 at 3/28/12 10:22 AM:
-----------------------------------------------------------------
Dan could you please try and get it in 5.1.4.CR1 or at least a patch for JDG
was (Author: NadirX):
Dan could you please try and get it in 5.1.4.CR1 ?
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.2.0.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
7:04 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
JBoss JIRA Server <jira-update(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on jira ISPN-1799
Dan could you please try and get it in 5.1.4.CR1 ?
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.2.0.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
7:04 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
JBoss JIRA Server <jira-update(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on jira ISPN-1799
Dan could you please try and get it in 5.1.4.CR1 or at least a patch for JDG
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.2.0.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
7:04 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Known issue for ER5, ER6, appeared in the tests.
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.2.0.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
9:01 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Technical note added. If any revisions are required, please edit the "Technical
Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services
team.
New Contents:
CCFR - mlinhard
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.2.0.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
11:14 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
Michal Linhard <mlinhard(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 +1,10 @@
-CCFR - mlinhard+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.
+
+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.2.0.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
5:18 p.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
dex chen commented on ISPN-1799:
--------------------------------
we saw this error in our 3 node cluster in which the network connectivity to one of nodes
is not reliable and has high latency. Does this exception have anything to do with the
network connectivity and high latency?
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.2.0.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
3:08 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
Mircea Markus resolved ISPN-1799.
---------------------------------
Resolution: Done
integrated on 5.1 and master.
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.2.0.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
11:12 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-1799:
------------------------------------
Dex, if you have high latency or high losses then your cluster could split into two or
more partitions, and during the split/merge it's possible to see these
StateTransferInProgressExceptions and you can ignore them.
However, you should try to avoid these cluster changes by increasing your FD timeout, as
saturating the network with the state transfer might lead to yet another split.
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.2.0.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
7:02 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1799:
-----------------------------------
Fix Version/s: 5.1.4.FINAL
(was: 5.2.0.FINAL)
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=765759 (was:
https://bugzilla.redhat.com/show_bug.cgi?id=765759)
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
4:20 p.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
JBoss JIRA Server <jira-update(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
dex chen <dex80526(a)yahoo.com> made a comment on jira ISPN-1799
we saw this error in our 3 node cluster in which the network connectivity to one of nodes
is not reliable and has high latency. Does this exception have anything to do with the
network connectivity and high latency?
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
4:20 p.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759] from ON_DEV to ON_QA
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
4:20 p.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
JBoss JIRA Server <jira-update(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Mircea Markus <mmarkus(a)redhat.com> updated the status of jira ISPN-1799 to Resolved
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
4:20 p.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
JBoss JIRA Server <jira-update(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Dan Berindei <dberinde(a)redhat.com> made a comment on jira ISPN-1799
Dex, if you have high latency or high losses then your cluster could split into two or
more partitions, and during the split/merge it's possible to see these
StateTransferInProgressExceptions and you can ignore them.
However, you should try to avoid these cluster changes by increasing your FD timeout, as
saturating the network with the state transfer might lead to yet another split.
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
4:20 p.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
JBoss JIRA Server <jira-update(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
Mircea Markus <mmarkus(a)redhat.com> made a comment on jira ISPN-1799
integrated on 5.1 and master.
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
4:35 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
Michal Linhard <mlinhard(a)redhat.com> changed the Status of [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759] from ON_QA to VERIFIED
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
4:35 a.m.
[
https://issues.jboss.org/browse/ISPN-1799?page=com.atlassian.jira.plugin....
]
RH Bugzilla Integration commented on ISPN-1799:
-----------------------------------------------
Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug
765759|https://bugzilla.redhat.com/show_bug.cgi?id=765759]
The StateTransferInProgressException doesn't occur anymore during cluster startup.
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
10:34 p.m.
[
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
10:53 p.m.
[
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 +1 @@
-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.+Previously, when state transfer was started with
different relays on different nodes, the lock was denied and a
<literal>StateTransferInProgressException</literal> 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
<literal>StateTransferInProgressException</literal> no longer displays when a
cluster starts up.
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
4436
days inactive
4565
days old
infinispan-issues@lists.jboss.org
28 comments
7 participants
participants (7)
-
Dan Berindei (JIRA) -
dex chen (JIRA)
-
Galder Zamarreño (JIRA)
-
Mircea Markus (JIRA)
-
Prabhat Jha (JIRA)
-
RH Bugzilla Integration (JIRA)
-
Tristan Tarrant (JIRA)