You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Gordon Sim (JIRA)" <qp...@incubator.apache.org> on 2008/05/01 21:40:55 UTC
[jira] Commented: (QPID-978) memory leak in C++ broker
[ https://issues.apache.org/jira/browse/QPID-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593615#action_12593615 ]
Gordon Sim commented on QPID-978:
---------------------------------
Apologies for the delay in responding! The memory build-up is due to messages not being acknowledged. This in turn is because the SubscriptionManager will not automatically acknowledge a message if the listener throws an exception while processing it. This is not a bug; its designed that way to avoid acknowledging messages whose processing was interrupted by some failure in order that the message can be redelivered if needed.
The envisaged use case for the SubscriptionManager (and the Dispatcher that underlies it) was that the run() call would keep going for the lifetime of the client and stop() would only be called when the client wished to exit. I can alter this to allow the dispatch thread to be restarted, however I wonder if perhaps there is a mre convenient pattern you could use here.
I've attached two examples that do the same thing as your original client (they are slightly updated for the final 0-10 spec changes also; queueBind=>exchangeBind; arg::routingKey=arg::bindingKey). The first one uses the listener thread to send subsequent messages; the second uses a LocalQueue and a pull style pattern. Are either of these suitable approaches?
Another option would be to run the dispatch loop on a separate thread and continue publishing on the main thread (publishing and receiving would then proceed concurrently). If this would help I can add a start() method to SubscriptionManager that could be called instead of run() and would return immediately with dispatching on a newly spawned thread.
> memory leak in C++ broker
> -------------------------
>
> Key: QPID-978
> URL: https://issues.apache.org/jira/browse/QPID-978
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: M2, M2.1
> Environment: Fedora 8 x86_64, qpid from redhat's package, compiled from qpid 2.1 sources and from svn trunk
> Reporter: Rudolf Polzer
> Assignee: Gordon Sim
> Attachments: client.cpp, server.cpp
>
>
> In a simple test program (basically, a qpid based echo server) used for measuring the latency of qpid, I get a severe memory leak - the 4GB RAM of this system are fully utilized after about two minutes.
> Also, subscriptions.stop() does not work right (subscriptions.run() then appears to succeed, but will never receive a packet), which is why I had to throw an exception to get out of the Listener after a packet was received on the latency measuring client. I will try to attach a test program code for this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.