Re: proton-j Reactor: Best way to implement Concurrent Sender

We followed a model similar to the first one Robbie outlined below. - We dedicate a thread to running the Reactor. - When an application does a ‘send’ the message is put on an internal queue and reactor.wakeup() is used just in case that thread is asleep. - We attempt physical message

RE: [JAVA-Android]Memory Leak Investigation

PS: don't use nabble when you send a mail because half of it is missing when we receive it. As for the Azure part, unfortunately I cannot help you because I never used it. Hopefully someone else will be able to. On Fri, Jul 29, 2016 at 7:45 PM +0300, wrote:

RE: [JAVA-Android]Memory Leak Investigation

If A holds a reference to B and B holds a reference to A. Then you will get this cyclic tree when you open A. Try opening the "referent" instead of the "runner" in the second image. From: kevin.le Sent: Friday, July 29, 18:53 Subject: RE: [JAVA-Android]Memory Leak Investigation To:

RE: [JAVA-Android]Memory Leak Investigation

Thanks for the quick reply Adel. Tried your suggestion. Here are some screengrabs: Looking at the second image, I could not understand it. The

RE: [Java Broker - 6.0.1] OutOfMemory in the directy memory buffer

Hello again, I re-launched the tests with 2 configurations and they both failed very quick: Xmx1g ---> Failed after sending just 12 000 messages Xmx2g ---> Failed after sending just 25 000 messages Regards, Adel > From: adelbout...@live.com > To: users@qpid.apache.org > Subject: RE: [Java

RE: [JAVA-Android]Memory Leak Investigation

Hi Kevin, For an object to be GCed, no other object should hold reference to it. So you need to know who is holding a reference to the object which you suspect is leaking.To do so in Eclipse Memory analyzer, right-click any object in the tree, select "List object --> with incoming references".

[JAVA-Android]Memory Leak Investigation

Hi all, I am using a slightly modified version of QPID to communicate with Microsoft Azure IoT Hub called proton-j-azure-iot-0.12.2. So straight to the problem. I am investigating a memory leak when using a HandlerThread class to post a task. Here is the rough code snippet : I've been

RE: [Java Broker - 6.0.1] OutOfMemory in the directy memory buffer

Hello Keith, As stated in this thread[1], we are actually doing some benchmarks to test the performance of the broker and the dispatch router. In the failing test case, I try to send the messages using 4 JMS producers connected directly to the broker each having its own connection (1 JVM per

RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid Java Broker 6.0.0

Here is an image representation of the badly formatted table: http://imgur.com/a/EuWch > From: adelbout...@live.com > To: users@qpid.apache.org > Subject: RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid > Java Broker 6.0.0 > Date: Fri, 29 Jul 2016 14:40:10 +0200 > > Hello

RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid Java Broker 6.0.0

Hello Ted, Increasing the link capacity had no impact. So, I have done a series of tests to try and isolate the issue. We tested 3 different architecture without any consumers: Producer --> Broker Producer --> Dispatcher Producer --> Dispatcher --> Broker In every test, we sent 100 000 messages