| Author |
Message
|
| izhelezn |
 Posted: Sun Jul 10, 2005 9:33 am Post subject: 2195 (Unexpected Error) starts to be thrown upon inactivity |
 |
|
Newbie
Joined: 10 Jul 2005
Posts: 2
|
Hello! Hope somebody can help!!
We are experiencing an issue where the MQ Java API on the Windows 2000 Client side (running as a part of enterprise application on IBM WAS) starts throwing 2195 (Unexpected Error) MQ Exceptions while communicating to MQ 5.2 Server on AIX.
MQ Completion Code = 2 ; MQ Reason Code = 2195
My issue is that the code works fine most of the time. The connections to the Queue Manager are allocated by Java code at the start of the application (start of day) and are being stored in the pool from where they retrieved and returned back by the app and are fine for about 12 hours of operations with a load of about dozens requests per minute.
The application is then being inactive for about 4 hours (no activity at all). Then, when attempt to use the app is made again, the 2195s start to appear for EACH request and we have to restart WAS to resolve.
Does anyone know if a connection to a queue manager can expire under 5.2? Are there any issues with compiling code with MQ 5.3 jars but running 5.2 in production? Can it have to do with memory available on the server?
This problem is reported by a Client so I do not have a direct access to that environment and can't replicate locally. I do not have FDC logs from the server right now but I will at some point.
Also, are there FDC logs on the Client side (under WAS, etc)?
Any suggestions at all???
Thank you! and sorry if any of this sounds not very intelligent.
Igor. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun Jul 10, 2005 7:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As I understand it you are not running in bindings but with a client connection.
There should be no downside to running with the 5.3 or even 6.0 jars...
Enjoy  |
|
| Back to top |
|
|
| punktoad |
| Posted: Thu Aug 11, 2005 8:38 am Post subject: Similar situation |
|
|
Newbie
Joined: 11 Aug 2005
Posts: 1
|
I have a similar situation.
5.3 server
Windows 2000 Java client
? version of MQ jars
Our connections are not pooled and are created as needed. The transaction rate is similar. We randomly experience the issue which happens when trying to connect to the queue manager.
The client application is running in 1.3.1 JVM...not sure if that will cause any issues...unfortunately, this cannot be changed.
If someone has some additional suggestions to check out, I'd appreciate it. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 11, 2005 11:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Client connections are not as stable as a bindings connection and subject to network failures and shortfall of bandwidth etc....
If you need a reliable connection why not use a qmgr to qmgr connection and a bindings connection to the qmgr ....
Enjoy |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 11, 2005 11:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It doesn't sound like a similar situation at all.
It merely sounds like a problem with connections.
If you disconnect and then connect rapidly in Java, you can very easily fill up the available connection pools.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tkane |
| Posted: Thu Aug 11, 2005 12:42 pm Post subject: |
|
|
Voyager
Joined: 23 Dec 2002
Posts: 82
Location: Kansas City
|
Is there by any chance a firewall between the client and the queue manager? We've had issues where the firewall permitted us through as we instructed but had a bad timeout behavior. I don't remember the details but it was terminating socket connections.
I'm not sure that I'd even recommend keeping a network session open for that length of time. Making a comparison to sdr/rcvr channel pairs we had tons of problems back in the 90s when we ran our channels with discint(0) and kept them up all the time. Since we've been disconnecting them with 10 minutes of inactivity we have many fewer channel failures to recover from.
Of course the product has gotten a lot better in those 5+years. But we've also grown from 20 queue managers to over 300 and don't have near the grief that we had back prior to 5.2.
Good Luck
Tom |
|
| Back to top |
|
|
|
|
