|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
message put times difference channel and queue |
« View previous topic :: View next topic » |
Author |
Message
|
zrux |
Posted: Sat Apr 04, 2020 12:19 pm Post subject: message put times difference channel and queue |
|
|
Apprentice
Joined: 21 May 2006 Posts: 41 Location: UK
|
Hello
I am facing a peculiar issue where I am trying to send a request message asking for a COA and response from another QM on customer side.
The COA and response comes back to the intended Qs respectively. When I look at the "putdate" on the COA and response message it shows as 5 seconds more then the "LSTMSGTI" on the receiver channel.
I am only sending 1 message at one time to observe the behaviour on the RCVR channel and the putdate on the message on the Queue.
I have tried send to ask for a COA only and same behaviour is noticed.
Any idea why there would be a difference in times between the chl stats and message putdate? |
|
Back to top |
|
 |
bruce2359 |
Posted: Sat Apr 04, 2020 2:09 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
If I understand your question correctly, one explanation for the discrepancy between put times and transmit time may be due to the COA and response message delayed in the transmission queue waiting for batchinterval to expire so the batch could be formed and transmitted.
What is the batchsize value on the channel? What is batchinterval value on the channel? If batchsize is set to 50, for example, and only 2 messages arrive, the channel will wait for batchinterval to expire before the batch is sent.
If I misunderstood your question, please try again. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
zrux |
Posted: Sun Apr 05, 2020 1:11 am Post subject: |
|
|
Apprentice
Joined: 21 May 2006 Posts: 41 Location: UK
|
to be clear, lets say the request was sent from QM1 to QM2
the putTime measured was on the queue on QM1, once the COA was received.
And the LSTMSGTI was also measured on the QM1 RCVR channel, once the COA was received.
The LSTMSGTI was showing as 5 second lesser then the putTime on the message on the queue on QM1.
The message itself was size 140 bytes approx.
The channels were created with default batchsize , batchinterval.
The XMITQ and batch size would be on the QM2. Why should that attribute to the difference in times. |
|
Back to top |
|
 |
hughson |
Posted: Sun Apr 05, 2020 1:54 am Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
The PutDate/Time of the COA report message are burnt in at the sender end when the message is created.
A receiver channel does not change the contents of the MQMD, it uses set all context to ensure that what came over the wire is what ends up on the queue.
However, even given that the time in the COA is from the sending machine and the Last Message Time is on the receiving machine, 5 seconds is a long time to take between putting the COA message and it arriving at the receiver channel, given that you say that the system is not doing any else.
Given you are comparing times set by two different machines, are you certain that both machines have aligned clocks? For example are you using some sort of time service?
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
bruce2359 |
Posted: Sun Apr 05, 2020 4:33 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Tell us more, please.
Firstly, does the requesting app see a 5 second delay from from the responding app? That is, do you see sub-second response? 5 seconds is a long time.
What are the putdate/puttime for both COA and Response messages? Please display putdate/puttime, and post results here.
Putdste/puttime for both of these messages (COA and Response messages) should be slightly different, as my worthy colleague suggests, as they are produced by different mq components.
I might expect to see COA puttime, Response puttime and transmit time to be within milliseconds or microseconds of each other - and not 5 seconds diff.
Look in mq error logs on both qmgrs. Any channel events logged - errors or not?
What processing does the responding application do after it has consumed the Request message from the Request queue on QM2? Is this a new application? A new qmgr? Has this worked successfully before?
Does the responding app do Units of Work (syncpoints) processing? If the Responding app does its processing in a UofW, it is possible that the batch of Response messages get delayed in the transmission queue awaiting the app to MQCMIT the UofW. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
zrux |
Posted: Sun Apr 05, 2020 9:49 am Post subject: |
|
|
Apprentice
Joined: 21 May 2006 Posts: 41 Location: UK
|
1) The QM1 and QM2 are in 2 different time zones. The clocks are not in sync. Leave alone the responding app, even the COA is showing a delay in 5 sec when looked at the message PutDate and compared with the RCVR channel LSTMSGTI
2) The COA and Channel Status times is not within milisec. Would the difference in time zones and the clock not in sync cause the 5 sec difference between the stats at message level on QM1 and stats at RCVR on QM1
3) Will check the errors on MQ and report back and the rest of the stats asked...don't have the access right now. |
|
Back to top |
|
 |
bruce2359 |
Posted: Sun Apr 05, 2020 12:01 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
All times in MQ are GMT, but acquired locally. If your local time servers are out of sync by 5 seconds, the embedded puttimes will be out of sync.
What are your SLAs (Service Level Agreements) for this app? Response times are usually measured locally, as in: I press enter, wait for the reply/COA, then with a stopwatch, I calculate response time.
Ignore for a moment the time/date stamps. What is your perception: Are you getting sub-second response? When you initiate the requesting app on QM1, do the reply and COA arrive quickly? Or does it take 5 seconds or more for the reply/COA to arrive? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
hughson |
Posted: Sun Apr 05, 2020 3:30 pm Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
zrux wrote: |
The clocks are not in sync. Leave alone the responding app, even the COA is showing a delay in 5 sec when looked at the message PutDate and compared with the RCVR channel LSTMSGTI |
As noted in my previous post, the COA PutTime is set by QM2, the LSTMSGTI is set by QM1.
How different are the clocks for the machine where QM1 is and the machine where QM2 is?
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Last edited by hughson on Sun Apr 05, 2020 8:51 pm; edited 1 time in total |
|
Back to top |
|
 |
bruce2359 |
Posted: Sun Apr 05, 2020 5:55 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
IMS, COA puttime/putdate are set at (responder) QM2 by the rcvr channel MCA to confirm that the message has arrived. When the COA report message arrives at QM1 (requester), the rcvr channel MCA will put the COA report message to the ReplyToQueue with the date/time set at QM2 - the usual behavior of a rcvr MCA. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
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
|
|
|
|