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 SupportServer side ReconDelay possible?

Post new topicReply to topic
Server side ReconDelay possible? View previous topic :: View next topic
Author Message
pcelari
PostPosted: Mon May 11, 2020 7:34 am Post subject: Server side ReconDelay possible? Reply with quote

Chevalier

Joined: 31 Mar 2006
Posts: 411
Location: New York

Greetings...

somewhere in the last releases, "ReconDelay" stanza is introduced to cause a reconnect delay for clients that keeps auto-reconnect.

we have a need for exactly that - letting client connect once every 10 minutes, but would like to enforce it at qmgr side because although we can insert that stanza in the mqclient.ini file, the client can remove it. so it's not enforceable.

Is there a way to do that from the qmgr end? As we all know, there isn't much we can do to ensure client side applications follow common good practices, whose application just keeps connect-put/get-disconnect-connect-put/get-disconnect ... for every single message, or simply drop out without disconnecting, resulting in large number of hanging channel instances until discint kicks in.

So if there is a way for enforcing a connection policy, we'll be in more solid control, and have more leverage in forcing good manners.

Any insight?
_________________
pcelari
-----------------------------------------
- a master of always being a newbie
Back to top
View user's profile Send private message
mqrules
PostPosted: Mon May 11, 2020 1:24 pm Post subject: Reply with quote

Centurion

Joined: 01 Jun 2005
Posts: 100
Location: US

There are certain Client related settings/files/exits etc that will have to be on the Client machine, and mqclient.ini is one of them. Just make sure no one (other than MQ Admins) has write/delete access to it.

Hope this helps.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Mon May 11, 2020 3:16 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

Quote:
... although we can insert that stanza in the mqclient.ini file, the client can remove it. so it's not enforceable. ... As we all know, there isn't much we can do to ensure client side applications follow common good practices, whose application just keeps connect-put/get-disconnect-connect-put/get-disconnect ... for every single message, or simply drop out without disconnecting, resulting in large number of hanging channel instances until discint kicks in.

As MQ administrators, there is a lot we can do to eliminate this unsociable behavior. We have a responisibility to ensure that MQ is used properly, or it will come to bite us big-time down the track. Keep rattling the cage. It may take weeks, months, years. Patience will pay off.

Quote:
we have a need for exactly that - letting client connect once every 10 minutes

What is the requirement? 10 minutes seems a bit excessive.
_________________
Glenn
Back to top
View user's profile Send private message
pcelari
PostPosted: Tue May 12, 2020 4:25 am Post subject: Reply with quote

Chevalier

Joined: 31 Mar 2006
Posts: 411
Location: New York

gbaddeley wrote:
... What is the requirement? 10 minutes seems a bit excessive.


Yes, 3 minutes seems to be more reasonable.

By "rocking the cage" are you saying we should urge IBM to implement something to enforce the delay at SVRCONN end?
_________________
pcelari
-----------------------------------------
- a master of always being a newbie
Back to top
View user's profile Send private message
pcelari
PostPosted: Tue May 12, 2020 7:19 am Post subject: Reply with quote

Chevalier

Joined: 31 Mar 2006
Posts: 411
Location: New York

mqrules wrote:
There are certain Client related settings/files/exits etc that will have to be on the Client machine, and mqclient.ini is one of them. Just make sure no one (other than MQ Admins) has write/delete access to it.


... but if the client is a different organization, how is it possible to prevent them from changing it after the hand-over? to my understanding, server side channel exit is not possible on SVRCONN channels. Is there another way?
_________________
pcelari
-----------------------------------------
- a master of always being a newbie
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Tue May 12, 2020 4:07 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

pcelari wrote:
... but if the client is a different organization, how is it possible to prevent them from changing it after the hand-over? to my understanding, server side channel exit is not possible on SVRCONN channels. Is there another way?

You could make an agreement with them that if they change MQ client settings or access permissions, their application connections may not be supported and may fail. ie. They own the risk and consequences of making unauthorized changes.

Access controls have already been mentioned.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue May 12, 2020 4:34 pm Post subject: Reply with quote

Poobah

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

pcelari wrote:
... to my understanding, server side channel exit is not possible on SVRCONN channels.

SVRCONN channels are server-side, and channel exits are available. Refer to Table 1. Channel exits available for each channel type here: https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q027990_.htm
_________________
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
gbaddeley
PostPosted: Tue May 12, 2020 6:11 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

pcelari wrote:
gbaddeley wrote:
... What is the requirement? 10 minutes seems a bit excessive.

Yes, 3 minutes seems to be more reasonable.


1 minute is not out of the question, however I wouldn't go much lower than that for a connection retry interval. It depends if the app is critical or has real people waiting on its front end.

Quote:
By "rocking the cage" are you saying we should urge IBM to implement something to enforce the delay at SVRCONN end?


No, urge the app owners to fix code that has poor MQ design. It is in their best long term interests, and yours.
_________________
Glenn
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed May 13, 2020 3:09 am Post subject: Reply with quote

Poobah

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

There is often a “terms of use” agreement with the client. Such an agreement specifies that client misbehavior is a violation, and subject to some kind of disciplinary action by the service provider.

One of my clients added a CHLAUTH rule to ban the offending client from accessing the channel. Was a bit of political push back, but the server side won it.
_________________
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
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportServer side ReconDelay possible?
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.