activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Message announcement and routing
Date Tue, 26 Aug 2008 09:35:31 GMT
2008/8/26 Eugene Dzhurinsky <>:
> On Tue, Aug 26, 2008 at 09:17:09AM +0100, James Strachan wrote:
>> How many commands and sets of messages are required? Only normally
>> with the the worker pattern you send all the required commands to be
>> executed by a consumer in a single message.
> In fact the consumer may issue various commands depending on results returned
> by the worker and user input, so it is not possible to use batch of commands.
>> While supporting many messages is possible - its just way more chatty
>> and complex; requiring dealing with partial failure and so forth.
> We don't need to solve the task when the worker consumer going down during the
> processing of intermediate commands, so we just presume the consumer will be
> alive from getting the initial command to finishing the processing after the
> client is satisfied with results.
>> If you want reliability, you should use message acknowledgement or
>> transactions so the broker can failover to other clients if the
>> consumer fails to process the message. But if you are sending many
>> messages in a stateful conversation, you're gonna have to implement
>> your own failover protocol as you're gonna have to restart the
>> conversation and reply all the messages to another consumer if you get
>> a failure.
> It's a good point, however this isn't the case we are worrying about for now,
> we are just trying to prove the concept. If the consumer did not send the
> acknowledgement, will the broker not route another messages to that consumer?

Yes - assuming the consumer closes or the process dies. If a valid
consumer just sits there and never acks (assuming you're not using
AUTO_ACK mode) then the broker will just assume your consumer is
taking a long time to process the message (which is valid in many

Though if you use temporary queues for all communication after the
first message to the consumer - then there is no failover if a
consumer dies - the whole conversation is dropped as the temporary
queue is deleted when the consumer goes away; but then I think thats
what you want.

i.e. reliable load balancing of the first incoming message - from that
point on the rest of the conversation takes place on a temporary
queue. If the consumer dies the client has to restart the conversation


Open Source Integration

View raw message