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.
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?
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.
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.
Just wondering how to setup durable subscribers for stomp clients eg. perl etc ?