Thanks for your suggestion. I tried to implement it, but I did not get the
behaviour I'd like.
If I understood correctly, you suggested to create as many MessageConsumer instances as topics, and connect every
consumer to the same queue, each time specifying a different binding key.
What happens in this situation is that, for each message which matches with at least one of the bindings of the queue,
one of the consumers is called, in a round-robin fashion. So the first consumer is called for the first matching
message, the second consumer for the second message, and so on, with no relationship between the subject of the message
and the intended topic of the consumer.
If this is the expected behaviour, then I'm supposed to implement the matching logic in the application code, which I
was trying to avoid (in the real application the topics are not always fully-specified, but often contain # or *).
Flavio
Il 2013/11/15 15:43 PM, Gordon Sim ha scritto:
On 11/12/2013 04:56 PM, Flavio Baronti wrote:
I'm using the C++ broker on Linux, and the
Java client on windows.
The sender is sending through producers obtained with
MessageProducer topicProducer =
session.createProducer(session.createTopic(topicName + "; {node: { type:
topic } }"));
while the receiver is receiving with a listener set on consumers
obtained with
MessageConsumer consumer =
session.createConsumer(session.createTopic(topicName));
I don't know what to gather from CPU usage. With few sessions it's
higher on the broker, and lower on the client.
Increasing the number of session it's the other way round, higher on
client and lower on broker.
In both cases we're very far from 100%.
I created a bug report, I'm not too familiar with JIRA so I hope I did
it ok.
I added the two test programs I'm using. If there is anything else I can
help with, please let me know.
Sorry for the delayed response.
The way the c++ broker does delivery is by setting interest in the writability of the connection if there is a message
available. A worker thread will then process that connection which involves attempting to pull the message off the
queue. This gets increasingly expensive as the number of queues from which you are consuming on that connection goes up.
A suggested change to avoid the problem would be to have all those distinct subscriptions on the session use the same
underlying subscription queue, and just add the bindings for the different keys.
I've attached a patch to your JMSReceiver example that does this. (Unfortunately due to QPID-5345, the address is
somewhat less intuitive than ideal).
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
