Queue-like/Persistent Topics

[driveraf]

Hello everyone, this is my first post.

I have a question/problem for which I think I have an answer/solution. What I need is sort of a hybrid between a queue and a topic (unless there's a topic configuration that already does what I want).

I *already* have a service that every once in a while (say 10 msg/min) publishes messages to a Topic. I can then have multiple clients connect to this topic, subscribe and receive messages *as they are published*.

But I need the option to retrieve those messages that have already been published before subscribing, like a JMS Queue, which stores messages waiting to be consumed.

A more concrete example of what I *NEED*:

1. Service (i.e. the Message Publisher) starts up.
2. Publisher sends 10 messages.
3. Client 1 connects, subscribes and receives those ten messages, along with any new messages
4. Publisher sends 10 more messages; Client 1 receives them
5. Client 2 connects, subscribes and receives 20 messages, then any new messages
6. Publisher keeps sending messages and Clients 1 & 2 receive them.

Now, all I have been able to do is receive messages after subscribing. All messages published before subscribing are lost. I've searched high and low and have found no standard (i.e. configurable) way to do what I want.

I do have a work-around, but I am not too sure that it is the best way to go (the best way might be some configuration I've overlooked). I can have the publishing service create a certain amount of persistent subscriptions at start-up (i.e. create 30 subscribers named 'Subscriber-n", where n goes from 1 to 30), disconnect each of these 30 subscribers immediately, and then have the clients connect using one of these pre-created subscriptions. Since the subscriptions are persistent, they will receive every message since start-up.

I know a database should work as well, but I need to use JMS.

Any suggestions or comments?

Thanx,
Daniel

[peterj]

You can use a durable subscription. Any messages posted while not connected will be available the next time you connect. The only gotcha is that the client has to connect and make a durable subscription first - any messages sent beforehand will not be available.

[driveraf]

Thanks for your reply!

That was what I was thinking about. But then there's that requirement to access all previous messages before the first connection... all I'm coming up with is creating a bunch of durable subscriptions beforehand, then allowing all new clients to either create new connections OR using one of the subscriptions created in the first batch. I could potentially put the durable subscription names on a regular JMS Queue, so clients can consume one message from there and then use it.

Any other suggestions?

[peterj]

Creating the durable subscriptions beforehand and then having later subscribers use them is the only thing I could come up with. But you will need to know how many potential subscribers you will have. If you create too few durable subscriptions, some subscribers will not get the messages. If you create too many, the messages will hang around forever.

This really sounds like a job for a MDB and a SLSB. The MDB subscribes to the topic and places all messages in a database. When a new client comes up, it connects to the topic to get future messages and asks the SLSB for the historical messages.

[peterj]

My MDB/SLSB suggestion also keeps the messages around, just like if you created too many durable subscriptions. Therefore I would go with the surplus durable subscriptions - it's less coding on your part.

[bbansal]

Hey Peter,

Just wondering how to setup durable subscribers for stomp clients eg. perl etc ?