Author |
Message
|
niraj.chaudhary |
Posted: Tue Nov 20, 2007 10:18 pm Post subject: Too many channels open |
|
|
Novice
Joined: 20 Jun 2007 Posts: 22 Location: UK
|
Hi all,
We are using MQ server and MQ client (both 6.0) on solaris boxes. The abpplication is using JMS implementation to access MQ. From last few weeks, we are getting error while sending the message from application (reason code 2059).
An MQ consultant told us that this is because too many channels are open and most probably these are not closed properly from application. Following is the our code:
try
{
if (queueConnectionFactory != null)
{
queueConnection = queueConnectionFactory.createQueueConnection();
queueSession = queueConnection.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);
queueSender = queueSession.createSender(queue);
Message message = queueSession.createTextMessage(msg);
queueSender.send(message);
logger.log("Message send [(putMessage())]" ,"");
}
}
catch (Exception e)
{
logger.log("Exception while sending the message["+e.getMessage()+"] [(putMessage())]" ,"");
throw e;
}
finally
{
try
{
logger.log("Closing Connection [(putMessage())]" ,"");
queueSession.close();
queueConnection.close();
queueSender.close();
}
catch (Exception e)
{
logger.log("Exception while closing the queueSession["+e.getMessage()+"] [(putMessage())]" ,"");
throw e;
}
}
Am I missing some thing here? Can any body help ?
Thanks in advance!
Niraj |
|
Back to top |
|
 |
Gaya3 |
Posted: Tue Nov 20, 2007 10:22 pm Post subject: |
|
|
 Jedi
Joined: 12 Sep 2006 Posts: 2493 Location: Boston, US
|
Hi
There is some thing called TCPAlive, this parameter you have to set it.
This also play the vital role.
This issue happens when the channel process pollutes.
Regards
Gayathri _________________ Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
Back to top |
|
 |
Vitor |
Posted: Wed Nov 21, 2007 1:36 am Post subject: Re: Too many channels open |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
niraj.chaudhary wrote: |
From last few weeks, we are getting error while sending the message from application (reason code 2059).
An MQ consultant told us that this is because too many channels are open |
If you'd hit max channels from a client I'd have expected 2009 or 2019 personally!
Under what circumstances do you get the 2059? Is it under times of extreme load when a lot of clients are attached? Or do you run for a while and then all the clients start throwing 2059s?
Gaya3 wrote: |
There is some thing called TCPAlive, this parameter you have to set it |
Really?
Gaya3 wrote: |
This issue happens when the channel process pollutes.
|
What?  _________________ Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Wed Nov 21, 2007 1:49 am; edited 1 time in total |
|
Back to top |
|
 |
Gaya3 |
Posted: Wed Nov 21, 2007 1:48 am Post subject: |
|
|
 Jedi
Joined: 12 Sep 2006 Posts: 2493 Location: Boston, US
|
Hi
I'm damn sure...if he sets the TCPAlive properly he will get rid off this problem......
This issue happens when the channel process pollutes. (lots of orphan process will be remaining.....with out cleaning) I bet on this...
Regards
Gayathri  _________________ Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
Back to top |
|
 |
niraj.chaudhary |
Posted: Wed Nov 21, 2007 5:33 am Post subject: |
|
|
Novice
Joined: 20 Jun 2007 Posts: 22 Location: UK
|
Vitor,
I am getting it when the application is running for a while and then all the clients are throwing 2059. I have a little idea about MQ, but the guy (referred to as MQ consultant in eariler post ) did some thing called 'bouncing', which apparently fixed it for a while, but after some time we are getting the same error again.
Do you have any idea?
Gayathri,
Thanks for your response. But, I am not sure where can I set this parameter 'TCPAlive' & how. I am using Weblgoic 8.1 and the application implements MDB.
Niraj |
|
Back to top |
|
 |
Vitor |
Posted: Wed Nov 21, 2007 5:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
niraj.chaudhary wrote: |
the guy (referred to as MQ consultant in eariler post ) did some thing called 'bouncing', which apparently fixed it for a while, but after some time we are getting the same error again.
|
Typically refers to the stopping & immediate restarting of a queue manager, which does indicate a resource issue. Shows what I know.
On that basis I'll leave it to Gaya3 to explain his solution in detail.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Gaya3 |
Posted: Wed Nov 21, 2007 6:06 am Post subject: |
|
|
 Jedi
Joined: 12 Sep 2006 Posts: 2493 Location: Boston, US
|
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Nov 21, 2007 6:41 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Vitor,
I think he was getting a 2059 on new connection attempts, which makes sense if the QM has hit max active channels. 2009 and 2019 will be returned for existing connections that drop, but existing connections won't drop just because max active channels was hit.
Gaya,
TCP Keep Alive will only help if the problem of to many channels is caused by orphaned conections (the app ends without issuing MQDISC). If the app creates too many channels and just keeps adding new connections to the pool TCP Keep Alive will do nothing. Its not going to clean up good connections to the QM, even if there are to many of them.
TCP Keep Alive is a way for an MQ Admin to try and protect himself from poorly written apps that don't disconnect when they are done. The real solution is for the app to close its connections when its done, or reuse existing connections instead of reconnecting over and over until max channels is hit.
Niraj,
Keep Alive is first turned on at the server level by the System Admin, and then the MQ Admin tells the Queue Manager to use that value. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Nov 21, 2007 12:20 pm Post subject: Re: Too many channels open |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
niraj.chaudhary wrote: |
Following is the our code:
try
{
if (queueConnectionFactory != null)
{
queueConnection = queueConnectionFactory.createQueueConnection();
queueSession = queueConnection.createQueueSession(false,Session.AUTO_ACKNOWLEDGE);
queueSender = queueSession.createSender(queue);
Message message = queueSession.createTextMessage(msg);
queueSender.send(message);
logger.log("Message send [(putMessage())]" ,"");
}
}
catch (Exception e)
{
logger.log("Exception while sending the message["+e.getMessage()+"] [(putMessage())]" ,"");
throw e;
}
finally
{
try
{
logger.log("Closing Connection [(putMessage())]" ,"");
queueSession.close();
queueConnection.close();
queueSender.close();
}
catch (Exception e)
{
logger.log("Exception while closing the queueSession["+e.getMessage()+"] [(putMessage())]" ,"");
throw e;
}
}
Am I missing some thing here? Can any body help ?
Thanks in advance!
Niraj |
Yes you missed a whole lot.
Review your finally block.
You should have a try catch finally block in there for each operation:
- sender.close()
- session.rollback()
- session.close()
- connection.close()
Because if any of those operations is throwing an exception you are not getting to the next operation and thus not closing the connection.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
niraj.chaudhary |
Posted: Wed Nov 21, 2007 10:31 pm Post subject: |
|
|
Novice
Joined: 20 Jun 2007 Posts: 22 Location: UK
|
fjb_saper wrote:
Quote: |
Yes you missed a whole lot.
Review your finally block.
You should have a try catch finally block in there for each operation:
sender.close()
session.rollback()
session.close()
connection.close()
Because if any of those operations is throwing an exception you are not getting to the next operation and thus not closing the connection.
|
Got your point! Will change my finally block. But, say if none of the close operation threw any exception, then it will ensure that channel is closed. isn't it? So, I shoudln't be in a situation where there are too many channels open. But that's not what's happening.
Niraj |
|
Back to top |
|
 |
niraj.chaudhary |
Posted: Wed Nov 21, 2007 11:51 pm Post subject: |
|
|
Novice
Joined: 20 Jun 2007 Posts: 22 Location: UK
|
There is one more thing. When one is implementing onMessage() to receive the messages, what about receiever.close()? Can it be the reason for too many channels open or is it some thing that's taken care automatically? |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Nov 22, 2007 4:35 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Depends if you're doing a stand alone or an MDB.
On a stand alone you should - stop the connection
- set the listener to null
- close the receiver
- depending on what you do rollback the session
- close the session
- close the connection
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
niraj.chaudhary |
Posted: Thu Nov 22, 2007 5:06 am Post subject: |
|
|
Novice
Joined: 20 Jun 2007 Posts: 22 Location: UK
|
It is an MDB and I am opening a connection, only when I need to send the message. While sending...
1. obtain the connection from queue connection factory
2. obtain the session from connection
3. obtain sender from session
4. send message
5. close session
6. close connection.
Still the SVRCONN channels remain open. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Nov 22, 2007 5:28 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
The channel remains open because the appserver (WAS?) transaction handling supersedes MQ's transaction handling and the transaction is not committed. Also once released the connection goes back into the JMSConnectionPool so you need to look at both aspects of things.
a) transaction handling of the MDB method
b) JMSConnectionPool properties...
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
niraj.chaudhary |
Posted: Thu Nov 29, 2007 4:01 am Post subject: |
|
|
Novice
Joined: 20 Jun 2007 Posts: 22 Location: UK
|
One of the Mq consultant suggested using IBM's jms libraries instead of using BEA jms libraries. (I am using weblogic 8.1sp4).
While I have the jms.jar file that comes along with mq installation in the classpath, it comes after weblogic.jar (having bea's jms lib). Does it mean that my application is using BEA's jms lib? Or, is it otherwise??
what do you guys say on this??
One more thing, isn't SVRCONN initiated by MQ client? if it is so, then it should be MQ client, who should be closing it?
sorry, if i am talking like a novice. but after all i am one.
niraj |
|
Back to top |
|
 |
|