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, 5  Next
Wait time question and delay in getting messages View previous topic :: View next topic
Author Message
PeterPotkay
PostPosted: Mon Aug 06, 2018 4:28 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7463

ucbus1 wrote:
few more updates on the application.

1.mainframe puts a request on a queue.
2. Datapower's front side handler takes the message and hands it over to a back end process via Multi protocol gateway (MPGW)
3. The response from back end process is received by the Datapower and the response is put on the mainframe response queue .The response queue is indexed on correlation id. Mainframe picks up the message using correlation id
4. The front side handlers of the datapower use "units of work"="1" on MQ queue manager object. I believe this setting should make messages put by datapower on COMMIT.
While getting the message from mainframe, datapower does not encounter any timeout issues. However when the response is sent by datapower, mainframe is timing out on Getting the message.

@belchman, I will try to get more info and provide the input


Are you 1000% sure DataPower is setting the Correlation ID to the value the mainframe app expects for the reply message?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Aug 06, 2018 4:31 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7463

gbaddeley wrote:
2 secs is quite a short WaitInterval, for any MQ interface. Try increasing it to 60 secs to make it easier to diagnose.

For a mainframe IMS application a short get with wait is not odd in my experience. Otherwise you have IMS TCODEs blocking and waiting.....and waiting.....and waiting for the MQGET that will just 2033 eventually anyway. Oh do the MVS ancients get ornery when that happens.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Aug 06, 2018 5:20 pm Post subject: Reply with quote

Poobah

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

PeterPotkay wrote:
ucbus1 wrote:
On a different thought. could this be due to low batcsz parameter cluster receiver channel. It is currently set to 50 which I believe is default.

Could this Batchsize parm is the issue? What is criteria and ideal value to set this Batchsize parameter?

Probably not the issue unless BATCHINT is also high and there is very little traffic on the channel, causing it to wait until BATCH INTERVAL or BATCH SIZE is met.

What is batchinterval for the the cluster-receiver channel? It is the cluster-receiver channel def that is used to create a CLUSSDRA/B cluster sender channel. The default is zero.
_________________
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: Wed Aug 08, 2018 5:16 am Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 559

The batch interval on the channel is set to ZERO and the batch size is set to "50", I am thinking of suggesting to change to a lower value if it is going to help. How this needs to be tested. Does running dspmqtrn before making the change and after making the change help to identify lag in commits? Please let me know.
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Wed Aug 08, 2018 5:31 am Post subject: Reply with quote

Poobah

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

ucbus1 wrote:
The batch interval on the channel is set to ZERO and the batch size is set to "50", I am thinking of suggesting to change to a lower value if it is going to help. How this needs to be tested. Does running dspmqtrn before making the change and after making the change help to identify lag in commits? Please let me know.

Please be precise. Which channel? What type of channel?
_________________
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: Wed Aug 08, 2018 8:50 am Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 559

Here are the details:
Code:

 CHLTYPE(CLUSRCVR) QSGDISP(QMGR) CLUSTER(xxx-xxx-xxx) CLUSNL() TRPTYPE(TCP) CONNAME(XXXX(4005))
 DESCR() MODENAME() TPNAME() DISCINT(6000) SHORTRTY(10) SHORTTMR(60) LONGRTY( 999999999) LONGTMR(1200)
 SCYEXIT() SCYDATA() MSGEXIT() MSGDATA() SENDEXIT() SENDDATA() RCVEXIT() RCVDATA()
 MREXIT() MRRTY(0) MRTMR(1000) PROPCTL(COMPAT) PUTAUT(DEF) SEQWRAP( 999999999) CONVERT(NO) BATCHINT(0)
 BATCHHB(0) KAINT(AUTO) NETPRTY(0) CLWLRANK(0) CLWLPRTY(0) CLWLWGHT(50) MCATYPE(THREAD) MONCHL(QMGR)
 ALTDATE(xxxx-xx-xx) ALTTIME(xx.xx.xx) SSLCAUTH(REQUIRED  ) SSLCIPH() SSLPEER()
 CERTLABL() BATCHLIM(5000) USEDLQ(YES) STATCHL(QMGR) MCAUSER() LOCLADDR() BATCHSZ(50)
 MAXMSGL(  20971520) COMPHDR(NONE) COMPMSG(NONE) HBINT(300) NPMSPEED(FAST)
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Wed Aug 08, 2018 12:37 pm Post subject: Reply with quote

Poobah

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

ucbus1 wrote:
The batch interval on the channel is set to ZERO and the batch size is set to "50"

Good so far.
ucbus1 wrote:
I am thinking of suggesting to change to a lower value if it is going to help.

It won't. Batchinterval of zero tells the channel to transmit messages as they arrive committed into the transmission queue, and NOT to wait for other messages to complete a batch.
_________________
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: Wed Aug 08, 2018 12:46 pm Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 559

bruce2359 wrote:
ucbus1 wrote:
The batch interval on the channel is set to ZERO and the batch size is set to "50"

Good so far.
ucbus1 wrote:
I am thinking of suggesting to change to a lower value if it is going to help.

It won't. Batchinterval of zero tells the channel to transmit messages as they arrive committed into the transmission queue, and NOT to wait for other messages to complete a batch.


Hmm. This is different from what I have noted on the documentation. https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.ref.con.doc/q081700_.htm
Quote:

You can specify any number of milliseconds, from zero through 999 999 999. The default value is zero.
If you do not specify a batch interval, the batch closes when the number of messages specified in BATCHSZ has been sent or when the transmission queue becomes empty. On lightly loaded channels, where the transmission queue frequently becomes empty the effective batch size might be much smaller than BATCHSZ.


Since BATCHINT is zero, doesn't the batch close when the number of messages specified in BATCHSZ has been sent, in this case "50"? I am confused.
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Wed Aug 08, 2018 1:01 pm Post subject: Reply with quote

Poobah

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

ucbus1 wrote:
Since BATCHINT is zero, doesn't the batch close when the number of messages specified in BATCHSZ has been sent, in this case "50"? I am confused.

No.

You missed the big Note
Quote:
BATCHINT specifies the total amount of time that is spent waiting for messages. It does not include the time spent retrieving messages that are already available on the transmission queue, or the time spent transferring messages.


Quote:
Batch interval (BATCHINT)

This attribute is a period, in milliseconds, during which the channel keeps a batch open even if there are no messages on the transmission queue.


Thus, zero batchinterval effectively tells the sender end of the channel to wait zero milliseconds to close (and send) the batch. In short, send the batch now, don't wait for any other messages to arrive.
_________________
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: Wed Aug 08, 2018 1:28 pm Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 559

I think I am getting confused with BATCHINT and BATCHSZ parameters.

I have been reviewing the threads on this forum:

http://www.mqseries.net/phpBB/viewtopic.php?t=25986
Quote:
Highest speed - batchint 0 batchsz 1 - but every message is committed.
High speed - batchint 0 batchsz xxx - which means if there is a (little) message queueing on the xmitq xxx messages are transfered (committed) in one go. this will save some commits and so some cpu. if there is no queueing on the xmit when using batchsz 0 then this setting has no effekt (except on errors where messages pile up and similiar).


In my case, we find the response messages sent by sending app ( datapower) were not being available for the receiver app( mainframe) and wonder if Commits were not happening immediately after PUT and thought BATCHINt and BATCHSZ parameters were the issue. So BATCHINT=0 dictates the COMMITs to happen instantaneously and BATCHSZ parameter only helps in reducing how frequently the COMMITS are happening.
It appears like I am back to square one.
Back to top
View user's profile Send private message Send e-mail
exerk
PostPosted: Wed Aug 08, 2018 1:41 pm Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5934

ucbus1 wrote:
...So BATCHINT=0 dictates the COMMITs to happen instantaneously and BATCHSZ parameter only helps in reducing how frequently the COMMITS are happening.
It appears like I am back to square one.

Neither of those settings will affect whether or when the application commits messages, they only affect the transmission of messages on the XMITQ that are available to be transmitted, i.e. messages that an application has put on the XMITQ and committed.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Aug 08, 2018 4:20 pm Post subject: Reply with quote

Poobah

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

To eliminate MQ channel as the source of the delay, use amqsput to put msgs to another cluster queue on the same qmgr. Id expect sub-second across the channel.
_________________
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: Wed Aug 08, 2018 4:52 pm Post subject: Reply with quote

Poobah

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

When this odd behavior next occurs, DISPLAY CHATATUS for the affected channel. Display CURRENT and SAVED.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Aug 08, 2018 7:40 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7463

ucbus1 wrote:
bruce2359 wrote:
ucbus1 wrote:
The batch interval on the channel is set to ZERO and the batch size is set to "50"

Good so far.
ucbus1 wrote:
I am thinking of suggesting to change to a lower value if it is going to help.

It won't. Batchinterval of zero tells the channel to transmit messages as they arrive committed into the transmission queue, and NOT to wait for other messages to complete a batch.


Hmm. This is different from what I have noted on the documentation. https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.ref.con.doc/q081700_.htm
Quote:

You can specify any number of milliseconds, from zero through 999 999 999. The default value is zero.
If you do not specify a batch interval, the batch closes when the number of messages specified in BATCHSZ has been sent or when the transmission queue becomes empty. On lightly loaded channels, where the transmission queue frequently becomes empty the effective batch size might be much smaller than BATCHSZ.


Since BATCHINT is zero, doesn't the batch close when the number of messages specified in BATCHSZ has been sent, in this case "50"? I am confused.


BATCHSZ is 50.
BATCHINT is 0.
10 message arrive and are sent, the transmit queue depth becomes zero, the batch is committed and th e10 messages are available right away. Its not going to wait to get to 50. Actually it does wait. It waits exactly BATCHINT seconds, and if that is set to zero seconds....
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Aug 08, 2018 7:42 pm Post subject: Reply with quote

Jedi Council

Joined: 15 May 2001
Posts: 7463

ucbus1 wrote:
few more updates on the application.

1.mainframe puts a request on a queue.
2. Datapower's front side handler takes the message and hands it over to a back end process via Multi protocol gateway (MPGW)
3. The response from back end process is received by the Datapower and the response is put on the mainframe response queue .The response queue is indexed on correlation id. Mainframe picks up the message using correlation id
4. The front side handlers of the datapower use "units of work"="1" on MQ queue manager object. I believe this setting should make messages put by datapower on COMMIT.
While getting the message from mainframe, datapower does not encounter any timeout issues. However when the response is sent by datapower, mainframe is timing out on Getting the message.

@belchman, I will try to get more info and provide the input


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?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2, 3, 4, 5  Next Page 3 of 5

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.