Hi Eugene, >> . If the consumer dies for some reason - we need to resume it's job.
Would a durable subscription [1] for your consumer work. Then if the consumer dies, you would just need to recover from where you left off. If you used CLIENT_ACKNOWLEDGE you should be able to control how many messages are resent. /Dave [1] http://activemq.apache.org/how-do-durable-queues-and-topics-work.html On Tue, Nov 11, 2008 at 12:05 PM, Eugeny N Dzhurinsky <[EMAIL PROTECTED]>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 >
