You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Chuck Rolke (JIRA)" <ji...@apache.org> on 2012/11/05 21:40:13 UTC
[jira] [Created] (QPID-4421) C++ Broker Issue with reusing link
channel Id number too soon
Chuck Rolke created QPID-4421:
---------------------------------
Summary: C++ Broker Issue with reusing link channel Id number too soon
Key: QPID-4421
URL: https://issues.apache.org/jira/browse/QPID-4421
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.18
Reporter: Chuck Rolke
Following on to QPID-4392
As you add and remove replicated queues within an HA broker, bridges are opened and closed for each queue. Closing a bridge immediately re-adds the associated channel number into an available pool. As a result, when the old bridge (channel X) is closed it sends a "detach" command to the broker and the new bridge (assigned the same channel X) sends an "attach" command. The broker will eventually respond with a "detached" command which was meant for the original bridge on channel X. Unfortunately, the new bridge on channel X handles this detached command from the broker and flags the bridge as detached. This process can then repeat for several cycles until it break out of the detach/attach/detached race.
In addition to the detach/attach/detached race, the immediate re-use of channel numbers appears to create other issues like the following:
Nov 2 11:26:40 itcm31 qpidd[12122]: 2012-11-02 11:26:40 [Protocol] error Execution exception: invalid-argument: anonymous.qpid.bridge_session_qpid.replicator-Queue1.b64c23e6-cb01-4297-8935-c12b40
804ae2_84209514-2e58-4fb9-8d37-7c2440f5f144: confirmed < (2+0) but only sent < (0+0) (qpid/SessionState.cpp:154)
This issue may be worked around by assigning channel Id numbers from the pool in increasing serial order and not immediately reusing a deallocated Id. Although this does not fix the problem of the race condition it will provide relief.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[jira] [Commented] (QPID-4421) C++ Broker Issue with reusing link
channel Id number too soon
Posted by "Chuck Rolke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490914#comment-13490914 ]
Chuck Rolke commented on QPID-4421:
-----------------------------------
Workaround submitted by r1405946
> C++ Broker Issue with reusing link channel Id number too soon
> -------------------------------------------------------------
>
> Key: QPID-4421
> URL: https://issues.apache.org/jira/browse/QPID-4421
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.18
> Reporter: Chuck Rolke
>
> Following on to QPID-4392
> As you add and remove replicated queues within an HA broker, bridges are opened and closed for each queue. Closing a bridge immediately re-adds the associated channel number into an available pool. As a result, when the old bridge (channel X) is closed it sends a "detach" command to the broker and the new bridge (assigned the same channel X) sends an "attach" command. The broker will eventually respond with a "detached" command which was meant for the original bridge on channel X. Unfortunately, the new bridge on channel X handles this detached command from the broker and flags the bridge as detached. This process can then repeat for several cycles until it break out of the detach/attach/detached race.
> In addition to the detach/attach/detached race, the immediate re-use of channel numbers appears to create other issues like the following:
> Nov 2 11:26:40 itcm31 qpidd[12122]: 2012-11-02 11:26:40 [Protocol] error Execution exception: invalid-argument: anonymous.qpid.bridge_session_qpid.replicator-Queue1.b64c23e6-cb01-4297-8935-c12b40
> 804ae2_84209514-2e58-4fb9-8d37-7c2440f5f144: confirmed < (2+0) but only sent < (0+0) (qpid/SessionState.cpp:154)
> This issue may be worked around by assigning channel Id numbers from the pool in increasing serial order and not immediately reusing a deallocated Id. Although this does not fix the problem of the race condition it will provide relief.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org