[
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.
