If I understand your scenario correctly, the 'announcement' queue is a 'shared' queue from which all consumers compete for initial service requests. The producers (clients) and consumers also maintain 'private' queues through which conversational state is maintained between producer and consumer and subsequent 'jobs' are processed. So after picking off a service request from the shared queue, the consumer stops reading from the shared queue and processes the subsequent job via the private queues. After completing the job, the consumer goes back to the shared queue. Hopefully I've got this right and that the following will help.
I think it kind of boils down to when your clients and consumers 'acknowledge' the messages that they have received from the shared and private queues. If your consumer dies prior to completing and 'acknowledging' a job processing step, then when the consumer restarts, the broker will re-dispatch the corresponding message from the consumer's private queue. The same holds true for the producers private queue and the shared queue. If your intend to batch all processing steps into one atomic unit of work, then transactions may be the way to go. But sounds to me like you're not batching and instead going through one job step at a time? If you send persistent messages, the broker guarantees that those messages will not get lost if the broker dies. For added high-availability, you may want to consider creating a cluster of consumers for each private queue and assign it an 'exclusive' consumer. That way, if the exclusive consumer dies, one of the other consumers in the cluster can immediately take up the role of exclusive consumer for the cluster. Joe Get a free ActiveMQ user guide @ http://www.ttmsolutions.com Eugeny N Dzhurinsky-2 wrote: > > "Ben, eto Danila, I need help!" (C) > > Hello there! > > I would appreciate any help you could provide me with. I need to solve > some > kind of a strange task, which might be out of scope of Active MQ. > > We need to build the distributed network of data processors, which are > working > interactively with users (client application). This mean an user can start > the > session with any of the processor, then send a commands with data to be > processed, get the response and send another command until the customer > finishes the session. > > During this time the processor can't handle any other tasks - so it's tied > with the customer, who created the session. > > We had some success story with using ActiveMQ, and we decided to use it in > this way: we created the special "announcement" queue, where the client > application sends a message. ActiveMQ broker delivers this message to any > free > consumer, and the consumer doesn't acknowledge the message - instead it > starts > the data processing module. The message, which was sent to announcement > queue, > contains the reply-to address of a client-side queue, which is used to > handle > data processing responses. The consumer prepares it's own queue and sends > information about it back to the client. So far so good - after the client > and server establish the queues and know the names of corresponding queue > - > they can receive requests (on the data processor side), process these > requests, produce responses and send them to the client queue to be > processed > at the client side. So we did simple request-response implementation, as > advised in the FAQ. > > And now the tricky part comes in place. If the consumer dies for some > reason - > we need to resume it's job. This means we need to re-send all commands > with > data to another consumer, so it will process them in a batch. Or we need > to > store the last success command somehow and send it to another "idle" > consumer. > > All of this is raising at least 2 questions: > > 1) how can we configure the broker so it will check if the consumer is > still > "alive" > > 2) is it possible to use "transaction" in the way, when the client will > start > the transaction and request-response queue will use this transaction as > well. > So if the consumer or producer dies - the messages are not lost, and we > can > get access to these queues somehow? > > 3) Is it possible to implement such thing, as describe above, with > ActiveMQ at > all, or we need to check some another solution/framework? If you could > also > suggest such a framework - tat would be great! > > Thank you all in advance! > > -- > Eugene N Dzhurinsky > > > -- View this message in context: http://www.nabble.com/activemq%2C-session-management--tp20443871p20447069.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
