[JBoss JIRA] Created: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
7:02 a.m.
CloserThread's attempt to interrupt TimeScheduler on closure could be end up being
ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Reporter: Galder Zamarreno
Assigned To: Bela Ban
Fix For: 2.3 SP1, 2.3
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster.
--
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:06 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
[ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]
Galder Zamarreno updated JGRP-507:
----------------------------------
Fix Version/s: 2.4.1 SP3
(was: 2.3)
(was: 2.3 SP1)
Affects Version/s: 2.3 SP1
2.3
TimeScheduler has been rewritten for 2.4.1.SP3 and does not have this issue.
CloserThread's attempt to interrupt TimeScheduler on closure
could be end up being ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3, 2.3 SP1
Reporter: Galder Zamarreno
Assigned To: Bela Ban
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster.
--
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:06 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
[ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]
Galder Zamarreno updated JGRP-507:
----------------------------------
Fix Version/s: (was: 2.4.1 SP3)
CloserThread's attempt to interrupt TimeScheduler on closure
could be end up being ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3, 2.3 SP1
Reporter: Galder Zamarreno
Assigned To: Bela Ban
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster.
--
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:08 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
[ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]
Galder Zamarreno updated JGRP-507:
----------------------------------
http://jira.jboss.com/jira/browse/JGRP-486 fixed it.
CloserThread's attempt to interrupt TimeScheduler on closure
could be end up being ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3, 2.3 SP1
Reporter: Galder Zamarreno
Assigned To: Bela Ban
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster.
--
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:10 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
[ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]
Galder Zamarreno updated JGRP-507:
----------------------------------
Description:
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster and unable to merge back.
was:
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster.
CloserThread's attempt to interrupt TimeScheduler on closure
could be end up being ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3, 2.3 SP1
Reporter: Galder Zamarreno
Assigned To: Bela Ban
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster and unable to merge back.
--
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:12 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
[ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]
Galder Zamarreno updated JGRP-507:
----------------------------------
Affects Version/s: 2.4.1 SP2
2.4.1 SP1
2.4.1
2.4
2.2.9 SP4
2.2.9 SP3 (2.2.9.3)
2.2.9.2
2.2.9.1
2.2.9
2.2.8
2.2.7 SP1
This issue can appear in pretty much any version
CloserThread's attempt to interrupt TimeScheduler on closure
could be end up being ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Affects Versions: 2.2.8, 2.2.9, 2.3, 2.4, 2.2.9.1, 2.2.9.2, 2.2.9 SP3 (2.2.9.3), 2.3
SP1, 2.2.9 SP4, 2.2.7 SP1, 2.4.1, 2.4.1 SP1, 2.4.1 SP2
Reporter: Galder Zamarreno
Assigned To: Bela Ban
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster and unable to merge back.
--
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
10:04 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
[ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]
Bela Ban updated JGRP-507:
--------------------------
Fix Version/s: 2.6
Will look at it in the 2.6 release time frame 9although it won't probably get fixed in
2.6 as 2.6 doesn't seem to have this problem).
CloserThread's attempt to interrupt TimeScheduler on closure
could be end up being ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3 SP1, 2.3, 2.4.1 SP2, 2.4.1 SP1, 2.4.1, 2.4, 2.2.9 SP4, 2.2.9 SP3
(2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8, 2.2.7 SP1
Reporter: Galder Zamarreno
Assigned To: Bela Ban
Fix For: 2.6
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster and unable to merge back.
--
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
10:11 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
[ http://jira.jboss.com/jira/browse/JGRP-507?page=comments#action_12374627 ]
Galder Zamarreno commented on JGRP-507:
---------------------------------------
Bela, it was fixed in 2.4.1.SP3. I just posted the link to the case that raised
this a few months ago.
CloserThread's attempt to interrupt TimeScheduler on closure
could be end up being ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3 SP1, 2.3, 2.4.1 SP2, 2.4.1 SP1, 2.4.1, 2.4, 2.2.9 SP4, 2.2.9 SP3
(2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8, 2.2.7 SP1
Reporter: Galder Zamarreno
Assigned To: Bela Ban
Fix For: 2.6
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster and unable to merge back.
--
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:40 a.m.
New subject: [JBoss JIRA] Resolved: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
[ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]
Galder Zamarreno resolved JGRP-507.
-----------------------------------
Fix Version/s: 2.4.1 SP3
(was: 2.6)
Resolution: Done
Change in timer design as part of 2.4.1.SP3 fixed this.
CloserThread's attempt to interrupt TimeScheduler on closure
could be end up being ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Affects Versions: 2.2.8, 2.2.9, 2.3, 2.4, 2.2.9.1, 2.2.9.2, 2.2.9 SP3 (2.2.9.3), 2.3
SP1, 2.2.9 SP4, 2.2.7 SP1, 2.4.1, 2.4.1 SP1, 2.4.1 SP2
Reporter: Galder Zamarreno
Assigned To: Bela Ban
Fix For: 2.4.1 SP3
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster and unable to merge back.
--
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:42 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-507) CloserThread's attempt to interrupt TimeScheduler on closure could be end up being ignored
[ http://jira.jboss.com/jira/browse/JGRP-507?page=all ]
Galder Zamarreno updated JGRP-507:
----------------------------------
Fix Version/s: 2.5
CloserThread's attempt to interrupt TimeScheduler on closure
could be end up being ignored
------------------------------------------------------------------------------------------
Key: JGRP-507
URL: http://jira.jboss.com/jira/browse/JGRP-507
Project: JGroups
Issue Type: Bug
Affects Versions: 2.2.8, 2.2.9, 2.3, 2.4, 2.2.9.1, 2.2.9.2, 2.2.9 SP3 (2.2.9.3), 2.3
SP1, 2.2.9 SP4, 2.2.7 SP1, 2.4.1, 2.4.1 SP1, 2.4.1 SP2
Reporter: Galder Zamarreno
Assigned To: Bela Ban
Fix For: 2.5, 2.4.1 SP3
A race condition in JGroups could cause a channel that should be closed (for example,
after being shunned)
to never be closed.
In order to stop TimeScheduler thread, CloserThread set's TimeScheduler's thread
status
as interrupted. If the interruption occurs while TimeScheduler is waiting, then no
problems.
But, in TimeScheduler._run(), actual running of a task via task.run(); happens outside
synchronized(queue) block which means that CloserThread could set the TimeSchedule
thread's
status as interrupted while the task is running, for example, sending an FD are-you-alive
message.
If down the protocol that's carrying out the task, all down threads are set to false,
and TimeScheduler
thread is interrupted while the task is running, the interruption could be caught while
sending a message to network:
TP (UDP and TCP/TCP_NIO's parent):
TP.down(Event evt)
....
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) log.error("failed sending message", e);
}
Catching InterruptedException and doing nothing will clear the Thread's interrupted
status. If
the interruption from CloserThread is caught here, TimeScheduler thread will never
finished,
leaving the channel blocked and never rejoining the cluster and unable to merge back.
--
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
6901
days inactive
7013
days old
9 comments
2 participants
participants (2)
-
Bela Ban (JIRA) -
Galder Zamarreno (JIRA)