ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportWait time question and delay in getting messages

Post new topicReply to topic Goto page Previous  1, 2, 3, 4
Wait time question and delay in getting messages View previous topic :: View next topic
Author Message
ucbus1
PostPosted: Wed Aug 08, 2018 9:10 pm Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 553

PeterPotkay wrote:

Are you 1000% sure DataPower is setting the Correlation ID to the value the mainframe app expects for the reply message?
How do you know?

Yes. Because 90% of the messages get processed and picked up. We are finding the messages to appear late and but the mainframe is able to find the messages after the timeout on its second execution. So the app logic works, its the delay that is causing the issue.
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Thu Aug 09, 2018 5:11 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

ucbus1 wrote:

So BATCHINT=0 dictates the COMMITs to happen instantaneously ...(


No. It is up to the application to MQCMIT the messages MQPUT to a queue - this includes a transmission queue.

ucbus1 wrote:
and BATCHSZ parameter only helps in reducing how frequently the COMMITS are happening.
It appears like I am back to square one.


The values of batch size and batchinterval only affect messages sent down an mq channel. They may/will affect throughput of messages, but do not "tell" the upstream message producing app to "hurry up and commit."
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Aug 09, 2018 7:56 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

MQ implements store and forward. A message must be successfully stored (committed) before it can be forwarded. Once committed, your app can no longer affect the message or its delivery.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Aug 09, 2018 9:34 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

ucbus1 wrote:
...but the mainframe is able to find the messages after the timeout on its second execution. So the app logic works, its the delay that is causing the issue.

What timeout? Where do you see evidence of a timeout?

If it's a TCP timeout, this event will have been written to the errors file on the midrange platform, and/or on the CHIN address space syslog on the z/OS mainframe.

2033 ReasonCode is not a timeout. Rather, it means that no message was available to satisfy the MQGET request.

About the mainframe consuming application:

Does the app do only one MQGET with WAITINTERVAL? If, at the end of the waitinterval, does the app try again to MQGET a message? Or, if no message is available, does the app give up trying and end itself?
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
ucbus1
PostPosted: Thu Aug 09, 2018 11:06 am Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 553

bruce2359 wrote:

What timeout? Where do you see evidence of a timeout?

If it's a TCP timeout, this event will have been written to the errors file on the midrange platform, and/or on the CHIN address space syslog on the z/OS mainframe.

2033 ReasonCode is not a timeout. Rather, it means that no message was available to satisfy the MQGET request.

About the mainframe consuming application:

Does the app do only one MQGET with WAITINTERVAL? If, at the end of the waitinterval, does the app try again to MQGET a message? Or, if no message is available, does the app give up trying and end itself?

The timeout is from the app perspective. When the app receives 2033 error code it is what the app says as timeout. The app does a GET with wait interval which we increased it to 4 sec. When it times out it does not try for the message. However there is a secondary clean up process which runs at regular intervals which GETs these response messages. Ideally we want all responses to be processed on the first pass and the clean up process not to find any response messages for processing.
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Thu Aug 09, 2018 11:38 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

ucbus1 wrote:

The timeout is from the app perspective. When the app receives 2033 error code it is what the app says as timeout.

2033 is a ReasonCode indicating no message available. It could be queue is empty OR there was no message that matched the msgid, correlid, groupid specified in the MQMD. 2033 is not an error.
ucbus1 wrote:
The app does a GET with wait interval which we increased it to 4 sec. When it times out it does not try for the message.

So, the app gives up AND ends itself? Does an MQCLOSE and MQDISC?

Waitinterval tells MQ to end the MQGET with Waitinterval after, in your case, 4 seconds. What if the message arrives a millisecond later?

Have you tried to send a message with IBM's supplied utility amqsput from the client platform? Does the message traverse the channel sub-second? If so, it's likely not an MQ imposed delay, is it?
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Aug 09, 2018 3:58 pm Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8128
Location: US: west coast, almost. Otherwise, enroute.

For clarity: MQGET with WAITINTERVAL does not delay the consuming app in MQGETting the message.

If a message already exists in the queue, the MQGET will not wait, and MQ will deliver the message immediately to the app with no wait at all. If a message arrives in one second, the MQGET will end immediately, and MQ will deliver the message to the app immediately.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
ucbus1
PostPosted: Thu Aug 09, 2018 6:13 pm Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 553

Will test and post my findingings
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2, 3, 4 Page 4 of 4

MQSeries.net Forum IndexGeneral IBM MQ SupportWait time question and delay in getting messages
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.