[JBoss JIRA] Created: (JGRP-1328) LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request
2:03 p.m.
LockService and ExecutionService may drop a message if the coordinator goes down while
trying to send a request
---------------------------------------------------------------------------------------------------------------
Key: JGRP-1328
URL: https://issues.jboss.org/browse/JGRP-1328
Project: JGroups
Issue Type: Bug
Reporter: William Burns
Assignee: Bela Ban
I was talking with Bela in regards to this and am not sure if this is an issue or not. It
may be that the view change will block the msg, but there is still no way the Service
knows to now resend to the new coordinator as it is trying to send to the now down
coordinator. This is just here to not forget about the issue and so we can revisit it at
a later time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:27 p.m.
New subject: [JBoss JIRA] Updated: (JGRP-1328) LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request
[
https://issues.jboss.org/browse/JGRP-1328?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1328:
---------------------------
Fix Version/s: 2.12.2
3.1
LockService and ExecutionService may drop a message if the
coordinator goes down while trying to send a request
---------------------------------------------------------------------------------------------------------------
Key: JGRP-1328
URL: https://issues.jboss.org/browse/JGRP-1328
Project: JGroups
Issue Type: Bug
Reporter: William Burns
Assignee: Bela Ban
Fix For: 2.12.2, 3.1
I was talking with Bela in regards to this and am not sure if this is an issue or not.
It may be that the view change will block the msg, but there is still no way the Service
knows to now resend to the new coordinator as it is trying to send to the now down
coordinator. This is just here to not forget about the issue and so we can revisit it at
a later time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:45 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1328) LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request
[
https://issues.jboss.org/browse/JGRP-1328?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1328:
---------------------------
Fix Version/s: (was: 2.12.2)
LockService and ExecutionService may drop a message if the
coordinator goes down while trying to send a request
---------------------------------------------------------------------------------------------------------------
Key: JGRP-1328
URL: https://issues.jboss.org/browse/JGRP-1328
Project: JGroups
Issue Type: Bug
Reporter: William Burns
Assignee: Bela Ban
Fix For: 3.1
I was talking with Bela in regards to this and am not sure if this is an issue or not.
It may be that the view change will block the msg, but there is still no way the Service
knows to now resend to the new coordinator as it is trying to send to the now down
coordinator. This is just here to not forget about the issue and so we can revisit it at
a later time.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:44 a.m.
New subject: [JBoss JIRA] (JGRP-1328) LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request
[
https://issues.jboss.org/browse/JGRP-1328?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1328:
--------------------------------
This is not an issue in PEER_LOCK (handleView()):
[code]
// For all non-acquired client locks, send the GRANT_LOCK request to the new
coordinator (if changed)
if(old_coord != null && !old_coord.equals(coord)) {
Map<String,Map<Owner,ClientLock>> copy;
synchronized(client_locks) {
copy=new HashMap<String,Map<Owner,ClientLock>>(client_locks);
}
if(!copy.isEmpty()) {
for(Map<Owner,ClientLock> map: copy.values()) {
for(ClientLock lock: map.values()) {
if(!lock.acquired && !lock.denied)
sendGrantLockRequest(lock.name, lock.owner, lock.timeout,
lock.is_trylock);
}
}
}
}
}
[/code]
On a view change that excludes the current coordinator, this code re-submits *pending*
lock requests to the new coordinator
LockService and ExecutionService may drop a message if the
coordinator goes down while trying to send a request
---------------------------------------------------------------------------------------------------------------
Key: JGRP-1328
URL: https://issues.jboss.org/browse/JGRP-1328
Project: JGroups
Issue Type: Bug
Reporter: William Burns
Assignee: Bela Ban
Fix For: 3.1
I was talking with Bela in regards to this and am not sure if this is an issue or not.
It may be that the view change will block the msg, but there is still no way the Service
knows to now resend to the new coordinator as it is trying to send to the now down
coordinator. This is just here to not forget about the issue and so we can revisit it at
a later time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:44 a.m.
New subject: [JBoss JIRA] (JGRP-1328) LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request
[
https://issues.jboss.org/browse/JGRP-1328?page=com.atlassian.jira.plugin....
]
Bela Ban edited comment on JGRP-1328 at 11/16/11 7:44 AM:
----------------------------------------------------------
This is not an issue in PEER_LOCK (handleView()):
// For all non-acquired client locks, send the GRANT_LOCK request to the new
coordinator (if changed)
if(old_coord != null && !old_coord.equals(coord)) {
Map<String,Map<Owner,ClientLock>> copy;
synchronized(client_locks) {
copy=new HashMap<String,Map<Owner,ClientLock>>(client_locks);
}
if(!copy.isEmpty()) {
for(Map<Owner,ClientLock> map: copy.values()) {
for(ClientLock lock: map.values()) {
if(!lock.acquired && !lock.denied)
sendGrantLockRequest(lock.name, lock.owner, lock.timeout,
lock.is_trylock);
}
}
}
}
}
On a view change that excludes the current coordinator, this code re-submits *pending*
lock requests to the new coordinator
was (Author: belaban):
This is not an issue in PEER_LOCK (handleView()):
[code]
// For all non-acquired client locks, send the GRANT_LOCK request to the new
coordinator (if changed)
if(old_coord != null && !old_coord.equals(coord)) {
Map<String,Map<Owner,ClientLock>> copy;
synchronized(client_locks) {
copy=new HashMap<String,Map<Owner,ClientLock>>(client_locks);
}
if(!copy.isEmpty()) {
for(Map<Owner,ClientLock> map: copy.values()) {
for(ClientLock lock: map.values()) {
if(!lock.acquired && !lock.denied)
sendGrantLockRequest(lock.name, lock.owner, lock.timeout,
lock.is_trylock);
}
}
}
}
}
[/code]
On a view change that excludes the current coordinator, this code re-submits *pending*
lock requests to the new coordinator
LockService and ExecutionService may drop a message if the
coordinator goes down while trying to send a request
---------------------------------------------------------------------------------------------------------------
Key: JGRP-1328
URL: https://issues.jboss.org/browse/JGRP-1328
Project: JGroups
Issue Type: Bug
Reporter: William Burns
Assignee: Bela Ban
Fix For: 3.1
I was talking with Bela in regards to this and am not sure if this is an issue or not.
It may be that the view change will block the msg, but there is still no way the Service
knows to now resend to the new coordinator as it is trying to send to the now down
coordinator. This is just here to not forget about the issue and so we can revisit it at
a later time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:46 a.m.
New subject: [JBoss JIRA] (JGRP-1328) LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request
[
https://issues.jboss.org/browse/JGRP-1328?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1328:
--------------------------------
Dito for CENTRAL_EXECUTOR:
if (oldCoord != coord) {
for (Long requests : _requestId.values()) {
sendToCoordinator(Type.RUN_REQUEST, requests, local_addr);
}
for (Long requests : _consumerId.keySet()) {
sendToCoordinator(Type.CONSUMER_READY, requests, local_addr);
}
}
Pending requests are re-submitted to the new coordinator
LockService and ExecutionService may drop a message if the
coordinator goes down while trying to send a request
---------------------------------------------------------------------------------------------------------------
Key: JGRP-1328
URL: https://issues.jboss.org/browse/JGRP-1328
Project: JGroups
Issue Type: Bug
Reporter: William Burns
Assignee: Bela Ban
Fix For: 3.1
I was talking with Bela in regards to this and am not sure if this is an issue or not.
It may be that the view change will block the msg, but there is still no way the Service
knows to now resend to the new coordinator as it is trying to send to the now down
coordinator. This is just here to not forget about the issue and so we can revisit it at
a later time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:48 a.m.
New subject: [JBoss JIRA] (JGRP-1328) LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request
[
https://issues.jboss.org/browse/JGRP-1328?page=com.atlassian.jira.plugin....
]
Bela Ban resolved JGRP-1328.
----------------------------
Resolution: Won't Fix
Works as designed (see other comments)
LockService and ExecutionService may drop a message if the
coordinator goes down while trying to send a request
---------------------------------------------------------------------------------------------------------------
Key: JGRP-1328
URL: https://issues.jboss.org/browse/JGRP-1328
Project: JGroups
Issue Type: Bug
Reporter: William Burns
Assignee: Bela Ban
Fix For: 3.1
I was talking with Bela in regards to this and am not sure if this is an issue or not.
It may be that the view change will block the msg, but there is still no way the Service
knows to now resend to the new coordinator as it is trying to send to the now down
coordinator. This is just here to not forget about the issue and so we can revisit it at
a later time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:48 a.m.
New subject: [JBoss JIRA] (JGRP-1328) LockService and ExecutionService may drop a message if the coordinator goes down while trying to send a request
[
https://issues.jboss.org/browse/JGRP-1328?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1328:
---------------------------
Fix Version/s: 3.0
(was: 3.1)
LockService and ExecutionService may drop a message if the
coordinator goes down while trying to send a request
---------------------------------------------------------------------------------------------------------------
Key: JGRP-1328
URL: https://issues.jboss.org/browse/JGRP-1328
Project: JGroups
Issue Type: Bug
Reporter: William Burns
Assignee: Bela Ban
Fix For: 3.0
I was talking with Bela in regards to this and am not sure if this is an issue or not.
It may be that the view change will block the msg, but there is still no way the Service
knows to now resend to the new coordinator as it is trying to send to the now down
coordinator. This is just here to not forget about the issue and so we can revisit it at
a later time.
--
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
5070
days inactive
5244
days old
7 comments
6 participants
participants (6)
-
Bela Ban (Commented) (JIRA) -
Bela Ban (Issue Comment Edited) (JIRA)
-
Bela Ban (JIRA)
-
Bela Ban (Resolved) (JIRA)
-
Bela Ban (Updated) (JIRA)
-
William Burns (JIRA)