2008/8/26 Eugene Dzhurinsky <[EMAIL PROTECTED]>: > 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 circumstances). 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 again. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
