| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ behavior when Q fills up |
« View previous topic :: View next topic » |
| Author |
Message
|
| vivica12 |
 Posted: Fri Jul 09, 2010 6:39 am Post subject: |
 |
|
Acolyte
Joined: 13 Jul 2007
Posts: 58
|
Youzers -- i think these suggestions are going way past anythign I want to do. It would complicate and confuse the environment.
We are researching our current tool and it's ability to raise q-depth automatically on an alert.
We know the underlying problem yesterday was that 1 app did not pick up messages. They have fixed that app, that does not mean another app won't have some weird issue and we get in the same boat. So we definitely want to continue to research either how to keep the cluster channels from pausing in our shared environment, or how to act on Q-depth with rules that also take into account Qfile size, log space etc -so as not to allow an app to take out the whole enviornment by filling file system space.
I don't think we will even consider overlapping clusters -- just more complicated, and more room for error.
_________________
Vivica - signing off |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Jul 09, 2010 7:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| We know the underlying problem yesterday was that 1 app did not pick up messages. They have fixed that app... |
Not picking up (getting) messages is a symptom. Exactly what was fixed to resolve this?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| sumit |
| Posted: Fri Jul 09, 2010 9:31 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
One cluster means one autodefined clussndr channel between qmgrs. Which means all msgs will go through the same channel.
If you don't want to use multicluster (which is a good option considering your scernario), try these-
1. Educate your application users to optimize their app (long term task)
2. Assign priority to msgs which you think are critical.
3. Provide sufficient maxdepth to queues.
4. Configure your dlq handler as required.
5. Let the monitoring tools generate alerts if q curdepth is reaching 60-70% of maxdepth.
We can also include lots of temprary work around but it's better to take care of your config now if it's really handling that bulk of critical messages.
_________________
Regards
Sumit |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
