-
1. Re: Message life on the bus
cbrock Jun 15, 2012 1:06 PM (in response to nva)1 of 1 people found this helpfulYes. This is how the bus works. It does not work like a JMS queue. Messages are not persistent.
-
2. Re: Message life on the bus
nva Jun 16, 2012 6:06 AM (in response to cbrock)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.
-
3. Re: Message life on the bus
cbrock Jun 16, 2012 11:06 AM (in response to nva)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.
-
4. Re: Message life on the bus
nva Jun 16, 2012 11:54 AM (in response to cbrock)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.