On 07/13/2012 05:45 PM, Vijay Devadhar wrote:
Hi Gordon,
Thanks for the suggestion.
What is the reason for recommendation to not mix onMessage() and
subsequent receive?
I believe it will make the code simpler and clearer and see no drawbacks.
In theory, this will work well since onMessage()
is like a signal and receive() will actually fetch all the data;
This will avoid the need for periodic polling of data.
Using receive() isn't the same as polling. There is really little
difference from the brokers perspective in setting a listener versus
calling receive().
Having a single subscription (i.e. a single consumer) seems to me to
make life easier and I don't see any advantage in complicating that.
In practice, will we run into efficiency issues or some other
mixup in the transport layer? I am just trying to understand.
The biggest complication I see is ensuring the messages go to the
subscription you want since you will have two subscriptions. As I
understand it you want the first message in the batch delivered to the
listener, but subsequent messages to be delivered to the subscription
associated with the consumer on which you will call receive().
That requires turning off prefetch. Even then, once you return from the
listener the broker is free to deliver another message to that consumer.
I would be nervous calling receive() on the second consumer from the
dispatcher thread of the onMessage() callback.
If you did solve that, then I believe the prefetch is controlled at the
session level, so either you would have to turn it off completely
meaning the delivery of the batch is less efficient (round trip per
message) or you would complicate the transactionality by having separate
sessions.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
