Hi Gordon turning out setting to Browse fixed the memory issue. Also one of the queues did not having a limit on it. Setting a limit resolved the issue. Thanks
On Fri, Feb 1, 2013 at 6:42 AM, Rajesh Khan <[email protected]> wrote: > Just looked at the code and to my surprise I am not browsing at that queue > - while I am at other LVQ. I thought that would not make much of a > difference. I'll add the browsing option as soon as I get to the code. > Could you kindly explain what effect browsing would have ? > > > > On Fri, Feb 1, 2013 at 6:42 AM, Gordon Sim <[email protected]> wrote: > >> On 02/01/2013 01:30 PM, Rajesh Khan wrote: >> >>> I'll be running the same project in an hour. However with different >>> capacity sizes as you suggested earlier (the sender C++ will have a >>> capacity of 300 and the receiver C# will have a 0 capacity and return >>> acknowledgment of messages after every 10 messages). Maybe this might >>> help.I am almost 80% sure this was the warning exception that I saw. >>> However Ill be certain to note the exception that comes up and post it >>> back. Also did you have any thoughts on the memory issue that I just >>> mentioned. Why the broker released all the memory only when the C# >>> receiver >>> reconnected.(I had to disconnect the receiver and reconnect). >>> >> >> My guess is that there were still a lot of unacknowledged messages being >> tracked, and closing the receiver allowed the broker to cleanup its records >> of those. Browsing or acking more frequently would reduce the number of >> deliveries the broker was tracking in this regard. >> >> Can I ask if there is a reason you are not browsing? (In that case the >> queue would always hold the last value for each key; the receiver would >> never delete anything from the queue and messages would be removed only >> when replaced by an update with the same key). >> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> [email protected].**org<[email protected]> >> For additional commands, e-mail: [email protected] >> >> >
