Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <20447069.post@talk.nabble.com>
Date: Tue, 11 Nov 2008 12:04:56 -0800 (PST)
From: Joe Fernandez <joe.fernandez@ttmsolutions.com>
To: users@activemq.apache.org
Subject: Re: activemq, session management?
In-Reply-To: <20081111170556.GF99157@office.redwerk.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <20081111170556.GF99157@office.redwerk.com>


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.