Uploaded image for project: 'AMQ Clients'
  1. AMQ Clients
  2. ENTMQCL-3063

[cpp] Memory Leak When Closing Sender In Response to Exception

Details

    • Bug
    • Resolution: Unresolved
    • Normal
    • None
    • None
    • amqp-cpp-client
    • False
    • False
    • Hide

      Workaround documented in ENTMQCL-2871

      Show
      Workaround documented in ENTMQCL-2871
    • Hide

      Configure a router with a broker connector and linkRoute, similar to the attached example-qdrouterd.conf

      2. Configure and start an AMQ broker instance at the location indicated by the broker connector in the exmple-qdrouterd.conf

      3. Build and run the attached proton-cpp exmple . To track memory usage, run with valgrind.

      4. Monitor the broker until messages are produced to the foo.unicast address

      5. Stop and restart the broker

      6. Observe the error message logged by the client

      7. The error_handler closes the existing sender and creates a new sender. If this is repeated several time, growing memory usage is observed and reported as possible leakage by valgrind.

      Show
      Configure a router with a broker connector and linkRoute, similar to the attached example-qdrouterd.conf 2. Configure and start an AMQ broker instance at the location indicated by the broker connector in the exmple-qdrouterd.conf 3. Build and run the attached proton-cpp exmple . To track memory usage, run with valgrind. 4. Monitor the broker until messages are produced to the foo.unicast address 5. Stop and restart the broker 6. Observe the error message logged by the client 7. The error_handler closes the existing sender and creates a new sender. If this is repeated several time, growing memory usage is observed and reported as possible leakage by valgrind.

    Description

      In an environment where the Proton C++ client is presented with a link failure without an accompanying connection failure, there does not seem to be any obvious means of restoring the link without inducing a possible memory leak. Consider the following scenario:

      A client is connected to a qpid-dispatch router with a liniRoute to another router or broker, something like:

      proton-cpp-client<->qpid-dispatch-1<->qpid-dispatch-2<->amq-broker
      

      One of the upstream resources (qpid-dispatch-2 or broker) is restarted, resulting in a link failure, while the client remains connected to qpid-dispatch-1. Restoring connectivity upstream does not automatically restore the link and the client (a sender in this case) continues to report sending messages, but the messages never reach the sink (broker). Closing the sender on the client and opening a new sender seems to work (sending resumes and I can see messages reaching the broker), but this introduces a memory leak, as closing the old sender does not seem to clean up the resources (valgrind reports this as a possible leak, because the sender is still referenced by the connection). Naming the sender confirms this; if we try to close the sender and recreate it with the same name, creation fails, reporting that the link already exists.

      Attachments

        Issue Links

          Activity

            People

              kvanderr@redhat.com Kim van der Riet
              rhn-support-dhawkins Duane Hawkins
              Petr Matousek Petr Matousek
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated: