| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| default system timeout queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| paustin_ours |
 Posted: Tue May 07, 2013 11:01 pm Post subject: default system timeout queue |
 |
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
What are the cases when someone would need to use a separate timeout queue other than the default system time out queue.
One of the reasons i am hearing is that if a timeout notification flow is stopped the system queue fill ups and that would cause other flows to fail. But on testing i am seeing consequent timeout messages are overwriting existing messages for the same identifier. Only time i am seeing messages build up is when a flow is deleted from the EG and then there is that timeout message that is stuck. Also, are there possibilities of rogue messages sitting on system timeout queue? is that the reason why someone would want a separate timeout queue for each timeout flow?
trying to understand the need for separate timeout queues is all. Please help. Thanks. |
|
| Back to top |
|
 |
| Esa |
| Posted: Tue May 07, 2013 11:34 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
I think it's not that the queue fills up but that it may become too deep. Applications may store large payloads with the timeout notifications. If you have several applications that store large timeout messages, for example if they all use some standard retry framework and they end up in a retry loop simultaneusly, the queue may grow too deep. Or actually the amount of data stored in the queue.
This is because of the way MQ gets messages. When a queue is opened for getting, the whole queue is read into memory. A deep queue with large messages may cause memory problems and slow the whole system down.
That's the only reason for having application specific timeout queues that I can think of. There may be better reasons.
On the other hand, if MQ loads one 500 MB queue in memory or five 100 MB queues, does it make any difference, you may ask. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 08, 2013 12:26 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Separate timeout queues allows application support people to see what's going on in their application more easily.
Also, if you allow them to, they could delete messages from their queue without being able to affect other applications.
Essentially this queue becomes part of the application - so it's quite sensible to use a dedicated queue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 08, 2013 5:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Esa wrote: |
| This is because of the way MQ gets messages. When a queue is opened for getting, the whole queue is read into memory. |
That's a bit of a generalisation. Queues with large depths can degrade performance and are generally a non-optimal idea but not just for that reason.
I incline to @zpat; the benefits are principally administrative and have the happy side effect of keeping queue depths down.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
