You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Kevin Yaussy (JIRA)" <ji...@activemq.org> on 2006/03/18 00:55:26 UTC
[jira] Created: (AMQ-643) maxInactivityDuration does not seem to
work properly
maxInactivityDuration does not seem to work properly
----------------------------------------------------
Key: AMQ-643
URL: http://jira.activemq.org/jira//browse/AMQ-643
Project: ActiveMQ
Type: Bug
Components: Connector
Versions: 4.0 M5
Environment: AMQ 4 03/17/2006 SNAPSHOT
Solaris 8, 10
Reporter: Kevin Yaussy
Fix For: 4.0 M5
AMQ 4 03/17/2006 SNAPSHOT
Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Hiram Chirino (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=all ]
Hiram Chirino resolved AMQ-643:
-------------------------------
Resolution: Fixed
Fix Version: (was: 4.0 RC 2)
4.0 RC1
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC1
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Kevin Yaussy (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35890 ]
Kevin Yaussy commented on AMQ-643:
----------------------------------
Doh! Yes, issue resolved!
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC 2
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Hiram Chirino (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35852 ]
Hiram Chirino commented on AMQ-643:
-----------------------------------
Hi Kevin,
Yeah, I agree, making sure everybody is using the same setting is a bit of a problem. I working on a change right now that will allow the setting to be negociated by the 2 sides of the connection when it's initialy established.
If the server setting is x and the client setting is y, then the inactivity duration for the established connection will be calculated at min(x,y). This way the client and server do not have to have their configs match up exactly.
I'll update the issue once the change is commited.
Regards,
Hiram
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC1
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Kevin Yaussy (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35887 ]
Kevin Yaussy commented on AMQ-643:
----------------------------------
Tried this out yesterday and it seems to work perfectly. I was able to freeze brokers and have them disconnect from each other, but recover after unfreezing. Same for clients.
Nondurable messages are still queued to a disconnected broker, but that can be mitigated by having the asyncDispatch and an eviction strategy to your liking. I'd rather see the subscriptions dropped, and no further queuing, but maybe that wasn't doable.
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC 2
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Kevin Yaussy (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35847 ]
Kevin Yaussy commented on AMQ-643:
----------------------------------
So, in the case of the client setting the maxInactivityDuration value on its connector url, you are saying that the broker must have a maxInactivityDuration setting (with the same value) on the transportConnector url?
Not quite sure why you would want to make this restriction. Seems problematic with regards to potential timing issues.
Also, if you set the maxInactivityDuration on the transportConnector url, then when you have two brokers connected to each other, they continuously drop connections and resubscribe. If you also set maxInactivityDuration on the networkConnector url for each broker, then the brokers still drop connections and get whacked out with subcriptions.
I'll attach broker XML configs in a bit.
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC1
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Kevin Yaussy (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=all ]
Kevin Yaussy updated AMQ-643:
-----------------------------
Attachment: amq2.xml
amq1.xml
Attached are my broker XML configs. We run embedded brokers, but have external access to them (i.e. the tcp connectivity).
I've tried with and without the maxInactivityDuration setting on the networkConnector url.
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC1
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "james strachan (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35888 ]
james strachan commented on AMQ-643:
------------------------------------
We could always raise another feature request JIRA for the subscription dropping; also for nondurable messaging we have the option to drop old messages if consumers slow down.
So is this issue resolved now?
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC 2
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Hiram Chirino (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35845 ]
Hiram Chirino commented on AMQ-643:
-----------------------------------
Hi Kevin,
The maxInactivityDuration setting has to match on both sides of the connection. If they do then there is no need to make KeepAlives request a reply since the other side will send a KeepAlive if his side of the connection remains idle for too long.
Could you attache the broker configuration scripts you using? Thanks!
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC1
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Hiram Chirino (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35864 ]
Hiram Chirino commented on AMQ-643:
-----------------------------------
The change has been commited.
You now configure the maxInactivityDuration on the wireFormat. So on tcp connection, it would look like:
tcp://localhost:61616?wireFormat.maxInactivityDuration=10000
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC1
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Kevin Yaussy (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35861 ]
Kevin Yaussy commented on AMQ-643:
----------------------------------
However, that sounds like both sides would still have to explicitly make the setting, right?
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC1
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Hiram Chirino (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=all ]
Hiram Chirino updated AMQ-643:
------------------------------
Fix Version: (was: 4.0 RC1)
4.0 RC 2
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC 2
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Kevin Yaussy (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35889 ]
Kevin Yaussy commented on AMQ-643:
----------------------------------
I'm very happy with the eviction policy features. We will make *extensive* use of that (btw, we may want to implement an eviction policy at some point - any way to do that ?). However, I can raise a feature request for the subscription dropping.
One thing I forgot to mention in my comment above is that the broker networkConnector url config changed again. You now have to explicitly put on failover if you want broker-to-broker connections to use failover. That dropped off at one point (I was trying to find where you and I conversed about that - it was some other JIRA entry), where you would get double failover transport decorators, thus causing problems with shutdown. You said that static would do the same thing.
Anyway, not a big deal, but I believe you had updated some documentation regarding this. So, you might want to revisit that again.
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC 2
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "Kevin Yaussy (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35865 ]
Kevin Yaussy commented on AMQ-643:
----------------------------------
I'll try this out tomorrow after the SNAPSHOT build.
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC1
> Attachments: amq1.xml, amq2.xml
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (AMQ-643) maxInactivityDuration does not seem to
work properly
Posted by "james strachan (JIRA)" <ji...@activemq.org>.
[ http://jira.activemq.org/jira//browse/AMQ-643?page=all ]
james strachan reassigned AMQ-643:
----------------------------------
Assign To: Hiram Chirino
> maxInactivityDuration does not seem to work properly
> ----------------------------------------------------
>
> Key: AMQ-643
> URL: http://jira.activemq.org/jira//browse/AMQ-643
> Project: ActiveMQ
> Type: Bug
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC1
>
>
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.activemq.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira