| Author |
Message
|
| exerk |
 Posted: Thu Sep 25, 2008 2:55 pm Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I fully agree with the above two posts, but we've (I'm sure) had to fettle MQ to address application shortcomings. An API exit may be viewed by the business as an unacceptable intrusion.
_________________
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 |
|
 |
| Jonathan Juler |
| Posted: Thu Sep 25, 2008 8:34 pm Post subject: |
|
|
Newbie
Joined: 18 Nov 2007
Posts: 6
|
Go gently on me...
Re the first challenge - if the logs are on a disk that fails, what good is persistence anyway? |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Thu Sep 25, 2008 8:45 pm Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
| Jonathan Juler wrote: |
Go gently on me...
Re the first challenge - if the logs are on a disk that fails, what good is persistence anyway? |
Its entirely depends upon the business, as the question comes, they are using Persistence messages,
how to avoid the issues:
1)Alter mechanism
2)API EXITs
3)Programming Practice
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Sep 25, 2008 10:09 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| Which copy member does JMS use? |
don't know 
well, something i did not took into account because thats not really my game.... but you are right, my solution is only possible in a specific environment and for specific programming languages........
for some applications i do have a channel message exit that checks the incoming and outgoing messages for persistence. of course this does not prevent the application to write NP messages, but - if detected in test environment - you are alerted before this program hits production.
we use this exit especially for customer connections, as we do not want our customers to send NP messages for specific applications. In case we detect NP messages, we inform the customer that he changes his configuration or programm.
Again, this is just a partial solution and works only in distributed environment, but in this special case (customer connection) we do not have any influence on the customers programming work......
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Challenger |
| Posted: Fri Sep 26, 2008 2:19 am Post subject: |
|
|
Centurion
Joined: 31 Mar 2008
Posts: 115
|
wow !
I am pleasntly surprised by the number of responses received. thanks.
2- for the Second Question: although AkankshA was heading towards the answer/fix, Atheek got the specifics right and is declared the winner.
A bit of searching/googling here and there, you would have found a reference to: http://www-1.ibm.com/support/docview.wss?uid=swg1IY74915, saying that on AIX only, performance will degrade if the API Exit is invoked frequently without this fix (users affected are WMQ 5.3.1 pre CSD12 and WMQ 6.0.0). The above description may seem to indicate that the Exit will only be invoked occasionally, but in reality it has to be invoked for every single PUT.
Lesson: especially when using “global” code (E.g. exits, wrapper code, …), ALWAYS carefully check all IBM bulletins for applicable maintenance.
1- for the First Question: Got the most hits and replies, certainly is more controversial with the Apps Development folks vs the Admin side. I'd love to read a few more Developer folks stating their side of the ' P vs NP good practices ' story . So, let's let the debate go on a bit more before I declare the winner of this one.
Challenger  |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Sep 26, 2008 2:58 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Jonathan Juler wrote: |
Go gently on me...
Re the first challenge - if the logs are on a disk that fails, what good is persistence anyway? |
OK you asked for it! 
'cause normally you have your queues and log data on seperate disks, loosing both at the same time is unlikely. With either of the 2 recovery is possible (provided you have used linear logging)
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Sep 26, 2008 5:53 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
I have found all too often that WMQ is viewed as a piece of Cat 5 cable, and that code is cut and fixed long before an MQ Admin (or someone with the necessary expertise that could have made a difference) is involved.
Third Party applications, over which I have no control, so-called systems integrators who have no in-house knowledge of WMQ but get the job anyway, are always going to be a fact of life.
All Sys Admins, or SME's, can do is try to educate (bruce2359, you're too soft - I use a baseball bat with 6 inch nails sticking out of it, but just as an entre  ) and mitigate the effects.
_________________
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 |
|
|
| bruce2359 |
| Posted: Fri Sep 26, 2008 6:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| if the logs are on a disk that fails, what good is persistence anyway? |
The typical behavior is: program A puts a message in a queue, and immediately (or pretty darn quickly) program B consumes it. Once consumed (comitted), for this message, there is no need for the logs or the queue files.
If your applications are such that program A puts a message in a queue, AND it stays in the queue for an extended time period (like for midnight processing); then the messages are at risk, and the logs are required should the qmgr fail.
Good application design (and I've seen very little of it) would require that program A keep track of request messages that it has sent, and the replies it has received. Program B should do the same: keep track of request messages it has received, and replies it has sent.
In other words, both apps should be sensitive to loss or duplication of messages, and behave acccordingly.
It's more likely that program A (or B) will duplicate its messages by bad design or coding; and less likely that MQ will duplicate or lose messages.
_________________
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 |
|
|
| dgolding |
| Posted: Fri Sep 26, 2008 12:36 pm Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
Bruce2359 wrote:
| Quote: |
| The typical behavior is: program A puts a message in a queue, and immediately (or pretty darn quickly) program B consumes it. Once consumed (comitted), for this message, there is no need for the logs or the queue files. |
Didn't I read somewhere that introduced in one the 5.x releases, that if Program A puts the message, and Program B is waiting on the same queue and immediately consumes it, that nothing gets logged, and the message never gets "hardened" by writing to disk (even if persistent), only exists for a nano-second in memory - as the net effect on the queue is zero? This was introduced as speed-up code, IIRC |
|
| Back to top |
|
|
| atheek |
| Posted: Fri Sep 26, 2008 2:57 pm Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
| dgolding wrote: |
| if Program A puts the message, and Program B is waiting on the same queue and immediately consumes it |
Should this be corrected to if Program A puts the message outside a syncpoint(' ') |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 26, 2008 9:11 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
In your original post you were looking at persistence setting for messages possibly in a JMS environment.
Well as always JMS is a little bit a different animal than the rest of it:
Here is the skinny of it.
a) the application sets the persistence -- this overrides everything
b) the application uses the setting as qdef.
This would normally go as defined on the queue. However in JMS you define the queue (Destination) in JNDI and can set the persistence there if the application uses as queue def. Mind you in the JNDI layer you can also set as queue def which then goes to the queue setting on the qmgr.
So nothing really changes you have just another level on indirections in between.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| AkankshA |
| Posted: Mon Sep 29, 2008 11:40 pm Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
| atheek wrote: |
| Quote: |
The Second one:
We’re running a heterogeneous network with queue managers at various versions (but all 5.3 or higher) on a variety of platforms (Solaris, Win 2003 Server, Win XP, AIX 5.2 and 5.3 and HP/UX). Gievn how most people on the forums seem to like Exits in general, after some decent testing on all platforms, we implemented an API Exit that writes an alert to the Windows Event Log / Unix syslog whenever the application writes a message to the “Application Error Queue” (this happens very rarely, at most a few times a day). Everything seems to be running fine, except… some AIX based users complain about slow response times. Any idea what could have caused this? |
Any chance this is of a MQ product bug?
I could see this APAR for v 5.3 on AIX:
http://www-01.ibm.com/support/docview.wss?&apar=only&uid=swg1IY74915 |
Not just 5.3...
It was there in 6 also...
_________________
Cheers |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Tue Sep 30, 2008 5:25 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
1) The project should have a point of Contact to update/alter the mqm objects. and it must have Request for Change Details and it has to be approved before doing it.
2) Robust Monitoring Tools which helps to update the altered object(s) (accidently).
Hope the above two helps out
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| Challenger |
| Posted: Tue Sep 30, 2008 9:15 am Post subject: |
|
|
Centurion
Joined: 31 Mar 2008
Posts: 115
|
1st question brought in many good responses. Honorable mentions to Gaya3, Mr Butcher, exerk, PeterPotKay and fjb_saper amongst a few others. I have picked bruce2359 as my selected winner.
For the 2nd question, Atheek was earlier announced as the winner.
Thanks for participating in our September challenge. you are all  s |
|
| Back to top |
|
|
| Tibor |
| Posted: Wed Oct 01, 2008 12:17 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
I know the challenge is over, but one more comment: If a message broker exists in your environment, the persistency attribute can be controlled and any 'rebel application' would get a notification: "Penitence because of non-persistence"  |
|
| Back to top |
|
|
|
|
