| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Losing Messages Sending From 0S/390 to HP-UX |
« View previous topic :: View next topic » |
| Author |
Message
|
| oz1ccg |
 Posted: Wed Aug 14, 2002 6:17 am Post subject: |
 |
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Dear Peter, MQSeries keep no track of non-peristent messages eg. they are not logged due to performance.
You can see something when you're doing a DIS CHS(channel), you will get some information about how many messages, bytes etc. there have flown over the channel.
The other thing could be run a trace (GTF if it's a Z/OS or similar system), and analyze the data....... 
I saw for some time ago, a channel exit that was designed for auditing channel traffic, that could be something for you, but with a high wolume (production), it's never there we test, right 
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Wed Aug 14, 2002 7:54 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Roger,
After reading the manual I have to disagree with your view of the manual.
It states
The disadvantage is that because they are not part of
a transaction, messages may be lost if there is a transmission failure or if the channel stops when the messages are in transit.
It will MAY lose only messages that are in transit if an error/stop channel event happens, not on the restart of a channel
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries
Last edited by mrlinux on Wed Aug 14, 2002 8:05 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 14, 2002 8:02 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Reading further into the Intercommunications handbook, I found the following under Fast, nonpersistent messages:
If a channel terminates while fast, nonpersistent messages are in transit, the messages may be lost and it is up to the application to arrange for their recovery if required. Similarly, if the MQPUT by the receiving MCA fails for any reason, the messages are lost.
So my question now is: Is a message on an XMIT queue considered to be "in transit " ?
And how in the world are we supposed to know that a message was lost because of this?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Aug 14, 2002 7:35 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Ok, any time that I see "may" in a MQ manual I assume they mean "will". So I may be pushing it a little.
The bottom line is that non-persistent messages travelling over a "Fast" channel "may" be lost if there are problems with the channel.
Peter, I'm not trying to be rude but I don't get it. You say that your application cannot operate correctly if messages are lost but then you code them with the non-persistent attribute. I don't get it. Why?
I have a question for you (Peter). What if in the middle of the day - during peak volumes, the queue manager needed to be re-cycled (or the box rebooted)? All (and I mean ALL) non-persistent messages would be deleted. What would your application do?
Peter, the minimum thing that you should do ASAP is remove the "Fast" attribute from the channel. But if it is true that your application cannot survive if a message or two go missing then you need to switch to persistent messages.
later
Roger...
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Aug 15, 2002 5:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Didn't see the question as rude at all.
Here is my take. Why would any application send any message that it does not consider necessary to get to where it's going? Why send it in the first place if you don't care that it makes it? That's why we use MQ: assurred delivery.
The way I use persistence is this. If the message is an Inquiry style message that is probably going to be irrelevant in a few seconds (because the requestor will give up waiting for the reply if it doesn't come and do some thing else, like send a second request), why make it persistent? Is the QM going to go down and come back up before the the requestor gives up on the first request? No, so why bother logging all those messages. But yet I consider those messages important. I want them to make it.
Any message that would be relevant for more than like 15 minutes (the fastest I could see a QM/server being realistically being brought down (intentionally or not)and then back up) should be persistent. This includes all messages that make applications do updates to DBs, etc. In these cases its up to the requesting app to handle the possability that the confirmation of the transaction on the other side may not arrive for quite a while.
Anyway, I think I will switch the speed of the channel. Is FAST a bad default for a channel? If I had 2 QMs that sent nothing but Inquriy request replies back and forth that were irrelevant in 5 seconds, clearly non persistent messages is the way to go. Yet the default channel settings would introduce the possability of lost messages.
So to get assured messages, you either make them persistent, which slows them down due to logging, or make the channel not FAST, which slows down the messages as well. Either way, to get assured delivery, you have to accept a performance hit.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
