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 Index » General IBM MQ Support » Wait time question and delay in getting messages

Post new topic  Reply 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
ucbus1
PostPosted: Fri Aug 03, 2018 1:22 pm    Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 560

belchman wrote:
From Dr. Google searching on key words datapower mq commit

https://www.ibm.com/support/knowledgecenter/en/SS9H2Y_7.6.0/com.ibm.dp.doc/mq_unitsofwork.html

LOL thanks.
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Fri Aug 03, 2018 3:05 pm    Post subject: Reply with quote

Poobah

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

Is this a new app?

Has it worked before? If it worked before, what has changed?

Does every transaction cause this message delay? Or just some messages?
_________________
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
View user's profile Send private message
ucbus1
PostPosted: Mon Aug 06, 2018 8:03 am    Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 560

On further investigation noticed we were getting message not found error 2033 even when the put time on the message was bit old ,showing that the message was put 10 sec before. This could be a COMMIT issue by the datapower as some of you have suggeted. But the datapower documentation and settings suggest that the COMMIT should have happened immediately after a successful PUT. May open a ticket and see where it leads. if anyone has any further input on the issue please share.
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Mon Aug 06, 2018 8:20 am    Post subject: Reply with quote

Poobah

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

Run a trace on the affected qmgr to confirm whether an MQCMIT took place or not.
_________________
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
View user's profile Send private message
ucbus1
PostPosted: Mon Aug 06, 2018 8:44 am    Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 560

bruce2359 wrote:
Run a trace on the affected qmgr to confirm whether an MQCMIT took place or not.


Thanks. Since this is production queue, will running trace cause any issue?
How about running dspmqtrn?
Back to top
View user's profile Send private message Send e-mail
rammer
PostPosted: Mon Aug 06, 2018 8:55 am    Post subject: Reply with quote

Partisan

Joined: 02 May 2002
Posts: 359
Location: England

ucbus1 wrote:
bruce2359 wrote:
Run a trace on the affected qmgr to confirm whether an MQCMIT took place or not.


Thanks. Since this is production queue, will running trace cause any issue?
How about running dspmqtrn?


IBM quote running trace can cause system to slow down but only by milliseconds. You will only want to put trace on for a minute or so as well due to so much data gathered. ensure you have plenty of space for storage! also review the trace options to ensure you pick the right options for your criteria.
Back to top
View user's profile Send private message
ucbus1
PostPosted: Mon Aug 06, 2018 9:10 am    Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 560

rammer wrote:


IBM quote running trace can cause system to slow down but only by milliseconds. You will only want to put trace on for a minute or so as well due to so much data gathered. ensure you have plenty of space for storage! also review the trace options to ensure you pick the right options for your criteria.


Thanks
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Mon Aug 06, 2018 9:30 am    Post subject: Reply with quote

Poobah

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

Tim Zielke should be along any time now. He’s our resident trace guy.
_________________
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
View user's profile Send private message
ucbus1
PostPosted: Mon Aug 06, 2018 11:26 am    Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 560

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.

From IBM documentation
"Messages arriving at the receiving MCA are placed on the target application queues under syncpoint control. This means that they are not visible to any receiving applications until the commit is performed. If the batch size is large, messages may not be made available to receiving applications for some time which may have a severe impact on the message throughput of the overall system. Because the batch size is so greatly influenced by the message arrival rate on the transmission queue, it is generally recommended to set the Batchsize quite high"

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


Last edited by ucbus1 on Mon Aug 06, 2018 11:29 am; edited 2 times in total
Back to top
View user's profile Send private message Send e-mail
tczielke
PostPosted: Mon Aug 06, 2018 11:27 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

What platform is this trace being run on?
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
ucbus1
PostPosted: Mon Aug 06, 2018 11:28 am    Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 560

tczielke wrote:
What platform is this trace being run on?
Z/OS
Back to top
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Mon Aug 06, 2018 12:32 pm    Post subject: Reply with quote

Poobah

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

ucbus1 wrote:
tczielke wrote:
What platform is this trace being run on?
Z/OS

If z/OS, there's little/no worry about impacting performance.

OP should contact z/OS systems programmer to enable GTF trace.

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.tro.doc/q039640_.html
_________________
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
View user's profile Send private message
tczielke
PostPosted: Mon Aug 06, 2018 12:42 pm    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

On z/OS, some of the monitoring tools (e.g. BMC Mainview) have their own API tracing that you can do, as well.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
ucbus1
PostPosted: Mon Aug 06, 2018 2:56 pm    Post subject: Reply with quote

Knight

Joined: 30 Jan 2002
Posts: 560

bruce2359 wrote:
ucbus1 wrote:
tczielke wrote:
What platform is this trace being run on?
Z/OS

If z/OS, there's little/no worry about impacting performance.

OP should contact z/OS systems programmer to enable GTF trace.

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.tro.doc/q039640_.html


Thank you
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Mon Aug 06, 2018 4:25 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

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

MQSeries.net Forum Index » General IBM MQ Support » Wait 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.