| Author |
Message
|
| alan.turnbull |
 Posted: Mon Nov 22, 2004 3:33 pm Post subject: Build up of established connections with com.ibm.mq.jarV5.3 |
 |
|
Novice
Joined: 28 Apr 2002
Posts: 11
|
Hi
We are running WebSphere MQ V5.3 on zlinux. Our websphere application includes the com.ibm.mq.jar in the application .ear file. This is probably the wrong thing to do, but its the way it is at present. We found that we were using the 5.1 version of the com.ibm.mq.jar and changed our .ear file to include the 5.3 version.
The result was a steady build up in the number of established MQ connections during the day eventually with the application failing getting lots of 2009 return codes requiring a restart of websphere. Reverting to the 5.1 jar the problem went away.
Does any one know why this is happening and how to fix it?
Thanks
Alan |
|
| Back to top |
|
 |
| alan.turnbull |
| Posted: Mon Nov 22, 2004 3:43 pm Post subject: further info |
|
|
Novice
Joined: 28 Apr 2002
Posts: 11
|
Hi
Just a bit of further explanation for my question above , we don't use JMS and don't use any connection pooling
Thanks
Alan |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Nov 22, 2004 8:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Hi Alan,
My first suspicion is that your application is not disconnecting properly.
Can you show us some code ?
Thanks
F.J.  |
|
| Back to top |
|
|
| alan.turnbull |
| Posted: Mon Nov 22, 2004 9:36 pm Post subject: |
|
|
Novice
Joined: 28 Apr 2002
Posts: 11
|
Hi Fj
Thanks for your reply.
I think the disconnecting is OK as we have fixed our code for that before. Our zLinux / WebSphere systems guy produced a graph of what he calls "MQ established connections" - it went through the roof the day we had V5.3 jar there - getting to around 1000 before things crashed. With the V5.1 jar it hardly registers more than 10-20. There were no application changes associated with the V5.3 jar. Im wondering that as we don't use connection pooling, if we are hitting some default behaviour with V5.3 that it doesn't release connections.
Our code is in a class that is reused from various places - our application puts request messages and gets a reply b4 disconnecting, (the disconnectAfterGet flag is true by default in the application)
Thanks
Alan
public boolean putMessagesOnQueue(String[] messagesStr) {
MQQueue putQ = null;
MQMessage putMsg;
MQPutMessageOptions pmo;
int qOpenOptions = MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING;
if (Utilities.isEmpty(messagesStr)) {
return false;
}
messageIds = new byte[messagesStr.length][];
logger.info(".putMessagesOnQueue Queue Name = " + putQStr);
try {
for (int i = 0; i < messagesStr.length; i++) {
putMsg = new MQMessage();
putMsg.format = messageFormat;
putMsg.messageType = this.messageType;
if (putMsg.messageType != MQC.MQMT_DATAGRAM) {
putMsg.replyToQueueManagerName = replyToQMgrStr;
putMsg.replyToQueueName = replyToQStr;
}
putMsg.persistence = this.persistence;
putMsg.expiry = this.expiry;
putMsg.writeString(messagesStr[i]);
pmo = new MQPutMessageOptions();
pmo.options = MQC.MQPMO_FAIL_IF_QUIESCING;
putQ = openQueue(putQStr, qOpenOptions);
putQ.put(putMsg, pmo);
this.messageId = this.messageIds[i] = putMsg.messageId;
}
closeQueue(putQ);
logMessages("putMessagesOnQueue ", messagesStr);
return (!(Utilities.isEmpty(messageId) || Utilities.isEmpty(messageIds)));
} catch (MQException mqe) {
exceptionFromMQ(mqe);
logger.error(".putMessagesOnQueue MQException", mqe);
disconnectFromMQ();
return false;
} catch (IOException ioe) {
logger.error(".putMessagesOnQueue IOException", ioe);
disconnectFromMQ();
return false;
}
}
public String[] getMessagesOffQueue() {
MQQueue getQ = null;
MQMessage getMsg;
MQGetMessageOptions gmo;
int qOpenOptions = MQC.MQOO_INPUT_SHARED + MQC.MQOO_FAIL_IF_QUIESCING + MQC.MQOO_BROWSE;
try {
String[] messagesStr = new String[messageIds.length];
for (int i = 0; i < messageIds.length; i++) {
getMsg = new MQMessage();
getMsg.correlationId = messageIds[i];
gmo = new MQGetMessageOptions();
gmo.options = MQC.MQGMO_FAIL_IF_QUIESCING + MQC.MQGMO_WAIT;
gmo.matchOptions = MQC.MQMO_MATCH_CORREL_ID;
gmo.waitInterval = waitInterval;
logger.info(".getMessagesOffQueue waitInterval " + waitInterval);
getQ = openQueue(getQStr, qOpenOptions);
getQ.get(getMsg, gmo, 4194304);
messagesStr[i] = getMsg.readString(getMsg.getDataLength());
}
closeQueue(getQ);
if ( disconnectAfterGet ) {
disconnectFromMQ();
}
logMessages("getMessagesOffQueue", messagesStr);
return (Utilities.isEmpty(messagesStr) ? null : messagesStr);
} catch (MQException mqe) {
exceptionFromMQ(mqe); //Prints error message.
disconnectFromMQ();
return null;
} catch (IOException ioe) {
logger.error(".getMessagesOffQueue IOException", ioe);
disconnectFromMQ();
return null;
} catch (Exception e) {
logger.error(".getMessagesOffQueue Exception", e);
disconnectFromMQ();
return null;
}
} |
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue Nov 23, 2004 8:20 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| What is the state of the connections that haven't gone away? Are they actually active or in close_wait? Also, were you using the base 5.3 classes or ones that were upgraded to the latest CSD? If the base ones, try with the CSD upgraded ones. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 23, 2004 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
In your put code you are disconnecting from the queue on successful completion but only disconnecting from the qmgr if the put fails for some reason.
I do not see where you open the connection to the qmgr. There is no way to ensure a clean disconnect unless all the connect points are disconnected (including the qmgr).
Enjoy |
|
| Back to top |
|
|
| alan.turnbull |
| Posted: Tue Nov 23, 2004 12:37 pm Post subject: |
|
|
Novice
Joined: 28 Apr 2002
Posts: 11
|
Hi Bower
How do I view the state of the connections? Query channel status?
Thanks
Alan |
|
| Back to top |
|
|
| alan.turnbull |
| Posted: Tue Nov 23, 2004 12:43 pm Post subject: |
|
|
Novice
Joined: 28 Apr 2002
Posts: 11
|
Hi FJ
A lot of classes use those methods and what they all do is, create the connection, put a request message, get the reply message and disconnect. Im sure the application does not leave open connections as we are aware of that issue and in past have been through and cleaned up the code in that regard.
Thanks again
Alan |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 23, 2004 12:48 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you are connecting and then disconnecting from a queue manager in rapid succession, that will be causing the problem.
The 5.3 Java classes can take a minute or more after you have issued "disconnect" to actually close the connection and clean it up. It may depend on the channel definitions, I don't remember.
I seem to remember that this was 'working as designed', but I don't remember why.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 23, 2004 8:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Here we are entering into application design and pooling vs not pooling considerations. Without knowing much more about the way your app is used I fear you will have to do with the advice so far given.
Enjoy |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Nov 26, 2004 4:50 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| netstat -a will show you the state of the tcp/ip sockets. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Sun Nov 28, 2004 12:33 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Make sure that the applications haven't copied the MQ .jar client files into other locations on the Client Application Server and referenced them in the their classpath or bundled them with other .jar files.
I ran into a similar problem when I attempted to upgrade my WMQ JAVA Client filesets from 5.3.0.0 to 5.3.0.6 on my Remote AIX5.1/WAS 4.0.0.6 Application Servers.
We discovered that in some instances the com.ibm.mq.jar file was being referenced by the WebSphere classpath in as many as four different places by certain applications. As long as all four instances of the com.ibm.mq.jar file were the same it didn't appear to have any adverse impact but the minute the 5.3.0.6 version of com.ibm.mq.jar and the other .jar and properties files were placed in /usr/mqm/java/lib, ALL HELL BROKE LOOSE!"
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
|
|
