activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Stanley" <dstanl...@gmail.com>
Subject Re: activemq, session management?
Date Tue, 11 Nov 2008 19:33:50 GMT
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 <bofh@redwerk.com>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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message