| Author |
Message
|
| bcostacurta |
 Posted: Tue Jul 19, 2011 7:00 am Post subject: J2EE-JMS pool and client channel unreleased connections |
 |
|
Acolyte
Joined: 10 Dec 2009
Posts: 71
Location: Luxembourg
|
Hello,
one of my client has a J2EE application hosted on WAS v7 using MQSeries v6 on Unix.
Briefly, the JMS pool connection setups are :
- Aged Timeout=900
- REAP=1800.
- Minimum connection is 1, max is 10.
However the connections on the channel client used by the application (Message Drive Bean) are not released as a lot of (all ?) connections remains opened for days until its client channel is stop in mode Force to avoid saturation of MaxActiveChannels.
In which direction can I dig for this type of problem ?
Is there a way to trace more deeply the client channel opened connection and activity ?
Some impact of Timeout and Keep Alive on the IP setup ?
The MQseries use dthe KeepAlive = YES stanza in qm.ini
Unfortunately as an outsourcing company we do not have the code of this application from one of our client.
Thanks for any clue or idea.
Bye,
Bruno |
|
| Back to top |
|
 |
| George Carey |
| Posted: Tue Nov 01, 2011 2:44 pm Post subject: same problem space |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Ok, I am in the same problem space as this person (and I see he got a lot of responses) but I will try anyway.
I too am getting channels connections that build up over time from an app server client connections to MQ QMGR. The app server is Oracle (not WLS) and the Oracle RA is being used and the MQ client Jar files are version 7.0 (not sure may be some version of 6.x). But have a similar problem as above post where client channel connections grow over time. An app server java bean is used to put a soap message to a request queue and an MDB is used to listen for incomnig response soap messages and failures on reading the soap message put the bad message out to an error queue.
So I would think that the likely number of channels from this appserver would be three. One in the MQGET substate and two in the Receiving substate for the three separate queues.
However, I see 1, then I see 2 , then I see 3, then they seem stable for a while then I see them grow over time slowly.
The MDB and regular bean appear to have code that does appropriate closing and disconnections.
But lets start with the basics, how many connections should I see initially at start up and what determines the number of initial client connections when the containers for these Beans are started ?
I am trying to get to square one numbers and go from there. Not an appserver admin and can't get answer to this question from those that 'supossedly' are ??
Any feedback appreciated.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 01, 2011 8:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
OK... There is out somewhere an article (maybe from developerworks) that specifies what you should set as pool reap parameters if you are doing XA.
I suspect strongly that your left over connections may be connections that were reaped by the pool before the final commit could be issued...by the app server (XA).
Does the qmgr think it has long running transactions?
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Nov 03, 2011 10:05 am Post subject: transactions |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
1st, Thanks for bothering to respond.
No there are no open transactions on any of the queues. And in general there should be no long running transactions.
Not sure how a 'pool reaper' should work but I would think it would not reap any JMS connection pool thread/session not released to the pool unless a sizable timer had expired or some other signaling/alerting attribute on/about the thread/session had occured.
A simple JMS send/put ,whatever, to a request queue is being done and an MDB On Message() method getting from a response queue which hands off quickly with no real business processing logic to speak of going on in the method are the interactions with the QMGR from the app server.
I am trying to figure out initially just how many client channels should be active with the previous description given. And then maybe find out why/how/when new ones should be initiated. Easy to say not so easy to find out.
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 03, 2011 11:35 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As a rule of thumb:
- for each mdb: number of max instances + 1
- for each mdb needing to send a reply ... 2*number of max instances + 1
- for each "put" i.e. non mdb connections, max number of concurrent occurrences (sessions?)
Hopes that helps some in your count...
Now of course you can bunch in V7 using shareconversations but then the rule is still valid for the number of conversations...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Nov 03, 2011 12:59 pm Post subject: max instances |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
When you say max instances what are you referring to ?
Max number of MDB bean instances or something else ? If so is that an app server config item ?
If it is MDB bean instances and say max was 1 (?) then the count for the number of client channels to start would be 2 and if needing to do a reply 3 ?
Like wise the max number of concurrent occurences(sessions) where is that set ? Again an app server config item ?
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 03, 2011 7:21 pm Post subject: Re: max instances |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| George Carey wrote: |
When you say max instances what are you referring to ?
Max number of MDB bean instances or something else ? If so is that an app server config item ? |
Yes, that's right
| George Carey wrote: |
| If it is MDB bean instances and say max was 1 (?) then the count for the number of client channels to start would be 2 and if needing to do a reply 3 ? |
you got it.
| George Carey wrote: |
Like wise the max number of concurrent occurrences(sessions) where is that set ? Again an app server config item ?
GTC |
Yes the max number of sessions is an app server config. Be aware that this is a potential max number. For it to be effective, each session would need to access MQ at the same time. I do not expect this to happen as I'm sure your users have other pages to use and view... but the potential is there.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
