| Author |
Message
|
| pcelari |
 Posted: Mon May 11, 2020 7:34 am Post subject: Server side ReconDelay possible? |
 |
|
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 |
|
 |
| mqrules |
| Posted: Mon May 11, 2020 1:24 pm Post subject: |
|
|
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 |
|
|
| gbaddeley |
| Posted: Mon May 11, 2020 3:16 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| pcelari |
| Posted: Tue May 12, 2020 4:25 am Post subject: |
|
|
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 |
|
|
| pcelari |
| Posted: Tue May 12, 2020 7:19 am Post subject: |
|
|
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 |
|
|
| gbaddeley |
| Posted: Tue May 12, 2020 4:07 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| bruce2359 |
| Posted: Tue May 12, 2020 4:34 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| gbaddeley |
| Posted: Tue May 12, 2020 6:11 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| bruce2359 |
| Posted: Wed May 13, 2020 3:09 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
|
|
