| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Trying to make orphaned connections into my QM. |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Thu Jan 06, 2005 5:48 am Post subject: Trying to make orphaned connections into my QM. |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQClient
VB.NET application (with CSD08 version of amqmdnet.dll)
Windows XP SP1
MQ 5.3 CSD08
QM
Windows 2000
5.3 CSD08
I connect to the QM and open the queue. I want to end my app somehow so that it leaves an orphaned connection into the QM, so that after 2 hours Keep Alive sees the orphaned socket, and ends the connection. Yet I can't end my VB.NET app so that it leaves a connection to the QM. As soon as my exe ends, there must be some sort of garbage collection or something that .NET does that destroys the queue object and the QM object, effectively telling the QM right away that the connection is closed. Even though I skip the Q.Close method and the QM.disconnect method, everything gets disconnected cleanly when the exe ends
How can I end my VB.NET app so it leaves an orphaned connection that Keep Alive will see and eliminate? Or is VB.NET "better, smarter" than Java, and there is no way to leave a connection to the QM/Queue that is truly orphaned, i.e. an orphaned connection being something that uses a SVRCONN instance, but will not actually continue to consume message, and something that Keep Alive will clean up.
I would also like to reproduce the error message that I see all over my
error logs, so that I can show the apps, "See, if you don't clean up after
yourself like I purposely did in this sample program, then you dirty up my
error logs with these errors.". But again, I can't seem to recreate them
with .NET. Yet I have hundreds of these errors, from all different hosts, on my live queue managers.
What I want to create:
| Code: |
AMQ9208: Error on receive from host abcqax1 (123.456.789.000).
EXPLANATION:
An error occurred receiving data from abcqax1 (123.456.789.000) over TCP/IP.
This may be due to a communications failure.
ACTION:
The return code from the TCP/IP (recv) call was 10054 (X'2746'). Record
these
values and tell the systems administrator.
|
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Thu Jan 06, 2005 6:10 am; edited 1 time in total |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Thu Jan 06, 2005 5:59 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Peter,
I am no expert on .NET as I am self taught but my understanding is that .Net will do the cleaning up for you.
You may be able to get a connection left open if you totally crash the machine or use TCPIP to kill the connection. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 06, 2005 11:37 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
By yanking the cable out of my pc that was running the MQClient, I was able to get the QM to right that error to the error log. But the connection into the QM was stilled cleaned up within a few seconds.
So I know all my application servers are not yanking their cables, and I know our network is not that flaky, so how am I getting all those errors in the error logs?
Is it because when .NET MQCONNs, MQOPENs, MQGETs, and just ends, MQ is cleaned up, but if Java MQCONNs, MQOPENs, MQGETs, and just ends, it leaves orphaned connections?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 06, 2005 1:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
In JMS I 've seen the connections getting cleaned up on exit of the VM
(System.exit(int x)). (running finalizer and gc will probably help too)
Don't know how the cleanup is being handled in base java.
Anyway you don't want to leave the cleaning up to the garbage collector as this is not timely enough. You may have run out of resources long before the gc kicks in.
F.J. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 06, 2005 1:23 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Peter, you can also try using Environment::Exit in .NET to cause your process to abend, rather than a "clean" quit.
This may allow you to simulate the same thing in .NET.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 07, 2005 1:45 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQCONN, MQOPEN, MQGET with 20000 WAIT, yank the cable---> As soon as the MQGET with wait ends, the QM drops the orphnaed q handle and connection. My theory is that the QM tries to send the 2033 error back to the client, sees that there is no one on the other end, and immediatly drops the orphaned channel. 10054 error is written to the error log. If the Get With WAIT is long enough, the Heartbeat Interval sees the other side is gone, and again the orphaned connection is dropped.
MQCONN, MQOPEN, yank the cable (while there is no outstanding MQ API call)---> The orphaned connection is maintained. Heartbeat Interval passes with no change (as expected). When Keep Alive Interval is passed (I asked the SA to switch it to 900 seconds), the orphaned connection is dropped. Multiple 10054 errors are written to the error log, first one when I yanked the cable, and the last one at Keep Alive time. (Why not just one error at Keep Alive time?)
MQCONN, MQOPEN, end the .exe---> The orphaned connection is immediatly dropped. No error in the error logs.
So it looks like in .NET, there is no way to end the app without some sort of cleanup occurring and the QM immediatly knowing the other side is gone, and the connection is cleaned up. The only way to get the errors is by yanking the cable.
But apparently in Java, ending the app, even gracefully, will leave orphaned connections if the app does not explicitly MQCLOSE and MQDISC. I wish I know Java well enough to test this out.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 07, 2005 1:49 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I am making a guess here.
The .NET interface is actually using a DCOM object or COM+ object to give you the MQ .NET API.
The connections are handled by the DCOM system services.
So when your app dies, the DCOM system services notice this, and clean up.
The standard JVM does not include such a thing - and you wouldn't want it to. You want the JVM to end completely when your app ends.
I am probably using DCOM and COM+ inaccurately here.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 07, 2005 1:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter,
Did the test in following manner under JMS quite some while ago...
Used transacted sessions.
Connected, created session, sender, send msg ...
throw exception to the main no closing of connection
-- connection remains open
exit JVM (System.exit(int x))
-- connection released no msg in queue (uncommitted rolled back)
-- JVM exit triggers finalizer and garbage collection
So like in .NET when you exit the CLR there is a cleanup
Now try the following :
Kill the .NET process before it releases the resources and the resources may stay active.
Can't remember what happens if you kill the JVM and do not exit it gracefully.
Enjoy |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 07, 2005 1:58 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
Now try the following :
Kill the .NET process before it releases the resources and the resources may stay active.
Enjoy |
As soon as the VB.NET exe ends, no matter how it is killed, the connections get cleaned up. At least in my tests they are.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 07, 2005 2:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter,
Is there a way to kill the .NET framework before you kill the VBNET.exe application ?
Would the resources stay active in such a case ?
F.J. |
|
| 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
|
|
|
|
