| Author |
Message
|
| fjb_saper |
 Posted: Thu Jan 31, 2008 4:09 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| GMcCarthy wrote: |
AMQ8276: Display Connection details.
CONN(479236B523CAE6AB)
EXTCONN(414D51434C4E584D5153503120202020)
TYPE(*)
PID(10061) TID(2817616)
APPLTAG(ssor\ArrowOrderProcessor.exe) APPLTYPE(USER)
CHANNEL(MY.SVRCONN) CONNAME(111.222.333.444)
CONNOPTS(MQCNO_SHARED_BINDING) USERID(nobody)
UOWLOG( ) UOWSTDA( )
UOWSTTI( ) UOWLOGDA( )
UOWLOGTI( ) URTYPE(QMGR)
EXTURID(XA_FORMATID[00000000] XA_GTRID[] XA_BQUAL[])
QMURID(0.0) UOWSTATE(NONE)
OBJNAME(WMS.TMSX.REQUEST) OBJTYPE(QUEUE)
OPENOPTS(MQOO_INPUT_SHARED) HSTATE(ACTIVE)
OBJNAME(WMS.TMSX.RESPONSE) OBJTYPE(QUEUE)
OPENOPTS(MQOO_OUTPUT) HSTATE(INACTIVE) |
Gina, I consider this connection highly suspicious as it is coming in with an mcauser/user of 'nobody' ...
Could that be a server process started under the wrong identity?
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| GMcCarthy |
| Posted: Fri Feb 01, 2008 4:19 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
 I changed some stuff to protect the innocent.
Here is the channel I want to get rid of...
AMQ8417: Display Channel Status details.
CHANNEL(MY.SVRCONN) CHLTYPE(SVRCONN)
BUFSRCVD(13) BUFSSENT(12)
BYTSRCVD(10237) BYTSSENT(20532)
CHSTADA(2008-01-29) CHSTATI(21.24.48 )
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(111.222.333.444) CURRENT
EXITTIME(0,0) HBINT(300)
JOBNAME(0000090D007987F7) LOCLADDR(::ffff:1.2.3.4(1417))
LSTMSGDA(2008-01-29) LSTMSGTI(21.25.10)
MCASTAT(RUNNING) MCAUSER(nobody)
MONCHL(OFF) MSGS(10)
RAPPLTAG(ssor\ArrowOrderProcessor.exe)
RQMNAME( ) SSLCERTI( )
SSLKEYDA( ) SSLKEYTI( )
SSLPEER( ) SSLRKEYS(0)
STATUS(RUNNING) STOPREQ(NO)
SUBSTATE(RECEIVE) XMITQ( )
It's 1 of 4 svrconn channels of the same name. I cannot correlate that to the info in the conn and qstatus displays.
I also looked at the JOBNAME which states it's a concatenation of the PID and TID. There was no PID/TID in my system even close to it. 
Thanks for your response! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 01, 2008 4:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well the channel's conname will be in the dis conn(*) command.
Usually I go about a connection hitting a specific queue and check the objname in the connection...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Fri Feb 01, 2008 4:52 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
Thank you again for your reply
I have 4 channels of the same name coming in from the same connname. I also have channels with this name coming in from other clients. So I cannot perform a stop channel or they'll all get lost.
I also cannot determine based on the info in these displays, which 1 of the 4 connections to stop.
Isn't that what the STOP CONN command was supposed to do? Oh, well. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 01, 2008 5:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
dis qstats() type(handle) may help.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Fri Feb 01, 2008 5:10 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
| qstats? Do you mean qstatus? If so, the info in dis qstatus and dis conn cannot be matched back to the specific channel connection I need to stop. Thanks a bunch!! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 01, 2008 5:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I missed that you were checking qstatus.
I got nothing. Stop the application... or stop all 4 channels by using stop channel() conname().
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Fri Feb 01, 2008 5:29 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
THANKS!!!
Yeah, that would be the easy way out.
I thought STOP CONN was developed to be able to stop a conn without having to stop the channel and lose multiple connections. Maybe I misunderstood Morag.
I'm just gonna leave it be until the next recycle.
Thank you again! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 01, 2008 5:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, but it seems that something is really weird about your channel/app.
The connection is broken, but the app doesn't seem aware of it, or the MCA isn't aware of it.
I had this happen recently with a cluster mca... that was not so good.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Fri Feb 01, 2008 5:55 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
Can you elaborate? The reason why I am looking at this is because we are having a performance issue, or at least it's perceived to be. The app is coming from an MQ Client on a windows box. The app starts up 4 threads (the box has 4 CPUs) and then does an MQGET with a wait of 60 seconds. Based on the conn info:
OBJNAME(WMS.TMSX.REQUEST) OBJTYPE(QUEUE)
OPENOPTS(MQOO_INPUT_SHARED) HSTATE(INACTIVE)
OBJNAME(WMS.TMSX.RESPONSE) OBJTYPE(QUEUE)
OPENOPTS(MQOO_OUTPUT) HSTATE(INACTIVE)
I am assuming that the app opens up 2 queues one for input and one for output. I am confused here as to why the HSTATE is INACTIVE.
If no msg is gotten, they get a 2033 and restart the MQGET. After 16 2033's, they restart the entire connection.
If they do get a msg (coming from an MQPUT1, NO SYNCHPOINT, MQ Client), they process the message and put the response. They hold the thread for the get and then the put.
What we are seeing is that during volume times, it can take up to 1 minute for the app to actually get the message.
I'm thinking the app is buggy. They are asking that I prove the message is available when we say it is.
This app is vendor code and hopefully I can get a copy today.
The messages coming into this application are persistant and average 5K. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 01, 2008 6:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I can't really elaborate... I don't know what was wrong with the mca when I had a problem, and I don't know what's wrong here.
I don't know under what cases it's possible for STOP CONN to fail to stop the connection - so I don't know what's weird about the conn or program here.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 01, 2008 3:07 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
<deleted incorrect info I had posted before in this post>
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Thu Feb 07, 2008 1:13 pm; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Feb 07, 2008 1:12 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Gina, I was wrong on this. I removed my incorrect info in the previous post.
Issue
| Code: |
| DIS CONN(*) CHANNEL CONNAME |
then
| Code: |
| STOP CONN(<connection ID>) |
As long as you can uniquely identify the channel instance in the first step then you can grab the Conn ID and kill it in the second step. I tested it and it works fine. I was able to shutdown one instance of a named channel and all the others remained running.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 07, 2008 2:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter,
I use this all the time. We have a .NET process that leaves the queue open until the program closes.
Of course I need to do a few things that need the queue not have any handles open...and the collegue running the .NET program is not at his desk or has left for the day... So I check the conn(*) where(objname eq myqueue) and after that stop the conn. The IP in the conname is quite recognizable... to me.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
