durable queues for clients without state

[falconair]

I'm trying to figure out if hornetq supports the following scenario:

The server sends messages (point to point or broadcast) to clients.  If a client connects after the messages were sent, on connection, the client gets all missed messages.  If a client get disconnected, then reconnects, it gets ALL the messages as if it never received any (or at least has the option to receive them all).

My understanding is that the current implementation of durable queues don't have the option of saving all messages sent through a queue.  Once a client acknowledges that it has received a message, the server removes them from its own record.

Obviously I wouldn't do this with something like stock market data, since the server will have to remember vast amount of data; however, I would like to do this with order/trade information.  The client may connect to hornetq using a webstart GUI. In the middle of the day, the client may decide to move to a different machine and log into his GUI again.

Thanks

[clebert.suconic]

I'm not sure what you're trying to achieve. I'm actually confused on your text.

You started describing the ACK process, which most messaging systems implement.

Then you started describing messages sent from a topic to a queue?

Can you clarify what you mean with a simple statement please?

[falconair]

Hm..I'm not sure why I'm having such trouble describing what something that is basically quite simple

First, this is my understanding:

Durable topics record all messages.  This is because 'topic' is a broadcast mechanism and the server doesn't know when any client may connect and ask for the whole history of messages.

Durable queues only record messages which have not been acked by the client.  Since queues are 1-to-1 mechanism, once the client acks a message, the server assumes it no longer needs to keep a copy itself.

If this understanding is correct, then in a durable queue scenario, if a client acks a message, but later loses it, there is no way to get it from the server again.  I'm trying to figure out if it is possible to make durable queue remember all its messages forever (or until cleanup is run).  This way, even if the client loses the message it has already acknowledged, it can still get the whole history again. Or is it better to simply use a topic for this scenario rather than a queue?

[clebert.suconic]

A message stays on a queue (that is durable or not) as long as you didn't Acknowledge.

You can't use a message system as a database. you will build up messages on memory.

You could use a Browser, but you will end up on the case described above.

You should use the right tool for the right thing. Have a Consumer listening for the data and add it to the database. Recover it from there when you need.

[clebert.suconic]

BTW: using a message system as a database is an anti-pattern for any messaging system.