WAS8 application spinning up a lot of SVRCONN channels to MQ

[Barton, Linda]

Hi Folks,
I currently have a prod application (WAS 8.0.0.6) that connects to my QMgrs using SRCONN channels. It is only putting messages to ONE queue. There have been response time issues since March 9th. When I check the channel status for the application, I see over 100 SVRCONNS running. The application PUTs to an Alias queue on this server which then sends it to a backend server where the receiving application resides. The application READING the messages is not reporting higher response times. It is the application PUTTING the messages that is. Also, there is no request-reply model, it is Request-only.
The databases have not seen any locks or timeouts.

Can anyone tell me why a WAS app would keep spinning up more channels? I can only imagine that it thinks it is getting poor response times so it adds more channels to do the work. Where is it set though? To tell it how many to spin up or what criteria to use to determine what "slow" is?

Thanks in advance...


Linda Barton





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

[Petri kaunisto]

[Ian Alderson]

Hi Linda,
There isn’t a lot to go on from your mail so my reply is slightly speculative.

I am assuming here that the WAS set-up is using the built-in JNDI configuration (accessible through the WAS admin console) rather than using an external JNDI such as provided by JMSAdmin. In WAS you have the ability to set connection pooling for the MQ connections. A WAS Admin should be able to locate and confirm the settings for you. Configuration and options may vary according to the WAS version.

Assuming the application is an EJB:
The way connection pooling works if the application issues a connect (connectionFactory.createConnection method) it will create a new MQ connection to the Queue Manager for the first time. When the application issues a disconnect (connection.close) it will return the connection to the connection pool (the connection on the Queue Manager is still open at this point).
If a second application then issues a connect (again issuing a createConnection) *and* there is a free connection in the connection pool, then it uses the previously opened connection and no new connection is opened to MQ.
If however there are no free connections in the pool, then the connect method will create a new connection to MQ.

MDBs are slightly different as they listen on a queue but that is not your scenario here I believe.

So, and here is the speculative part, as you are saying that you have 100 connections is it possible that the application may not be closing its connections properly and releasing them to the connection pool, therefore increasing the active connections in the pool? As I understand it, once the connection pool is full then a new connect call will wait for an available connection to be released which may be some time (there should also be a timeout setting on the connection pooling in the WAS settings).

Having said that, I don’t know what you mean by response time issues – is it slow to send one message, or is throughput backing up somewhere? And how do you expect the application to behave – e.g. sending one message then closing, or should it be sending many messages and staying connected?

Hope that helps,
Ian







Ian Alderson
MQ Technical Architect

[cid:***@136710c5.418b8399]

DL 0203 003 3055


________________________________
Ignis Asset Management
Fixed Income | Equities | Real Estate | Advisors | Solutions
150 Cheapside | London | EC2V 6ET

http://www.ignisasset.com
http://twitter.com/IgnisAM
http://www.linkedin.com/companies/ignis-asset-management

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Barton, Linda
Sent: Monday, March 31, 2014 7:04 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi Folks,
I currently have a prod application (WAS 8.0.0.6) that connects to my QMgrs using SRCONN channels. It is only putting messages to ONE queue. There have been response time issues since March 9th. When I check the channel status for the application, I see over 100 SVRCONNS running. The application PUTs to an Alias queue on this server which then sends it to a backend server where the receiving application resides. The application READING the messages is not reporting higher response times. It is the application PUTTING the messages that is. Also, there is no request-reply model, it is Request-only.
The databases have not seen any locks or timeouts.

Can anyone tell me why a WAS app would keep spinning up more channels? I can only imagine that it thinks it is getting poor response times so it adds more channels to do the work. Where is it set though? To tell it how many to spin up or what criteria to use to determine what “slow” is?

Thanks in advance



Linda Barton





________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


**************************************************************
The information contained in this email (including any attachments transmitted within it) is confidential and is intended solely for the use of the named person.
The unauthorised access, copying or re-use of the information in it by any other person is strictly forbidden.
If you are not the intended recipient please notify us immediately by return email to ***@ignisasset.com.

Internet communication is not guaranteed to be timely, secure, error or virus free. We accept no liability for any harm to systems or data, nor for personal emails. Emails may be recalled, deleted and monitored.

Ignis Asset Management is the trading name of the Ignis Asset Management Limited group of companies which includes the following subsidiaries:
Ignis Asset Management Limited (Registered in Scotland No. SC200801), Ignis Investment Services Limited* (Registered in Scotland No. SC101825)
Ignis Fund Managers Limited* (Registered in Scotland No. SC85610) Scottish Mutual Investment Managers Limited* (Registered in Scotland No. SC88674)
Registered Office: 50 Bothwell Street, Glasgow, G2 6HR, Tel: [phone] and Scottish Mutual PEP & ISA Managers Limited* (Registered in England No. 971504)
Registered Office: 1 Wythall Green Way, Wythall, Birmingham B47 6WG and Ignis Investment Management Limited (Registered in England No. 5809046)
Registered Office: 150 Cheapside, London, EC2V 6ET Tel: [phone]. Scottish Mutual is a registered trade mark of Scottish Mutual Assurance Limited

*Authorised and regulated by the Financial Conduct Authority.

**************************************************************

[Barton, Linda]

Thanks Ian. The WAS app is using the internal WebSphere MQ adapter. The app not closing connections sounds like it might fit the bill. I do see that some channels have a lstmsgda of 03-31 so perhaps I need to add the ClientIdle parm to the qm.ini. My HBINT is 300 and my KAINT is AUTO. There are even channels from today that keep starting up even though the traffic for that queue is about 5 messages per second so I would not expect any to be idle.

From a WAS perspective, the connection and session pool settings are the same.
10 max connections
180 timeout value for the pool – so if the 10 connections are used, it will wait 3 minutes before trying to get one again.
1800 secs for unused timeout.
The connection pool purge policy is set to entire pool
The session pool purge policy is set to failing connection only.

I am wondering why WAS is not cleaning up its unused connections, or is it really MQ? I have an mq counterpart in the company who has mentioned he uses the clientidle on his qmgrs. I will ask him how that worked for him and if there are any other settings I need to be aware of to set it. I saw it discussed in this technote: http://www-01.ibm.com/support/docview.wss?uid=swg21376219



Linda Barton


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Ian Alderson
Sent: Tuesday, April 01, 2014 4:47 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi Linda,
There isn’t a lot to go on from your mail so my reply is slightly speculative.

I am assuming here that the WAS set-up is using the built-in JNDI configuration (accessible through the WAS admin console) rather than using an external JNDI such as provided by JMSAdmin. In WAS you have the ability to set connection pooling for the MQ connections. A WAS Admin should be able to locate and confirm the settings for you. Configuration and options may vary according to the WAS version.

Assuming the application is an EJB:
The way connection pooling works if the application issues a connect (connectionFactory.createConnection method) it will create a new MQ connection to the Queue Manager for the first time. When the application issues a disconnect (connection.close) it will return the connection to the connection pool (the connection on the Queue Manager is still open at this point).
If a second application then issues a connect (again issuing a createConnection) *and* there is a free connection in the connection pool, then it uses the previously opened connection and no new connection is opened to MQ.
If however there are no free connections in the pool, then the connect method will create a new connection to MQ.

MDBs are slightly different as they listen on a queue but that is not your scenario here I believe.

So, and here is the speculative part, as you are saying that you have 100 connections is it possible that the application may not be closing its connections properly and releasing them to the connection pool, therefore increasing the active connections in the pool? As I understand it, once the connection pool is full then a new connect call will wait for an available connection to be released which may be some time (there should also be a timeout setting on the connection pooling in the WAS settings).

Having said that, I don’t know what you mean by response time issues – is it slow to send one message, or is throughput backing up somewhere? And how do you expect the application to behave – e.g. sending one message then closing, or should it be sending many messages and staying connected?

Hope that helps,
Ian







Ian Alderson
MQ Technical Architect

[cid:***@01CF4D97.C1EA4530]
DL 0203 003 3055




________________________________
Ignis Asset Management
Fixed Income | Equities | Real Estate | Advisors | Solutions
150 Cheapside | London | EC2V 6ET

http://www.ignisasset.com
http://twitter.com/IgnisAM
http://www.linkedin.com/companies/ignis-asset-management


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Barton, Linda
Sent: Monday, March 31, 2014 7:04 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi Folks,
I currently have a prod application (WAS 8.0.0.6) that connects to my QMgrs using SRCONN channels. It is only putting messages to ONE queue. There have been response time issues since March 9th. When I check the channel status for the application, I see over 100 SVRCONNS running. The application PUTs to an Alias queue on this server which then sends it to a backend server where the receiving application resides. The application READING the messages is not reporting higher response times. It is the application PUTTING the messages that is. Also, there is no request-reply model, it is Request-only.
The databases have not seen any locks or timeouts.

Can anyone tell me why a WAS app would keep spinning up more channels? I can only imagine that it thinks it is getting poor response times so it adds more channels to do the work. Where is it set though? To tell it how many to spin up or what criteria to use to determine what “slow” is?

Thanks in advance



Linda Barton





________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


**************************************************************
The information contained in this email (including any attachments transmitted within it) is confidential and is intended solely for the use of the named person.
The unauthorised access, copying or re-use of the information in it by any other person is strictly forbidden.
If you are not the intended recipient please notify us immediately by return email to ***@ignisasset.com<mailto:***@ignisasset.com>.

Internet communication is not guaranteed to be timely, secure, error or virus free. We accept no liability for any harm to systems or data, nor for personal emails. Emails may be recalled, deleted and monitored.

Ignis Asset Management is the trading name of the Ignis Asset Management Limited group of companies which includes the following subsidiaries:
Ignis Asset Management Limited (Registered in Scotland No. SC200801), Ignis Investment Services Limited* (Registered in Scotland No. SC101825)
Ignis Fund Managers Limited* (Registered in Scotland No. SC85610) Scottish Mutual Investment Managers Limited* (Registered in Scotland No. SC88674)
Registered Office: 50 Bothwell Street, Glasgow, G2 6HR, Tel: [phone] and Scottish Mutual PEP & ISA Managers Limited* (Registered in England No. 971504)
Registered Office: 1 Wythall Green Way, Wythall, Birmingham B47 6WG and Ignis Investment Management Limited (Registered in England No. 5809046)
Registered Office: 150 Cheapside, London, EC2V 6ET Tel: [phone]. Scottish Mutual is a registered trade mark of Scottish Mutual Assurance Limited

*Authorised and regulated by the Financial Conduct Authority.

**************************************************************

[Costa, D. (Damian)]

Hi,
The client idle setting will disconnect ANY idle client channel. Irrespective of whether it’s a valid connection or not based on the inactivity of that connection.
It might be a good idea to consider the version of the MQ client adapter shipped with WAS. IIRC It has to be upgraded individually. We encountered this proliferation of MQ client channels issue at some point before with WAS V7*.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Barton, Linda
Sent: 01 April 2014 04:47 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: WAS8 application spinning up a lot of SVRCONN channels to MQ

Thanks Ian. The WAS app is using the internal WebSphere MQ adapter. The app not closing connections sounds like it might fit the bill. I do see that some channels have a lstmsgda of 03-31 so perhaps I need to add the ClientIdle parm to the qm.ini. My HBINT is 300 and my KAINT is AUTO. There are even channels from today that keep starting up even though the traffic for that queue is about 5 messages per second so I would not expect any to be idle.

From a WAS perspective, the connection and session pool settings are the same.
10 max connections
180 timeout value for the pool – so if the 10 connections are used, it will wait 3 minutes before trying to get one again.
1800 secs for unused timeout.
The connection pool purge policy is set to entire pool
The session pool purge policy is set to failing connection only.

I am wondering why WAS is not cleaning up its unused connections, or is it really MQ? I have an mq counterpart in the company who has mentioned he uses the clientidle on his qmgrs. I will ask him how that worked for him and if there are any other settings I need to be aware of to set it. I saw it discussed in this technote: http://www-01.ibm.com/support/docview.wss?uid=swg21376219



Linda Barton


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Ian Alderson
Sent: Tuesday, April 01, 2014 4:47 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi Linda,
There isn’t a lot to go on from your mail so my reply is slightly speculative.

I am assuming here that the WAS set-up is using the built-in JNDI configuration (accessible through the WAS admin console) rather than using an external JNDI such as provided by JMSAdmin. In WAS you have the ability to set connection pooling for the MQ connections. A WAS Admin should be able to locate and confirm the settings for you. Configuration and options may vary according to the WAS version.

Assuming the application is an EJB:
The way connection pooling works if the application issues a connect (connectionFactory.createConnection method) it will create a new MQ connection to the Queue Manager for the first time. When the application issues a disconnect (connection.close) it will return the connection to the connection pool (the connection on the Queue Manager is still open at this point).
If a second application then issues a connect (again issuing a createConnection) *and* there is a free connection in the connection pool, then it uses the previously opened connection and no new connection is opened to MQ.
If however there are no free connections in the pool, then the connect method will create a new connection to MQ.

MDBs are slightly different as they listen on a queue but that is not your scenario here I believe.

So, and here is the speculative part, as you are saying that you have 100 connections is it possible that the application may not be closing its connections properly and releasing them to the connection pool, therefore increasing the active connections in the pool? As I understand it, once the connection pool is full then a new connect call will wait for an available connection to be released which may be some time (there should also be a timeout setting on the connection pooling in the WAS settings).

Having said that, I don’t know what you mean by response time issues – is it slow to send one message, or is throughput backing up somewhere? And how do you expect the application to behave – e.g. sending one message then closing, or should it be sending many messages and staying connected?

Hope that helps,
Ian







Ian Alderson
MQ Technical Architect

[cid:***@01CF4DCD.6AEB8C90]
DL 0203 003 3055




________________________________
Ignis Asset Management
Fixed Income | Equities | Real Estate | Advisors | Solutions
150 Cheapside | London | EC2V 6ET

http://www.ignisasset.com
http://twitter.com/IgnisAM
http://www.linkedin.com/companies/ignis-asset-management


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Barton, Linda
Sent: Monday, March 31, 2014 7:04 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi Folks,
I currently have a prod application (WAS 8.0.0.6) that connects to my QMgrs using SRCONN channels. It is only putting messages to ONE queue. There have been response time issues since March 9th. When I check the channel status for the application, I see over 100 SVRCONNS running. The application PUTs to an Alias queue on this server which then sends it to a backend server where the receiving application resides. The application READING the messages is not reporting higher response times. It is the application PUTTING the messages that is. Also, there is no request-reply model, it is Request-only.
The databases have not seen any locks or timeouts.

Can anyone tell me why a WAS app would keep spinning up more channels? I can only imagine that it thinks it is getting poor response times so it adds more channels to do the work. Where is it set though? To tell it how many to spin up or what criteria to use to determine what “slow” is?

Thanks in advance



Linda Barton





________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


**************************************************************
The information contained in this email (including any attachments transmitted within it) is confidential and is intended solely for the use of the named person.
The unauthorised access, copying or re-use of the information in it by any other person is strictly forbidden.
If you are not the intended recipient please notify us immediately by return email to ***@ignisasset.com<mailto:***@ignisasset.com>.

Internet communication is not guaranteed to be timely, secure, error or virus free. We accept no liability for any harm to systems or data, nor for personal emails. Emails may be recalled, deleted and monitored.

Ignis Asset Management is the trading name of the Ignis Asset Management Limited group of companies which includes the following subsidiaries:
Ignis Asset Management Limited (Registered in Scotland No. SC200801), Ignis Investment Services Limited* (Registered in Scotland No. SC101825)
Ignis Fund Managers Limited* (Registered in Scotland No. SC85610) Scottish Mutual Investment Managers Limited* (Registered in Scotland No. SC88674)
Registered Office: 50 Bothwell Street, Glasgow, G2 6HR, Tel: [phone] and Scottish Mutual PEP & ISA Managers Limited* (Registered in England No. 971504)
Registered Office: 1 Wythall Green Way, Wythall, Birmingham B47 6WG and Ignis Investment Management Limited (Registered in England No. 5809046)
Registered Office: 150 Cheapside, London, EC2V 6ET Tel: [phone]. Scottish Mutual is a registered trade mark of Scottish Mutual Assurance Limited

*Authorised and regulated by the Financial Conduct Authority.

**************************************************************

********************
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 ]
********************

[Barton, Linda]

Hm, I am looking at the article from Morag that Peter sent me. https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/avoiding_runaway_numbers_of_mq_channels?lang=en
We have not played with MAXINST or MAXINSTC before. They are currently set to 999999999. I will look in to that but wonder what the implication is for the WAS app. Since it appears not to know that it already has running instances of the channel it can use. If I limit it, will the app be able to use the existing connections? And if so, why didn’t it before? Just wondering out loud.


Linda Barton


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Costa, D. (Damian)
Sent: Tuesday, April 01, 2014 11:12 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi,
The client idle setting will disconnect ANY idle client channel. Irrespective of whether it’s a valid connection or not based on the inactivity of that connection.
It might be a good idea to consider the version of the MQ client adapter shipped with WAS. IIRC It has to be upgraded individually. We encountered this proliferation of MQ client channels issue at some point before with WAS V7*.

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Barton, Linda
Sent: 01 April 2014 04:47 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: WAS8 application spinning up a lot of SVRCONN channels to MQ

Thanks Ian. The WAS app is using the internal WebSphere MQ adapter. The app not closing connections sounds like it might fit the bill. I do see that some channels have a lstmsgda of 03-31 so perhaps I need to add the ClientIdle parm to the qm.ini. My HBINT is 300 and my KAINT is AUTO. There are even channels from today that keep starting up even though the traffic for that queue is about 5 messages per second so I would not expect any to be idle.

From a WAS perspective, the connection and session pool settings are the same.
10 max connections
180 timeout value for the pool – so if the 10 connections are used, it will wait 3 minutes before trying to get one again.
1800 secs for unused timeout.
The connection pool purge policy is set to entire pool
The session pool purge policy is set to failing connection only.

I am wondering why WAS is not cleaning up its unused connections, or is it really MQ? I have an mq counterpart in the company who has mentioned he uses the clientidle on his qmgrs. I will ask him how that worked for him and if there are any other settings I need to be aware of to set it. I saw it discussed in this technote: http://www-01.ibm.com/support/docview.wss?uid=swg21376219



Linda Barton


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Ian Alderson
Sent: Tuesday, April 01, 2014 4:47 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi Linda,
There isn’t a lot to go on from your mail so my reply is slightly speculative.

I am assuming here that the WAS set-up is using the built-in JNDI configuration (accessible through the WAS admin console) rather than using an external JNDI such as provided by JMSAdmin. In WAS you have the ability to set connection pooling for the MQ connections. A WAS Admin should be able to locate and confirm the settings for you. Configuration and options may vary according to the WAS version.

Assuming the application is an EJB:
The way connection pooling works if the application issues a connect (connectionFactory.createConnection method) it will create a new MQ connection to the Queue Manager for the first time. When the application issues a disconnect (connection.close) it will return the connection to the connection pool (the connection on the Queue Manager is still open at this point).
If a second application then issues a connect (again issuing a createConnection) *and* there is a free connection in the connection pool, then it uses the previously opened connection and no new connection is opened to MQ.
If however there are no free connections in the pool, then the connect method will create a new connection to MQ.

MDBs are slightly different as they listen on a queue but that is not your scenario here I believe.

So, and here is the speculative part, as you are saying that you have 100 connections is it possible that the application may not be closing its connections properly and releasing them to the connection pool, therefore increasing the active connections in the pool? As I understand it, once the connection pool is full then a new connect call will wait for an available connection to be released which may be some time (there should also be a timeout setting on the connection pooling in the WAS settings).

Having said that, I don’t know what you mean by response time issues – is it slow to send one message, or is throughput backing up somewhere? And how do you expect the application to behave – e.g. sending one message then closing, or should it be sending many messages and staying connected?

Hope that helps,
Ian







Ian Alderson
MQ Technical Architect

[cid:***@01CF4D9F.FC612F00]
DL 0203 003 3055




________________________________
Ignis Asset Management
Fixed Income | Equities | Real Estate | Advisors | Solutions
150 Cheapside | London | EC2V 6ET

http://www.ignisasset.com
http://twitter.com/IgnisAM
http://www.linkedin.com/companies/ignis-asset-management


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Barton, Linda
Sent: Monday, March 31, 2014 7:04 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi Folks,
I currently have a prod application (WAS 8.0.0.6) that connects to my QMgrs using SRCONN channels. It is only putting messages to ONE queue. There have been response time issues since March 9th. When I check the channel status for the application, I see over 100 SVRCONNS running. The application PUTs to an Alias queue on this server which then sends it to a backend server where the receiving application resides. The application READING the messages is not reporting higher response times. It is the application PUTTING the messages that is. Also, there is no request-reply model, it is Request-only.
The databases have not seen any locks or timeouts.

Can anyone tell me why a WAS app would keep spinning up more channels? I can only imagine that it thinks it is getting poor response times so it adds more channels to do the work. Where is it set though? To tell it how many to spin up or what criteria to use to determine what “slow” is?

Thanks in advance



Linda Barton





________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


**************************************************************
The information contained in this email (including any attachments transmitted within it) is confidential and is intended solely for the use of the named person.
The unauthorised access, copying or re-use of the information in it by any other person is strictly forbidden.
If you are not the intended recipient please notify us immediately by return email to ***@ignisasset.com<mailto:***@ignisasset.com>.

Internet communication is not guaranteed to be timely, secure, error or virus free. We accept no liability for any harm to systems or data, nor for personal emails. Emails may be recalled, deleted and monitored.

Ignis Asset Management is the trading name of the Ignis Asset Management Limited group of companies which includes the following subsidiaries:
Ignis Asset Management Limited (Registered in Scotland No. SC200801), Ignis Investment Services Limited* (Registered in Scotland No. SC101825)
Ignis Fund Managers Limited* (Registered in Scotland No. SC85610) Scottish Mutual Investment Managers Limited* (Registered in Scotland No. SC88674)
Registered Office: 50 Bothwell Street, Glasgow, G2 6HR, Tel: [phone] and Scottish Mutual PEP & ISA Managers Limited* (Registered in England No. 971504)
Registered Office: 1 Wythall Green Way, Wythall, Birmingham B47 6WG and Ignis Investment Management Limited (Registered in England No. 5809046)
Registered Office: 150 Cheapside, London, EC2V 6ET Tel: [phone]. Scottish Mutual is a registered trade mark of Scottish Mutual Assurance Limited

*Authorised and regulated by the Financial Conduct Authority.

**************************************************************

********************
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 ]
********************

[Ian Alderson]

Linda,
You might find this link useful on connection pools and session pools.
http://www-01.ibm.com/support/docview.wss?uid=swg21201242
So a default setting of connection pool and session pool could have a max of 100 connections. Are you seeing 100 connections in total or more? Note that these settings are per connection factory. I don’t know if you have other connection factories configured on the same WAS server.

Now if you have other applications using the same connection factory then they will also contribute to the number of channels. MDBs are different animals and will, I think, open up by connections automatically based on the config. But if the only MQ app on this WAS app instance is simply putting messages to a single queue, then I think it may well be down to the logic in the application itself. I think Damian’s advice on considering updating the shipped version of the resource adapter may be worth considering, perhaps IBM can advise if there are known issues with the versions you’re running.

5 messages per second is not a lot in terms of performance. How is the performance problem manifesting itself? Is it the latency of how long it takes to send a single message? And what process starts the creation of a message? You mentioned databases in your first post.

Ian

From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Barton, Linda
Sent: Tuesday, April 01, 2014 3:47 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: WAS8 application spinning up a lot of SVRCONN channels to MQ

Thanks Ian. The WAS app is using the internal WebSphere MQ adapter. The app not closing connections sounds like it might fit the bill. I do see that some channels have a lstmsgda of 03-31 so perhaps I need to add the ClientIdle parm to the qm.ini. My HBINT is 300 and my KAINT is AUTO. There are even channels from today that keep starting up even though the traffic for that queue is about 5 messages per second so I would not expect any to be idle.

From a WAS perspective, the connection and session pool settings are the same.
10 max connections
180 timeout value for the pool – so if the 10 connections are used, it will wait 3 minutes before trying to get one again.
1800 secs for unused timeout.
The connection pool purge policy is set to entire pool
The session pool purge policy is set to failing connection only.

I am wondering why WAS is not cleaning up its unused connections, or is it really MQ? I have an mq counterpart in the company who has mentioned he uses the clientidle on his qmgrs. I will ask him how that worked for him and if there are any other settings I need to be aware of to set it. I saw it discussed in this technote: http://www-01.ibm.com/support/docview.wss?uid=swg21376219



Linda Barton


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Ian Alderson
Sent: Tuesday, April 01, 2014 4:47 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi Linda,
There isn’t a lot to go on from your mail so my reply is slightly speculative.

I am assuming here that the WAS set-up is using the built-in JNDI configuration (accessible through the WAS admin console) rather than using an external JNDI such as provided by JMSAdmin. In WAS you have the ability to set connection pooling for the MQ connections. A WAS Admin should be able to locate and confirm the settings for you. Configuration and options may vary according to the WAS version.

Assuming the application is an EJB:
The way connection pooling works if the application issues a connect (connectionFactory.createConnection method) it will create a new MQ connection to the Queue Manager for the first time. When the application issues a disconnect (connection.close) it will return the connection to the connection pool (the connection on the Queue Manager is still open at this point).
If a second application then issues a connect (again issuing a createConnection) *and* there is a free connection in the connection pool, then it uses the previously opened connection and no new connection is opened to MQ.
If however there are no free connections in the pool, then the connect method will create a new connection to MQ.

MDBs are slightly different as they listen on a queue but that is not your scenario here I believe.

So, and here is the speculative part, as you are saying that you have 100 connections is it possible that the application may not be closing its connections properly and releasing them to the connection pool, therefore increasing the active connections in the pool? As I understand it, once the connection pool is full then a new connect call will wait for an available connection to be released which may be some time (there should also be a timeout setting on the connection pooling in the WAS settings).

Having said that, I don’t know what you mean by response time issues – is it slow to send one message, or is throughput backing up somewhere? And how do you expect the application to behave – e.g. sending one message then closing, or should it be sending many messages and staying connected?

Hope that helps,
Ian







Ian Alderson
MQ Technical Architect

[cid:***@01CF4DCC.A9504170]
DL 0203 003 3055




________________________________
Ignis Asset Management
Fixed Income | Equities | Real Estate | Advisors | Solutions
150 Cheapside | London | EC2V 6ET

http://www.ignisasset.com
http://twitter.com/IgnisAM
http://www.linkedin.com/companies/ignis-asset-management


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Barton, Linda
Sent: Monday, March 31, 2014 7:04 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: WAS8 application spinning up a lot of SVRCONN channels to MQ

Hi Folks,
I currently have a prod application (WAS 8.0.0.6) that connects to my QMgrs using SRCONN channels. It is only putting messages to ONE queue. There have been response time issues since March 9th. When I check the channel status for the application, I see over 100 SVRCONNS running. The application PUTs to an Alias queue on this server which then sends it to a backend server where the receiving application resides. The application READING the messages is not reporting higher response times. It is the application PUTTING the messages that is. Also, there is no request-reply model, it is Request-only.
The databases have not seen any locks or timeouts.

Can anyone tell me why a WAS app would keep spinning up more channels? I can only imagine that it thinks it is getting poor response times so it adds more channels to do the work. Where is it set though? To tell it how many to spin up or what criteria to use to determine what “slow” is?

Thanks in advance



Linda Barton





________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


**************************************************************
The information contained in this email (including any attachments transmitted within it) is confidential and is intended solely for the use of the named person.
The unauthorised access, copying or re-use of the information in it by any other person is strictly forbidden.
If you are not the intended recipient please notify us immediately by return email to ***@ignisasset.com<mailto:***@ignisasset.com>.

Internet communication is not guaranteed to be timely, secure, error or virus free. We accept no liability for any harm to systems or data, nor for personal emails. Emails may be recalled, deleted and monitored.

Ignis Asset Management is the trading name of the Ignis Asset Management Limited group of companies which includes the following subsidiaries:
Ignis Asset Management Limited (Registered in Scotland No. SC200801), Ignis Investment Services Limited* (Registered in Scotland No. SC101825)
Ignis Fund Managers Limited* (Registered in Scotland No. SC85610) Scottish Mutual Investment Managers Limited* (Registered in Scotland No. SC88674)
Registered Office: 50 Bothwell Street, Glasgow, G2 6HR, Tel: [phone] and Scottish Mutual PEP & ISA Managers Limited* (Registered in England No. 971504)
Registered Office: 1 Wythall Green Way, Wythall, Birmingham B47 6WG and Ignis Investment Management Limited (Registered in England No. 5809046)
Registered Office: 150 Cheapside, London, EC2V 6ET Tel: [phone]. Scottish Mutual is a registered trade mark of Scottish Mutual Assurance Limited

*Authorised and regulated by the Financial Conduct Authority.

**************************************************************