Re: JMS resource problems after 254 'connections' ?
Hi Ruzi, I have one answer for you - PS requires CLIENT mode because of their architecture requirements, which allow for the components to run on separate machines, if the customer desires to split the components. We have them running on separate servers.. So far, no one here has heard about a 15M message size requirement/standard. I'll post again if I hear any more about it. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Ruzi R Sent: Friday, March 19, 2004 8:13 AM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Hi Peter, Yes, you can find out the num of connections from the CHSATUS of the SVRCONN. Since your environment sounds like mine, I have 2 unrelated questions for you: 1-PS apps are running in a client mode on the server. I would like to change it the TRANSPORT(BIND) in the bindings file. However, the people working as middleman between us and PS are saying that PS wants to run in CLIENT mode. I don t understand why. I have never been able to get a reason for this. DO you know why they want to run as a client app? 2-Apparently, PS default message size is 15 MB that they use between their internal programs. They have one interface in which they put 15 MB messages on the queue despite the fact that I repeatedly asked them to make the messages shorter (for obvious reasons) by using various techniques. They have been reluctant to do this as they claim that, since WMQ can handle 100 MB they are only using 15% of the capacity, what is the big deal etc etc.. There have been problems with this big messages in Prod. I had to increase the number of log files (circular) to the max. LogFileSize is still at 512. (When I have a chance I am going to change to linear and increase the LogFileSize to 16384). My question is: During our conversations, a person using the PS Handler mentioned that it is faster to send 15 MB messages than many smaller messages. I think he based his assumption based on another interface which takes about 10-30 sec to Put a 32 K message. He demonstrated it to me. Since this is not happening in other interfaces, I assume it has something to do with the app. Have you been aware of this ? If so, what was the problem? Thanks, Ruzi --- "Heggie, Peter" <[EMAIL PROTECTED]> wrote: > Thanks Ruzi, > > We are going to increase MAXHANDS for now. I just > got off the phone with > our PeopleSoft administrators and they discovered > late last night that > PeopleSoft/JMS code never lets go of these handles. > They modified some > of the PS JMS classes to force the release of the > connections and the > problem disappeared. They are pursuing the issue > with PS to get an > approved fix. > > Is it correct to say that each of these handles is > associated with a > SVRCONN channel connection, and that I can display > the CHSTATUS to see > the open handles? So counting the number of > connections would give me > the number of handles and confirm the problem. We > could run 254 of these > synchronous requests and we should see the 254 open > connections in the > display. > > Peter Heggie > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] > On Behalf Of Ruzi R > Sent: Thursday, March 18, 2004 4:00 PM > To: [EMAIL PROTECTED] > Subject: Re: JMS resource problems after 254 > 'connections' ? > > Hi Peter, > > We had the same problem with PeopleSoft/JMS. We > increased MAXHANDS to 512 about a year ago, and we > have never had this problem again since then. > > Ruzi > > --- "Heggie, Peter" <[EMAIL PROTECTED]> > wrote: > > More information - the source of the '254' > > connections is the MQ queue > > manager MAXHANDS attribute. When we raised it, we > > immediately were able > > to run more transactions before encountering > > exceptions. The new number > > we could run exactly matched the new MAXHANDS > value, > > minus 2. > > > > We tried explicitly closing the temporary queues > as > > soon as we received > > the reply on them, but we still encountered > > exceptions (in PeopleSoft) > > after the limit was reached. > > > > From a distance, it looks like PeopleSoft's > > implementation of JMS is not > > releasing the queue handles. We will try to test > > more with a much higher > > limit, and see if the higher limit allows more > time > > for requests to > > complete and release enough queue handles to stay > > below the limit. I'm > > hoping we will find some kind of JMS configuration > > parameter that has > > been set incorrectly which can release handles > > quickly. > > > >
Re: JMS resource problems after 254 'connections' ?
Hi Peter, Yes, you can find out the num of connections from the CHSATUS of the SVRCONN. Since your environment sounds like mine, I have 2 unrelated questions for you: 1-PS apps are running in a client mode on the server. I would like to change it the TRANSPORT(BIND) in the bindings file. However, the people working as middleman between us and PS are saying that PS wants to run in CLIENT mode. I don t understand why. I have never been able to get a reason for this. DO you know why they want to run as a client app? 2-Apparently, PS default message size is 15 MB that they use between their internal programs. They have one interface in which they put 15 MB messages on the queue despite the fact that I repeatedly asked them to make the messages shorter (for obvious reasons) by using various techniques. They have been reluctant to do this as they claim that, since WMQ can handle 100 MB they are only using 15% of the capacity, what is the big deal etc etc.. There have been problems with this big messages in Prod. I had to increase the number of log files (circular) to the max. LogFileSize is still at 512. (When I have a chance I am going to change to linear and increase the LogFileSize to 16384). My question is: During our conversations, a person using the PS Handler mentioned that it is faster to send 15 MB messages than many smaller messages. I think he based his assumption based on another interface which takes about 10-30 sec to Put a 32 K message. He demonstrated it to me. Since this is not happening in other interfaces, I assume it has something to do with the app. Have you been aware of this ? If so, what was the problem? Thanks, Ruzi --- "Heggie, Peter" <[EMAIL PROTECTED]> wrote: > Thanks Ruzi, > > We are going to increase MAXHANDS for now. I just > got off the phone with > our PeopleSoft administrators and they discovered > late last night that > PeopleSoft/JMS code never lets go of these handles. > They modified some > of the PS JMS classes to force the release of the > connections and the > problem disappeared. They are pursuing the issue > with PS to get an > approved fix. > > Is it correct to say that each of these handles is > associated with a > SVRCONN channel connection, and that I can display > the CHSTATUS to see > the open handles? So counting the number of > connections would give me > the number of handles and confirm the problem. We > could run 254 of these > synchronous requests and we should see the 254 open > connections in the > display. > > Peter Heggie > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] > On Behalf Of Ruzi R > Sent: Thursday, March 18, 2004 4:00 PM > To: [EMAIL PROTECTED] > Subject: Re: JMS resource problems after 254 > 'connections' ? > > Hi Peter, > > We had the same problem with PeopleSoft/JMS. We > increased MAXHANDS to 512 about a year ago, and we > have never had this problem again since then. > > Ruzi > > --- "Heggie, Peter" <[EMAIL PROTECTED]> > wrote: > > More information - the source of the '254' > > connections is the MQ queue > > manager MAXHANDS attribute. When we raised it, we > > immediately were able > > to run more transactions before encountering > > exceptions. The new number > > we could run exactly matched the new MAXHANDS > value, > > minus 2. > > > > We tried explicitly closing the temporary queues > as > > soon as we received > > the reply on them, but we still encountered > > exceptions (in PeopleSoft) > > after the limit was reached. > > > > From a distance, it looks like PeopleSoft's > > implementation of JMS is not > > releasing the queue handles. We will try to test > > more with a much higher > > limit, and see if the higher limit allows more > time > > for requests to > > complete and release enough queue handles to stay > > below the limit. I'm > > hoping we will find some kind of JMS configuration > > parameter that has > > been set incorrectly which can release handles > > quickly. > > > > Peter Heggie > > > > -Original Message- > > From: MQSeries List > [mailto:[EMAIL PROTECTED] > > On Behalf Of Wyatt, > > T. Rob > > Sent: Wednesday, March 17, 2004 11:01 AM > > To: [EMAIL PROTECTED] > > Subject: Re: JMS resource problems after 254 > > 'connections' ? > > > > Peter, > > > > I agree that the number sounds suspicious. > > Especially in relation to > > messages as opposed to connections. It suggests > the > > app is making a new > > connection for each message and not releasing > them.
Re: JMS resource problems after 254 'connections' ?
Thanks Ruzi, We are going to increase MAXHANDS for now. I just got off the phone with our PeopleSoft administrators and they discovered late last night that PeopleSoft/JMS code never lets go of these handles. They modified some of the PS JMS classes to force the release of the connections and the problem disappeared. They are pursuing the issue with PS to get an approved fix. Is it correct to say that each of these handles is associated with a SVRCONN channel connection, and that I can display the CHSTATUS to see the open handles? So counting the number of connections would give me the number of handles and confirm the problem. We could run 254 of these synchronous requests and we should see the 254 open connections in the display. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Ruzi R Sent: Thursday, March 18, 2004 4:00 PM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Hi Peter, We had the same problem with PeopleSoft/JMS. We increased MAXHANDS to 512 about a year ago, and we have never had this problem again since then. Ruzi --- "Heggie, Peter" <[EMAIL PROTECTED]> wrote: > More information - the source of the '254' > connections is the MQ queue > manager MAXHANDS attribute. When we raised it, we > immediately were able > to run more transactions before encountering > exceptions. The new number > we could run exactly matched the new MAXHANDS value, > minus 2. > > We tried explicitly closing the temporary queues as > soon as we received > the reply on them, but we still encountered > exceptions (in PeopleSoft) > after the limit was reached. > > From a distance, it looks like PeopleSoft's > implementation of JMS is not > releasing the queue handles. We will try to test > more with a much higher > limit, and see if the higher limit allows more time > for requests to > complete and release enough queue handles to stay > below the limit. I'm > hoping we will find some kind of JMS configuration > parameter that has > been set incorrectly which can release handles > quickly. > > Peter Heggie > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] > On Behalf Of Wyatt, > T. Rob > Sent: Wednesday, March 17, 2004 11:01 AM > To: [EMAIL PROTECTED] > Subject: Re: JMS resource problems after 254 > 'connections' ? > > Peter, > > I agree that the number sounds suspicious. > Especially in relation to > messages as opposed to connections. It suggests the > app is making a new > connection for each message and not releasing them. > Have you checked > for > that? > > Alternatively, what kind of logging are you using > and are all the > messages > in a single unit of work? > > -- T.Rob > > -Original Message- > From: Heggie, Peter > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 17, 2004 10:05 AM > To: [EMAIL PROTECTED] > Subject: JMS resource problems after 254 > 'connections' ? > > > Has anyone encountered a problem with a MQ to JMS > environment, where a > synchronous transfer (request/reply) encounters a > 'Resouce Exception' > after 245 reply messages are processed? > > We have an MQ to PeopleSoft environment where we > send messages from an > MQ application via JMS to the PeopleSoft Integration > Broker, which then > sends a PS message to a PS component. When PS sends > a reply back to the > PS Integration Broker, after 254 replies have been > received by the > Integration Broker (and passed on to JMS & MQ), the > 255th reply causes a > JMS resource exception. > > The number 254 is very suspicious, but also, I would > perfer eliminating > a 'limit number' altogether, rather than just > raising it. > > Has anyone seen something like this before? > > > This e-mail and any files transmitted with it, are > confidential to > National > Grid and are intended solely for the use of the > individual or entity to > whom > they are addressed. If you have received this > e-mail in error, please > reply > to this message and let the sender know. > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available a
Re: JMS resource problems after 254 'connections' ?
Hi Peter, We had the same problem with PeopleSoft/JMS. We increased MAXHANDS to 512 about a year ago, and we have never had this problem again since then. Ruzi --- "Heggie, Peter" <[EMAIL PROTECTED]> wrote: > More information - the source of the '254' > connections is the MQ queue > manager MAXHANDS attribute. When we raised it, we > immediately were able > to run more transactions before encountering > exceptions. The new number > we could run exactly matched the new MAXHANDS value, > minus 2. > > We tried explicitly closing the temporary queues as > soon as we received > the reply on them, but we still encountered > exceptions (in PeopleSoft) > after the limit was reached. > > From a distance, it looks like PeopleSoft's > implementation of JMS is not > releasing the queue handles. We will try to test > more with a much higher > limit, and see if the higher limit allows more time > for requests to > complete and release enough queue handles to stay > below the limit. I'm > hoping we will find some kind of JMS configuration > parameter that has > been set incorrectly which can release handles > quickly. > > Peter Heggie > > -Original Message- > From: MQSeries List [mailto:[EMAIL PROTECTED] > On Behalf Of Wyatt, > T. Rob > Sent: Wednesday, March 17, 2004 11:01 AM > To: [EMAIL PROTECTED] > Subject: Re: JMS resource problems after 254 > 'connections' ? > > Peter, > > I agree that the number sounds suspicious. > Especially in relation to > messages as opposed to connections. It suggests the > app is making a new > connection for each message and not releasing them. > Have you checked > for > that? > > Alternatively, what kind of logging are you using > and are all the > messages > in a single unit of work? > > -- T.Rob > > -Original Message- > From: Heggie, Peter > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 17, 2004 10:05 AM > To: [EMAIL PROTECTED] > Subject: JMS resource problems after 254 > 'connections' ? > > > Has anyone encountered a problem with a MQ to JMS > environment, where a > synchronous transfer (request/reply) encounters a > 'Resouce Exception' > after 245 reply messages are processed? > > We have an MQ to PeopleSoft environment where we > send messages from an > MQ application via JMS to the PeopleSoft Integration > Broker, which then > sends a PS message to a PS component. When PS sends > a reply back to the > PS Integration Broker, after 254 replies have been > received by the > Integration Broker (and passed on to JMS & MQ), the > 255th reply causes a > JMS resource exception. > > The number 254 is very suspicious, but also, I would > perfer eliminating > a 'limit number' altogether, rather than just > raising it. > > Has anyone seen something like this before? > > > This e-mail and any files transmitted with it, are > confidential to > National > Grid and are intended solely for the use of the > individual or entity to > whom > they are addressed. If you have received this > e-mail in error, please > reply > to this message and let the sender know. > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list > subscription are provided in > the Listserv General Users Guide available at > http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS resource problems after 254 'connections' ?
More information - the source of the '254' connections is the MQ queue manager MAXHANDS attribute. When we raised it, we immediately were able to run more transactions before encountering exceptions. The new number we could run exactly matched the new MAXHANDS value, minus 2. We tried explicitly closing the temporary queues as soon as we received the reply on them, but we still encountered exceptions (in PeopleSoft) after the limit was reached. >From a distance, it looks like PeopleSoft's implementation of JMS is not releasing the queue handles. We will try to test more with a much higher limit, and see if the higher limit allows more time for requests to complete and release enough queue handles to stay below the limit. I'm hoping we will find some kind of JMS configuration parameter that has been set incorrectly which can release handles quickly. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Wednesday, March 17, 2004 11:01 AM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Peter, I agree that the number sounds suspicious. Especially in relation to messages as opposed to connections. It suggests the app is making a new connection for each message and not releasing them. Have you checked for that? Alternatively, what kind of logging are you using and are all the messages in a single unit of work? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 10:05 AM To: [EMAIL PROTECTED] Subject: JMS resource problems after 254 'connections' ? Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application via JMS to the PeopleSoft Integration Broker, which then sends a PS message to a PS component. When PS sends a reply back to the PS Integration Broker, after 254 replies have been received by the Integration Broker (and passed on to JMS & MQ), the 255th reply causes a JMS resource exception. The number 254 is very suspicious, but also, I would perfer eliminating a 'limit number' altogether, rather than just raising it. Has anyone seen something like this before? This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS resource problems after 254 'connections' ?
Thanks - We are trying to check for connection pooling but are not familiar enough with the products to see where that attribute is set or being modified. So far, we don't see anything in the JMS Bindings file that looks like a parameter for connection pooling, but maybe it has been left out. We have not gotten any documentation or information from PS as to whether they use connection pooling. Your other two comments are provoking.. logging - do you think that logging may be started on a per-message / connection basis, and there is some kind of limit on log files or threads for logging? The unit-of-work question is also new - I had assumed that going from MQ to JMS to PS and back would not involve a unit of work, simply because the request is traversing three different systems. Our calling application is not specifying an MQBegin before sending a messsage. I'm not sure if the JMS Bindings file can specify a parameter pertaining to unit-of-work, or if the PS JMS Listening Connector is XA compliant. I will ask. -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Wednesday, March 17, 2004 11:01 AM To: [EMAIL PROTECTED] Subject: Re: JMS resource problems after 254 'connections' ? Peter, I agree that the number sounds suspicious. Especially in relation to messages as opposed to connections. It suggests the app is making a new connection for each message and not releasing them. Have you checked for that? Alternatively, what kind of logging are you using and are all the messages in a single unit of work? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 10:05 AM To: [EMAIL PROTECTED] Subject: JMS resource problems after 254 'connections' ? Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application via JMS to the PeopleSoft Integration Broker, which then sends a PS message to a PS component. When PS sends a reply back to the PS Integration Broker, after 254 replies have been received by the Integration Broker (and passed on to JMS & MQ), the 255th reply causes a JMS resource exception. The number 254 is very suspicious, but also, I would perfer eliminating a 'limit number' altogether, rather than just raising it. Has anyone seen something like this before? This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: JMS resource problems after 254 'connections' ?
Peter, I agree that the number sounds suspicious. Especially in relation to messages as opposed to connections. It suggests the app is making a new connection for each message and not releasing them. Have you checked for that? Alternatively, what kind of logging are you using and are all the messages in a single unit of work? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 10:05 AM To: [EMAIL PROTECTED] Subject: JMS resource problems after 254 'connections' ? Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application via JMS to the PeopleSoft Integration Broker, which then sends a PS message to a PS component. When PS sends a reply back to the PS Integration Broker, after 254 replies have been received by the Integration Broker (and passed on to JMS & MQ), the 255th reply causes a JMS resource exception. The number 254 is very suspicious, but also, I would perfer eliminating a 'limit number' altogether, rather than just raising it. Has anyone seen something like this before? This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
JMS resource problems after 254 'connections' ?
Has anyone encountered a problem with a MQ to JMS environment, where a synchronous transfer (request/reply) encounters a 'Resouce Exception' after 245 reply messages are processed? We have an MQ to PeopleSoft environment where we send messages from an MQ application via JMS to the PeopleSoft Integration Broker, which then sends a PS message to a PS component. When PS sends a reply back to the PS Integration Broker, after 254 replies have been received by the Integration Broker (and passed on to JMS & MQ), the 255th reply causes a JMS resource exception. The number 254 is very suspicious, but also, I would perfer eliminating a 'limit number' altogether, rather than just raising it. Has anyone seen something like this before? This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
