| Author |
Message
|
| BarryB |
 Posted: Mon Jul 19, 2004 6:01 am Post subject: MQDisc and Get with wait |
 |
|
Acolyte
Joined: 01 Jul 2004
Posts: 53
Location: Vernon Hills, Il
|
Hello,
We have a program that does a 'get with wait unlimited' on the queue. When the first initial batch of messages arrive on the queue, the program reads them perfectly.
After about a 2 - 3 minute waiting period, a new batch of messages arrives on the queue, and the program just hangs there and does not read.
If we 'kill' the program and restart it, it retrieves the batch fine, and then the same scenario occurs for the next new batch where the program hangs. I am curious, should we be disconnecting after the initial read? If so, that would imply that using the get with wait is not a good idea?
Thanks,
B |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Mon Jul 19, 2004 8:13 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Several questions spring to mind
Are you retrieving messages based on MSGID or CORRELID?
How are you opening the queue and browsing the messages?
Are the messages being put onto the queue under syncpoint?
What other GET options are being used?
Are the messages being sent from a remote system?
Is the program that reads the message a client program?
What platform is this happening on?
Personally I have never experienced any problems whatsoever with MQGET and wait intervals that didn't resolve to application errors. |
|
| Back to top |
|
|
| BarryB |
| Posted: Mon Jul 19, 2004 8:25 am Post subject: |
|
|
Acolyte
Joined: 01 Jul 2004
Posts: 53
Location: Vernon Hills, Il
|
Application A (running on Windows using MQClient), puts a message to the remote queue on the Unix/AIX MQServer. Application A will put up to 25 messages before it then commits the batch to the queue on Unix/AIX. Application B will then 'ingest' these messages for backend processing (runnng on Unix/AIX).
Application B uses the following for get:
Get with wait, wait set to unlimited
Get with syncpoint
Get with a 'match option' on group id
The message id and correlation id are set to MQMI_NONE and MQCI_NONE on each retrieval of each new read.
The first 'batch' of messages is always 'ingested' and processed. Once the second batch is sent in, the program hangs on the first read. It will hang indefinitely until we 'kill' the process and restart. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Jul 19, 2004 8:40 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
I suspect that the Client connection is getting broken and that is causing the problem. Personally I would never use an indefinate wait over a client connection....too much can go wrong.
It looks like triggering may be a workable solution in this scenario. |
|
| Back to top |
|
|
| BarryB |
| Posted: Mon Jul 19, 2004 8:55 am Post subject: |
|
|
Acolyte
Joined: 01 Jul 2004
Posts: 53
Location: Vernon Hills, Il
|
| Is there any way to programatically re-establish the client connection? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 19, 2004 11:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Are you clearing the group id after the last message in the group is processed ?
| Quote: |
Get with a 'match option' on group id
The message id and correlation id are set to MQMI_NONE and MQCI_NONE on each retrieval of each new read.
|
If you are not clearing the group id after the last message of the group your process is waiting indefinitely for further messages in that specific group, thus appearing to be hanging and ignoring messages from the next group....
Last edited by fjb_saper on Wed Jul 21, 2004 12:12 pm; edited 1 time in total |
|
| Back to top |
|
|
| BarryB |
| Posted: Tue Jul 20, 2004 5:34 am Post subject: |
|
|
Acolyte
Joined: 01 Jul 2004
Posts: 53
Location: Vernon Hills, Il
|
| yes, clearing the groupid after each message. |
|
| Back to top |
|
|
| kapoorvineesh |
| Posted: Tue Jul 20, 2004 11:01 pm Post subject: |
|
|
Newbie
Joined: 13 Apr 2004
Posts: 7
|
Hi,
kevinf2349 wrote
| Quote: |
| It looks like triggering may be a workable solution in this scenario |
Can we do this in a cleint/server model? Since the Qmgr resides on the server, How will we trigger a client application from a server? I dont think we can do this. All please enlighten me.
Also kevinf2349 wrote
| Quote: |
| I suspect that the Client connection is getting broken... |
I concur with this. I think we need to see the server connection settings for this. Also i would roughly estimate the the longest round trip time for a request/reply message and set that value in the server connection setting. Also i would make the client application gracefully display an error message about the message being lost/not replied (on completion of that time limit) and consequently will/will not resubmit the request. Send the message(arriving late) to the DLQ and let the Admin see to the problem at the server side. Meanwhile an error log file on the client side will help the Admin's analysis.
What do you all think about this. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Jul 21, 2004 6:15 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| There is a client version of the trigger monitor program (runmqtmc). It runs on a client machine to watch a queue and then triggers an application on the client machine. |
|
| Back to top |
|
|
| BarryB |
| Posted: Wed Jul 21, 2004 6:25 am Post subject: |
|
|
Acolyte
Joined: 01 Jul 2004
Posts: 53
Location: Vernon Hills, Il
|
| Is runmqtmc the only command I have to issue on the AIX MQ Client, or is there other configuration? I haven't done this before, so any documentation you know of would be greatful!!! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jul 21, 2004 7:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 21, 2004 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
Get with wait, wait set to unlimited
Get with syncpoint
Get with a 'match option' on group id
The message id and correlation id are set to MQMI_NONE and MQCI_NONE on each retrieval of each new read.
|
At the end of the first group your process goes into an unlimited wait state for more messages of the same group which will never appear
Instead of doing a get wait with no time out,
do a get wait with timeout of x as soon as you match on group id.
Then clear the match group id and do a get wait with no time limit.
This should give you the 1st message of the next group.
 |
|
| Back to top |
|
|
|
|
