activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Hartung <>
Subject Design Guidance
Date Fri, 14 Apr 2006 00:30:18 GMT

I'm looking for some design tips here.

Here's the basics. Thick client written in .NET talking to a host server
through Webservices that needs to be "continually updated".

Obvious choice would be to use ActiveMQ and the .NET client library,
subscribe to an appropriate topic/queue, and live happily ever after.

To be blunt, that simply isn't going to happen. Just close your eyes and
think of England, it's not in the cards.

Rather, we're going to have to Poll the server regularly to get our changes.

But that doesn't mean that we cannot post our updates to a queue/topic, and
then leverage that on the web server to send the updates to the client when
they call.

So, here's my thinking. Every time the client calls the web server. it
connects to the JMS server using a Durable Subscription. It then slurps down
all of the pending update messages (or some max number of them), then
forwards them down to the client and disconnecting from the JMS server.

The problem is that we don't have any real sense of transactions here.
There's no obvious way to make sure the client actually recieved and
processed those changes that the server forwarded to it.

One thought was that when the client requests an update, it includes a
timestamp representing the "last time" it got an update, which would be the
timestamp of the last message that it got. Then, when the server is fetching
messages from the JMS server, it would simply ACK the ones that are before
that timestamp, and then simply discard them. But for the current messages,
it would not ACK or Commit them, and leave them on the server. Another
thought is that after the client does a refresh and update, it "commits" the
request by sending a "Ok up to *timestamp*" and the server then refetches
and discards those older messages.

Either solution requires fetching the messages twice from the JMS server.

So, with my limited knowledge of ActiveMQ and JMS in particular, is that a
good solution? Is there some functionality that would make this more
efficient? I can't see any way to get around using the durable subscription.

Overall, I'm thinking of having a small JMS cluster (for reliability moreso
than performance) backing the web services tier, then the app tier funnels
update events in to the JMS cluster. Can ActiveMQ be gateway with Oracle
Queues, so that, say, a stored procedure can post an update event to an
Orcale Queue that then forwards it in to ActiveMQ?

Thanx for any thoughts on this.


Will Hartung

View this message in context:
Sent from the ActiveMQ - User forum at

View raw message