| Author |
Message
|
| Vitor |
 Posted: Wed Mar 10, 2010 8:03 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lash wrote: |
| i wrote a java program which sends persistant msgs continously. but msg size was 3kb only. |
That's because you need to write your program badly to fill a circular log. Just sending persistent messages is not enough.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Mar 10, 2010 8:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Or, stated another way: logs full is not a queue manager failure. Similarly, running out of space on the filesystem is not a failure of the queue manager, and thus something that HA can resolve.
Yes, you can fill the logs (put more or bigger persistent messages), and fill the filesystem (same way); but the queue manager lives on. Each returns a ReasonCode and CompletionCode to the application.
If we have misunderstood the purpose of your testing, please state exactly what you are trying to accomplish.
_________________
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 |
|
|
| lash |
| Posted: Wed Mar 10, 2010 8:17 am Post subject: |
|
|
Apprentice
Joined: 14 May 2003
Posts: 47
|
vitor, ur quote
"It stops working, it doesn't stop running."
than How to make qmgr start working again. We know it wont work in failover also. So there should be some way to make qmgr start working again in production. apart from increasing the file-system. |
|
| Back to top |
|
|
| lash |
| Posted: Wed Mar 10, 2010 8:27 am Post subject: |
|
|
Apprentice
Joined: 14 May 2003
Posts: 47
|
purpose of testing this is
what are the options available to us if MQHA/data, MQHA/log or both fills up and qmgr stop working.
We know options are increasing the file system . But if increasing the file-system option cannot be used. or clusetering cannot be used. what else we can do to make prodution qmgr operable. without much downtime etc...
Last edited by lash on Wed Mar 10, 2010 8:30 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 10, 2010 8:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lash wrote: |
| than How to make qmgr start working again. |
Wait 5 seconds for the queue manager to finish it's log recovery.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lash |
| Posted: Wed Mar 10, 2010 8:32 am Post subject: |
|
|
Apprentice
Joined: 14 May 2003
Posts: 47
|
| vitor, so if if log is full, if we wait for 5sec. it will start again ? how about data is full condition. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 10, 2010 8:35 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| what are the options available to us if MQHA/data, MQHA/log or both fills up and qmgr stop working |
.
Your testing premise is irrational. As stated several times in this post, the queue manager does not stop working. It will be your applications that fail.
When your apps attempt an activity (API) that requires logging, it will receive a ReasonCode and CompletionCode indicating the nature of the failed attempt.
_________________
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 |
|
|
| lash |
| Posted: Wed Mar 10, 2010 8:41 am Post subject: |
|
|
Apprentice
Joined: 14 May 2003
Posts: 47
|
| Bruce, if apps cannot put or get the msgs from the qmgr. then i dont think we can say qmgr is working fine. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 10, 2010 8:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lash wrote: |
| Bruce, if apps cannot put or get the msgs from the qmgr. then i dont think we can say qmgr is working fine. |
Yes you can. That is not a queue manager failure, in the same way a hardware fault taking out the disc the log is sitting on is not a queue manager failure.
And I agree your premise is slightly irrational. You're testing the wrong thing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 10, 2010 8:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lash wrote: |
| vitor, so if if log is full, if we wait for 5sec. it will start again ? how about data is full condition. |
The queue manager doesn't stop in either a log full or disc full condition. It will attempt to recover from both. Clearly if there is no disc available for the queue manager then recovery will not be successful until more disc comes up (e.g. messages are read from a local queue).
This is one reason the documentation recommends queue and logs be on 2 different discs.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lash |
| Posted: Wed Mar 10, 2010 8:51 am Post subject: |
|
|
Apprentice
Joined: 14 May 2003
Posts: 47
|
| thankyou gurus for your feedback. with this iam ending this post. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 10, 2010 8:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Bruce, if apps cannot put or get the msgs from the qmgr. then i dont think we can say qmgr is working fine. |
The queue manager is working as designed, and as described in the WMQ APR and APG manuals.
The queue manager is a server, like DB2 for example, serving dozens, hundreds or thousands of applications. It is the responsibility of a server to protect itself and its user-community from application/sysadmin errors.
A perfect example of an application error is an endless loop that fills the logs. For applications that don't require logging (non-persistent messages), the queue manager continues to respond successfully to these MQI calls; but fails the applications that require a resource that is not (currently) available.
Neither DB2 nor a WMQ queue manger fails (abends, ends itself, terminates) because of a recoverable error.
_________________
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 Mar 10, 2010 9:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lash wrote: |
purpose of testing this is
what are the options available to us if MQHA/data, MQHA/log or both fills up and qmgr stop working.
We know options are increasing the file system . But if increasing the file-system option cannot be used. or clusetering cannot be used. what else we can do to make prodution qmgr operable. without much downtime etc... |
If the disc is physically full then there's nothing that can be done. The queue manager will recover unused space from the log once it's abended the transaction, and recover space from the queues once messages are read off.
But you can't fix disc full problems with an HA solution.
That's what I meant about you're testing the wrong thing; you should be looking at testing the applications to ensure they don't fill the logs with badly written transactions, don't leave messages sitting on queues inappropriately and most importantly test your monitoring solution to ensure you're warned of near-full discs in good time to allow additional space to be added during a maintenance cycle.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 10, 2010 9:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I understand your concern. My clients face these exact same concerns.
That said, planning is the key to the successful operation of a queue manager. The WMQ System Admin Guide manual has lots of narrative on how to size your logs. This is a critical step in preparing a queue manager for production.
Primary logs should be sized sufficiently large enough to support your usual workload, plus a little extra for small spikes in workload.
Secondary logs are for those times when the primaries are insufficient for your workload.
On Windows and UNIX, it is always a possibility that misbehaving applications may fill the filesystem. From the o/s perspective, this is not a recoverable error.
If you didn't have WMQ, how would you plan for recovery if an application that fills up the filesystem? You really can't, can you? More filesystem space is the solution - and disk space is very, very inexpensive.
Beyond buying more disk space, here are some things you can do:
With WMQ, you can set maxdepth and maxmsglength for a queue. This will have a limiting effect on an application in an endless loop.
You can also set the maximum number of uncommitted messages allowed in a single unit-of-work. This will also have a limiting effect on what the manuals call a long running unit of work. These settings (and others) are part of the business application design.
My question for you: what would you like to happen when WMQ runs out of filesystem and/or log space?
_________________
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 |
|
|
|
|
