| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Trusted Applications |
« View previous topic :: View next topic » |
| Author |
Message
|
| jcv |
 Posted: Thu Jan 03, 2008 7:17 am Post subject: |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Well, then I have understood him well in the first place. I was just looking for this document:
http://www-1.ibm.com/support/docview.wss?uid=swg21170751
I also wanted to make clear distinction between:
"works as expected if you understand the details of its implementation"
"well known minor defect"
"useful option which is better to avoid"
because it seemed to me Peter didn't emphasize it enough. |
|
| Back to top |
|
 |
| jcv |
| Posted: Fri Jan 04, 2008 10:57 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| fjb_saper wrote: |
Please don't use "TERMINATE" on a first pass.
First try mode(QUIESCE) status(STOPPED).
If this doesn't work the next pass is mode(FORCE).
This should lead to a gradual shutdown of the channel.
If this fails entirely you may have to use terminate.
Terminate should be a last resort.  |
I wonder then, what does this mean (the multi-stage process part):
| Quote: |
Terminate
Stops the channel immediately. If the channel is running as a process, it can terminate the channel's process, or if the channel is running as a thread, its thread.
This is a multi-stage process. If mode terminate is used, an attempt is made to stop the server-connection channel, first with mode quiesce, then with mode force, and if necessary with mode terminate.
|
It seems to me that if you consider TERMINATE as a resort of any kind, it will always be the last one, automatically, without that procedure you're proposing fjb_saper. Am I misinterpreting the manual? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 04, 2008 11:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you had personally tried mode(quiesce) first, and it had told you that it couldn't stop the channel... would you have taken steps to reduce the impact of the other methods? Or would you have always gone ahead with mode(force) and mode(terminate)?
The point here is that doing it manually gives you more options on how to escalate. Using mode(terminate) doesn't give you that option - it *will* try all modes UNTIL the channel is stopped.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jcv |
| Posted: Sun Jan 06, 2008 3:57 pm Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
It depends on how well I'm informed of the reasons why any particular method may fail, which automatically implies information on which steps may be taken in order to succeed, and avoid the need to escalate on to another stage. The information on the unwanted impact of every method (stage) is also significant. I'm missing all that stuff in one place (document), which should be one click away from the chapter explaining stopping of channels.
For example, I suppose long running batch may be the reason why sender channel can't be stopped in quiesce mode? That is, something has to be done to finish the batch (maybe just waiting) Otherwise, channel may go indoubt when using force method. When server connection channel cannot be stopped in the force mode, what to do to enable that, what are all possible scenarios? In my case, all client applications from conname ipaddr were already terminated, when I tried to garbage collect svrconn instance, and I didn't have KEEPALIVE set to YES in TCP stanza of qm.ini, if that has anything to do with it. And without any hint in the manual, I was supposing that generic object name given in command, will constrain all possible impact only to that object. |
|
| Back to top |
|
|
| jcv |
| Posted: Mon Jan 07, 2008 7:56 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| jefflowrey wrote: |
| ... would you have taken steps to reduce the impact of the other methods? |
What steps exactly did you have in mind...? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 07, 2008 7:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jcv wrote: |
| jefflowrey wrote: |
| ... would you have taken steps to reduce the impact of the other methods? |
What steps exactly did you have in mind...? |
Try to stop connections, rather than channels, perhaps...
Try to find out more about why the channel is not stopping normally...
Try to schedule a better time when system interruption will have a small impact...
Try to kill applications, rather than channels...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Jan 08, 2008 9:12 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
jefflowrey, sorry for the delay in conversation, I had other important tasks.
| Quote: |
| Try to stop connections, rather than channels, perhaps... |
Actually, I thought you were going to tell me that I should be handling MQ objects, not underlying OS entities. On the other hand, I think you are actually telling me to use KEEPALIVE setting, as a part of qm.ini configuration?
| Quote: |
| Try to find out more about why the channel is not stopping normally... |
I am trying to find out reasons in general, as well as in my concrete case, and this looks a bit like you are posing my question back at me. So, the key is whether the socket which accepted the connection is alive or not? If it's alive, there is no way to stop svrconn channel by using force method, in the same way as running batch is the key for quiesce stage? Or is there something else that I'm still missing?
| Quote: |
| Try to schedule a better time when system interruption will have a small impact... |
I'd rather schedule system interruptions not to occur at all, although in my case nothing critical happened. And if v6 is used, or channels are not running in trusted mode, the worst thing it can happen when using TERMINATE is to force (other) channels to indoubt state?
| Quote: |
| Try to kill applications, rather than channels... |
You are explaining again about how I killed the channel, and I wanted it dead, just the right one, not all of them, not the qmgr,... I believe client applications were already terminated. Isn't that the part of the problem, that they didn't properly close the connections to qmgr? Or would server side sockets be eventually garbage collected in that case by OS, and you're telling me that I somehow missed the living client application? |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Jan 09, 2008 8:55 pm Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| After noticing STOP CONN command in the middle of the Information center jungle, I realized that it was the part I was missing. Obviously, that has nothing to do with closing sockets, and has everything to do with invalidating connection handles. And that's what's missing when applications are terminated and don't close properly connections to qmgrs. Then it must be the key for the force stage, under circumstances when this command succeeds? |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Feb 26, 2008 11:28 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Here are some things IBM wants us to know about problems with stop channel mode(force|terminate).
http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg1IY87162
The point here is to apply all available fixes, and you should be safe with using any command provided. At least this is the idea of providing them (fixes and commands). |
|
| Back to top |
|
|
| jcv |
| Posted: Sat Mar 08, 2008 3:39 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
I always do reassessment of things I've done and said. I think I have to correct some of them.
stop chl(*) is valid syntax, object resolution parsing phase is complaining here, because * is generic object name. And SYSTEM.DEF.SVRCONN is not.
Misguided by a slang which refers to sockets as network connections, I reffered to them as OS entities (objects), because I thougt we both talk about them.
As Doug Lea describes in his Session article, socket descriptor and qmgr connection handle belong to same abstract category of session handles. Hence, closing of socket also means invalidating some kind of connection handle.
http://g.oswego.edu/dl/pats/session.html
In case of svrconn chl instance, thread which owns sd and connHandle, uses them I think for communication with client application and qmgr. If any of them is invalid I suppose it would commit suicide. In fact, connHandle is owned by client application which uses it to communicate with the qmgr, and svrconn communicates I suppose by other means with the rest of the qmgr, being part of it. And if stop conn is issued, and client application is idle, that does not disturb much any of them?
A colleague of mine is an Oracle DBA. We share the same office and often compare what is it like to be an MQ admin and an Oracle DBA, what are the differences and similarities. Similarities are result of same design patterns which result in similar problems. Here is one, which helped me a bit to get cleaner picture of my problem:
http://www.ixora.com.au/q+a/0110/12162502.htm
As a conclusion, I want to say that I really tried to find out why svrconn chl does not stop normally, asking IBM about three stage process of stopping channel and all that, but I think that my previous post has greater practical importance regarding that matter. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Mar 20, 2008 7:11 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I'm interested in description of preferred or recommended uses of STOP CONN vs STOP CHL on svrconn channel. If I understand well, STOP CHL command has two main functions: to stop channel activity leading to termination of appropriate threads or processes, and to disable automatic resume of its activity by using STATUS(STOPPED), where applicable (not with QMNAME or CONNAME parameters specified). Hence, I see clear preference in favour of STOP CHL when channel has to be disabled, or when multiple instances of channel have to be terminated, according to QMNAME or CONNAME or no parameters specified. On the other hand, when shutting down one particular instance of svrconn channel is needed, and this is not feasible via STOP CHL, then I guess STOP CONN should be used. Another recommendation was to use it when STOP CHL fails in QUIESCE or FORCE mode. Is this correct, and is there something else which might help to complete the picture? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 20, 2008 7:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Right, so normally there's only one "instance" of a given channel - so the difference between "STOP CONN" and "STOP CHL" is moot.
Except in the case of CLUS* channels and *CONN channels. There's more than one running instance of a given CLUSRCVR or CLUSSDR and likewise (usually) more than one instance of a given SVRCONN.
Here you have need for the ability to halt a particular instance rather than the total set of instances. The preference is to always limit the impact of any administrative access to the right scope. So start with STOP CONN.
Then move up to the larger scope of the channel as a whole, if that doesn't succeed or the scope is indeed larger (applying an MCAUSER or some such).
As you move to STOP CHL, you get more and more impactful choices based on MODE. MODE(TERMINATE) will perform all of the choices available, including the last resort of killing the MCA instance (and thus *all* channels in that instance!)
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Mar 20, 2008 8:45 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
