| Author |
Message
|
| mhubbard |
 Posted: Sun Jan 09, 2005 9:52 am Post subject: Missing Records with C++ API |
 |
|
Acolyte
Joined: 25 Aug 2004
Posts: 54
|
I have written an application using the C++ API that is working great...most of the time. But, occasionally, I seem to get queue.put() calls that do not behave correctly. I have been able to capture the behavior with this code:
long lDepth = m_pQueue->currentDepth();
cout << "Depth prior to put is " << lDepth << end;
if ( m_pQueue->put( * pMessage ) )
{
lDepth = m_Queue->currentDepth();
cout << "Depth after put is " << lDepth << endl;
}
And sure enough, on occasion, I get something like this:
Depth prior to put is 0
Depth after put is 0
I am 100% certain that there are no consumers connected to the queue during this test. In my sequence of several records that I write, I have also seen this behavior happen once where the depth was 1 before and after the put.
Does anyone have any ideas about how this can be? What codes am I not checking on after the put that I should be?
Thanks so much
_________________
Michael J. Hubbard |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Sun Jan 09, 2005 10:23 am Post subject: Re: Missing Records with C++ API |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| mhubbard wrote: |
| What codes am I not checking on after the put that I should be? |
The code you posted didn't check the return or completion code at all.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kirani |
| Posted: Sun Jan 09, 2005 3:02 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
There are some sample C++ programs on this site as well as on IBM site. Please look at some sample programs to capture Reason Code and Completion Codes.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| mhubbard |
| Posted: Mon Jan 10, 2005 6:29 am Post subject: |
|
|
Acolyte
Joined: 25 Aug 2004
Posts: 54
|
Sorry - I presumed that the boolean returned from the PUT was an indication of success. I have added the following checks with the same result:
long lDepth = m_pQueue->currentDepth();
cout << "Depth prior to put is" << lDepth << endl;
if ( m_pQueue->put( * pMessage, * pPutOptions ) )
{
long lReasonCode = m_pQueue->reasonCode();
long lCompCode = m_pQueue->completionCode();
lDepth = m_pQueue->currentDepth();
long lMessageFlags = pMessage->messageFlags();
long lPersistance = pMessage->persistence();
long lPriority = pMessage->priority();
char buffer[100];
memset(buffer, 0, sizeof(buffer));
ImqString strDate = pMessage->putDate();
strDate.copyOut(buffer, 50, '0');
cout << "Depth after put is " << lDepth << endl;
cout << "Length after put is " << lLength << endl;
cout << "Flags after put are " << lMessageFlags << endl;
cout << "Persistance after put is " << lPersistance << endl;
cout << "Priority after put is " << lPriority << endl;
cout << "PutDate after put is " << buffer << endl;
cout << "REASON CODE is " << lReasonCode << endl;
cout << "Completion CODE is " << lCompCode << endl;
}
Which results in....
Depth prior to put is0
Depth after put is 0
Flags after put are 0
Persistance after put is 2
Priority after put is -1
PutDate after put is 20050110000000000000000000000000000000000000000000
REASON CODE is 0
Completion CODE is 0
The second and subsequent messages seem to go in fine......
Depth prior to put is0
Depth after put is 1
Flags after put are 0
Persistance after put is 2
Priority after put is -1
PutDate after put is 20050110000000000000000000000000000000000000000000
REASON CODE is 0
Completion CODE is 0
Thanks for pointing out that code repository. I did not know it was there and it looks like a great resource. Can anyone suggest any other debugging information that I might look at?
Thanks
_________________
Michael J. Hubbard |
|
| Back to top |
|
|
| mhubbard |
| Posted: Mon Jan 10, 2005 6:58 am Post subject: An additional clue |
|
|
Acolyte
Joined: 25 Aug 2004
Posts: 54
|
In my test, I attempt to put 8 records on the queue.
I end up with only 7.
To clear the queue for the next test, I have been starting my Consumer application which drains the queue.
This consumer application does a get on the queue with an unlimited timeout value.
When I want to start my test again, I just kill this app which does not nicely end sessions or close queues.
I have found that, if I instead use the CLEAR QLOCAL command from within runmqsc to clear the queue, that I get all 8 records on the next test.
_________________
Michael J. Hubbard |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 10, 2005 12:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Mike,
If you had switched the characteristics of the queue to get(inhibited) before putting your messages you would have seen the full number of 8 messages...
This was most probably due to the fact that your previous application was shut down before releasing any of the resources and/or locks...
Enjoy  |
|
| Back to top |
|
|
| mhubbard |
| Posted: Tue Jan 11, 2005 5:54 am Post subject: |
|
|
Acolyte
Joined: 25 Aug 2004
Posts: 54
|
Are you saying that if I have a process doing a get on a queue.
And that process is doing this get with no timeout specified.
And there is even the remotest chance that the process could go down (maybe because of a reboot or something).
That, in order to make sure I don't loose any records, I have to inhibit Get operations, then do a put, then reenable Gets?
And that I must program the consumer side to understand that if it gets a GET_INHIBITED error, it should just try back again later?
I can certainly do that, but it sounds strange.
_________________
Michael J. Hubbard |
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue Jan 11, 2005 6:16 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
I'm not sure what he's saying, but I can tell you that it is possible to "lose" messages when you are using MQGETs with a client connection. For example:
- Connect as an WMQ client (This starts an agent on the server)
- Issue MQGET with wait on a queue without any messages and outside of a UOW (this results in the agent on the server waiting in an MQGET)
- Kill your program (The agent doesn't realize that your program died)
- Put a message onto the queue
The MQGET in the agent will now return. The agent will try to send your program the message. The agent realizes your program is gone. The message is outside of a UOW and it is 'thrown away'. However, if you had attempted to MQGET the message in a UOW, the agent would see that your program is gone and rollback the message.
I hope this clarifies rather than clouds the issue. |
|
| Back to top |
|
|
| mhubbard |
| Posted: Tue Jan 11, 2005 9:38 am Post subject: |
|
|
Acolyte
Joined: 25 Aug 2004
Posts: 54
|
That did it.
Thanks for the patient support.
_________________
Michael J. Hubbard |
|
| Back to top |
|
|
|
|
