| Author |
Message
|
| gbaddeley |
 Posted: Thu Nov 25, 2010 2:03 pm Post subject: |
 |
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| Increasing the default maxdepth can be dangerous, as it tends to delay the detection of application problems - for poorly tested applications. |
- and for consuming applications that are not running (for whatever reason)
A large maxdepth is OK if some sort of monitoring is in place.
_________________
Glenn |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Nov 25, 2010 2:11 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| PeterPotkay wrote: |
| zpat wrote: |
5. Make the system default queues persistent (since 99% of our data needs this) and maxdepth increased on the default local.
|
IMHO, If an app needs persistent messages, they can take the minimal effort to code the 1 line of code needed to specifically choose this. If they are to lazy to do that, the heck with them, they can default to non persistent. |
It would be nice if application programmers read the manual. But they don't and so it's safer to use persistent messages as the default (esp when it is needed in almost all our cases at present) and since the value of the messages is high. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 25, 2010 5:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
| PeterPotkay wrote: |
| zpat wrote: |
5. Make the system default queues persistent (since 99% of our data needs this) and maxdepth increased on the default local.
|
IMHO, If an app needs persistent messages, they can take the minimal effort to code the 1 line of code needed to specifically choose this. If they are to lazy to do that, the heck with them, they can default to non persistent. |
It would be nice if application programmers read the manual. But they don't and so it's safer to use persistent messages as the default (esp when it is needed in almost all our cases at present) and since the value of the messages is high. |
I would have thought that in such an environment testing is the rule.
So what happens when their programs fail the test. (qmgr restart)? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zonko |
| Posted: Thu Nov 25, 2010 11:14 pm Post subject: |
|
|
Voyager
Joined: 04 Nov 2009
Posts: 78
|
| Quote: |
| But they don't and so it's safer to use persistent messages as the default |
Where is gbaddeley when you need him?
Setting DEFPSIST on a queue does not make msgs put to the queue persistent by default. If the app does nothing with MD.Persistence, the default (if you must use that word) is non-persistent. The app must choose to use the DEFPSIST attribute by setting MD.Persistence to MQPER_PERSISTENCE_AS_Q_DEF.
In summary, administrators cannot make up for the deficiencies of lazy or incompetent programmers. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Nov 26, 2010 12:21 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zonko wrote: |
| ...In summary, administrators cannot make up for the deficiencies of lazy or incompetent programmers. |
True, but unfortunately we often end up having to fettle the infrastructure to accommodate the shortcomings of an application. I always push for early engagement of the WMQ Team at any site I'm on, so best practice etc. is followed. Too often that recommendation falls on deaf ears.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Nov 26, 2010 1:02 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| zonko wrote: |
| Quote: |
| But they don't and so it's safer to use persistent messages as the default |
Where is gbaddeley when you need him?
Setting DEFPSIST on a queue does not make msgs put to the queue persistent by default. If the app does nothing with MD.Persistence, the default (if you must use that word) is non-persistent. The app must choose to use the DEFPSIST attribute by setting MD.Persistence to MQPER_PERSISTENCE_AS_Q_DEF.
In summary, administrators cannot make up for the deficiencies of lazy or incompetent programmers. |
NOT true, by default the value is "persistence as queue default". RTM.
| Quote: |
| This is an output field for the MQGET call, and an input field for the MQPUT and MQPUT1 calls. The initial value of this field is MQPER_PERSISTENCE_AS_Q_DEF. |
In summary, administrators can help prevent the loss of high value messages by setting queue persistence to guard against the application not setting it, or relying on the queue value. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 26, 2010 2:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Persistency default really behave differently depending on the applications.
If you set the JNDI attribute to APP_DEFINED the default on the JMS destination would/used to be persistent... Not always the desired effect.
Anyways as stated by numerous colleagues, this is something you HAVE to push back on the application designers.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Nov 26, 2010 3:29 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It is still worth setting as best practice (if you should have mainly persistent messages) - that is the point I was making.
It can (and it has) prevented issues. Developers are far from perfect and the chances of them changing production code just because an admin would like them to is very low. You have to deal with the ways things are and not the way you would like them to be. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Nov 26, 2010 6:21 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
On dedicated Queue Managers I would not have any problem with that. The only app impacted is the one not setting its persistence explicitly.
On shared Queue Managers that talk to other shared Queue Managers, the risk I see is that as new apps get added over the years, the more and more apps that get added that were created by developers that didn't bother to explicitly set persistence, the more apps you have sending persistent messages. Perhaps some actually need that. Many potentially do not. And as more and more unnecessarily persistent messages get added to the system, everything...starts.....to......s-l-o-w.............down. And then the knuckleheads come out of the woodwork and complain that "the MQ is slow". And whose fault is it at that point? BOTH the developers's and the MQ Admin's.
But if the queues were set to have that value as non persistent, and some messages go missing because they were not persistent, the fault is entirely with the developers for not setting it explicitly.
If the shop's practice / standards / guidelines are to have the apps use the queue's value for their MQPUTs and its documented and every one agrees that that is how messages get their persistence determined, I'd sign off on that. The problem is I think in most cases the queues value is used not by design, but accidentally.
Coming from a highly shared environment where dozens of apps share Queue Managers I have a different perspective on this. I have to police the infrastructure for the greater good of all apps.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Nov 26, 2010 6:31 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, and I pointed out that 99% of our apps need persistence and the financial impact of any message loss is high.
There is nothing to stop apps (1) setting messages to non-persistent, or (2) requesting their queue have the default as non-persistent.
My suggestion was to make the system default a safer one (in terms of avoiding potential message loss) when persistent is the norm. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Nov 28, 2010 2:53 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
Yes, and I pointed out that 99% of our apps need persistence and the financial impact of any message loss is high.
There is nothing to stop apps (1) setting messages to non-persistent, or (2) requesting their queue have the default as non-persistent.
My suggestion was to make the system default a safer one (in terms of avoiding potential message loss) when persistent is the norm. |
MQ admins do not have any responsiblity for message peristence. If they change the default persistence for all new queue definitions (alter SYSTEM.DEFAULT.LOCAL.QUEUE) they are creating a misleading impression of MQ, particularly if they don't tell the app team.
I do not believe in changing any defaults. It will often come back to bite. For one thing, it tends to confuse newer MQ admins, they might change it back to the "proper" default during a problem situation because they think something is wrong.
If MQ admins feel they should have some responsibility for message persistence, they should inform the app teams that they must explicitly code the persistence as appropriate on all puts, or that all requests for defining new queues need to specify the DEFPSIST setting.
A more diligent MQ admin might look at messages on app queues and recommend or query the app team whether they should be peristent (high value) or not (for performance).
Not all messages need to be persistent, even in the finance industry, eg. account balance enquiry.
_________________
Glenn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Nov 28, 2010 3:00 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I view a production qmgr as something that should be planned from the groun up, and designed and built to limit the number of ways in which an application team can cause the MQ admins pager to go off at two am on a Friday, after the pub.
Leaving a qmgr at mostly default settings can, among other things leave it open to well-known security risks... CHAD, no MCAUSER...,etc., etc. .... |
|
| Back to top |
|
|
|
|
