| Author |
Message
|
| aayteka |
 Posted: Wed Dec 27, 2006 12:36 am Post subject: Remaining / increasing MQ connections |
 |
|
Novice
Joined: 26 Dec 2006
Posts: 15
|
hi,
We have a system that has a central Websphere MQ Server and multiple MQ Agents (Java applications using MQ API, mq.jar). Every agents connect 3 Queues with using a server-connection channel.
The problem is the remaining connections after the agent processes die. The max channel count is set to 400 and everytime the application connection count aproaches this number we have manually close connection with MQ Explorer.
How can I handle this issue if there is a persistenst solution?
Or how can I close all inactive connections?
Queue Manager initialization method
public void initialize(String queueManagerName, String hostName,
String channelName, int port) throws MQException {
if(connectionManager==null)
{
connectionManager=new MQSimpleConnectionManager();
connectionManager.setActive(MQSimpleConnectionManager.MODE_AUTO);
connectionManager.setTimeout(60*60*1000);
MQEnvironment.setDefaultConnectionManager(connectionManager);
}
MQEnvironment.hostname = hostName; // host to connect to
MQEnvironment.port = port; // port to connect to. If I don't set this,
MQEnvironment.channel = channelName; // the CASE-SENSITIVE name of
queueManager = new MQQueueManager(queueManagerName);
}
Websphere MQ, Version 6.0 on Redhat
Agents are running on different configurations.
thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Dec 27, 2006 12:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You need to ensure the agents clean up properly on death.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aayteka |
| Posted: Wed Dec 27, 2006 12:55 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 15
|
Thanks for your quick reply.
What should I clean on death? We may kill processes or the machine can be shutdown so we may not do anty clean up on death. |
|
| Back to top |
|
|
| aayteka |
| Posted: Wed Dec 27, 2006 1:07 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 15
|
Also in the agent machine, I ensure that there is no related (port 2414) line at the output of "netstat -an" command.
MQ Connection port: 2414 |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 27, 2006 1:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The agents should disconnect properly when they terminate (using a catch block if necessary). The connection is being held at the server end hence your netstat is not showing anything client side.
If you're killing the agents with kill-9 or similar so they don't have a chance to clean up then this is something you're just going to have to live with (or change your procedures!). 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aayteka |
| Posted: Wed Dec 27, 2006 1:34 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 15
|
We have a shutdown procedure that call disconnect method. But I think the exceptional cases should be handled.
While connecting to server I have used "connectionManager.setTimeout(60*60*1000);" Is this timeout provide the clean up the remaining connections. or do we have a timeout value that is configured in the server side. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 27, 2006 1:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The server-connection channel will not timeout while there's an active connection, and the timeout you're specifing is client side. You can fiddle with (sorry, tune  ) the server side to adjust the KeepAlive; search the forum for some threads about how various people have dealt with this.
Bottom line - if there's an exceptional situation you have to take exceptional actions.
Longer term you might want to consider running inside a Websphere App Server & using connection pooling. At additional cost obviously, so you'd need to weigh it up carefully.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aayteka |
| Posted: Wed Dec 27, 2006 4:39 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 15
|
Although I have found a lot of similar (most of them are same) issues in the forum, I didn't find a proper solution. Most of the threads, its written that "check keepalive" "check heartbeat". But this is just a product not a research topic. And also we have a running application in an airport and we need exact solution. I think the official ibm support and documentation is not enough and the product is not stable.
Anyway, thanks for your help,
Just one question, is there a way to close the remaining channel connections (more than 150 channels remaining from the last 3-4 months) |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Dec 27, 2006 4:51 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| I think the official ibm support and documentation is not enough and the product is not stable. |
You are wrong. The problem is clearly caused by your apps failing to disconnect from the qmgr when they end. In such a case, the connection will be maintained in cae it is still active. Look at this from the converse point of view - if the connection were still active then it would be bad if the qmgr closed the connection unilaterally.
As already suggested, you need to set the keepalive interval on the machines such that a period of inactivity causes the connectoin to be closed.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 27, 2006 4:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aayteka wrote: |
| I think the official ibm support and documentation is not enough and the product is not stable. |
It's amazing how IBM have managed to sell so many copies. You'd have thought they'd have got it right after 10 years of R&D. But we all still struggle on as best we can.
| aayteka wrote: |
| Anyway, thanks for your help, |
You're quite welcome. 
P.S. Let me know which airport. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aayteka |
| Posted: Wed Dec 27, 2006 5:49 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 15
|
Yes it is very amazing:)
Finally, I have manually stop the channel from the MQ Explorer Screen. But After I have restarted the channel, I have check the "current status" of the channel from the MQ explorer, but this stable! product still has the death connections.
Our Queue manager properties:
TCP Keep Alive = yes
Adopt new mca = NO
adopt new mca check= name,address,qm
adopt new mca timeout= 60
Our Channel properties: (we have used just 1 channel)
Type: Server-connection
Transmission Protocol: TCP
Heartbeat Interval:300
Keep AliveÝnterval: Auto
MCA User ID:
So, Nigelg do I need to Keep Alive Interval to a value greater than 300? Will it solve all the problem we have? |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Dec 27, 2006 6:06 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| Vitor wrote: |
| P.S. Let me know which airport. |
Haha, maybe it wasn't thick fog that closed Heathrow recently but some errant Java app and idle svrconn channels
| aayteka wrote: |
Although I have found a lot of similar (most of them are same) issues in the forum, I didn't find a proper solution. Most of the threads, its written that "check keepalive" "check heartbeat". But this is just a product not a research topic. And also we have a running application in an airport and we need exact solution. I think the official ibm support and documentation is not enough and the product is not stable.
Anyway, thanks for your help,
Just one question, is there a way to close the remaining channel connections (more than 150 channels remaining from the last 3-4 months) |
You can end the channels using the command
| Code: |
| stop channel(MY.CHANNEL.NAME) MODE(FORCE) STATUS(INACTIVE) conname(old_host) |
if you know which connection names are old ones. You may find that it will terminate active clients too if the same hosts have reconnected.
Using the TCP/IP KeepAlive setting in the qm.ini stanza you can have your svrconn channels automatically cleanup on the qmgr side when the client does not correctly disconnect. The KAINT parameter allows a per-channel setting. It was available on zOS in V5.3 and it was introduced in a V5.3 CSD across the distributed platforms (its recognised on my CSD12 Windows installation). However on non-zOS platforms the WMQv6 documentation states "there is no functional implementation of this parameter". I'm reading this as "it won't have any effect".
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 27, 2006 6:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aayteka wrote: |
| Will it solve all the problem we have? |
No, only allowing the applications to close down properly & preventing orphan connections is guaranteed to do that.
Have you looked through some of the other threads on this matter? Despite the product stability problems you've highlighted it is in use on a number of sites in a number of configurations, and a number of people have posted on connection best practice. You may find some useful information.
It's certainly the case that WMQ (in common with most heavily featured products) has some interesting and confusing habits. If it didn't this board would be populated only by those sad unfortunates medically unable to use a manual. But it does seem to work more or less alright for the many customers foolish enough to use it (banks, investment houses, other gullible institutions) once it's configured and the proper processes to support it are in place.
P.S. Thanks for the airport information. It will inform my itinerary choices.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 27, 2006 6:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| scottj2512 wrote: |
| Vitor wrote: |
| P.S. Let me know which airport. |
Haha, maybe it wasn't thick fog that closed Heathrow recently but some errant Java app and idle svrconn channels |
Nope - unless the Met Office have the same problem in their weather control system.
(Don't tell me they don't control the weather. It's all part of the conspiracy. Have you noticed how the weather always almost matches the forecast? Coincidence - I think not!!)
{Pause for medication}
If it was I want the programmer caught and shot. Took me ages to drive home through that.
| scottj2512 wrote: |
| However on non-zOS platforms the WMQv6 documentation states "there is no functional implementation of this parameter". I'm reading this as "it won't have any effect". |
A good translation of IBM-speak. Like "functionally stabilised" means "buy the upgrade" and "out of service" means "if you're still using this you're crazy"
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aayteka |
| Posted: Wed Dec 27, 2006 6:41 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 15
|
Hi,
In order to stop channel,
1. I have used MQ Explorer(I think this is an IBM product). I have clicked the stop and select proper fields, Then it gives the following error "Websphere MQ is unable to perform your request because the channel is not active.(AMQ4184)", Then I clicked the details of error, just the same very informative/helpful message is displayed. (The overall channel status: running)
2. I have used command line
# runmqsc QM_NAME
# stop channel(SYSTEM.ADMIN.SVRCONN) MODE(FORCE) STATUS(INACTIVE) conname(10.35.0.84)
Result is same: AMQ9533: Channel 'SYSTEM.ADMIN.SVRCONN' is not cureently active.
Result is disappointment.
Connection Count of Queue manager is still 255 (real active connection count is: 110 (with broker connections)) And I can see all the connections on the current status of channel.
For keepalive issue, we are using redhat and you mentioned we habe no solution? |
|
| Back to top |
|
|
|
|
