|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
MQ error 2101: OBJECT_DAMAGED |
« View previous topic :: View next topic » |
Author |
Message
|
bruce2359 |
Posted: Wed Jun 24, 2009 10:55 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9482 Location: US: west coast, almost. Otherwise, enroute.
|
to avoid queue full, why not set maxdepth at 999999999?. _________________ 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 |
|
 |
JosephGramig |
Posted: Wed Jun 24, 2009 11:02 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
This is a capacity planning exercise.
Calculate max queue depth X average msgs size X 1.2 for a little extra.
Make sure you have at least that much file system space at the QMGR.
Don't put your logs on the same file system. |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Jun 24, 2009 11:11 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9482 Location: US: west coast, almost. Otherwise, enroute.
|
I'm with Mr. Potkay on this one: it's a bad design. MQ is asynchronous by nature.
This design creates a synchronous application model - where service requester app is bound on the current queue depth to slow down or stop its requests. _________________ 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 |
|
 |
Vitor |
Posted: Wed Jun 24, 2009 2:26 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Sam Uppu wrote: |
When the queue is full, the sending app will stop sending the msgs onto this queue. |
It's massively bad practice for the sending app to know anything about what's going on at the receiving end. In design terms it means you can only run the sending application on the same queue manager as the reciever so it can do an enquire.
In practical terms it also means you have a serious WMQ administration / sizing problem; probably between the ears of the people doing the task. If you're worried that the inbound queue will fill because it's being emptied more slowly than it's being filled, the inbound queue doesn't have enough space. It's always possible for a queue to fill up in a problem situation, but in normal running the input queue should be large enough to take a normal load plus a margin. This is especially easy to work out when you have a history of inbound files that can be used as sizing. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Jun 24, 2009 2:45 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9482 Location: US: west coast, almost. Otherwise, enroute.
|
Consider that it might be possible to have more than one consuming application getting messages from the queue. Or having a clustered queue each with a single consuming application. _________________ 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 |
|
 |
Vitor |
Posted: Wed Jun 24, 2009 2:49 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
bruce2359 wrote: |
Consider that it might be possible to have more than one consuming application getting messages from the queue. Or having a clustered queue each with a single consuming application. |
In a design this dubious, I have a contact admin suspicion that the messages need to be read off in sequence by a single instance due to message affinity issues. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
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
|
|
|
|