| Author |
Message
|
| woolmerc |
 Posted: Mon Nov 08, 2004 5:33 pm Post subject: Trusted Applications |
 |
|
Novice
Joined: 12 May 2004
Posts: 21
|
Hi guys,
This is a topic I have seen discussed in these forums, but never in any real detail. The option to set the MQIBINDTYPE to FASTPATH allows an application to become a trusted one.
But what are the real pros and cons of doing this??
I have an application that sits on the MQ Server. I have 2 channels defined - one being a SENDER and the other a RECEIVER. What are the implications of me setting the bind type to FASTPATH?
Also what concerns are involved in having adoptNewMCA turned on at the same time? I have read the Sys Admin Guide, but it doesn't give me enough info.
Thanks,
_________________
Chris Woolmer
Programmer
KAZ Group Limited |
|
| Back to top |
|
 |
| KeeferG |
| Posted: Tue Nov 09, 2004 2:36 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Running an application as trusted removes a number of levels of calls. Usually an application communicates with the internal API calls via an agent process amqzlaa0. This process performs the API calls on behalf of an application. The reason for this is the application then remains in its own address space so if anything fails, it is only the applications address space that has the problem. When running as a trusted application the agent process is removed and the application calls the internal API directly. This removes several levels of calls which improves performance, but does mean that should the application fail you will have a very good chance of trashing your queue manager as well as you share its memory. In general it is best to avoid trusted application unless you have a VERY well behaved application that has correct start up and shut down procedures.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Nov 09, 2004 5:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I *think* that if you run your channels in FASTPATH mode, and you STOP the channel with the FORCE command, you can/will force your QM to go down, since the channel and QM are one and the same in FASTPATH mode. I remember reading this somewhere.
Jason or Nigel, is this true?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| KeeferG |
| Posted: Tue Nov 09, 2004 6:53 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
 I really should read the whole text before flying off into an answer.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Nov 09, 2004 9:03 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
I do not think it is true that the qmgr will crash (or end) if a fastbound channel is ended. You always get an FDC if a fastbound app of any kind ends unexpectedly, so that would happen if you did a STOP CHL MODE(TERMINATE) because that kills the thread, but a MODE(FORCE) ends the channel more or less nicely.
To get back to the original question, there should be no problem running a channel fastbound, since it is all IBM code. I do not think it is really worth doing it, because all you are getting is the elimination of the context switches between the app and the agent. This is unlikely to be an issue in channel code, because if there are a lot of switches between MCA and agent, perhaps because of large msgs, there will be even more data transmissions on the channel with the transmit size of ~32K, and so the speed of the channel will be constrained (as usual) by the comms speed, and not by the in-memory transfers. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Nov 09, 2004 12:03 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I knew I read it somewhere:
When running channels as FastPath.
| Quote: |
Care should also be taken when using the STOP MODE(FORCE) command on releases prior to V5.3, and on V5.3 care should be taken when using the STOP MODE(TERMINATE) command, either of which could corrupt or hang the queue manager as cleanup may not be completely performed when the channel is killed.
|
This is from the Support Pack on keeping your channels running, which has a lot of good stuff on performance tuning for channels.
http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24006699&loc=en_US&cs=utf-8&lang=en
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| woolmerc |
| Posted: Thu Nov 11, 2004 2:40 pm Post subject: |
|
|
Novice
Joined: 12 May 2004
Posts: 21
|
From the responses I have received I conclude that it is generally advisable not to use trusted applications/channels.
If we set MQIBINDTYPE to FASTPATH, does this mean that every channel running on the queue manager and every application connected, runs as an trusted application?
_________________
Chris Woolmer
Programmer
KAZ Group Limited |
|
| Back to top |
|
|
| Nigelg |
| Posted: Fri Nov 12, 2004 1:19 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Yes it does. You can also specify FASTPATH in an env var, not in the ini file, and then the bind type will only be set to FASTPATH in channel processes which have the env var set in the shell. See the Intercomms manual. |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Jan 02, 2008 10:44 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| PeterPotkay wrote: |
I knew I read it somewhere:
When running channels as FastPath.
| Quote: |
Care should also be taken when using the STOP MODE(FORCE) command on releases prior to V5.3, and on V5.3 care should be taken when using the STOP MODE(TERMINATE) command, either of which could corrupt or hang the queue manager as cleanup may not be completely performed when the channel is killed.
|
This is from the Support Pack on keeping your channels running, which has a lot of good stuff on performance tuning for channels.
http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24006699&loc=en_US&cs=utf-8&lang=en |
I have issued:
stop channel(SYSTEM.DEF.SVRCONN) conname(host.ip) MODE(terminate)
and it stopped all instances of all channels defined on that particular qmgr. No FDC's were dumped. In AMQERR01.LOG for that qmgr it reported (section about CHNAME termination is repeated for all channel names):
| Quote: |
-------------------------------------------------------------------------------
01/02/2008 03:52:17 PM - Process(8719.1) User(mqm) Program(amqrcmla)
AMQ9604: Channel 'SYSTEM.DEF.SVRCONN' terminated unexpectedly
EXPLANATION:
The process or thread executing channel 'SYSTEM.DEF.SVRCONN' is no longer
running. The check process system call returned 0 for process 12145.
ACTION:
No immediate action is required because the channel entry has been removed from
the list of running channels. Inform the system administrator who should
examine the operating system procedures to determine why the channel process
has terminated.
----- amqrcsia.c : 1410 -------------------------------------------------------
01/02/2008 03:52:27 PM - Process(8703.1) User(mqm) Program(runmqsc)
AMQ9604: Channel 'SYSTEM.DEF.SVRCONN' terminated unexpectedly
EXPLANATION:
The process or thread executing channel 'SYSTEM.DEF.SVRCONN' is no longer
running. The check process system call returned 545284357 for process 12145.
ACTION:
No immediate action is required because the channel entry has been removed from
the list of running channels. Inform the system administrator who should
examine the operating system procedures to determine why the channel process
has terminated.
----- amqrcsia.c : 1410 -------------------------------------------------------
01/02/2008 03:52:27 PM - Process(8703.1) User(mqm) Program(runmqsc)
AMQ9604: Channel 'CHNAME' terminated unexpectedly
EXPLANATION:
The process or thread executing channel 'CHNAME' is no longer running.
The check process system call returned 545284357 for process 12145.
ACTION:
No immediate action is required because the channel entry has been removed from
the list of running channels. Inform the system administrator who should
examine the operating system procedures to determine why the channel process
has terminated.
. . .
|
I'm pretty much sure I didn't issue:
stop channel(*) MODE(terminate)
Is this behaviour explained by previous quote, or has nothing to do with it?
Is there something I should be worried now about the behaviour of the qmgr (take some corrective action, it said no immediate action is needed)?
Thanks.
Last edited by jcv on Wed Jan 02, 2008 3:12 pm; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 02, 2008 11:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jcv wrote: |
Is this behaviour explained by previous quote, or has nothing to do with it?
Is there something I should be worried now about the behaviour of the qmgr (take some corrective action, it said no immediate action is needed)?
Thanks. |
Nothing to do with it.
You killed a channel process. That process owns mutiple threads, each of which is a channel instance. If you killed Process 123 and it owned say 60 threads which represented all 60 of your channels than you just killed all 60 channels.
Don't use the terminate option unless all other means of stopping the channel have failed.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Jan 03, 2008 2:29 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Peter, I wish you all the best in 2008. My question was totaly misplaced, since I don't run channels in FASTPATH mode at all.
I did nothing like it (killed the channel process). If I wanted to do it, I would contact os via kill -9 pid. I have contacted mqsc engine instead, asking it to terminate instances of SYSTEM.DEF.SVRCONN channel, instantiated on behalf of clients connecting from the ipaddress defined by conname parameter. And according to explanation taken from information center:
| Quote: |
Stopping channels
In WebSphere MQ, when you issue a STOP CHANNEL command against a server-connection channel,
you can choose what method to use to stop the client-connection channel.
...
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. |
it looks now to me, it terminated wrong threads. Although, I must admit that I don't understand to which processes and threads does that refer (server side or client side). I think server side, if that's the case, what's the difference between the observed behaviour and this hypothetic: you ask mqsc engine to delete certain local queue, and it deletes all other queues too. The fun part here is that the syntax checker for this engine reports, if you try something like this:
stop chl(*)
4 : stop chl(*)
AMQ8227: Channel * not found.
I just want to add that on another platform, the same command functioned as designed (or at least as I would expect), on several occasions, leaving other instances of server connection channel intact (those with different connames). Could you point out the document which explains the risks you just mentioned to me, of terminate option for that particular command? Without it, I'm sure I will never use it again. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 03, 2008 2:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Does it not seem likely that the mode(terminate) causes the process to be killed?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Jan 03, 2008 4:00 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I think it is obvious. As well as my point here. I don't care what does mode(terminate) cause, killing of the whole process or just some of its threads, as long as it causes the expected result. I want this to be completely transparent to me, when I use runmqsc. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 03, 2008 4:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, I agree.
It just seems that Peter has said that the mqsc you issued killed the process, which took down other channel instances.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 03, 2008 6:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
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. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
