Author |
Message
|
saba_MQ |
Posted: Tue Aug 05, 2008 3:04 am Post subject: Problem When more number of messages in the Queue |
|
|
Newbie
Joined: 05 Aug 2008 Posts: 1
|
Dear Friends,
I am new to MQ Series. We have the following flow.
The host program take the msg from front end and puts the msg in a Request Queue which has Local Defn in AIX MQ QM , the broker running in AIX server converts this EBCDIC msg in to XML and this XML is taken by the API as a request. This is the request flow.
The response flow is in reverse. The API put the XML msg in the AIX MQ QM Queue and the broker converts the response XML into EBCDIC and put into queue which has remote definition in host.
To get the response corresponding to request we use msg ID ie we set the message ID during PUT by the HOST program and the same message id is used through the entire request flow and response flow. After MQPut the host program triggers the MQGet program to get the response. If there is no response msg in 30 Seconds or the response doesnt have the msg ID the MQGet Program will return an error.
Now this request and response flow works very fine when the request is from 2 or 3 terminals. But when it goes for 40 or 50 terminals, we get more requests and for some requests we get the error msgs though it got the response messages with the same msg ID as the request. Have any one come across this situation. I am hardly struck and please help.
Thanks,
Saba |
|
Back to top |
|
 |
zpat |
Posted: Tue Aug 05, 2008 4:31 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Don't confuse codepage EBCDIC with message content format XML.
Conversion of codepage should be done at the receiving program.
However I will assume you mean COBOL copybook like format.
The response message should use the CORRELID field to contain the MSGID of the original request.
The requestor should look for the correct reply based on matching the CORRELID.
All requests must have unique MSGIDs. |
|
Back to top |
|
 |
sri_csee1983 |
Posted: Tue Aug 05, 2008 9:13 am Post subject: |
|
|
 Centurion
Joined: 25 Mar 2008 Posts: 125 Location: Chennai,India
|
Dear Zpat,
This I am posting on behalf of my team mate Saba.
many thanks for ur reply, What I was suppose to mean was Conversion from CWF to XML in request flow and XML to CWF in response flow. So no confusion in that. U mean the request msg and the response msg shud not have the same msg ID as the msg ID shud be unique? Ok thts a valid point.But still that logice works for 80% of the transactions, it doenst work only for 20% of transactions. Ok any how will set tht to the CorrelID of the response msg and try. _________________ With Cheers,
Sri |
|
Back to top |
|
 |
belchman |
Posted: Tue Aug 19, 2008 4:14 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006 Posts: 386 Location: Ohio, USA
|
Is the problem due to the likelihood that as the system handles greater demand that is slows down and 20% or so of the messages can no longer be completed in <=30 seconds?
You might try to arbitrarily set a higher expiry limit to see if the 20% number is reduced. _________________ Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Aug 19, 2008 5:30 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Also the request reply model does not lend itself to long waiting times with high volume. (30 s is an eternity in machine time). What I would suggest here is an aggregation pattern as it will handle the volume much better.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bower5932 |
Posted: Tue Aug 19, 2008 6:05 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
30 seconds is definitely an eternity. However, I find it hard to believe that 40 to 50 terminals (which I take to mean a human sitting on them) can generate enough work (message traffic) to cause a system to take more than 30 seconds to reply. I'd have to wonder what else is going on. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Aug 19, 2008 11:55 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
bower5932 wrote: |
30 seconds is definitely an eternity. However, I find it hard to believe that 40 to 50 terminals (which I take to mean a human sitting on them) can generate enough work (message traffic) to cause a system to take more than 30 seconds to reply. I'd have to wonder what else is going on. |
Try single threading the stuff at max time and you already have 1500 secs (25 mins)  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|