activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tabish...@gmail.com>
Subject Re: ActiveMQ-CPP and Advisory messages
Date Fri, 12 Jun 2009 23:44:02 GMT
On Thu, 2009-06-11 at 08:26 -0700, Nascent wrote:
> Scenario: 
> I have a consumer written in C++ that uses ActiveMQ-CPP to communicate with
> ActiveMQ. It implements a callback interface where a client can request
> on-change updates for data points. The consumer then does a response message
> to the original request from the client any time the data point updates. The
> response messages go to a temporary queue (reply queue basically) that is
> associated with the client.
> 
> Problem:
> I am trying to figure out a way for the consumer to know that the client has
> gone away so it can stop sending updates and free up resources associated
> with that client. I cannot always trust that the client will send some kind
> of unsubscribe message. I am looking for a way that the consumer can know
> authoritatively that the client has either disconnected from ActiveMQ or
> that the temporary/reply queue for that client is no longer valid. It seems
> like ActiveMQ's Advisory messages are the solution however I don't see how
> they can be used through ActiveMQ-CPP since the messages use Java objects as
> the body. 
> 
> Questions:
> Is there anyway to make use of the advisory messages through ActiveMQ-CPP? 
> 

Since this seemed like a question that might confront many ActiveMQ-CPP
users I've created a Tutorial on it on the CMS Wiki.  Here's the link:

http://activemq.apache.org/cms/handling-advisory-messages.html

The tutorial is a work in progress, so comments are welcome, if you see
something that needs more explanation let me know.

I also created an example Producer and Consumer that show the basics of
using the advisory messages.  You will need to download the latest SVN
source to see the code, its in the src/exmaples/advisories folder.

Regards
Tim.

> Is there perhaps a better way to handle the scenario listed above that has
> less overhead? I have considered using a topic that all data point updates
> would go to and then clients could consume with a selector to get only the
> updates they care about. However, in my case, there are potentially hundreds
> of data points updating every second and clients are usually only interested
> in a handful of them. So it seems inefficient to me to have all these data
> point updates going to a topic where less than 5% of them may actually be
> consumed.
> 
> Thanks in advance!
-- 
Tim Bish
http://fusesource.com
http://timbish.blogspot.com/




Mime
View raw message