| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Connection problems - again |
« View previous topic :: View next topic » |
| Author |
Message
|
| Ruthie |
 Posted: Thu Jul 11, 2002 9:56 am Post subject: Connection problems - again |
 |
|
Newbie
Joined: 21 May 2002
Posts: 6
|
 I'm managing a queue manager for a client who keeps maxing the connections. They are using java for the application with the mq.jar and mqjms.jar. They maxed out connections this morning and when I did a netstat, I showed 1383 connections on port 1414 !!!!!! Most of these were in CLOSE_WAIT status. We rebooted the server and restarted the app - I now show 93 connections - all in ESTABLISHED state, and they show 14.
The client made a change to their app this morning to change the message persistence and expiry, but they did not change anything with the connection. They saw 2009's on their side at the time of 1383 connections, but since we rebooted, nothing - no errors on either side.
The queue manager is on a Windows NT 4.0 server, sp 6a. MQ Version 5.1, CSD06. (High number of connections on my side is quite normal, but this is ridiculous.) The client is connecting to the server over a secure VPN tunnel through the internet. This has worked for the last 2 years and the only error we see often is 9208 (connection reset by peer).
Any suggestions, comments, or good insight on what I could/should do to fix the problem? |
|
| Back to top |
|
 |
| oz1ccg |
| Posted: Fri Jul 12, 2002 3:03 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Hi Ruthie,
tell the developers to do an MQCLOSE and MQDISC, well it's doen otherwise in JAVA, I know that, but from a sysprog. point of view that's way.
I hope it helps.
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| Ruthie |
| Posted: Fri Jul 12, 2002 4:27 am Post subject: |
|
|
Newbie
Joined: 21 May 2002
Posts: 6
|
The client is using java (weblogic) and they report that they are issuing the MQCLOSE and MQDISC.
The problem seems to be that weblogic is closing the connections but the MQ server does not see them close and treats them as still open and valid.
Another problem is that if weblogic runs into a problem sending a message, it SEEMS to close what it considers a "bad" connection and open a new one, but the MQ server, again, does not see that "bad" connection as closed.
This problem has been ongoing for quite some time, but since I don't code, and the client doesn't manage the server, we are having a problem figuring out the root cause of it. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Fri Jul 12, 2002 5:34 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well this is sort of cheapo fix
1 Using runmqsc you can do the following
dis chs(CLIENT.CHANNEL.NAME) BYTSRCVD BYTSSENT JOBNAME
2) after X amout time if the above are not changing you can kill
the process defined by JOBNAME, note the JOBNAME has to fields in it
one is the process number(last half), Iam not sure what the other is
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| Ruthie |
| Posted: Fri Jul 12, 2002 7:10 am Post subject: |
|
|
Newbie
Joined: 21 May 2002
Posts: 6
|
Thanks. The first part of the number from jobname is the listener the channel is connected to. The second part is the job id of the child process from that listener, which I cannot easily kill - need special software to even see it.
Any other ideas?
|
|
| Back to top |
|
|
| mrlinux |
| Posted: Fri Jul 12, 2002 7:57 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Thats right, forgot that NT only runs one instances of the listener program
and creates threads for each channel.
Ok, I have another Idea, I tested this just a little and it might work for you
Please test this first in your enviroment.
1) Issue stop channel(SVRCONN.CHANNEL.NAME) mode(QUIESCE)
This will stop all non-active channels only, If someone has app running
it will continue to run.
2) Issue start channel(SVRCONN.CHANNEL.NAME)
The only time you may have an issue is, when someone tries to connect
between steps 1 & 2, if you put this in a script file this will minimize this
time.
I know this is a really cheesy Idea, but it may work for you
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| taran4u |
| Posted: Tue Sep 23, 2003 11:21 pm Post subject: Using Weblogic's InitialContext, MA88 support pac |
|
|
Newbie
Joined: 23 Sep 2003
Posts: 3
|
Hi
I am using MA88 support pac and using Weblogic's initialcontext for running MqSeries on Win NT.
When trying to run JMSAdmin and trying to create QueueConnectionFactory it is not creating it and giving me execption as :
[1064320345531] [main] com.ibm.mq.jms.admin.AdminService@480bc51f Throwing javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: com.ibm.mq.jms.MQQueueConnectionFactory
I am writing down the steps that I followed:
1. Running JMSAdmin using
JMSAdmin -t -v -cfg <JMSAdminConfigFileName>
2. On start of JMSAdmin and getting the Initial COntext of weblogic running at t3://localhost:7001, I get
InitCtx> // as command input.
3. I created one Context
InitCtx > def ctx(xyz)
4. Changed the context
InitCtx > chg ctx(xyz)
5. Tried to create connectionfactory using following command:
def qcf(ptpQcf) transport(CLIENT) channel(SenderCH) qmanager(QMgr) host(t3://localhost:7001)
I am getting error as specified.
As of I understand it is not a error of Classpath as since JMSAdmin is already started so it is taking classes from the com.ibm.mqjms.jar only but it is not been able to get the MQQueueConnectionFactory class lying in the same jar file ??
If you can help me it will be of great help to me.
Thx in advance |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 24, 2003 5:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jeff, you wrote:
| Quote: |
1) Issue stop channel(SVRCONN.CHANNEL.NAME) mode(QUIESCE)
This will stop all non-active channels only, If someone has app running
it will continue to run.
|
If the client app has coded the FAIL_IF_QUIESCING option, I would think the legitimate instances of the app that are running at this moment will get dropped at their next MQ API call, no?
Ruthie,
I don't care what the app says, I bet you they are not closing and disconnecting. Just because they say they are probably means a developer found the close method somewhere and the disconnect method somewhere. Is that branch of code called 100% of the time, out of every try/catch? I bet anytime the code errors, it ends without closing and disconnecting first. I've seen it a thousand times... 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
