Message life on the bus

[nva]

I haven't found much information in the documentation on what happens to the message once it is published on the bus. How long does it live, what happens if there are no subscribers on the given subject. Is it possible to control the message time-to-live?

I have an application that needs to 'push' about 25-30 messages/second from the server to the client and I'd like to set up a 0 ttl - meaning that if there are no subscribers on the given subject, then the message should be discarded by the bus. Clients come and go, but they all need the same data when they are there. Can this be done by bus configuration or do I need to maintain a subscription status for the connected clients separately?

Thanks!

Cheers,

V.

[cbrock]

Yes. This is how the bus works. It does not work like a JMS queue. Messages are not persistent.

[nva]

Thanks Mike, this helps! I understand that I can use the MessageListener interface to handle the messages published on the bus before they get delivered. Is there any way that I can examine the queue size/content at that point as well?

In my application it is more important to receive the most recent data than all data - ie. message loss is accepted. In case messages are published at a faster rate than they get consumed by the subscribers and the queue grows above a given size, instead of paging out to disk, I'd like to drop messages before delivery. What would be the right approach to achieve this?

Cheers,

V.

[cbrock]

Hey Valentin,

What you are asking for is essentially how the bus works by default. Clients are either in a connected or disconnected state. No messages are queued/retained for clients in a disconnected state.

However, dropping all but the most recent messages for a client in the connected state is not something that is supported, per se. But it's not really something one would have to worry about since we don't hold messages persistently.

The maximum window, by default, that the bus gives for a client to receive a message before it is dropped is 45 seconds. 

But understanding why we can't simply ignore all but the most recent messages within this window comes down to the architecture of the bus itself. The bus' own federation and management protocols are self-hosted, meaning that message data cannot simply be aggressively discarded without potentially undesirable side effects.

Further, the manner in which message data is queued, occurs in a ring buffer on the server which is shared for all queues. So memory use is stable, regardless of load.

[nva]

Thanks for the explanation Mike, this makes perfect sense. I understand that in a federatd bus environment one can't just willy-nilly drop messages. I was less worried about capping resources, more about the 'freshness' of the data that I push to the client. The data is time-sensitive, but not accuracy-sensitive, meaning that it is better to drop some data, but always show the freshest. I tried to make sure that the data processing returns as fast as possible - within the limits of the javascript environment, of course. I'm sure I can live with the 45sec, though.

Cheers,

V.