Thursday, 8 October 2015

JMS Pending Messages - What harms does it do.

Generally it is not recommended to store large number of the pending messages in the EMS server for the following reasons:

1.     The pending messages in the EMS queue will either consume memory and/or disk space.
-       While the pending messages are in the reasonable amount, it will consume the memory and EMS would still treats the messages as for quick consumption by the client application
-       While the pending messages exceeds certain size for a queue, they will then be swapped-out to the EMS data store file located normally in the shared disk / SAN storage.
So a careful planning of the EMS server RAM and data store size is always needed while design the solution.

2.     The data store swapped EMS pending message may lead to EMS performance impact.
In the situation of a EMS queue having huge size of the pending message will cause the pending messages to be swapped-out to the EMS data store file located normally in the shared disk / SAN storage.
In that case, if the queue consumer would like to consume the messages from the queue (e.g. consumers recovered after x hours), then the EMS server needs to swap-in the messages which may severely impact the EMS server performance. Longer queue message recovery is also expected in such situation.

3.     If the number of the pending messages becomes huge, it could have overall performance impact for the entire EMS server as the overall awareness that should be kept in mind.

4.     Disaster Recovery slowness for persistent messages.
Persistent messages sent to the queue are always written to the disk. So, the more pending persistent messages pending on the queue, in DR situation, it would take longer for EMS to recover the messages, especially when EMS still need to receive high throughput / big size messages at the mean time.


Large number of pending messages can be caused by many factors such as slow consumer or no consumer, busy server, or network issues. In addition, queue properties such as maxBytes and maxMsgs that can help limit the growth of queue depth.

No comments:

Post a Comment