| Author |
Message
|
| mveerman |
 Posted: Mon Feb 25, 2002 4:41 pm Post subject: |
 |
|
Newbie
Joined: 24 Feb 2002
Posts: 7
Location: Los Angeles
|
| We are using MQSeries under Windows2000, doing PUT/GET for about 200,000 messages a day. We are missing/losing messages on average about 1 message per day. We are doing syncpoints on all GETs and PUTs. At first, after checking the error logs, I thought we were using too small a log size in a circular logtype. After changing the queue manager to a linear log type and increasing the log size, we are still losing messages. I've been reading the docs and keep coming across 'replay the log' phrases, but can't find what command actually does 'replay the log'. (I know of rcdmqimg/rcrmqobj to restore objects and the dmpmqlog to view the log). Any ideas on how to replay the log? Any ideas on why we are lossing messages? |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Tue Feb 26, 2002 4:32 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
I would look closer at your application, I have not seen MQSeries lose messages
in the 4yrs we have used it. If you were to have logging issues it would show up in the form of FDC files. As far as replaying the logs MQSeries does that on it's own. Question are you using Persistant or non-persistant messages ???
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Feb 26, 2002 5:28 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
You need to examine your program logic carefully. Are you certain that there is no "window" for data loss? Unless you use XA coordination with your database manager, then you cannot be 100% certain of transactional integrity between your application database and MQSeries queues.
If you receive a successful completion from the committed MQPUT then MQSeries should have the message and not lose it en-route. Check your dead-letter queue.
|
|
| Back to top |
|
|
| mveerman |
| Posted: Tue Feb 26, 2002 9:45 am Post subject: |
|
|
Newbie
Joined: 24 Feb 2002
Posts: 7
Location: Los Angeles
|
Thanks both for your response. I'll double check our application code.
mrlinx: When does MQSeries replay the logs on it's own
...are starting up the Queue Manager? |
|
| Back to top |
|
|
| mveerman |
| Posted: Tue Feb 26, 2002 9:47 am Post subject: |
|
|
Newbie
Joined: 24 Feb 2002
Posts: 7
Location: Los Angeles
|
| ...forgot to respond to one of your questions...we are only using persistent messages. |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Feb 26, 2002 9:55 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Hi Veerman,
You said you are putting Persistent messages, about 200,000. There are just a few questions/doubts on it.
1) After you end the application, do you see any message on the queue these apps' were servicing.
2) Are there any message on the DLQ.
3) Any Events generated. If you are using Clients or there are channels involved, there is a window of messages being discarded(even though vague in this context). And thus you can check the event queue to see if something of this happened(of course enabling the events).
4) Was anything logged in any of the error logs involved.
5) Check with the Programmer to see the code of both put and get. How sure are you that the getting app did not recieve 2 msgs, reported one. Apply the same to the Putting app.
6) What happens if the sceanrio changes from 200,000 to say 100. Are you able to get/put all the messages without any messages being LOST.
7) Last question would be. How do you know that the messages are lost. Do you compare the curdepth, or get the count of messages put and got.
Check these questions out, and you probably would come a bit closer.
Hope this helps.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| mveerman |
| Posted: Mon Mar 11, 2002 4:53 pm Post subject: |
|
|
Newbie
Joined: 24 Feb 2002
Posts: 7
Location: Los Angeles
|
| Thanks for everyone's suggestions. It turns out the problem was in the app. For anyone coming after me, the solution was using the ClearErrorCodes method on the Queue object (we use v5.2) before the GET and checking the ReasonCode for 2033 (no msgs in Q). In a loop, if the ReasonCode isn't cleared, we get a message, but throw it away by doing a COMMIT when checking the past GET's ReasonCode. |
|
| Back to top |
|
|
|
|
