Uploaded image for project: 'Qpid JMS'
  1. Qpid JMS
  2. QPIDJMS-514

thread for reconnecting a session is blocked forever

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.52.0
    • Fix Version/s: 0.59.0, 1.0.0
    • Component/s: qpid-jms-client
    • Labels:
      None
    • Environment:

      Cloud Foundry

      Description

      We're using the Qpid JMS library to connect via amqpws to a amqp gateway which then opens a connection to a message broker in a cloud foundry environment. When the message broker is reporting an error e.g. exceeding connection limits, the gateway is reporting an error to Qpid JMS. Qpid JMS recognizes the error but waits on several request.sync() calls forever when trying to reconnect via the failover mechanism. We tried debugging the issue but having trouble with understanding the code. We are assuming there is a Bug within the QPID library but we are currently missing the knowledge of the Qpid code. Do you have any hints at where we can look at. Is there some kind of documentation in order to understand the flows within Qpid JMS? For instance we don't know how Qpid JMS recognizes if an issue happens while creating the connection. It seems like there are several threads which should manipulate the ProviderFuture objects.

      For testing purposes we refactored all of the request.sync() calls to use the request.sync(timeout, unit) method. Of course, this is only a workaround for testing purposes but we can see that the connection is re-established after the timeout.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                tabish Timothy A. Bish
                Reporter:
                morten.riedel Morten
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: