| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Need Help!... |
« View previous topic :: View next topic » |
| Author |
Message
|
| Ravee |
 Posted: Mon Oct 28, 2002 11:05 am Post subject: Need Help!... |
 |
|
Newbie
Joined: 28 Oct 2002
Posts: 9
Location: New York, NY
|
I have a very weird situation and need help. I recently inherited some code  . Following is a brief description of the current implementation and the problem.
The Scenario:
=========
ProcA does a GetMessage from Q1 with
MQ_MATCH_MSG_ID and passes a string for message id
MQ_WAIT and the wait time is INFINITE.
This is a static message being set up along with the constant messageId when the Queue is setup.
The idea is that the process will get the message in transaction when available and does some of its logical processing and does a rollback.
The ProcA is a C++ program running on NT using MQ Client, queue resides on MainFrame.
The Problem:
=========
When the process makes a request with INFINTE wait when the message is available and with no other connections to the queue, the requests does not fetch the msg.
Where as, if I change the wait time to a +ve value like 5 seconds, it fetches the message immediately.
I have been searching and reading up at google and ibm site and other docs for the last 2 weeks, but no luck.
Any and all help is deeply appreciated.
Thanks
Ravee. |
|
| Back to top |
|
 |
| bduncan |
| Posted: Mon Oct 28, 2002 2:41 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Two questions:
1) Is there anyway you can change the architecture of this system? Why on earth would you repeatedly get the same message and roll it back? There's got to be a better way to do this...
2) Did this problem suddenly crop up? It seems to me if the application has always been coded with an infinite wait, and that doesn't work, then how did this thing ever work in the past? If the wait time was a recent addition, then I'd recommend choosing some wait interval which is so high, it might was well be inifinite, but is still finite. Perhaps this will provide a quick fix...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| TonyD |
| Posted: Mon Oct 28, 2002 5:16 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
I 'm not sure I understand your description of the processing; you imply that a permanent message is generated on the queue which is read, some processing happens, and then it is put back on the queue with a rollback...using MQBACK?. However, if you had the following:
MQBEGIN
MQGET
If Message retrieved
Do some processing
Loop back to MQGET
Else wait for Wait Interval
Then (if '2033') go to MQBACK
MQBACK
:it seems to me that with an infinite wait time you will never complete the UOW and therefore will not see the message(s) that were retrieved; if the wait time is set to 5 seconds, the UOW will then be able to complete.
If there is no loop involved then this explanation obviously does not apply. |
|
| Back to top |
|
|
| nimconsult |
| Posted: Tue Oct 29, 2002 1:42 am Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
I have the impression that Ravee is describing an original way of implementing a semaphore.
semaphore.wait() = MQGET under syncpoint
semaphore.signal() = MQBACK
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| Ravee |
| Posted: Tue Oct 29, 2002 5:21 am Post subject: Urgent, Need Help! |
|
|
Newbie
Joined: 28 Oct 2002
Posts: 9
Location: New York, NY
|
Brandon,
1. No I cannot change the architecture at this stage, I am just putting in some frills to a version in production.
2. Yes, it seems to be working fine in prod. It started recently in test (though nothing was changed in the code regarding this module / logic).
nimconsult,
Yes, you are correct it is being implemented as a kind of a semaphore.
TonyD,
See above, The reason it is being read to remove from the queue is meant to stop any other instances/threads processing the same event / logic more than once. Whichever instances / threads takes hold of the static message will respond to that event accordingly.
Also, if I request a get message with INFINTE WAIT, the second the other instances/threads are done processing its event, this process would get the message or gain access to the semaphore, so to speak.
I am sorry if my original description of the problem was not described fully. However, since it was working in test prev. (currently still works in prod.) is there any settings on the QMgr / Channel set up of the Queue defnition /properties on the main frame, which would help me in this situation.
The Get/Put inhibited are set to NO and the persistence is set to YES.
Or am I approaching it wrongly, Appreciate your time and help. |
|
| Back to top |
|
|
| Ravee |
| Posted: Wed Oct 30, 2002 7:10 am Post subject: |
|
|
Newbie
Joined: 28 Oct 2002
Posts: 9
Location: New York, NY
|
Hi,
Finally cracked it  . Brandon, nimconsult & TonyD thanks for your input. The problem was with the way the message id was being converted to a binary string. I was setting it with '\0' as a low value and when ImqBinary converts it to the length of MQ_MSG_ID_LENGTH, it picks up junk chrs from the memory depending on where the code is being called from. Now it is being set with spaces as low value for MessageId, and the MQMO_MATCH_MSG_ID option works fine.
The reason it was working before when I set the timeout value to a +ve value was the reason that the call was not fetching any message due to a mismatch of MessageId and MQRC_NO_MSG_AVAILABLE is a valid condition thus not triggering the error condition.
I would presume this to be the case for CorelationId as well and wanted to post this info, for any future reference for others.
PS: This scenario applies to C++ on NT using the MQ Client libraries.
Thanks again,
Ravee. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
