1 of 1 people found this helpful
Yes. This is how the bus works. It does not work like a JMS queue. Messages are not persistent.
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?
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.