Uploaded image for project: 'Qpid'
  1. Qpid
  2. QPID-4421

C++ Broker Issue with reusing link channel Id number too soon

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 0.18
    • 0.19
    • C++ Broker
    • None

    Description

      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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            chug Charles E. Rolke
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: