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 » RECEIVER Channel PAUSED State

Post new topic  Reply to topic Goto page Previous  1, 2
 RECEIVER Channel PAUSED State « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Wed Dec 05, 2018 7:11 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

If the RCVR channel is Message Retrying each message in the batch 10 times, across 50 messages in the batch, what does the SNDR see during this time? What does the network seeing during this time? If the answer is nothing, is the SNDR / Network / Firewall treating the connection as dropped, because the RCVR is target locked on its Message Retry work and not frequently enough telling the Sending side to hold on, don't go away?

Pure speculation...need someone with knowledge of the channel internals. Or someone willing to analyze a detailed trace from both ends.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
hughson
PostPosted: Wed Dec 05, 2018 8:29 pm    Post subject: Re: retry settings Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

gsbureau wrote:
The Message retry settings i have shared are the RECEIVER channel settings.
CHLTYPE(RCVR) MRRTY(10) MRTMR(1000)

Wth these settings it could take 185 messages a total of around 30 minutes to get through and onto the DLQ. Each message will cause the channel to go into STATUS(PAUSED) for 10 seconds in total. A Queue Full situation ought to be transitory, so Message Retry will (by default) have 10 attempts, 1000 ms apart at retrying the put to the target queue which was found to be full and then will give up and go to the DLQ.

Meanwhile your SDR channel has sent a batch of 50 messages and is sitting in a receive awaiting an answer back from the RCVR channel as to how it got on with processing that batch of 50 messages. It will sit in that receive-wait for (by default) HBINT + 60 seconds (360 seconds) and then it will time out on the assumption that something bad has happened to the TCP/IP socket and it just hasn't heard about it, and go into retry and make a new connection.

gsbureau wrote:
Below are the errors I could see at both queue managers:

Source Queue Manager:

AMQ9259: Connection timed out from host 'XXXXXX(53303)'.

EXPLANATION:
A connection from host 'XXXXXXX(53303)' over TCP/IP timed out.
ACTION:
The select() [TIMEOUT] 360 seconds call timed out. Check to see why data was
not received in the expected time. Correct the problem. Reconnect the channel,
or wait for a retrying channel to reconnect itself.


Since the time it takes to retry EVERY message in the batch 10 times because the queue is full and staying full, this default receive time out is not long enough to await all this message retry processing and the channel isn't patient enough to ride it out.

Message Retry total time for batch of 50 messages = 500 seconds
Default receive-wait time-out = 360 seconds

Suggest changing Message Retry settings to be for a shorter total timeframe (since you do have a DLQ and thus get a lesser benefit from Message Retry than someone without a DLQ) or even turning it off altogether?

e.g.

Code:
ALTER CHANNEL(DEALS.GLOSSGW) CHLTYPE(RCVR) MRRTY(5) MRTMR(1000)


With above setting, Message Retry total time for batch of 50 messages = 250 seconds < 360 seconds.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
vicks_mq
PostPosted: Tue Dec 18, 2018 1:20 pm    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Didn't hear back from the poster, was curious whether the solution worked for him.

I have myself usually runs into issue with sender/receiver channels but it is mostly due to network, SSL, or the message size being too big.
Never came across this Retry mechanism of channel, it might be a new feature. was not there in earlier versions.
Back to top
View user's profile Send private message
hughson
PostPosted: Tue Dec 18, 2018 1:25 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

vicks_mq wrote:
Never came across this Retry mechanism of channel, it might be a new feature. was not there in earlier versions.

Been around on distributed platforms since V5, added to z/OS a little later, V5.3 or V6 (can't quite remember). It is on by default on all, but if you have channels that were created on z/OS prior to the addition of this feature, it will be turned off on those.

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
vicks_mq
PostPosted: Tue Dec 18, 2018 1:37 pm    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Hi Morag, thanks for quick reply. I didn't notice it probably.
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Tue Dec 18, 2018 1:59 pm    Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

on a separate topic related to SVRCONN channel, when I check the status of channel I see there is a parameter called "msgs", it indicates that the number of MQI calls being made and not exactly the number of MQ data messages has been sent.

Is there a way to know from SVRCONN channel status or any other way to see how many message count is being sent across?

Unfortunately I can't check it from the SENDER channel, because the same SENDER channel is shared by multiple interfaces.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Dec 21, 2018 6:12 am    Post subject: Reply with quote

Poobah

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

vicks_mq wrote:
Unfortunately I can't check it from the SENDER channel, because the same SENDER channel is shared by multiple interfaces.

Huh? What do you mean "shared by multiple interfaces?

A single SENDER channel opens a single xmitq, and transmits messages down the network to a single RECEIVER (or REQUESTER) channel.
_________________
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
exerk
PostPosted: Fri Dec 21, 2018 11:03 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

bruce2359 wrote:
Huh? What do you mean "shared by multiple interfaces?

My assumption is that the OP means a number of different applications use specific QREMOTE objects, all of which reference the same XMITQ.
_________________
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: Fri Dec 21, 2018 11:36 am    Post subject: Reply with quote

Poobah

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

I try not to make those.
_________________
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
PeterPotkay
PostPosted: Fri Dec 21, 2018 2:21 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

bruce2359 wrote:
I try not to make those.



bruce2359 wrote:
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data


Extrapolation requires assumption.
_________________
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 Page 2 of 2

MQSeries.net Forum Index » General IBM MQ Support » RECEIVER Channel PAUSED State
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.