Re: Fwd: qpid proton integration with other event loops (i.e QT and ACE)

[Faycal El Karaa]

Hi Toby,

Thanks for the feedback.

Do you mean that the socket_engine has been removed after version 0.12.2?
hmmm...this is not a viable solution because now it means that you are
stuck with that version and can't benefit from bugs fixes, improvements etc
from newer versions, right?

I will have a look at it anyway, but it seems to me that as of today qpid
proton has not been designed to be easily integrated in other io
frameworks, which is a pity. One solution I can think of in my framework
for a qpid producer/publisher client is to create a specific ACE task in a
separate thread and communicate with that task/thread with an ACE queue
(each time a message is inserted into the queue, ACE will wake up the ACE
task), that would be the easiest as I won't have to dig into qpid io
framework. But for a consumer client, I have to have some kind of mechanism
to trigger an ACE event and from there call qpid protonI will have a
look at your solution, but it does not look very straightforward to me,
maybe because the proton io interface is still a little bit obscure imwo.
Also, as you mentionned, no security layers, which can be annoying as well
as my app is communicating with a server that is abroad...

Cheers,
Faycal

On Sat, Jul 9, 2016 at 1:42 AM, Tobias Duckworth 
wrote:

> Hi,
>
> I am also new to qpid-proton and needed to achieve a similar thing to you.
>
> I found the most recent releases 0.14 snapshot and 0.13.0 weren't very easy
> to interface with for the purposes you describe.
>
> I ended up using 0.12.2, which has a socket_engine
> (proton-c/bindings/cpp/include/proton/io.hpp).
> With this you can either get the socket engine to connect to your URL, or
> you can just provide the socket descriptor as a constructor parameter.
> Then you can 'drive' the engine either by calling the run() function on a
> thread (which isn't very useful for integrating into your own io
> framework),
> or by implementing the proton::handler interface in such a way that it is
> executed on the thread you wish to do the work on.
>
> It all works very nicely once you get it right, apart from I can't get any
> of the security layers to work at present, so no ssl or sasl yet.
>
> Good luck,
> Toby
>
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Fwd-qpid-proton-integration-with-other-event-loops-i-e-QT-and-ACE-tp7647033p7647096.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: Broker with live data

[Artem]

Ted,

thanks a lot. May be Java  experts help me later.

Artem



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Broker-with-live-data-tp7647047p7647139.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Broker with live data

[Ted Ross]

I'll defer to the Java experts on the details of Proton-J.  My 
experience is with Proton-C.


Proton is single-threaded.  You cannot call Sender.send from within your 
cursor-waiting thread.  You need a way to awaken the Proton thread when 
the cursor has new data so you can invoke Sender.send from the Proton 
thread.


This is exactly how a message broker works, replacing the cursor with a 
queue.  There are probably several examples of how this can be done.  I 
know that both the Apache ActiveMQ and ActiveMQ-Artemis brokers use 
Proton-J for AMQP connectivity.  Perhaps you can take a look at how 
those projects solved this problem.


-Ted


On 07/08/2016 04:02 PM, Artem wrote:

Ted,

yes, the cursor associated with a link 1 to 1.  And no, i don`t know about
reactive programming model.

If my cursor waiting function processing at own thread and when it is onData
function invoke if can i send data to proton link using Sender.send?  (like
at this example)


Artem



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Broker-with-live-data-tp7647047p7647134.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Broker with live data

[Artem]

Ted,

yes, the cursor associated with a link 1 to 1.  And no, i don`t know about
reactive programming model.

If my cursor waiting function processing at own thread and when it is onData
function invoke if can i send data to proton link using Sender.send?  (like
at this example)

   

Artem



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Broker-with-live-data-tp7647047p7647134.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Broker with live data

[Ted Ross]

Artem,

Do AMQP subscribers subscribe to a cursor (i.e. cursor and pn_link are 1 
to 1)?  If so, you probably have some data structure that represents the 
subscription.  This data structure holds references to the proton link 
and the cursor.  I don't know how your program is structured, so I can't 
comment in too much detail.  Are you familiar with the reactive 
programming model?


-Ted

On 07/08/2016 03:33 PM, Artem wrote:

Ted,

Please describe how the data should be send to consumer function when onData
function is invoked?(if this function have a link, and i do the
Sender.send(message) whether there is a transfer messages in transport and
write to socket?)

Artem




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Broker-with-live-data-tp7647047p7647127.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Broker with live data

[Artem]

Ted,

Please describe how the data should be send to consumer function when onData
function is invoked?(if this function have a link, and i do the
Sender.send(message) whether there is a transfer messages in transport and
write to socket?)

Artem




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Broker-with-live-data-tp7647047p7647127.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Broker with live data

[Ted Ross]

Artem,

Proton uses a non-blocking, reactive model.  I think you need to also 
have such a model for whatever database you are interfacing to.


For the sending case (i.e. live data to a consumer), you need to have 
something like an onData function that is invoked when the cursor has 
more data to consume.  This can then check the outgoing credit and 
transfer the data if there is sufficient credit.  Likewise, when you get 
credit (onLinkFlow) from a consumer, you need to have a non-blocking way 
to query the cursor to see if it has more data.


With this model, live-data is controlled by onLinkFlow (you can transfer 
data to the consumer) and onData (there is new data to transfer).  This 
can scale to large numbers of cursors and consumers.


I hope this is helpful.

-Ted

On 07/08/2016 02:50 PM, Artem wrote:

Robbie,

Now i have a big broker server and now i want to support AMQP 1.0 protocol
and one of the best options that I found - is to use a Qpid Proton J.

I`m read examples how use Proton and write this work model of my server:
1)When i have event "onLinkRemoteOpen" - i`m create connection to my
database(it`s a cursor), and mapped it with the Link.
2)When i have event "onLinkFlow" - i get message from cursor and do
Sender.send(message). Then
it should be "onTransport" event. The specification of AMQP 1.0 says that
for each "onTransport" event will be return "onLinkFlow" event. Working on
this principle the server sends a large number of messages.

Cursor like iterator have 2 methods: next() and getMessage(). Cursor can
work at 2 modes: live and simple. At simple mode it read all data from DB
and then close. *But at live mode when data run out in the database and i
call cursor.next()  -  cursor waiting for data as long as they are not
written in database.* (I can waiting data in other thread.) In this way
while live cursor waiting data other links are not processing by the server.
And the second problem is that, how to send Heartbeat frame to user that
waiting live data?

How i can change this model of my server to support live data?


Artem





--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Broker-with-live-data-tp7647047p7647123.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Broker with live data

[Artem]

Robbie,

Now i have a big broker server and now i want to support AMQP 1.0 protocol
and one of the best options that I found - is to use a Qpid Proton J. 

I`m read examples how use Proton and write this work model of my server: 
1)When i have event "onLinkRemoteOpen" - i`m create connection to my
database(it`s a cursor), and mapped it with the Link. 
2)When i have event "onLinkFlow" - i get message from cursor and do
Sender.send(message). Then 
it should be "onTransport" event. The specification of AMQP 1.0 says that
for each "onTransport" event will be return "onLinkFlow" event. Working on
this principle the server sends a large number of messages.

Cursor like iterator have 2 methods: next() and getMessage(). Cursor can
work at 2 modes: live and simple. At simple mode it read all data from DB
and then close. *But at live mode when data run out in the database and i
call cursor.next()  -  cursor waiting for data as long as they are not
written in database.* (I can waiting data in other thread.) In this way
while live cursor waiting data other links are not processing by the server.
And the second problem is that, how to send Heartbeat frame to user that
waiting live data?

How i can change this model of my server to support live data?


Artem





--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Broker-with-live-data-tp7647047p7647123.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Ted Ross]

From what I understand of your setup, I think you should remove two 
autoLinks from your router config.  The perf.topic/in and the 
perfQueue/out links are not necessary and the perf.topic/in link is 
actually causing problems because of the side-effect of the creation of 
the temporary queue.


-Ted

On 07/08/2016 01:11 PM, Olivier Mallassi wrote:

We need to run the tests again but you are right. Looking at the Dispatch
Router config, the links are in and out.
thx.


On Fri, Jul 8, 2016 at 5:47 PM, Ted Ross  wrote:




On 07/08/2016 11:42 AM, Olivier Mallassi wrote:


Hi Rob

We have the following topology:

* Publisher -> Dispatcher -> Broker1 or Broker 2 (Java) -> Dispatcher
(same
instance) -> Consumer
* each Broker is configured (before the run)
- with an exchange perf.topic (amqp topic)
- with a queue  (perf.queue) that has a binding (binding key + header
based
filtering) to the perf.topic exchange

* the Dispatcher is configured with autoLink
* The publisher publish in perf.topic (kind of distributed topic)
* The consumer consume from perf.queue (distributed queue)
* Dispatch version is 0.6.0 and Broker is in version 6.0.0.



I think your autoLink _in_ from perf.topic is spurious.  I suspect that
there are no consumers on the router consuming from "perf.topic" and
therefore the listener attached to the temporary queue is never issued
credit and it accumulates all perf.topic messages.




We have the expected behavior : published messages are load-balanced on
brokers and consumed as expected.

Yet, and we observed the OOM while running the test for a longer time,
when
the dispatcher connect, it creates a queue with a UUID (more or less)
name.
that queue is bind to perf.topic with # as a binding key (so every
messages
sent by the publisher fill up this queue thus the OOM because it is in
memory).

It looks to be "expected".
Is there a way to avoid this? are we missing something?

Many thx.

oliv/






On Fri, Jul 8, 2016 at 5:16 PM, Rob Godfrey 
wrote:

Hi Adel,


I'm a bit confused... you say

As no consumer is connected to this queue, all messages are kept



in-memory which causes the OutOfMemory exception in the broker.

but then also say

Consumer connected to that queue (Is it the dispatcher?):

Name: qdlink.OyY41QAJRZ4JGGg
Mode: MOVE



Does the queue have a consumer or not?

As to holding on to the messages... the heap dump shows that the message
is
in the queue (which we know) and has not been evicted by flow to disk
(we'd
need to work out why)...

On average what size are the messages you are sending?  Do you see
messages
flow through this topic at all?

As to the "weird" queue name - what is happening is that we are creating
an
internal temporary queue when you subscribe to an exchange object in the
broker... for that we use a UUID as the queue name.

-- Rob

On 8 July 2016 at 15:48, Adel Boutros  wrote:

I forgot to add that when I execute a qdmanage command to delete the

"connector" to the broker, the weird queue disappears.

Adel

Date: Fri, 8 Jul 2016 07:45:49 -0700

From: adelbout...@live.com
To: users@qpid.apache.org
Subject: Re: OutOfMemory exception with a Qpid Java Broker linked to


qpid dispatcher



Fixing bad formatting on Nabbledue to Hotmail:

Hello,

We are doing some performance tests with a Qpid Java Broker connected


to



a


Qpid dispatcher.
We have noticed that after some time, the broker dies with an


OutOfMemory



exception and java heap is dumped.

After analyzing the heap dump and checking the broker, we have noticed


2



weird behaviors:


1) A queue is created on the broker with a weird Name bound on our


topic



(perf.topic) with a binding key "#". It will receive all messages.

This queue seems to be created only when the dispatcher is present and


is



configured.

As no consumer is connected to this queue, all messages are kept


in-memory


which causes the OutOfMemory exception in the broker.

Weird Queue definition
Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
Type: standard
State: ACTIVE
Durable: false
Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
Persist Messages: NEVER
Inbound: 0 msg/s (0.00 B/s)
Outbound: 0 msg/s (0.00 B/s)
Size: 2374 msgs (0.00 B)
Pre-fetched: 0 msgs (0.00 B)
Oldest Message Age: 356.064 secs
Enforced Max. Ttl(ms): 0
Enforced Min. Ttl(ms): 0
Exclusive: LINK

Consumer connected to that queue (Is it the dispatcher?):
Name: qdlink.OyY41QAJRZ4JGGg
Mode: MOVE


2) All messages even those consumed successfully by the consumers are


still


present on the broker

From the heap dump, we can see the Berkley DB is keeping a reference to


all


messages. Is this also coming from the above weird queue?


PS: If we only use the dispatcher instead, we have none of the weird
behaviors

Extract from the heap dump (Object holding
reference to one of the message header. "Validated" is one the message
header fields we set and which is already received by a consumer)

char[9] @ 0xf59ff3d8  VALIDATED
'- value java.lang.String @ 0xf59ff3c0  VALIDATED
  '

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Olivier Mallassi]

We need to run the tests again but you are right. Looking at the Dispatch
Router config, the links are in and out.
thx.


On Fri, Jul 8, 2016 at 5:47 PM, Ted Ross  wrote:

>
>
> On 07/08/2016 11:42 AM, Olivier Mallassi wrote:
>
>> Hi Rob
>>
>> We have the following topology:
>>
>> * Publisher -> Dispatcher -> Broker1 or Broker 2 (Java) -> Dispatcher
>> (same
>> instance) -> Consumer
>> * each Broker is configured (before the run)
>> - with an exchange perf.topic (amqp topic)
>> - with a queue  (perf.queue) that has a binding (binding key + header
>> based
>> filtering) to the perf.topic exchange
>>
>> * the Dispatcher is configured with autoLink
>> * The publisher publish in perf.topic (kind of distributed topic)
>> * The consumer consume from perf.queue (distributed queue)
>> * Dispatch version is 0.6.0 and Broker is in version 6.0.0.
>>
>
> I think your autoLink _in_ from perf.topic is spurious.  I suspect that
> there are no consumers on the router consuming from "perf.topic" and
> therefore the listener attached to the temporary queue is never issued
> credit and it accumulates all perf.topic messages.
>
>
>
>> We have the expected behavior : published messages are load-balanced on
>> brokers and consumed as expected.
>>
>> Yet, and we observed the OOM while running the test for a longer time,
>> when
>> the dispatcher connect, it creates a queue with a UUID (more or less)
>> name.
>> that queue is bind to perf.topic with # as a binding key (so every
>> messages
>> sent by the publisher fill up this queue thus the OOM because it is in
>> memory).
>>
>> It looks to be "expected".
>> Is there a way to avoid this? are we missing something?
>>
>> Many thx.
>>
>> oliv/
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 8, 2016 at 5:16 PM, Rob Godfrey 
>> wrote:
>>
>> Hi Adel,
>>>
>>> I'm a bit confused... you say
>>>
>>> As no consumer is connected to this queue, all messages are kept

>>> in-memory which causes the OutOfMemory exception in the broker.
>>>
>>> but then also say
>>>
>>> Consumer connected to that queue (Is it the dispatcher?):
 Name: qdlink.OyY41QAJRZ4JGGg
 Mode: MOVE

>>>
>>> Does the queue have a consumer or not?
>>>
>>> As to holding on to the messages... the heap dump shows that the message
>>> is
>>> in the queue (which we know) and has not been evicted by flow to disk
>>> (we'd
>>> need to work out why)...
>>>
>>> On average what size are the messages you are sending?  Do you see
>>> messages
>>> flow through this topic at all?
>>>
>>> As to the "weird" queue name - what is happening is that we are creating
>>> an
>>> internal temporary queue when you subscribe to an exchange object in the
>>> broker... for that we use a UUID as the queue name.
>>>
>>> -- Rob
>>>
>>> On 8 July 2016 at 15:48, Adel Boutros  wrote:
>>>
>>> I forgot to add that when I execute a qdmanage command to delete the
 "connector" to the broker, the weird queue disappears.

 Adel

 Date: Fri, 8 Jul 2016 07:45:49 -0700
> From: adelbout...@live.com
> To: users@qpid.apache.org
> Subject: Re: OutOfMemory exception with a Qpid Java Broker linked to
>
 qpid dispatcher

>
> Fixing bad formatting on Nabbledue to Hotmail:
>
> Hello,
>
> We are doing some performance tests with a Qpid Java Broker connected
>
 to
>>>
 a

> Qpid dispatcher.
> We have noticed that after some time, the broker dies with an
>
 OutOfMemory
>>>
 exception and java heap is dumped.
> After analyzing the heap dump and checking the broker, we have noticed
>
 2
>>>
 weird behaviors:
>
> 1) A queue is created on the broker with a weird Name bound on our
>
 topic
>>>
 (perf.topic) with a binding key "#". It will receive all messages.
> This queue seems to be created only when the dispatcher is present and
>
 is
>>>
 configured.
> As no consumer is connected to this queue, all messages are kept
>
 in-memory

> which causes the OutOfMemory exception in the broker.
>
> Weird Queue definition
> Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
> Type: standard
> State: ACTIVE
> Durable: false
> Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
> Persist Messages: NEVER
> Inbound: 0 msg/s (0.00 B/s)
> Outbound: 0 msg/s (0.00 B/s)
> Size: 2374 msgs (0.00 B)
> Pre-fetched: 0 msgs (0.00 B)
> Oldest Message Age: 356.064 secs
> Enforced Max. Ttl(ms): 0
> Enforced Min. Ttl(ms): 0
> Exclusive: LINK
>
> Consumer connected to that queue (Is it the dispatcher?):
> Name: qdlink.OyY41QAJRZ4JGGg
> Mode: MOVE
>
>
> 2) All messages even those consumed successfully by the consumers are
>
 still

> present on the broker
>
> From the heap dump, we can see the Berkley DB is keeping a reference to
>
 all

> messages. Is this also coming from the above weird queue?
>
>
> PS: If we only use

Re: Fwd: qpid proton integration with other event loops (i.e QT and ACE)

[Tobias Duckworth]

Hi,

I am also new to qpid-proton and needed to achieve a similar thing to you.

I found the most recent releases 0.14 snapshot and 0.13.0 weren't very easy
to interface with for the purposes you describe.

I ended up using 0.12.2, which has a socket_engine
(proton-c/bindings/cpp/include/proton/io.hpp).
With this you can either get the socket engine to connect to your URL, or
you can just provide the socket descriptor as a constructor parameter.
Then you can 'drive' the engine either by calling the run() function on a
thread (which isn't very useful for integrating into your own io framework),
or by implementing the proton::handler interface in such a way that it is
executed on the thread you wish to do the work on.

It all works very nicely once you get it right, apart from I can't get any
of the security layers to work at present, so no ssl or sasl yet.

Good luck,
Toby




--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Fwd-qpid-proton-integration-with-other-event-loops-i-e-QT-and-ACE-tp7647033p7647096.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Broker with live data

[Robbie Gemmell]

Hi Artem,

I'm afraid I still don't really understand your use case enough from
the limited description. Regardless, my main question would be whether
you really need/want to write your own AMQP 1.0 message broker/server
as your mail suggests, rather than just using one of several existing
available? A fuller understanding what it is you are doing would help
with suggesting things.

Robbie

On 8 July 2016 at 15:24, Artem  wrote:
> Robbie,
>
> I need to do Java broker server, that can send messages at live mode
> (desirable for each link asynchronously ). My server has a cursor, that
> return messages, if there is no messages , it expects them (can sleep at own
> thread, or throws exception).
>
> I need to make sure that the  driver
> 
> worked on a separate thread , and wait and sends a message at another
> thread.
>
> Artem
>
>
>
> --
> View this message in context: 
> http://qpid.2158936.n2.nabble.com/Broker-with-live-data-tp7647047p7647062.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

qpid-proton 0.12.2 connection_engine and ssl

[Tobias Duckworth]

Hi,

I've used qpid-proton-0.12.2 in my application as a connection_engine or 
io::socket_engine. I need to arrange for the connect and reading/writing 
to happen asynchronously and my implementation sits within an existing 
io framework.


Everything has integrated quite nicely, apart from SSL, which I cannot 
get to work.


I have some straightforward C++ examples, one of which derives from 
connection_engine, and the other from container. I can see that for the 
container example ssl_init gets called from connection_options.cpp and 
everything then works nicely, whereas for the connection_engine example 
it does not.


The problem seems to be that for the connection_engine build 'outbound' 
is not set, and therefore ssl_init does not get called.


Please could someone explain how to implement an amqp client using the 
connection_engine framework that supports SSL?


Many thanks,
Toby



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Ted Ross]

On 07/08/2016 11:42 AM, Olivier Mallassi wrote:

Hi Rob

We have the following topology:

* Publisher -> Dispatcher -> Broker1 or Broker 2 (Java) -> Dispatcher (same
instance) -> Consumer
* each Broker is configured (before the run)
- with an exchange perf.topic (amqp topic)
- with a queue  (perf.queue) that has a binding (binding key + header based
filtering) to the perf.topic exchange

* the Dispatcher is configured with autoLink
* The publisher publish in perf.topic (kind of distributed topic)
* The consumer consume from perf.queue (distributed queue)
* Dispatch version is 0.6.0 and Broker is in version 6.0.0.


I think your autoLink _in_ from perf.topic is spurious.  I suspect that 
there are no consumers on the router consuming from "perf.topic" and 
therefore the listener attached to the temporary queue is never issued 
credit and it accumulates all perf.topic messages.




We have the expected behavior : published messages are load-balanced on
brokers and consumed as expected.

Yet, and we observed the OOM while running the test for a longer time, when
the dispatcher connect, it creates a queue with a UUID (more or less) name.
that queue is bind to perf.topic with # as a binding key (so every messages
sent by the publisher fill up this queue thus the OOM because it is in
memory).

It looks to be "expected".
Is there a way to avoid this? are we missing something?

Many thx.

oliv/






On Fri, Jul 8, 2016 at 5:16 PM, Rob Godfrey  wrote:


Hi Adel,

I'm a bit confused... you say


As no consumer is connected to this queue, all messages are kept

in-memory which causes the OutOfMemory exception in the broker.

but then also say


Consumer connected to that queue (Is it the dispatcher?):
Name: qdlink.OyY41QAJRZ4JGGg
Mode: MOVE


Does the queue have a consumer or not?

As to holding on to the messages... the heap dump shows that the message is
in the queue (which we know) and has not been evicted by flow to disk (we'd
need to work out why)...

On average what size are the messages you are sending?  Do you see messages
flow through this topic at all?

As to the "weird" queue name - what is happening is that we are creating an
internal temporary queue when you subscribe to an exchange object in the
broker... for that we use a UUID as the queue name.

-- Rob

On 8 July 2016 at 15:48, Adel Boutros  wrote:


I forgot to add that when I execute a qdmanage command to delete the
"connector" to the broker, the weird queue disappears.

Adel


Date: Fri, 8 Jul 2016 07:45:49 -0700
From: adelbout...@live.com
To: users@qpid.apache.org
Subject: Re: OutOfMemory exception with a Qpid Java Broker linked to

qpid dispatcher


Fixing bad formatting on Nabbledue to Hotmail:

Hello,

We are doing some performance tests with a Qpid Java Broker connected

to

a

Qpid dispatcher.
We have noticed that after some time, the broker dies with an

OutOfMemory

exception and java heap is dumped.
After analyzing the heap dump and checking the broker, we have noticed

2

weird behaviors:

1) A queue is created on the broker with a weird Name bound on our

topic

(perf.topic) with a binding key "#". It will receive all messages.
This queue seems to be created only when the dispatcher is present and

is

configured.
As no consumer is connected to this queue, all messages are kept

in-memory

which causes the OutOfMemory exception in the broker.

Weird Queue definition
Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
Type: standard
State: ACTIVE
Durable: false
Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
Persist Messages: NEVER
Inbound: 0 msg/s (0.00 B/s)
Outbound: 0 msg/s (0.00 B/s)
Size: 2374 msgs (0.00 B)
Pre-fetched: 0 msgs (0.00 B)
Oldest Message Age: 356.064 secs
Enforced Max. Ttl(ms): 0
Enforced Min. Ttl(ms): 0
Exclusive: LINK

Consumer connected to that queue (Is it the dispatcher?):
Name: qdlink.OyY41QAJRZ4JGGg
Mode: MOVE


2) All messages even those consumed successfully by the consumers are

still

present on the broker

From the heap dump, we can see the Berkley DB is keeping a reference to

all

messages. Is this also coming from the above weird queue?


PS: If we only use the dispatcher instead, we have none of the weird
behaviors

Extract from the heap dump (Object holding
reference to one of the message header. "Validated" is one the message
header fields we set and which is already received by a consumer)

char[9] @ 0xf59ff3d8  VALIDATED
'- value java.lang.String @ 0xf59ff3c0  VALIDATED
  '- value java.util.HashMap$Entry @ 0xf59ff310
'- [3] java.util.HashMap$Entry[8] @ 0xf59ff2c0
  '- table java.util.HashMap @ 0xf59ff188
'- _appProperties
org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0 @ 0xf59fef88
  '- _metaData




org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$MessageDataSoftRef

@ 0xf59fef70
'- _messageDataRef




org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage

@ 0xf59fef20
  '- _handle

org.apache.qpid.server.protocol.v1_

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Olivier Mallassi]

Ted,

yes. this is as you describe
the queue that fills up is the "UUID name" queue (created by the Dispatch
Router ).

On Fri, Jul 8, 2016 at 5:42 PM, Olivier Mallassi  wrote:

> Hi Rob
>
> We have the following topology:
>
> * Publisher -> Dispatcher -> Broker1 or Broker 2 (Java) -> Dispatcher
> (same instance) -> Consumer
> * each Broker is configured (before the run)
> - with an exchange perf.topic (amqp topic)
> - with a queue  (perf.queue) that has a binding (binding key + header
> based filtering) to the perf.topic exchange
>
> * the Dispatcher is configured with autoLink
> * The publisher publish in perf.topic (kind of distributed topic)
> * The consumer consume from perf.queue (distributed queue)
> * Dispatch version is 0.6.0 and Broker is in version 6.0.0.
>
> We have the expected behavior : published messages are load-balanced on
> brokers and consumed as expected.
>
> Yet, and we observed the OOM while running the test for a longer time,
> when the dispatcher connect, it creates a queue with a UUID (more or less)
> name. that queue is bind to perf.topic with # as a binding key (so every
> messages sent by the publisher fill up this queue thus the OOM because it
> is in memory).
>
> It looks to be "expected".
> Is there a way to avoid this? are we missing something?
>
> Many thx.
>
> oliv/
>
>
>
>
>
>
> On Fri, Jul 8, 2016 at 5:16 PM, Rob Godfrey 
> wrote:
>
>> Hi Adel,
>>
>> I'm a bit confused... you say
>>
>> > As no consumer is connected to this queue, all messages are kept
>> in-memory which causes the OutOfMemory exception in the broker.
>>
>> but then also say
>>
>> > Consumer connected to that queue (Is it the dispatcher?):
>> > Name: qdlink.OyY41QAJRZ4JGGg
>> > Mode: MOVE
>>
>> Does the queue have a consumer or not?
>>
>> As to holding on to the messages... the heap dump shows that the message
>> is
>> in the queue (which we know) and has not been evicted by flow to disk
>> (we'd
>> need to work out why)...
>>
>> On average what size are the messages you are sending?  Do you see
>> messages
>> flow through this topic at all?
>>
>> As to the "weird" queue name - what is happening is that we are creating
>> an
>> internal temporary queue when you subscribe to an exchange object in the
>> broker... for that we use a UUID as the queue name.
>>
>> -- Rob
>>
>> On 8 July 2016 at 15:48, Adel Boutros  wrote:
>>
>> > I forgot to add that when I execute a qdmanage command to delete the
>> > "connector" to the broker, the weird queue disappears.
>> >
>> > Adel
>> >
>> > > Date: Fri, 8 Jul 2016 07:45:49 -0700
>> > > From: adelbout...@live.com
>> > > To: users@qpid.apache.org
>> > > Subject: Re: OutOfMemory exception with a Qpid Java Broker linked to
>> > qpid dispatcher
>> > >
>> > > Fixing bad formatting on Nabbledue to Hotmail:
>> > >
>> > > Hello,
>> > >
>> > > We are doing some performance tests with a Qpid Java Broker connected
>> to
>> > a
>> > > Qpid dispatcher.
>> > > We have noticed that after some time, the broker dies with an
>> OutOfMemory
>> > > exception and java heap is dumped.
>> > > After analyzing the heap dump and checking the broker, we have
>> noticed 2
>> > > weird behaviors:
>> > >
>> > > 1) A queue is created on the broker with a weird Name bound on our
>> topic
>> > > (perf.topic) with a binding key "#". It will receive all messages.
>> > > This queue seems to be created only when the dispatcher is present
>> and is
>> > > configured.
>> > > As no consumer is connected to this queue, all messages are kept
>> > in-memory
>> > > which causes the OutOfMemory exception in the broker.
>> > >
>> > > Weird Queue definition
>> > > Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
>> > > Type: standard
>> > > State: ACTIVE
>> > > Durable: false
>> > > Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
>> > > Persist Messages: NEVER
>> > > Inbound: 0 msg/s (0.00 B/s)
>> > > Outbound: 0 msg/s (0.00 B/s)
>> > > Size: 2374 msgs (0.00 B)
>> > > Pre-fetched: 0 msgs (0.00 B)
>> > > Oldest Message Age: 356.064 secs
>> > > Enforced Max. Ttl(ms): 0
>> > > Enforced Min. Ttl(ms): 0
>> > > Exclusive: LINK
>> > >
>> > > Consumer connected to that queue (Is it the dispatcher?):
>> > > Name: qdlink.OyY41QAJRZ4JGGg
>> > > Mode: MOVE
>> > >
>> > >
>> > > 2) All messages even those consumed successfully by the consumers are
>> > still
>> > > present on the broker
>> > >
>> > > From the heap dump, we can see the Berkley DB is keeping a reference
>> to
>> > all
>> > > messages. Is this also coming from the above weird queue?
>> > >
>> > >
>> > > PS: If we only use the dispatcher instead, we have none of the weird
>> > > behaviors
>> > >
>> > > Extract from the heap dump (Object holding
>> > > reference to one of the message header. "Validated" is one the message
>> > > header fields we set and which is already received by a consumer)
>> > >
>> > > char[9] @ 0xf59ff3d8  VALIDATED
>> > > '- value java.lang.String @ 0xf59ff3c0  VALIDATED
>> > >   '- value java.util.HashMap$Entry @ 0xf59ff310
>> > > '- [3] java.util.HashMap

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Olivier Mallassi]

Hi Rob

We have the following topology:

* Publisher -> Dispatcher -> Broker1 or Broker 2 (Java) -> Dispatcher (same
instance) -> Consumer
* each Broker is configured (before the run)
- with an exchange perf.topic (amqp topic)
- with a queue  (perf.queue) that has a binding (binding key + header based
filtering) to the perf.topic exchange

* the Dispatcher is configured with autoLink
* The publisher publish in perf.topic (kind of distributed topic)
* The consumer consume from perf.queue (distributed queue)
* Dispatch version is 0.6.0 and Broker is in version 6.0.0.

We have the expected behavior : published messages are load-balanced on
brokers and consumed as expected.

Yet, and we observed the OOM while running the test for a longer time, when
the dispatcher connect, it creates a queue with a UUID (more or less) name.
that queue is bind to perf.topic with # as a binding key (so every messages
sent by the publisher fill up this queue thus the OOM because it is in
memory).

It looks to be "expected".
Is there a way to avoid this? are we missing something?

Many thx.

oliv/






On Fri, Jul 8, 2016 at 5:16 PM, Rob Godfrey  wrote:

> Hi Adel,
>
> I'm a bit confused... you say
>
> > As no consumer is connected to this queue, all messages are kept
> in-memory which causes the OutOfMemory exception in the broker.
>
> but then also say
>
> > Consumer connected to that queue (Is it the dispatcher?):
> > Name: qdlink.OyY41QAJRZ4JGGg
> > Mode: MOVE
>
> Does the queue have a consumer or not?
>
> As to holding on to the messages... the heap dump shows that the message is
> in the queue (which we know) and has not been evicted by flow to disk (we'd
> need to work out why)...
>
> On average what size are the messages you are sending?  Do you see messages
> flow through this topic at all?
>
> As to the "weird" queue name - what is happening is that we are creating an
> internal temporary queue when you subscribe to an exchange object in the
> broker... for that we use a UUID as the queue name.
>
> -- Rob
>
> On 8 July 2016 at 15:48, Adel Boutros  wrote:
>
> > I forgot to add that when I execute a qdmanage command to delete the
> > "connector" to the broker, the weird queue disappears.
> >
> > Adel
> >
> > > Date: Fri, 8 Jul 2016 07:45:49 -0700
> > > From: adelbout...@live.com
> > > To: users@qpid.apache.org
> > > Subject: Re: OutOfMemory exception with a Qpid Java Broker linked to
> > qpid dispatcher
> > >
> > > Fixing bad formatting on Nabbledue to Hotmail:
> > >
> > > Hello,
> > >
> > > We are doing some performance tests with a Qpid Java Broker connected
> to
> > a
> > > Qpid dispatcher.
> > > We have noticed that after some time, the broker dies with an
> OutOfMemory
> > > exception and java heap is dumped.
> > > After analyzing the heap dump and checking the broker, we have noticed
> 2
> > > weird behaviors:
> > >
> > > 1) A queue is created on the broker with a weird Name bound on our
> topic
> > > (perf.topic) with a binding key "#". It will receive all messages.
> > > This queue seems to be created only when the dispatcher is present and
> is
> > > configured.
> > > As no consumer is connected to this queue, all messages are kept
> > in-memory
> > > which causes the OutOfMemory exception in the broker.
> > >
> > > Weird Queue definition
> > > Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
> > > Type: standard
> > > State: ACTIVE
> > > Durable: false
> > > Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
> > > Persist Messages: NEVER
> > > Inbound: 0 msg/s (0.00 B/s)
> > > Outbound: 0 msg/s (0.00 B/s)
> > > Size: 2374 msgs (0.00 B)
> > > Pre-fetched: 0 msgs (0.00 B)
> > > Oldest Message Age: 356.064 secs
> > > Enforced Max. Ttl(ms): 0
> > > Enforced Min. Ttl(ms): 0
> > > Exclusive: LINK
> > >
> > > Consumer connected to that queue (Is it the dispatcher?):
> > > Name: qdlink.OyY41QAJRZ4JGGg
> > > Mode: MOVE
> > >
> > >
> > > 2) All messages even those consumed successfully by the consumers are
> > still
> > > present on the broker
> > >
> > > From the heap dump, we can see the Berkley DB is keeping a reference to
> > all
> > > messages. Is this also coming from the above weird queue?
> > >
> > >
> > > PS: If we only use the dispatcher instead, we have none of the weird
> > > behaviors
> > >
> > > Extract from the heap dump (Object holding
> > > reference to one of the message header. "Validated" is one the message
> > > header fields we set and which is already received by a consumer)
> > >
> > > char[9] @ 0xf59ff3d8  VALIDATED
> > > '- value java.lang.String @ 0xf59ff3c0  VALIDATED
> > >   '- value java.util.HashMap$Entry @ 0xf59ff310
> > > '- [3] java.util.HashMap$Entry[8] @ 0xf59ff2c0
> > >   '- table java.util.HashMap @ 0xf59ff188
> > > '- _appProperties
> > > org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0 @ 0xf59fef88
> > >   '- _metaData
> > >
> >
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$MessageDataSoftRef
> > > @ 0xf59fef70
> > > '- _messageDataRef
> 

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Ted Ross]

On 07/08/2016 10:40 AM, Adel Boutros wrote:

Hello,

We are doing some performance tests with a Qpid Java Broker connected to a Qpid 
dispatcher.
We have noticed that after some time, the broker dies with an OutOfMemory 
exception and java heap is dumped.
After analyzing the heap dump and checking the broker, we have noticed 2 weird 
behaviors:

A queue is created on the broker with a weird Name bound on our topic
(perf.topic) with a binding key "#"
It will receive all messages.
This queue seems to be created only when the dispatcher is present and is 
configured.
As no consumer is connected to this queue, all messages are kept in-memory 
which causes the OutOfMemory exception in the broker.

Weird Queue definition
Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
Type: standard
State: ACTIVE
Durable: false
Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
Persist Messages: NEVER
Inbound: 0 msg/s (0.00 B/s)
Outbound: 0 msg/s (0.00 B/s)
Size: 2374 msgs (0.00 B)
Pre-fetched: 0 msgs (0.00 B)
Oldest Message Age: 356.064 secs
Enforced Max. Ttl(ms): 0
Enforced Min. Ttl(ms): 0
Exclusive: LINK

Consumer connected to that queue (Is it the dispatcher?):
Name: qdlink.OyY41QAJRZ4JGGg
Mode: MOVE


The queue with the UUID name is created when Dispatch Router (it's not 
called "dispatcher") attaches a listener to the "perf.topic" address. 
This is because the broker only allows consumers from queues, not 
exchanges.  This is a temporary queue that exists to hold messages 
coming through the exchange on the way to that consumer.  A copy of 
every message delivered to that exchange will be put on that queue.





All messages even those consumed successfully by the consumers are still 
present on the broker


In which queue?



From the heap dump, we can see the Berkley DB is keeping a reference to all 
messages. Is this also coming from the above weird queue?


PS: If we only use the dispatcher instead, we have none of the weird behaviors



Extract from the heap dump (Object holding
reference to one of the message header. "Validated" is one the message
header fields we set and which is already received by a consumer)
char[9] @ 0xf59ff3d8  VALIDATED
'- value java.lang.String @ 0xf59ff3c0  VALIDATED
  '- value java.util.HashMap$Entry @ 0xf59ff310
'- [3] java.util.HashMap$Entry[8] @ 0xf59ff2c0
  '- table java.util.HashMap @ 0xf59ff188
'- _appProperties 
org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0 @ 0xf59fef88
  '- _metaData 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$MessageDataSoftRef
 @ 0xf59fef70
'- _messageDataRef 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage
 @ 0xf59fef20
  '- _handle org.apache.qpid.server.protocol.v1_0.Message_1_0 @ 
0xf59feef0
'- _message 
org.apache.qpid.server.message.AbstractServerMessageImpl$Reference @ 0xf59621c8
  '- _message org.apache.qpid.server.queue.StandardQueueEntry @ 
0xf5962188
'- _next org.apache.qpid.server.queue.StandardQueueEntry @ 
0xf5962130
  - this$0 
org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0$MessageHeader_1_0 @ 
0xf59ff1f0
Broker Config
1 Virtual Host Node and 1 Virtual Host configured with Berkley DB types (BDB 
with the default configuration)
1 Topic (perf.topic)
bound to a queue (perfQueue) with a binding key and a jms-selector filterbound to an 
"alternate exchange" of a type fanout which is also bound to a queue but with 
no binding key (empty string)


You don't say what the binding key is for perfQueue, but all messages 
that match that binding are also enqueued on the temporary queue.  I 
expect that you are seeing the same messages delivered twice, once 
through perfQueue and once through perf.topic (via the temporary queue).


Is it true that the broker is out-of-memory because a queue filled up? 
Which queue is full?




Dispatcher Config

qdmanage -b amqp://localhost:10454 create --type=address prefix=perfQueue 
waypoint=true name=perf.queue.addr
qdmanage -b amqp://localhost:10454 create --type=address prefix=perf.topic 
waypoint=true name=perf.topic.addr
qdmanage -b amqp://localhost:10454 create --type=connector role=route-container 
addr=localhost port=10455 name=localhost.broker.10455.connector
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perfQueue 
dir=out connection=localhost.broker.10455.connector 
name=localhost.broker.10455.perfQueue.out
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perfQueue dir=in 
connection=localhost.broker.10455.connector 
name=localhost.broker.10455.perfQueue.in
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perf.topic 
dir=out connection=localhost.broker.10455.connector 
name=localhost.broker.10455.perf.topic.out
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perf.topic 
dir=in connection=localhost.broker.10455.connector 
name=localhost.broker.10455.perf.topic.in

Clients config
3 JMS Consumers

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Rob Godfrey]

Hi Adel,

I'm a bit confused... you say

> As no consumer is connected to this queue, all messages are kept
in-memory which causes the OutOfMemory exception in the broker.

but then also say

> Consumer connected to that queue (Is it the dispatcher?):
> Name: qdlink.OyY41QAJRZ4JGGg
> Mode: MOVE

Does the queue have a consumer or not?

As to holding on to the messages... the heap dump shows that the message is
in the queue (which we know) and has not been evicted by flow to disk (we'd
need to work out why)...

On average what size are the messages you are sending?  Do you see messages
flow through this topic at all?

As to the "weird" queue name - what is happening is that we are creating an
internal temporary queue when you subscribe to an exchange object in the
broker... for that we use a UUID as the queue name.

-- Rob

On 8 July 2016 at 15:48, Adel Boutros  wrote:

> I forgot to add that when I execute a qdmanage command to delete the
> "connector" to the broker, the weird queue disappears.
>
> Adel
>
> > Date: Fri, 8 Jul 2016 07:45:49 -0700
> > From: adelbout...@live.com
> > To: users@qpid.apache.org
> > Subject: Re: OutOfMemory exception with a Qpid Java Broker linked to
> qpid dispatcher
> >
> > Fixing bad formatting on Nabbledue to Hotmail:
> >
> > Hello,
> >
> > We are doing some performance tests with a Qpid Java Broker connected to
> a
> > Qpid dispatcher.
> > We have noticed that after some time, the broker dies with an OutOfMemory
> > exception and java heap is dumped.
> > After analyzing the heap dump and checking the broker, we have noticed 2
> > weird behaviors:
> >
> > 1) A queue is created on the broker with a weird Name bound on our topic
> > (perf.topic) with a binding key "#". It will receive all messages.
> > This queue seems to be created only when the dispatcher is present and is
> > configured.
> > As no consumer is connected to this queue, all messages are kept
> in-memory
> > which causes the OutOfMemory exception in the broker.
> >
> > Weird Queue definition
> > Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
> > Type: standard
> > State: ACTIVE
> > Durable: false
> > Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
> > Persist Messages: NEVER
> > Inbound: 0 msg/s (0.00 B/s)
> > Outbound: 0 msg/s (0.00 B/s)
> > Size: 2374 msgs (0.00 B)
> > Pre-fetched: 0 msgs (0.00 B)
> > Oldest Message Age: 356.064 secs
> > Enforced Max. Ttl(ms): 0
> > Enforced Min. Ttl(ms): 0
> > Exclusive: LINK
> >
> > Consumer connected to that queue (Is it the dispatcher?):
> > Name: qdlink.OyY41QAJRZ4JGGg
> > Mode: MOVE
> >
> >
> > 2) All messages even those consumed successfully by the consumers are
> still
> > present on the broker
> >
> > From the heap dump, we can see the Berkley DB is keeping a reference to
> all
> > messages. Is this also coming from the above weird queue?
> >
> >
> > PS: If we only use the dispatcher instead, we have none of the weird
> > behaviors
> >
> > Extract from the heap dump (Object holding
> > reference to one of the message header. "Validated" is one the message
> > header fields we set and which is already received by a consumer)
> >
> > char[9] @ 0xf59ff3d8  VALIDATED
> > '- value java.lang.String @ 0xf59ff3c0  VALIDATED
> >   '- value java.util.HashMap$Entry @ 0xf59ff310
> > '- [3] java.util.HashMap$Entry[8] @ 0xf59ff2c0
> >   '- table java.util.HashMap @ 0xf59ff188
> > '- _appProperties
> > org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0 @ 0xf59fef88
> >   '- _metaData
> >
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$MessageDataSoftRef
> > @ 0xf59fef70
> > '- _messageDataRef
> >
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage
> > @ 0xf59fef20
> >   '- _handle
> org.apache.qpid.server.protocol.v1_0.Message_1_0 @
> > 0xf59feef0
> > '- _message
> > org.apache.qpid.server.message.AbstractServerMessageImpl$Reference @
> > 0xf59621c8
> >   '- _message
> > org.apache.qpid.server.queue.StandardQueueEntry @ 0xf5962188
> > '- _next
> org.apache.qpid.server.queue.StandardQueueEntry
> > @ 0xf5962130
> >   - this$0
> >
> org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0$MessageHeader_1_0 @
> > 0xf59ff1f0
> >
> > Broker Config
> > 1 Virtual Host Node and 1 Virtual Host configured with Berkley DB types
> (BDB
> > with the default configuration).
> > 1 Topic (perf.topic)
> >  bound to a queue (perfQueue) with a binding key and a jms-selector
> > filter
> >  bound to an "alternate exchange" of a type fanout which is also
> bound
> > to a queue but with no binding key (empty string)
> >
> > Dispatcher Config
> >
> > qdmanage -b amqp://localhost:10454 create --type=address prefix=perfQueue
> > waypoint=true name=perf.queue.addr
> > qdmanage -b amqp://localhost:10454 create --type=address
> prefix=perf.topic
> > waypoint=true name=perf.topic.addr
> > qdmanage -b amqp://localhost:10454 create --type=connector
> > role=rou

RE: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Adel Boutros]

I forgot to add that when I execute a qdmanage command to delete the 
"connector" to the broker, the weird queue disappears.

Adel

> Date: Fri, 8 Jul 2016 07:45:49 -0700
> From: adelbout...@live.com
> To: users@qpid.apache.org
> Subject: Re: OutOfMemory exception with a Qpid Java Broker linked to qpid 
> dispatcher
> 
> Fixing bad formatting on Nabbledue to Hotmail:
> 
> Hello,
> 
> We are doing some performance tests with a Qpid Java Broker connected to a
> Qpid dispatcher.
> We have noticed that after some time, the broker dies with an OutOfMemory
> exception and java heap is dumped.
> After analyzing the heap dump and checking the broker, we have noticed 2
> weird behaviors:
> 
> 1) A queue is created on the broker with a weird Name bound on our topic 
> (perf.topic) with a binding key "#". It will receive all messages. 
> This queue seems to be created only when the dispatcher is present and is
> configured.
> As no consumer is connected to this queue, all messages are kept in-memory
> which causes the OutOfMemory exception in the broker.
> 
> Weird Queue definition
> Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
> Type: standard
> State: ACTIVE
> Durable: false
> Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
> Persist Messages: NEVER
> Inbound: 0 msg/s (0.00 B/s)
> Outbound: 0 msg/s (0.00 B/s)
> Size: 2374 msgs (0.00 B)
> Pre-fetched: 0 msgs (0.00 B)
> Oldest Message Age: 356.064 secs
> Enforced Max. Ttl(ms): 0
> Enforced Min. Ttl(ms): 0
> Exclusive: LINK
> 
> Consumer connected to that queue (Is it the dispatcher?): 
> Name: qdlink.OyY41QAJRZ4JGGg
> Mode: MOVE
> 
> 
> 2) All messages even those consumed successfully by the consumers are still
> present on the broker
> 
> From the heap dump, we can see the Berkley DB is keeping a reference to all
> messages. Is this also coming from the above weird queue?
> 
> 
> PS: If we only use the dispatcher instead, we have none of the weird
> behaviors
> 
> Extract from the heap dump (Object holding 
> reference to one of the message header. "Validated" is one the message 
> header fields we set and which is already received by a consumer)
> 
> char[9] @ 0xf59ff3d8  VALIDATED   
>
> '- value java.lang.String @ 0xf59ff3c0  VALIDATED 
>  
>   '- value java.util.HashMap$Entry @ 0xf59ff310   
> 
> '- [3] java.util.HashMap$Entry[8] @ 0xf59ff2c0
> 
>   '- table java.util.HashMap @ 0xf59ff188 
>   
> '- _appProperties
> org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0 @ 0xf59fef88 
> 
>   '- _metaData
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$MessageDataSoftRef
> @ 0xf59fef70 
> '- _messageDataRef
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage
> @ 0xf59fef20
>   '- _handle org.apache.qpid.server.protocol.v1_0.Message_1_0 @
> 0xf59feef0 
> '- _message
> org.apache.qpid.server.message.AbstractServerMessageImpl$Reference @
> 0xf59621c8  
>   '- _message
> org.apache.qpid.server.queue.StandardQueueEntry @ 0xf5962188  
>
> '- _next org.apache.qpid.server.queue.StandardQueueEntry
> @ 0xf5962130 
>   - this$0
> org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0$MessageHeader_1_0 @
> 0xf59ff1f0   
>  
> Broker Config
> 1 Virtual Host Node and 1 Virtual Host configured with Berkley DB types (BDB
> with the default configuration).
> 1 Topic (perf.topic)
>  bound to a queue (perfQueue) with a binding key and a jms-selector
> filter
>  bound to an "alternate exchange" of a type fanout which is also bound
> to a queue but with no binding key (empty string)
> 
> Dispatcher Config
> 
> qdmanage -b amqp://localhost:10454 create --type=address prefix=perfQueue
> waypoint=true name=perf.queue.addr
> qdmanage -b amqp://localhost:10454 create --type=address prefix=perf.topic
> waypoint=true name=perf.topic.addr
> qdmanage -b amqp://localhost:10454 create --type=connector
> role=route-container addr=localhost port=10455
> name=localhost.broker.10455.connector
> qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perfQueue
> dir=out connection=localhost.broker.10455.connector
> name=localhost.broker.10455.perfQueue.out
> qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perfQueue
> dir=in connection=localhost.broker.10455.connector
> name=localhost.broker.10455.perfQueue.in
> qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perf.topic
> dir=out connection=localhost.broker.10455.connector
> name=localhost.broker.10455.perf.topic.out
> qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perf.topic
> dir=in

Re: OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Adel Boutros]

Fixing bad formatting on Nabbledue to Hotmail:

Hello,

We are doing some performance tests with a Qpid Java Broker connected to a
Qpid dispatcher.
We have noticed that after some time, the broker dies with an OutOfMemory
exception and java heap is dumped.
After analyzing the heap dump and checking the broker, we have noticed 2
weird behaviors:

1) A queue is created on the broker with a weird Name bound on our topic 
(perf.topic) with a binding key "#". It will receive all messages. 
This queue seems to be created only when the dispatcher is present and is
configured.
As no consumer is connected to this queue, all messages are kept in-memory
which causes the OutOfMemory exception in the broker.

Weird Queue definition
Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
Type: standard
State: ACTIVE
Durable: false
Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
Persist Messages: NEVER
Inbound: 0 msg/s (0.00 B/s)
Outbound: 0 msg/s (0.00 B/s)
Size: 2374 msgs (0.00 B)
Pre-fetched: 0 msgs (0.00 B)
Oldest Message Age: 356.064 secs
Enforced Max. Ttl(ms): 0
Enforced Min. Ttl(ms): 0
Exclusive: LINK

Consumer connected to that queue (Is it the dispatcher?): 
Name: qdlink.OyY41QAJRZ4JGGg
Mode: MOVE


2) All messages even those consumed successfully by the consumers are still
present on the broker

>From the heap dump, we can see the Berkley DB is keeping a reference to all
messages. Is this also coming from the above weird queue?


PS: If we only use the dispatcher instead, we have none of the weird
behaviors

Extract from the heap dump (Object holding 
reference to one of the message header. "Validated" is one the message 
header fields we set and which is already received by a consumer)

char[9] @ 0xf59ff3d8  VALIDATED 
 
'- value java.lang.String @ 0xf59ff3c0  VALIDATED   
   
  '- value java.util.HashMap$Entry @ 0xf59ff310 
  
'- [3] java.util.HashMap$Entry[8] @ 0xf59ff2c0  
  
  '- table java.util.HashMap @ 0xf59ff188   

'- _appProperties
org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0 @ 0xf59fef88   
  
  '- _metaData
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$MessageDataSoftRef
@ 0xf59fef70 
'- _messageDataRef
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage
@ 0xf59fef20
  '- _handle org.apache.qpid.server.protocol.v1_0.Message_1_0 @
0xf59feef0 
'- _message
org.apache.qpid.server.message.AbstractServerMessageImpl$Reference @
0xf59621c8  
  '- _message
org.apache.qpid.server.queue.StandardQueueEntry @ 0xf5962188
 
'- _next org.apache.qpid.server.queue.StandardQueueEntry
@ 0xf5962130 
  - this$0
org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0$MessageHeader_1_0 @
0xf59ff1f0   
 
Broker Config
1 Virtual Host Node and 1 Virtual Host configured with Berkley DB types (BDB
with the default configuration).
1 Topic (perf.topic)
 bound to a queue (perfQueue) with a binding key and a jms-selector
filter
 bound to an "alternate exchange" of a type fanout which is also bound
to a queue but with no binding key (empty string)

Dispatcher Config

qdmanage -b amqp://localhost:10454 create --type=address prefix=perfQueue
waypoint=true name=perf.queue.addr
qdmanage -b amqp://localhost:10454 create --type=address prefix=perf.topic
waypoint=true name=perf.topic.addr
qdmanage -b amqp://localhost:10454 create --type=connector
role=route-container addr=localhost port=10455
name=localhost.broker.10455.connector
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perfQueue
dir=out connection=localhost.broker.10455.connector
name=localhost.broker.10455.perfQueue.out
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perfQueue
dir=in connection=localhost.broker.10455.connector
name=localhost.broker.10455.perfQueue.in
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perf.topic
dir=out connection=localhost.broker.10455.connector
name=localhost.broker.10455.perf.topic.out
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perf.topic
dir=in connection=localhost.broker.10455.connector
name=localhost.broker.10455.perf.topic.in

Clients config
3 JMS Consumers connected each to perfQueue on the dispatcher
2 JMS producers connected each to perf.topic on the dispatcher

With the above config, we send a number of messages of which only 1/3 will
be routed to the "alternate exchange" and never consumed.


Versions
Qpid Java Broker: 6.0.0
Qpid Dispatch: 0.6.0
JMS: 0.9.0

Regards,
Adel



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/OutOfMemory-exception-with-a-Qpid-J

OutOfMemory exception with a Qpid Java Broker linked to qpid dispatcher

[Adel Boutros]

Hello,

We are doing some performance tests with a Qpid Java Broker connected to a Qpid 
dispatcher.
We have noticed that after some time, the broker dies with an OutOfMemory 
exception and java heap is dumped.
After analyzing the heap dump and checking the broker, we have noticed 2 weird 
behaviors:

A queue is created on the broker with a weird Name bound on our topic 
(perf.topic) with a binding key "#"
It will receive all messages. 
This queue seems to be created only when the dispatcher is present and is 
configured.
As no consumer is connected to this queue, all messages are kept in-memory 
which causes the OutOfMemory exception in the broker.

Weird Queue definition
Name: 18bb86dd-2953-4c6f-8eb2-56e5128963f3
Type: standard
State: ACTIVE
Durable: false
Lifespan: DELETE_ON_NO_OUTBOUND_LINKS
Persist Messages: NEVER
Inbound: 0 msg/s (0.00 B/s)
Outbound: 0 msg/s (0.00 B/s)
Size: 2374 msgs (0.00 B)
Pre-fetched: 0 msgs (0.00 B)
Oldest Message Age: 356.064 secs
Enforced Max. Ttl(ms): 0
Enforced Min. Ttl(ms): 0
Exclusive: LINK

Consumer connected to that queue (Is it the dispatcher?): 
Name: qdlink.OyY41QAJRZ4JGGg
Mode: MOVE


All messages even those consumed successfully by the consumers are still 
present on the broker

>From the heap dump, we can see the Berkley DB is keeping a reference to all 
>messages. Is this also coming from the above weird queue?


PS: If we only use the dispatcher instead, we have none of the weird behaviors



Extract from the heap dump (Object holding 
reference to one of the message header. "Validated" is one the message 
header fields we set and which is already received by a consumer)
char[9] @ 0xf59ff3d8  VALIDATED 
 
'- value java.lang.String @ 0xf59ff3c0  VALIDATED   
   
  '- value java.util.HashMap$Entry @ 0xf59ff310 
  
'- [3] java.util.HashMap$Entry[8] @ 0xf59ff2c0  
  
  '- table java.util.HashMap @ 0xf59ff188   

'- _appProperties 
org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0 @ 0xf59fef88   
  
  '- _metaData 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$MessageDataSoftRef
 @ 0xf59fef70 
'- _messageDataRef 
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage
 @ 0xf59fef20
  '- _handle org.apache.qpid.server.protocol.v1_0.Message_1_0 @ 
0xf59feef0 
'- _message 
org.apache.qpid.server.message.AbstractServerMessageImpl$Reference @ 0xf59621c8 
 
  '- _message org.apache.qpid.server.queue.StandardQueueEntry @ 
0xf5962188 
'- _next org.apache.qpid.server.queue.StandardQueueEntry @ 
0xf5962130 
  - this$0 
org.apache.qpid.server.protocol.v1_0.MessageMetaData_1_0$MessageHeader_1_0 @ 
0xf59ff1f0
Broker Config
1 Virtual Host Node and 1 Virtual Host configured with Berkley DB types (BDB 
with the default configuration)
1 Topic (perf.topic)
bound to a queue (perfQueue) with a binding key and a jms-selector filterbound 
to an "alternate exchange" of a type fanout which is also bound to a queue but 
with no binding key (empty string)

Dispatcher Config

qdmanage -b amqp://localhost:10454 create --type=address prefix=perfQueue 
waypoint=true name=perf.queue.addr
qdmanage -b amqp://localhost:10454 create --type=address prefix=perf.topic 
waypoint=true name=perf.topic.addr
qdmanage -b amqp://localhost:10454 create --type=connector role=route-container 
addr=localhost port=10455 name=localhost.broker.10455.connector
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perfQueue 
dir=out connection=localhost.broker.10455.connector 
name=localhost.broker.10455.perfQueue.out
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perfQueue dir=in 
connection=localhost.broker.10455.connector 
name=localhost.broker.10455.perfQueue.in
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perf.topic 
dir=out connection=localhost.broker.10455.connector 
name=localhost.broker.10455.perf.topic.out
qdmanage -b amqp://localhost:10454 create --type=autoLink addr=perf.topic 
dir=in connection=localhost.broker.10455.connector 
name=localhost.broker.10455.perf.topic.in

Clients config
3 JMS Consumers connected each to perfQueue on the dispatcher2 JMS producers 
connected each to perf.topic on the dispatcher

With the above config, we send a number of messages of which only 1/3 will be 
routed to the "alternate exchange" and never consumed.


Versions
Qpid Java Broker: 6.0.0Qpid Dispatch: 0.6.0JMS: 0.9.0

Regards,
Adel

  

Re: Broker with live data

[Artem]

Robbie,

I need to do Java broker server, that can send messages at live mode
(desirable for each link asynchronously ). My server has a cursor, that 
return messages, if there is no messages , it expects them (can sleep at own
thread, or throws exception). 

I need to make sure that the  driver

 
worked on a separate thread , and wait and sends a message at another
thread.

Artem



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Broker-with-live-data-tp7647047p7647062.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Broker with live data

[Robbie Gemmell]

Hi Artem,

It would be good if you could elaborate more specifically on your use
case, to give us a better idea what it is you are aiming to do and
why, then we might be able to make suggestions.

Robbie

On 8 July 2016 at 08:45,   wrote:
> Hi, i need to use protonJ server for broker live data. How i can do it with a 
> lot of subscribes using this server?
>
> What changes i need to do with this driver? 
> https://github.com/apache/qpid-proton/blob/master/examples/engine/java/src/main/java/org/apache/qpid/proton/examples/Driver.java
>
> Thanks,
> Artem Fedorov
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Broker with live data

[artem . fedorov]

Hi, i need to use protonJ server for broker live data. How i can do it with a 
lot of subscribes using this server?

What changes i need to do with this driver? 
https://github.com/apache/qpid-proton/blob/master/examples/engine/java/src/main/java/org/apache/qpid/proton/examples/Driver.java
 
 
Thanks,
Artem Fedorov

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org