2:15 p.m.
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.6.3, 2.7
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:52 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=comments#action_12413563 ]
Vladimir Blagojevic commented on JGRP-759:
------------------------------------------
Yes I was aware of this. Flush will retry until it succeeds or it times out in these
cases. If users are dealing with particularly long state transfers, say more than 10
seconds, FLUSH retry_timeout parameter can be increased accordingly.
Suggesting a rejection of this issue.
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.7, 2.6.3
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:18 p.m.
New subject: [JBoss JIRA] Assigned: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=all ]
Vladimir Blagojevic reassigned JGRP-759:
----------------------------------------
Assignee: Bela Ban (was: Vladimir Blagojevic)
Consider closing as there is a workaround for very long state transfers - increase
retry_timeout in FLUSH.
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.7, 2.6.3
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:37 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=comments#action_12414237 ]
Vladimir Blagojevic commented on JGRP-759:
------------------------------------------
Bela said:"We should NOT send back a join response if the flush fails. The joiner
should block until the previous FLUSH completed"
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6.3, 2.7
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:41 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=comments#action_12414238 ]
Vladimir Blagojevic commented on JGRP-759:
------------------------------------------
Comment @Michael: Even if force is true flush cannot succeed until the previous one
completes.
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6.3, 2.7
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:45 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=comments#action_12414239 ]
Vladimir Blagojevic commented on JGRP-759:
------------------------------------------
Question for Bela:What should we do in regular JChannel#getState() call in case flush
fails? Return false or silently proceed with flush failed warning? We cannot throw
exception here!
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6.3, 2.7
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:58 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=comments#action_12414247 ]
Bela Ban commented on JGRP-759:
-------------------------------
why not ? getState() has exceptions in its signature. I think, if flushing is enabled, and
getState() fails, in analogy to connect&state, we should throw an exception
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6.3, 2.7
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:24 p.m.
New subject: [JBoss JIRA] Assigned: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=all ]
Vladimir Blagojevic reassigned JGRP-759:
----------------------------------------
Assignee: Vladimir Blagojevic (was: Bela Ban)
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.6.3, 2.7
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:30 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=comments#action_12414565 ]
Vladimir Blagojevic commented on JGRP-759:
------------------------------------------
Yes, it has ChannelNotConnectedException and ChannelClosedException! Which one should I
throw in case flush fails? We cannot add another exception to signature, can we?
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.6.3, 2.7
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:07 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=comments#action_12414578 ]
Bela Ban commented on JGRP-759:
-------------------------------
Maybe a runtime exception ? Or a simple ChannelException (super class of the 2)
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.7, 2.6.3
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:24 p.m.
New subject: [JBoss JIRA] Resolved: (JGRP-759) FLUSH: GMS potential problem
[ http://jira.jboss.com/jira/browse/JGRP-759?page=all ]
Vladimir Blagojevic resolved JGRP-759.
--------------------------------------
Resolution: Done
Resolved on 2.6 branch:
1.82.2.5 +10 -1 JGroups/src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
1.82.2.15 +22 -20 JGroups/src/org/jgroups/protocols/pbcast/FLUSH.java
1.158.2.18 +127 -24 JGroups/src/org/jgroups/JChannel.java
Resolved on HEAD (2.7)
1.189 +129 -26 JGroups/src/org/jgroups/JChannel.java
1.90 +10 -1 JGroups/src/org/jgroups/protocols/pbcast/CoordGmsImpl.java
1.104 +22 -20 JGroups/src/org/jgroups/protocols/pbcast/FLUSH.java
FLUSH: GMS potential problem
----------------------------
Key: JGRP-759
URL: http://jira.jboss.com/jira/browse/JGRP-759
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.6.3, 2.7
[Michael Newcomb]
When joining with state transfer, the coordinator starts the flush, but
the joining member stops it. This might lead to an issue because as soon
as the coordinator casts the new view to everyone (and receives their
acks) he starts processing the next request in the queue without waiting
for the flush to be completed.
I noticed this because I got a 'retrying flush' without ever seeing "...
Running FLUSH...". So, flushInProgress is still true. The problem might
arise in that when it retries it sets force=true and that could possibly
cause a flush to start before the stop has been received.
Not sure it is an issue, but just thought I'd bring it up.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6087
days inactive
6095
days old
10 comments
2 participants
participants (2)
-
Bela Ban (JIRA) -
Vladimir Blagojevic (JIRA)