MQ svrconn channels not reporting on lost network connections

Discussion:

Costa, D. (Damian)

2014-02-06 16:47:35 UTC

Hi all,
We've got a situation here where we're testing a scenario on our test bed: Solaris version 11 ( I think)
On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps connect to the qmgr using MQ clients from the other containers on this hardware.

When the Solaris admin disables the network interface on one of the container using mq clients to connect .

So the weird thing is only some of the active channels report a disconnect and some remain in a running state on the qmgr from that container.
Is there some sort of grace period in which these channels will eventually go down or does it depend on whether the application behind them actively tries to perform an MQ task and only then will the rest of these channels go down?

The production scenario is that an application appears not to make a connection to MQ but does not report that it failed to connect. If it is dependent on the MQ Client API to report a loss of connection and the srvconn channels are still in a running state when does the MQ client API in fact become aware that the network rug has been pulled out from under it?

Finally is the heartbeat interval on the svrconn channels even used at all?

Thanks.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Potkay, Peter M (CTO Architecture + Engineering)

2014-02-06 16:52:40 UTC

Permalink

Turn on Keep Alive at the O/S level, and set its value to something more reasonable then the typical default of 2 hours. We go with 15 minutes.
Then tell the QM to use the Keep Alive value (qm.ini file parm).

The QM will then be able to identify orphaned channels (nothing on the other end of the TCP IP socket) and end the channels. You will get a message in your AMQERR01.log when it happens. But it will be a generic error unfortunately. It doesn't mention TCP Keep Alive.

A client channel that is quiet but otherwise has a valid MQ Client on the other end of the socket will not be killed because of Keep Alive.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 11:48 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: MQ svrconn channels not reporting on lost network connections

Hi all,
We've got a situation here where we're testing a scenario on our test bed: Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps connect to the qmgr using MQ clients from the other containers on this hardware.

When the Solaris admin disables the network interface on one of the container using mq clients to connect .

So the weird thing is only some of the active channels report a disconnect and some remain in a running state on the qmgr from that container.
Is there some sort of grace period in which these channels will eventually go down or does it depend on whether the application behind them actively tries to perform an MQ task and only then will the rest of these channels go down?

The production scenario is that an application appears not to make a connection to MQ but does not report that it failed to connect. If it is dependent on the MQ Client API to report a loss of connection and the srvconn channels are still in a running state when does the MQ client API in fact become aware that the network rug has been pulled out from under it?

Finally is the heartbeat interval on the svrconn channels even used at all?

Thanks.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Costa, D. (Damian)

2014-02-06 17:07:27 UTC

Permalink

As in qm.ini :
TCP:
KeepAlive=YES

Ok. The Solaris guys don't want to fiddle with the Keep alive interval at the OS level. I think the keep alive has been activated for some time now but default is still 2 hours.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 06 February 2014 06:53 PM
Subject: Re: MQ svrconn channels not reporting on lost network connections
Turn on Keep Alive at the O/S level, and set its value to something more
reasonable then the typical default of 2 hours. We go with 15 minutes.
Then tell the QM to use the Keep Alive value (qm.ini file parm).
The QM will then be able to identify orphaned channels (nothing on the other
end of the TCP IP socket) and end the channels. You will get a message in your
AMQERR01.log when it happens. But it will be a generic error unfortunately. It
doesn't mention TCP Keep Alive.
A client channel that is quiet but otherwise has a valid MQ Client on the other
end of the socket will not be killed because of Keep Alive.
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 11:48 AM
Subject: MQ svrconn channels not reporting on lost network connections
Hi all,
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps connect to
the qmgr using MQ clients from the other containers on this hardware.
When the Solaris admin disables the network interface on one of the container
using mq clients to connect .
So the weird thing is only some of the active channels report a disconnect and
some remain in a running state on the qmgr from that container.
Is there some sort of grace period in which these channels will eventually go
down or does it depend on whether the application behind them actively tries to
perform an MQ task and only then will the rest of these channels go down?
The production scenario is that an application appears not to make a connection
to MQ but does not report that it failed to connect. If it is dependent on the MQ
Client API to report a loss of connection and the srvconn channels are still in a
running state when does the MQ client API in fact become aware that the
network rug has been pulled out from under it?
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names
of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee
and may contain proprietary, confidential and/or privileged information. If you
are not the intended recipient, any use, copying, disclosure, dissemination or
distribution is strictly prohibited. If you are not the intended recipient, please
notify the sender immediately by return e-mail, delete this communication and
destroy all copies.
************************************************************
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Potkay, Peter M (CTO Architecture + Engineering)

2014-02-06 17:15:15 UTC

Permalink

Do your test again and wait two hours :-)

When you can demonstrate the value this provides, maybe you can get them to lower the value. Yeah, that value applies for all apps on the server, so if multiple things besides MQ share that QM, you all have to agree on what a good value is.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 12:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ svrconn channels not reporting on lost network connections

As in qm.ini :
TCP:
KeepAlive=YES

Ok. The Solaris guys don't want to fiddle with the Keep alive interval at the OS level. I think the keep alive has been activated for some time now but default is still 2 hours.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 06 February 2014 06:53 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Turn on Keep Alive at the O/S level, and set its value to something
more reasonable then the typical default of 2 hours. We go with 15 minutes.
Then tell the QM to use the Keep Alive value (qm.ini file parm).
The QM will then be able to identify orphaned channels (nothing on the
other end of the TCP IP socket) and end the channels. You will get a
message in your AMQERR01.log when it happens. But it will be a generic
error unfortunately. It doesn't mention TCP Keep Alive.
A client channel that is quiet but otherwise has a valid MQ Client on
the other end of the socket will not be killed because of Keep Alive.
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 11:48 AM
Subject: MQ svrconn channels not reporting on lost network connections
Hi all,
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps
connect to the qmgr using MQ clients from the other containers on this hardware.
When the Solaris admin disables the network interface on one of the
container using mq clients to connect .
So the weird thing is only some of the active channels report a
disconnect and some remain in a running state on the qmgr from that container.
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application behind
them actively tries to perform an MQ task and only then will the rest of these channels go down?
The production scenario is that an application appears not to make a
connection to MQ but does not report that it failed to connect. If it
is dependent on the MQ Client API to report a loss of connection and
the srvconn channels are still in a running state when does the MQ
client API in fact become aware that the network rug has been pulled out from under it?
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Tim Zielke

2014-02-06 17:37:54 UTC

Permalink

Since Damian's queue manager is at v7 and v7 uses full duplex for channels, I thought adjusting the HBINT on his SVRCONN channel (or CLNTCONN if the client is v7, as well) would be another way to early detect a communication failure.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, February 06, 2014 11:15 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ svrconn channels not reporting on lost network connections

Do your test again and wait two hours :-)

When you can demonstrate the value this provides, maybe you can get them to lower the value. Yeah, that value applies for all apps on the server, so if multiple things besides MQ share that QM, you all have to agree on what a good value is.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 12:07 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ svrconn channels not reporting on lost network connections

As in qm.ini :
TCP:
KeepAlive=YES

Ok. The Solaris guys don't want to fiddle with the Keep alive interval at the OS level. I think the keep alive has been activated for some time now but default is still 2 hours.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 06 February 2014 06:53 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Turn on Keep Alive at the O/S level, and set its value to something
more reasonable then the typical default of 2 hours. We go with 15 minutes.
Then tell the QM to use the Keep Alive value (qm.ini file parm).
The QM will then be able to identify orphaned channels (nothing on the
other end of the TCP IP socket) and end the channels. You will get a
message in your AMQERR01.log when it happens. But it will be a generic
error unfortunately. It doesn't mention TCP Keep Alive.
A client channel that is quiet but otherwise has a valid MQ Client on
the other end of the socket will not be killed because of Keep Alive.
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 11:48 AM
Subject: MQ svrconn channels not reporting on lost network connections
Hi all,
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps
connect to the qmgr using MQ clients from the other containers on this hardware.
When the Solaris admin disables the network interface on one of the
container using mq clients to connect .
So the weird thing is only some of the active channels report a
disconnect and some remain in a running state on the qmgr from that container.
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application behind
them actively tries to perform an MQ task and only then will the rest of these channels go down?
The production scenario is that an application appears not to make a
connection to MQ but does not report that it failed to connect. If it
is dependent on the MQ Client API to report a loss of connection and
the srvconn channels are still in a running state when does the MQ
client API in fact become aware that the network rug has been pulled out from under it?
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Costa, D. (Damian)

2014-02-07 11:07:09 UTC

Permalink

Hi,
we have those settings but it doesn't appear to have made any difference. We're using full duplex and hbint at default of 300.
So what I'm understanding is that only after 2 hours will the client report a loss of connectivity to the qmgr?
Even if it actively polls a queue within that 2 hours interval?
That doesn't sound right to me at all. surely the MQ client API should report a loss of MQ connectivity even if it doesn't pick up a network issue.

Dazed and confused.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Tim Zielke
Sent: 06 February 2014 07:38 PM
Subject: Re: MQ svrconn channels not reporting on lost network connections
Since Damian's queue manager is at v7 and v7 uses full duplex for channels, I
thought adjusting the HBINT on his SVRCONN channel (or CLNTCONN if the
client is v7, as well) would be another way to early detect a communication
failure.
Thanks,
Tim
-----Original Message-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, February 06, 2014 11:15 AM
Subject: Re: MQ svrconn channels not reporting on lost network connections
Do your test again and wait two hours :-)
When you can demonstrate the value this provides, maybe you can get them to
lower the value. Yeah, that value applies for all apps on the server, so if multiple
things besides MQ share that QM, you all have to agree on what a good value is.
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 12:07 PM
Subject: Re: MQ svrconn channels not reporting on lost network connections
KeepAlive=YES
Ok. The Solaris guys don't want to fiddle with the Keep alive interval at the OS
level. I think the keep alive has been activated for some time now but default is
still 2 hours.

hardware.

Post by Potkay, Peter M (CTO Architecture + Engineering)
When the Solaris admin disables the network interface on one of the
container using mq clients to connect .
So the weird thing is only some of the active channels report a
disconnect and some remain in a running state on the qmgr from that

container.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application behind
them actively tries to perform an MQ task and only then will the rest of these

channels go down?

Post by Potkay, Peter M (CTO Architecture + Engineering)
The production scenario is that an application appears not to make a
connection to MQ but does not report that it failed to connect. If it
is dependent on the MQ Client API to report a loss of connection and
the srvconn channels are still in a running state when does the MQ
client API in fact become aware that the network rug has been pulled out from

under it?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return e-mail, delete this communication and destroy all

copies.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names
of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee
and may contain proprietary, confidential and/or privileged information. If you
are not the intended recipient, any use, copying, disclosure, dissemination or
distribution is strictly prohibited. If you are not the intended recipient, please
notify the sender immediately by return e-mail, delete this communication and
destroy all copies.
************************************************************
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Costa, D. (Damian)

2014-02-07 11:10:20 UTC

Permalink

Accept-Language: en-ZA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.59.4.242]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Feb 2014 11:10:21.0115 (UTC) FILETIME=[30E298B0:01CF23F5]
Content-Transfer-Encoding: quoted-printable
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2014.2.7.110020
X-PMX-Spam: Gauge= Probability=8%, Report='
AT_TLD 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_10000_PLUS 0, URI_ENDS_IN_HTML 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BADTHINGS 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_XOAT 0, __HAS_XOIP 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_FROM 0, __PHISH_FROM1 0, __PHISH_FROM2 0, __PHISH_FROM_N 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NS '

Also would the MQ application be thread safe at v 7.0.1.3. yes/no?
And if they use an MQ client with threads as well?

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
From: Costa, D. (Damian)
Sent: 07 February 2014 01:07 PM
Subject: RE: MQ svrconn channels not reporting on lost network connections
=
Hi,
we have those settings but it doesn't appear to have made any difference.
We're using full duplex and hbint at default of 300.
So what I'm understanding is that only after 2 hours will the client repo=

rt a loss

Post by Potkay, Peter M (CTO Architecture + Engineering)
of connectivity to the qmgr?
Even if it actively polls a queue within that 2 hours interval?
That doesn't sound right to me at all. surely the MQ client API should=

report a

Post by Potkay, Peter M (CTO Architecture + Engineering)
loss of MQ connectivity even if it doesn't pick up a network issue.
=
Dazed and confused.
=

agree

Post by Potkay, Peter M (CTO Architecture + Engineering)
on what a good value is.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 12:07 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
KeepAlive=3DYES
Ok. The Solaris guys don't want to fiddle with the Keep alive interval
at the OS level. I think the keep alive has been activated for some
time now but default is still 2 hours.

nutes.

Post by Potkay, Peter M (CTO Architecture + Engineering)

Post by Potkay, Peter M (CTO Architecture + Engineering)
Then tell the QM to use the Keep Alive value (qm.ini file parm).
The QM will then be able to identify orphaned channels (nothing on
the other end of the TCP IP socket) and end the channels. You will
get a message in your AMQERR01.log when it happens. But it will be a
generic error unfortunately. It doesn't mention TCP Keep Alive.
A client channel that is quiet but otherwise has a valid MQ Client
on the other end of the socket will not be killed because of Keep Ali=

ve.

Post by Potkay, Peter M (CTO Architecture + Engineering)

Post by Potkay, Peter M (CTO Architecture + Engineering)
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 11:48 AM
Subject: MQ svrconn channels not reporting on lost network
connections
Hi all,
We've got a situation here where we're testing a scenario on our tes=
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the
apps connect to the qmgr using MQ clients from the other containers
on this

hardware.

container.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application
behind them actively tries to perform an MQ task and only then will
the rest of these

channels go down?

Post by Potkay, Peter M (CTO Architecture + Engineering)
The production scenario is that an application appears not to make a
connection to MQ but does not report that it failed to connect. If
it is dependent on the MQ Client API to report a loss of connection
and the srvconn channels are still in a running state when does the
MQ client API in fact become aware that the network rug has been
pulled out from

under it?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Finally is the heartbeat interval on the svrconn channels even used a=

t all?

Post by Potkay, Peter M (CTO Architecture + Engineering)

Post by Potkay, Peter M (CTO Architecture + Engineering)
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use
of addressee and may contain proprietary, confidential and/or
privileged information. If you are not the intended recipient, any
use, copying, disclosure, dissemination or distribution is strictly
prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication
and destroy all

copies.

Post by Potkay, Peter M (CTO Architecture + Engineering)
************************************************************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Schanz, Arthur

2014-02-07 11:40:06 UTC

Permalink

Damian -

Are all of the connections using the same NIC? Perhaps the connections that are not failing are utilizing a different logical IP that resolves to a different NIC.

Regards,
Art

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 6:07 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ svrconn channels not reporting on lost network connections

Hi,
we have those settings but it doesn't appear to have made any difference. We're using full duplex and hbint at default of 300.
So what I'm understanding is that only after 2 hours will the client report a loss of connectivity to the qmgr?
Even if it actively polls a queue within that 2 hours interval?
That doesn't sound right to me at all. surely the MQ client API should report a loss of MQ connectivity even if it doesn't pick up a network issue.

Dazed and confused.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Tim Zielke
Sent: 06 February 2014 07:38 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Since Damian's queue manager is at v7 and v7 uses full duplex for
channels, I thought adjusting the HBINT on his SVRCONN channel (or
CLNTCONN if the client is v7, as well) would be another way to early
detect a communication failure.
Thanks,
Tim
-----Original Message-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, February 06, 2014 11:15 AM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Do your test again and wait two hours :-)
When you can demonstrate the value this provides, maybe you can get
them to lower the value. Yeah, that value applies for all apps on the
server, so if multiple things besides MQ share that QM, you all have to agree on what a good value is.
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 12:07 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
KeepAlive=YES
Ok. The Solaris guys don't want to fiddle with the Keep alive interval
at the OS level. I think the keep alive has been activated for some
time now but default is still 2 hours.

hardware.

container.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application
behind them actively tries to perform an MQ task and only then will
the rest of these

channels go down?

Post by Potkay, Peter M (CTO Architecture + Engineering)
The production scenario is that an application appears not to make a
connection to MQ but does not report that it failed to connect. If
it is dependent on the MQ Client API to report a loss of connection
and the srvconn channels are still in a running state when does the
MQ client API in fact become aware that the network rug has been
pulled out from

under it?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use
of addressee and may contain proprietary, confidential and/or
privileged information. If you are not the intended recipient, any
use, copying, disclosure, dissemination or distribution is strictly
prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication
and destroy all

copies.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Costa, D. (Damian)

2014-02-07 12:10:55 UTC

Permalink

Hi art,
Same NIC, all connects are cleared on the qmgr side in 5 minutes after the network interface is stopped. So the qmgr side of the conversation is operating as expected.
We're trying to determine if the MQ client side of the connection is behaving as expected ie that the qmgr is no longer available.
I started a generic MQ trace on the MQ client container, not sure if this is going to show anything.

Is it even possible to run an MQ trace on the client side?

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Schanz, Arthur
Sent: 07 February 2014 01:40 PM
Subject: Re: MQ svrconn channels not reporting on lost network connections
Damian -
Are all of the connections using the same NIC? Perhaps the connections that
are not failing are utilizing a different logical IP that resolves to a different NIC.
Regards,
Art
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 6:07 AM
Subject: Re: MQ svrconn channels not reporting on lost network connections
Hi,
we have those settings but it doesn't appear to have made any difference.
We're using full duplex and hbint at default of 300.
So what I'm understanding is that only after 2 hours will the client report a loss
of connectivity to the qmgr?
Even if it actively polls a queue within that 2 hours interval?
That doesn't sound right to me at all. surely the MQ client API should report a
loss of MQ connectivity even if it doesn't pick up a network issue.
Dazed and confused.

on what a good value is.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 12:07 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
KeepAlive=YES
Ok. The Solaris guys don't want to fiddle with the Keep alive interval
at the OS level. I think the keep alive has been activated for some
time now but default is still 2 hours.

hardware.

container.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application
behind them actively tries to perform an MQ task and only then will
the rest of these

channels go down?

Post by Potkay, Peter M (CTO Architecture + Engineering)
The production scenario is that an application appears not to make a
connection to MQ but does not report that it failed to connect. If
it is dependent on the MQ Client API to report a loss of connection
and the srvconn channels are still in a running state when does the
MQ client API in fact become aware that the network rug has been
pulled out from

under it?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use
of addressee and may contain proprietary, confidential and/or
privileged information. If you are not the intended recipient, any
use, copying, disclosure, dissemination or distribution is strictly
prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication
and destroy all

copies.

Potkay, Peter M (CTO Architecture + Engineering)

2014-02-07 12:43:20 UTC

Permalink

At MQ 7.0.1, Heartbeats can flow at any and all times if the MQ Client channel is running in full duplex mode. AND both ends of the connection are at MQ 7.0.1.

Are these MQ Clients 7.0.1 or newer?
Is the value of SHARECNV on the SVRCONN channel 1 or greater?

A. Unless both of these are true, you will only be getting heart beats when the MQ Client is in a MQGET with wait.
B. If both of these are true, you should be getting heart beats constantly (based on the HBINT values negotiated between the client and the QM - make sure you understand the nuances here as well).

TCP Keep Alive could/should be set in either case, but it will likely be the only thing that kicks in to clean up orphaned client connections in scenario A.

We enabled Keep Alive for our QMs at 15 minutes about 7 or 8 years ago. Prior to that we constantly struggled with buttloads of old connections using up our MaxActiveChannel count. After that, no problems.

Before someone else mentions it, ClientIdle. Yeah, you could set that at x minutes. Problem is that kills legitimate but quiet client connections the same as truly orphaned connections - it's a connection pool's worst enemy.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 7:11 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ svrconn channels not reporting on lost network connections

Hi art,
Same NIC, all connects are cleared on the qmgr side in 5 minutes after the network interface is stopped. So the qmgr side of the conversation is operating as expected.
We're trying to determine if the MQ client side of the connection is behaving as expected ie that the qmgr is no longer available.
I started a generic MQ trace on the MQ client container, not sure if this is going to show anything.

Is it even possible to run an MQ trace on the client side?

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Schanz, Arthur
Sent: 07 February 2014 01:40 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Damian -
Are all of the connections using the same NIC? Perhaps the
connections that are not failing are utilizing a different logical IP that resolves to a different NIC.
Regards,
Art
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 6:07 AM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Hi,
we have those settings but it doesn't appear to have made any difference.
We're using full duplex and hbint at default of 300.
So what I'm understanding is that only after 2 hours will the client
report a loss of connectivity to the qmgr?
Even if it actively polls a queue within that 2 hours interval?
That doesn't sound right to me at all. surely the MQ client API should report a
loss of MQ connectivity even if it doesn't pick up a network issue.
Dazed and confused.

on what a good value is.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 12:07 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
KeepAlive=YES
Ok. The Solaris guys don't want to fiddle with the Keep alive
interval at the OS level. I think the keep alive has been activated
for some time now but default is still 2 hours.

hardware.

Post by Potkay, Peter M (CTO Architecture + Engineering)
When the Solaris admin disables the network interface on one of
the container using mq clients to connect .
So the weird thing is only some of the active channels report a
disconnect and some remain in a running state on the qmgr from
that

container.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application
behind them actively tries to perform an MQ task and only then
will the rest of these

channels go down?

Post by Potkay, Peter M (CTO Architecture + Engineering)
The production scenario is that an application appears not to make
a connection to MQ but does not report that it failed to connect.
If it is dependent on the MQ Client API to report a loss of
connection and the srvconn channels are still in a running state
when does the MQ client API in fact become aware that the network
rug has been pulled out from

under it?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive
use of addressee and may contain proprietary, confidential and/or
privileged information. If you are not the intended recipient,
any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient,
please notify the sender immediately by return e-mail, delete this
communication and destroy all

copies.

Post by Potkay, Peter M (CTO Architecture + Engineering)
************************************************************
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

copies.

Post by Potkay, Peter M (CTO Architecture + Engineering)
************************************************************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Costa, D. (Damian)

2014-02-07 13:32:14 UTC

Permalink

HI Peter,
Shareconv =1 on the srvconn chl.
Both the qmgr and MQ client are at v7.0.1.3.

We've done some more testing by downing the network Interface and then the MQ client does report a 2009.
The app behind the client reports the errors and "terminates" the MQ connection , BUT the app remains active.
My suspicion is that their shutdown scripts are not terminating the app just terminating the MQ connection. Which appears to be the case as the support personnel confirm that this app is up and active when the end of day is run . Once End of day is complete the system is restarted.
I personally think the issue is the way the app is stopped and restarted and the manner in which it handles the MQ connection.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 07 February 2014 02:43 PM
Subject: Re: MQ svrconn channels not reporting on lost network connections
At MQ 7.0.1, Heartbeats can flow at any and all times if the MQ Client channel is
running in full duplex mode. AND both ends of the connection are at MQ 7.0.1.
Are these MQ Clients 7.0.1 or newer?
Is the value of SHARECNV on the SVRCONN channel 1 or greater?
A. Unless both of these are true, you will only be getting heart beats when the
MQ Client is in a MQGET with wait.
B. If both of these are true, you should be getting heart beats constantly (based
on the HBINT values negotiated between the client and the QM - make sure you
understand the nuances here as well).
TCP Keep Alive could/should be set in either case, but it will likely be the only
thing that kicks in to clean up orphaned client connections in scenario A.
We enabled Keep Alive for our QMs at 15 minutes about 7 or 8 years ago. Prior
to that we constantly struggled with buttloads of old connections using up our
MaxActiveChannel count. After that, no problems.
Before someone else mentions it, ClientIdle. Yeah, you could set that at x
minutes. Problem is that kills legitimate but quiet client connections the same as
truly orphaned connections - it's a connection pool's worst enemy.
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 7:11 AM
Subject: Re: MQ svrconn channels not reporting on lost network connections
Hi art,
Same NIC, all connects are cleared on the qmgr side in 5 minutes after the
network interface is stopped. So the qmgr side of the conversation is operating
as expected.
We're trying to determine if the MQ client side of the connection is behaving as
expected ie that the qmgr is no longer available.
I started a generic MQ trace on the MQ client container, not sure if this is going
to show anything.
Is it even possible to run an MQ trace on the client side?

to a different NIC.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Regards,
Art
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 6:07 AM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Hi,
we have those settings but it doesn't appear to have made any difference.
We're using full duplex and hbint at default of 300.
So what I'm understanding is that only after 2 hours will the client
report a loss of connectivity to the qmgr?
Even if it actively polls a queue within that 2 hours interval?
That doesn't sound right to me at all. surely the MQ client API should report a
loss of MQ connectivity even if it doesn't pick up a network issue.
Dazed and confused.

on what a good value is.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 12:07 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
KeepAlive=YES
Ok. The Solaris guys don't want to fiddle with the Keep alive
interval at the OS level. I think the keep alive has been activated
for some time now but default is still 2 hours.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----

Post by Potkay, Peter M (CTO Architecture + Engineering)

Post by Potkay, Peter M (CTO Architecture + Engineering)
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 06 February 2014 06:53 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Turn on Keep Alive at the O/S level, and set its value to
something more reasonable then the typical default of 2 hours. We go with

15 minutes.

Post by Potkay, Peter M (CTO Architecture + Engineering)

Post by Potkay, Peter M (CTO Architecture + Engineering)
Then tell the QM to use the Keep Alive value (qm.ini file parm).
The QM will then be able to identify orphaned channels (nothing on
the other end of the TCP IP socket) and end the channels. You will
get a message in your AMQERR01.log when it happens. But it will be
a generic error unfortunately. It doesn't mention TCP Keep Alive.
A client channel that is quiet but otherwise has a valid MQ Client
on the other end of the socket will not be killed because of Keep Alive.
Peter Potkay
-----Original Message-----

Post by Potkay, Peter M (CTO Architecture + Engineering)

Post by Potkay, Peter M (CTO Architecture + Engineering)
Behalf Of Costa, D. (Damian)
Sent: Thursday, February 06, 2014 11:48 AM
Subject: MQ svrconn channels not reporting on lost network connections
Hi all,
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the
apps connect to the qmgr using MQ clients from the other
containers on this

hardware.

Post by Potkay, Peter M (CTO Architecture + Engineering)
When the Solaris admin disables the network interface on one of
the container using mq clients to connect .
So the weird thing is only some of the active channels report a
disconnect and some remain in a running state on the qmgr from
that

container.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application
behind them actively tries to perform an MQ task and only then
will the rest of these

channels go down?

Post by Potkay, Peter M (CTO Architecture + Engineering)
The production scenario is that an application appears not to make
a connection to MQ but does not report that it failed to connect.
If it is dependent on the MQ Client API to report a loss of
connection and the srvconn channels are still in a running state
when does the MQ client API in fact become aware that the network
rug has been pulled out from

under it?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive
use of addressee and may contain proprietary, confidential and/or
privileged information. If you are not the intended recipient,
any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient,
please notify the sender immediately by return e-mail, delete this
communication and destroy all

copies.

Post by Potkay, Peter M (CTO Architecture + Engineering)
************************************************************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names
of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee
and may contain proprietary, confidential and/or privileged information. If you
are not the intended recipient, any use, copying, disclosure, dissemination or
distribution is strictly prohibited. If you are not the intended recipient, please
notify the sender immediately by return e-mail, delete this communication and
destroy all copies.
************************************************************
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Meekin, Paul

2014-02-07 12:23:25 UTC

Permalink

Hi Damian,

Are you sure the clients are at 7.0.1? Are all the containers using the same version of MQ and the apps aren't using their own bundled MQ jar files etc?

Cheers,
Paul

_______________________________________

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: 06 February 2014 16:48
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: MQ svrconn channels not reporting on lost network connections

Hi all,
We've got a situation here where we're testing a scenario on our test bed: Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps connect to the qmgr using MQ clients from the other containers on this hardware.

When the Solaris admin disables the network interface on one of the container using mq clients to connect .

So the weird thing is only some of the active channels report a disconnect and some remain in a running state on the qmgr from that container.
Is there some sort of grace period in which these channels will eventually go down or does it depend on whether the application behind them actively tries to perform an MQ task and only then will the rest of these channels go down?

The production scenario is that an application appears not to make a connection to MQ but does not report that it failed to connect. If it is dependent on the MQ Client API to report a loss of connection and the srvconn channels are still in a running state when does the MQ client API in fact become aware that the network rug has been pulled out from under it?

Finally is the heartbeat interval on the svrconn channels even used at all?

Thanks.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Costa, D. (Damian)

2014-02-07 14:42:00 UTC

Permalink

Not certain at all,
But I think the java MQ libs are all at V7.0 or better as we found a serious channel explosion issue about 3-4 years ago where they had to update the MQ client adapter shipped with the WAS that runs some of the stuff.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Meekin, Paul
Sent: 07 February 2014 02:23 PM
Subject: Re: MQ svrconn channels not reporting on lost network connections
Hi Damian,
Are you sure the clients are at 7.0.1? Are all the containers using the same
version of MQ and the apps aren't using their own bundled MQ jar files etc?
Cheers,
Paul
_______________________________________
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: 06 February 2014 16:48
Subject: MQ svrconn channels not reporting on lost network connections
Hi all,
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps connect to
the qmgr using MQ clients from the other containers on this hardware.
When the Solaris admin disables the network interface on one of the container
using mq clients to connect .
So the weird thing is only some of the active channels report a disconnect and
some remain in a running state on the qmgr from that container.
Is there some sort of grace period in which these channels will eventually go
down or does it depend on whether the application behind them actively tries to
perform an MQ task and only then will the rest of these channels go down?
The production scenario is that an application appears not to make a connection
to MQ but does not report that it failed to connect. If it is dependent on the MQ
Client API to report a loss of connection and the srvconn channels are still in a
running state when does the MQ client API in fact become aware that the
network rug has been pulled out from under it?
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names
of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Tim Zielke

2014-02-07 15:28:27 UTC

Permalink

Hi Damian,

A few tips on finding out what version the MQ client jars are at, in case you were not aware.

You can use the jar command to pull out the manifest information from the jar. That will have the MQ version in it.

Example:
jar xvf com.ibm.mq.jmqi.jar META-INF/MANIFEST.MF

You also mentioned this is Solaris. If you have access, you can do a pfiles on the running application pid to see what jar files are currently opened by the process, in case that helps in the investigation.

Thanks,
Tim

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 8:42 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ svrconn channels not reporting on lost network connections

Not certain at all,
But I think the java MQ libs are all at V7.0 or better as we found a serious channel explosion issue about 3-4 years ago where they had to update the MQ client adapter shipped with the WAS that runs some of the stuff.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Meekin, Paul
Sent: 07 February 2014 02:23 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Hi Damian,
Are you sure the clients are at 7.0.1? Are all the containers using
the same version of MQ and the apps aren't using their own bundled MQ jar files etc?
Cheers,
Paul
_______________________________________
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: 06 February 2014 16:48
Subject: MQ svrconn channels not reporting on lost network connections
Hi all,
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps
connect to the qmgr using MQ clients from the other containers on this hardware.
When the Solaris admin disables the network interface on one of the
container using mq clients to connect .
So the weird thing is only some of the active channels report a
disconnect and some remain in a running state on the qmgr from that container.
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application behind
them actively tries to perform an MQ task and only then will the rest of these channels go down?
The production scenario is that an application appears not to make a
connection to MQ but does not report that it failed to connect. If it
is dependent on the MQ Client API to report a loss of connection and
the srvconn channels are still in a running state when does the MQ
client API in fact become aware that the network rug has been pulled out from under it?
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Potkay, Peter M (CTO Architecture + Engineering)

2014-02-07 15:30:05 UTC

Permalink

You might want to do a test with a new SVRCONN channel and a client whose MQ version you are sure of and whose HBINT settings you are sure of (i.e amqsputc on a PC you control laptop using a channel table you built).

Establish the connection to this new channel, pull the network cable out of that PC, then watch the SVRCONN channel instance on the QM. It should go away according to the heartbeat rules.

This testing method is how we proved TYCP Keep Alive worked before we rolled with it.

Relying on just killing a process in Task manager to simulate the app 'going away' yielded some interesting and different results based on whether it was Java, or C, or VB, etc. Some would manage to spew an MQDISC as a last gasp, even though we killed the process, making the channel end normally even though we killed the app.

Yanking the cable was the surest most consistent test.

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 9:42 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ svrconn channels not reporting on lost network connections

Not certain at all,
But I think the java MQ libs are all at V7.0 or better as we found a serious channel explosion issue about 3-4 years ago where they had to update the MQ client adapter shipped with the WAS that runs some of the stuff.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Meekin, Paul
Sent: 07 February 2014 02:23 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Hi Damian,
Are you sure the clients are at 7.0.1? Are all the containers using
the same version of MQ and the apps aren't using their own bundled MQ jar files etc?
Cheers,
Paul
_______________________________________
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: 06 February 2014 16:48
Subject: MQ svrconn channels not reporting on lost network connections
Hi all,
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps
connect to the qmgr using MQ clients from the other containers on this hardware.
When the Solaris admin disables the network interface on one of the
container using mq clients to connect .
So the weird thing is only some of the active channels report a
disconnect and some remain in a running state on the qmgr from that container.
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application behind
them actively tries to perform an MQ task and only then will the rest of these channels go down?
The production scenario is that an application appears not to make a
connection to MQ but does not report that it failed to connect. If it
is dependent on the MQ Client API to report a loss of connection and
the srvconn channels are still in a running state when does the MQ
client API in fact become aware that the network rug has been pulled out from under it?
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Costa, D. (Damian)

2014-02-07 15:35:28 UTC

Permalink

We yanked the network interface and all connections dropped . The application on the other hand only terminated its MQ connection and not itself and hung around twiddling it's thumbs. So when the restart scripts come around it's already running, doesn't restart, and definitely doesn't re-establish the MQ connections.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 07 February 2014 05:30 PM
Subject: Re: MQ svrconn channels not reporting on lost network connections
You might want to do a test with a new SVRCONN channel and a client whose
MQ version you are sure of and whose HBINT settings you are sure of (i.e
amqsputc on a PC you control laptop using a channel table you built).
Establish the connection to this new channel, pull the network cable out of that
PC, then watch the SVRCONN channel instance on the QM. It should go away
according to the heartbeat rules.
This testing method is how we proved TYCP Keep Alive worked before we rolled
with it.
Relying on just killing a process in Task manager to simulate the app 'going
away' yielded some interesting and different results based on whether it was
Java, or C, or VB, etc. Some would manage to spew an MQDISC as a last gasp,
even though we killed the process, making the channel end normally even
though we killed the app.
Yanking the cable was the surest most consistent test.
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 9:42 AM
Subject: Re: MQ svrconn channels not reporting on lost network connections
Not certain at all,
But I think the java MQ libs are all at V7.0 or better as we found a serious
channel explosion issue about 3-4 years ago where they had to update the MQ
client adapter shipped with the WAS that runs some of the stuff.

files etc?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Cheers,
Paul
_______________________________________
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: 06 February 2014 16:48
Subject: MQ svrconn channels not reporting on lost network connections
Hi all,
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the apps
connect to the qmgr using MQ clients from the other containers on this

hardware.

container.

channels go down?

under it?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the names
of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of addressee
and may contain proprietary, confidential and/or privileged information. If you
are not the intended recipient, any use, copying, disclosure, dissemination or
distribution is strictly prohibited. If you are not the intended recipient, please
notify the sender immediately by return e-mail, delete this communication and
destroy all copies.
************************************************************
message body (not the subject), write: SIGNOFF MQSERIES Instructions for
managing your mailing list subscription are provided in the Listserv General
Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

Potkay, Peter M (CTO Architecture + Engineering)

2014-02-07 15:39:53 UTC

Permalink

Huh, I wonder if when its twiddling its thumbs its also rocking back on its heels and snapping its suspenders, admiring its connection pool of MQ Client Connections to the QM it chose not to end. If that's the case, those are valid MQ Client connections that would not be touched by TCP Keep Alive. And would continue to send heartbeats if both ends are in fact 7.0.1+

Peter Potkay

-----Original Message-----
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 10:35 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ svrconn channels not reporting on lost network connections

We yanked the network interface and all connections dropped . The application on the other hand only terminated its MQ connection and not itself and hung around twiddling it's thumbs. So when the restart scripts come around it's already running, doesn't restart, and definitely doesn't re-establish the MQ connections.

Post by Potkay, Peter M (CTO Architecture + Engineering)
-----Original Message-----
Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: 07 February 2014 05:30 PM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
You might want to do a test with a new SVRCONN channel and a client
whose MQ version you are sure of and whose HBINT settings you are sure
of (i.e amqsputc on a PC you control laptop using a channel table you built).
Establish the connection to this new channel, pull the network cable
out of that PC, then watch the SVRCONN channel instance on the QM. It
should go away according to the heartbeat rules.
This testing method is how we proved TYCP Keep Alive worked before we
rolled with it.
Relying on just killing a process in Task manager to simulate the app
'going away' yielded some interesting and different results based on
whether it was Java, or C, or VB, etc. Some would manage to spew an
MQDISC as a last gasp, even though we killed the process, making the
channel end normally even though we killed the app.
Yanking the cable was the surest most consistent test.
Peter Potkay
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Friday, February 07, 2014 9:42 AM
Subject: Re: MQ svrconn channels not reporting on lost network
connections
Not certain at all,
But I think the java MQ libs are all at V7.0 or better as we found a
serious channel explosion issue about 3-4 years ago where they had to
update the MQ client adapter shipped with the WAS that runs some of the stuff.

files etc?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Cheers,
Paul
_______________________________________
-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: 06 February 2014 16:48
Subject: MQ svrconn channels not reporting on lost network
connections
Hi all,
Solaris version 11 ( I think) On p11 hardware.
Got a number of containers one runs the qmgr at V 7.0.1.3 , the
apps connect to the qmgr using MQ clients from the other containers
on this

hardware.

container.

Post by Potkay, Peter M (CTO Architecture + Engineering)
Is there some sort of grace period in which these channels will
eventually go down or does it depend on whether the application
behind them actively tries to perform an MQ task and only then will
the rest of these

channels go down?

Post by Potkay, Peter M (CTO Architecture + Engineering)
The production scenario is that an application appears not to make a
connection to MQ but does not report that it failed to connect. If
it is dependent on the MQ Client API to report a loss of connection
and the srvconn channels are still in a running state when does the
MQ client API in fact become aware that the network rug has been
pulled out from

under it?

Post by Potkay, Peter M (CTO Architecture + Engineering)
Finally is the heartbeat interval on the svrconn channels even used at all?
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email
is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at
http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided
in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html