Yes we are doing sender.close() . Also why does the broker replay messages?

Nitin

-----Original Message-----
From: Gordon Sim [mailto:[email protected]] 
Sent: Tuesday, November 12, 2013 5:32 AM
To: [email protected]
Subject: Re: Problem/Explanation ?

On 11/11/2013 08:38 PM, Nitin Shah wrote:
> Hi,
>
> I wondered if someone on the Qpid mailing list can throw some light on this 
> issue we are seeing.
>
> We are using Qpid C++ brokers and clients of version 0.24.
>
> We are using Topic Exchanges.
>
> We create a sender on a particular session, then a message gets sent on that 
> sender followed by deleting the sender.

What exactly do you mean by 'deleting' in this case?

Are you calling Sender::close() for each of these? Are you waiting for the 
message sent asynchronously to complete before 'deleting' the sender?

If you are sending a single message per sender then perhaps it would be better 
to call send(msg, true), which blocks until the broker has confirmed the 
message.

> This is done a lot of times in a period of time.
> What we are seeing is that the memory usage on Qpid is increasing and 
> a lot of memory allocations sitting on the std::deque and that number 
> increases over time
>
> There are 2 problems we are seeing:
>
> 1.       That memory seems to be increasing on the std::deque list inside 
> Qpid.
>
> 2.       When we fail over the broker, there seems to be a lot of messages 
> that get replayed on the topics to the clients looking for received messages 
> on the same topic. These are message that have already been received before.
>
> Below is a snipet of what we have seen.
>
> Note that in the second half below, there are allocations which show the 
> number of bytes@address for time in -Minutes:seconds. These are blocks 
> allocated that are "alive" so to speak.
>
> Can someone explain why we would be seeing this and perhaps how we can avoid 
> the "replays".


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional 
commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to