[JBoss JIRA] Created: (JBMESSAGING-1262) It May be Posible to have two leases for the same client because they are tracked by jvm id. This results in leases being closed on the server without notification to the client.
8:49 a.m.
It May be Posible to have two leases for the same client because they are tracked by jvm
id. This results in leases being closed on the server without notification to the
client.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1262
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1262
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.0.SP3_CP01, 1.4.0.SP3
Reporter: Jay Howell
Assigned To: Tim Fox
Platform: EAP 4.2.1, JBM 1.4.0.SP3, JBREM 2.2.2.SP5 (pre-release)
After a short-network outage, if a JBM client detects the error, and reconnects to the JBM
server before the original lease expires, then the JBM server will clean up resources
associated with both the original connection, *and* the new connection, once the lease
expiry occurs.
The JBM server appears to track client sessions by a client JVM id, assuming that a
single remoting invoker/lease can exist for a given JBM client JVM at any given time.
However, in the error scenario described about, two leases associated with the same client
exist on the JBM server for a short period of time, until the first stale lease expires.
The net effect of this problem is that healthy sessions are closed on the JBM server, but
are never detected by the client, since the new client lease pinger continues to
functioning correctly.
Testcase:
1. Configure the lease timeout to a high value (e.g. 60 seconds)
2. Pull a network cable causing a JBM subscriber to disconnect. The network outage should
be < 2 * lease expiry
3. Restore the network cable, allowing the subscriber to reconnect
4. Wait for the original lease to expire on the JBM server
5. Observe that all subscriptions (including the new healthy ones) to the client have been
closed
--
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
8:49 a.m.
New subject: [JBoss JIRA] Commented: (JBMESSAGING-1262) It May be Posible to have two leases for the same client because they are tracked by jvm id. This results in leases being closed on the server without notification to the client.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-1262?page=comments#action_1... ]
Jay Howell commented on JBMESSAGING-1262:
-----------------------------------------
Also, the attached change to ClientConnectionFactoryDelegate.java appears to address the
problem in our (non-clustered) environment.
If you look in SimpleConnectionManager.closeConsumersForClientVMID, there is the following
comment, which looks correct:
// Remoting only provides one pinger per invoker, not per connection therefore when
the pinger
// dies we must close ALL connections corresponding to that jms client ID.
Therefore, I'm not sure why JBM tracks connections globally to the JVM, rather than on
a per-invoker basis.
It May be Posible to have two leases for the same client because they
are tracked by jvm id. This results in leases being closed on the server without
notification to the client.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1262
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1262
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.0.SP3, 1.4.0.SP3_CP01
Reporter: Jay Howell
Assigned To: Tim Fox
Platform: EAP 4.2.1, JBM 1.4.0.SP3, JBREM 2.2.2.SP5 (pre-release)
After a short-network outage, if a JBM client detects the error, and reconnects to the
JBM server before the original lease expires, then the JBM server will clean up resources
associated with both the original connection, *and* the new connection, once the lease
expiry occurs.
The JBM server appears to track client sessions by a client JVM id, assuming that a
single remoting invoker/lease can exist for a given JBM client JVM at any given time.
However, in the error scenario described about, two leases associated with the same client
exist on the JBM server for a short period of time, until the first stale lease expires.
The net effect of this problem is that healthy sessions are closed on the JBM server, but
are never detected by the client, since the new client lease pinger continues to
functioning correctly.
Testcase:
1. Configure the lease timeout to a high value (e.g. 60 seconds)
2. Pull a network cable causing a JBM subscriber to disconnect. The network outage
should be < 2 * lease expiry
3. Restore the network cable, allowing the subscriber to reconnect
4. Wait for the original lease to expire on the JBM server
5. Observe that all subscriptions (including the new healthy ones) to the client have
been closed
--
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
8:51 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1262) It May be Posible to have two leases for the same client because they are tracked by jvm id. This results in leases being closed on the server without notification to the client.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-1262?page=all ]
Jay Howell updated JBMESSAGING-1262:
------------------------------------
Attachment: ClientConnectionFactoryDelegate.java.htm
Changed, client connection factory.
It May be Posible to have two leases for the same client because they
are tracked by jvm id. This results in leases being closed on the server without
notification to the client.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1262
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1262
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.0.SP3, 1.4.0.SP3_CP01
Reporter: Jay Howell
Assigned To: Tim Fox
Attachments: ClientConnectionFactoryDelegate.java.htm
Platform: EAP 4.2.1, JBM 1.4.0.SP3, JBREM 2.2.2.SP5 (pre-release)
After a short-network outage, if a JBM client detects the error, and reconnects to the
JBM server before the original lease expires, then the JBM server will clean up resources
associated with both the original connection, *and* the new connection, once the lease
expiry occurs.
The JBM server appears to track client sessions by a client JVM id, assuming that a
single remoting invoker/lease can exist for a given JBM client JVM at any given time.
However, in the error scenario described about, two leases associated with the same client
exist on the JBM server for a short period of time, until the first stale lease expires.
The net effect of this problem is that healthy sessions are closed on the JBM server, but
are never detected by the client, since the new client lease pinger continues to
functioning correctly.
Testcase:
1. Configure the lease timeout to a high value (e.g. 60 seconds)
2. Pull a network cable causing a JBM subscriber to disconnect. The network outage
should be < 2 * lease expiry
3. Restore the network cable, allowing the subscriber to reconnect
4. Wait for the original lease to expire on the JBM server
5. Observe that all subscriptions (including the new healthy ones) to the client have
been closed
--
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
12:56 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-1262) It May be Posible to have two leases for the same client because they are tracked by jvm id. This results in leases being closed on the server without notification to the client.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-1262?page=all ]
Tim Fox updated JBMESSAGING-1262:
---------------------------------
Fix Version/s: 1.4.0.SP3.CP02
1.4.1.beta2
It May be Posible to have two leases for the same client because they
are tracked by jvm id. This results in leases being closed on the server without
notification to the client.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1262
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1262
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.0.SP3, 1.4.0.SP3_CP01
Reporter: Jay Howell
Assigned To: Tim Fox
Fix For: 1.4.0.SP3.CP02, 1.4.1.beta2
Attachments: ClientConnectionFactoryDelegate.java.htm
Platform: EAP 4.2.1, JBM 1.4.0.SP3, JBREM 2.2.2.SP5 (pre-release)
After a short-network outage, if a JBM client detects the error, and reconnects to the
JBM server before the original lease expires, then the JBM server will clean up resources
associated with both the original connection, *and* the new connection, once the lease
expiry occurs.
The JBM server appears to track client sessions by a client JVM id, assuming that a
single remoting invoker/lease can exist for a given JBM client JVM at any given time.
However, in the error scenario described about, two leases associated with the same client
exist on the JBM server for a short period of time, until the first stale lease expires.
The net effect of this problem is that healthy sessions are closed on the JBM server, but
are never detected by the client, since the new client lease pinger continues to
functioning correctly.
Testcase:
1. Configure the lease timeout to a high value (e.g. 60 seconds)
2. Pull a network cable causing a JBM subscriber to disconnect. The network outage
should be < 2 * lease expiry
3. Restore the network cable, allowing the subscriber to reconnect
4. Wait for the original lease to expire on the JBM server
5. Observe that all subscriptions (including the new healthy ones) to the client have
been closed
--
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
1:23 p.m.
New subject: [JBoss JIRA] Commented: (JBMESSAGING-1262) It May be Posible to have two leases for the same client because they are tracked by jvm id. This results in leases being closed on the server without notification to the client.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-1262?page=comments#action_1... ]
Jay Howell commented on JBMESSAGING-1262:
-----------------------------------------
Please disregard the previous commits to SVN that were logged. That was for a different
Jira(JBMESSAGING-1255).
It May be Posible to have two leases for the same client because they
are tracked by jvm id. This results in leases being closed on the server without
notification to the client.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1262
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1262
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.0.SP3, 1.4.0.SP3_CP01
Reporter: Jay Howell
Assigned To: Tim Fox
Fix For: 1.4.0.SP3.CP02, 1.4.1.beta2
Attachments: ClientConnectionFactoryDelegate.java.htm
Platform: EAP 4.2.1, JBM 1.4.0.SP3, JBREM 2.2.2.SP5 (pre-release)
After a short-network outage, if a JBM client detects the error, and reconnects to the
JBM server before the original lease expires, then the JBM server will clean up resources
associated with both the original connection, *and* the new connection, once the lease
expiry occurs.
The JBM server appears to track client sessions by a client JVM id, assuming that a
single remoting invoker/lease can exist for a given JBM client JVM at any given time.
However, in the error scenario described about, two leases associated with the same client
exist on the JBM server for a short period of time, until the first stale lease expires.
The net effect of this problem is that healthy sessions are closed on the JBM server, but
are never detected by the client, since the new client lease pinger continues to
functioning correctly.
Testcase:
1. Configure the lease timeout to a high value (e.g. 60 seconds)
2. Pull a network cable causing a JBM subscriber to disconnect. The network outage
should be < 2 * lease expiry
3. Restore the network cable, allowing the subscriber to reconnect
4. Wait for the original lease to expire on the JBM server
5. Observe that all subscriptions (including the new healthy ones) to the client have
been closed
--
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:58 p.m.
New subject: [JBoss JIRA] Closed: (JBMESSAGING-1262) It May be Posible to have two leases for the same client because they are tracked by jvm id. This results in leases being closed on the server without notification to the client.
[ http://jira.jboss.com/jira/browse/JBMESSAGING-1262?page=all ]
Tim Fox closed JBMESSAGING-1262.
--------------------------------
Resolution: Done
It May be Posible to have two leases for the same client because they
are tracked by jvm id. This results in leases being closed on the server without
notification to the client.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1262
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1262
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.4.0.SP3, 1.4.0.SP3_CP01
Reporter: Jay Howell
Assigned To: Tim Fox
Fix For: 1.4.0.SP3.CP02, 1.4.1.beta2
Attachments: ClientConnectionFactoryDelegate.java.htm
Platform: EAP 4.2.1, JBM 1.4.0.SP3, JBREM 2.2.2.SP5 (pre-release)
After a short-network outage, if a JBM client detects the error, and reconnects to the
JBM server before the original lease expires, then the JBM server will clean up resources
associated with both the original connection, *and* the new connection, once the lease
expiry occurs.
The JBM server appears to track client sessions by a client JVM id, assuming that a
single remoting invoker/lease can exist for a given JBM client JVM at any given time.
However, in the error scenario described about, two leases associated with the same client
exist on the JBM server for a short period of time, until the first stale lease expires.
The net effect of this problem is that healthy sessions are closed on the JBM server, but
are never detected by the client, since the new client lease pinger continues to
functioning correctly.
Testcase:
1. Configure the lease timeout to a high value (e.g. 60 seconds)
2. Pull a network cable causing a JBM subscriber to disconnect. The network outage
should be < 2 * lease expiry
3. Restore the network cable, allowing the subscriber to reconnect
4. Wait for the original lease to expire on the JBM server
5. Observe that all subscriptions (including the new healthy ones) to the client have
been closed
--
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
6629
days inactive
6631
days old
5 comments
2 participants
participants (2)
-
Jay Howell (JIRA) -
Tim Fox (JIRA)