| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQCNO_STANDARD_BINDING Vs MQCNO_FASTPATH_BINDING |
« View previous topic :: View next topic » |
| Author |
Message
|
| kakkarjatin |
 Posted: Wed Oct 05, 2005 11:25 pm Post subject: MQCNO_STANDARD_BINDING Vs MQCNO_FASTPATH_BINDING |
 |
|
Novice
Joined: 25 Aug 2005
Posts: 15
|
Hi All,
I have got a doubt regarding the MQCNO_STANDARD_BINDING and MQCNO_FASTPATH_BINDING options. The manual says that MQCNO_STANDARD_BINDING maintains the integrity and MQCNO_FASTPATH_BINDING compromises integrity, whereas MQCNO_FASTPATH_BINDING is used incase of trusted application. Does this mean we should not use MQCNO_STANDARD_BINDING for trusted applications? I believe that MQCNO_STANDARD_BINDING maintains integrity and should be used for trusted application.
Please find below the text that I copied from Application Programming guide.
MQCNO_STANDARD_BINDING
By default, MQCONNX (like MQCONN) implies two logical threads where the WebSphere MQ application and the local queue manager agent run in separate processes. This maintains the integrity of the queue manager (that is, it makes the queue manager immune to errant programs), but impairs the performance of the MQI calls.
MQCNO_FASTPATH_BINDING
Trusted applications imply that the WebSphere MQ application and the local queue manager agent become the same process.
This option compromises the integrity of the queue manager as there is no protection from overwriting its storage.
So, to run a trusted application, either:
1. Specify the MQCNO_FASTPATH_BINDING option on the MQCONNX call and the FASTPATH environment variable,
or
2. Specify the MQCNO_FASTPATH_BINDING option on the MQCONNX call and leave the environment variable undefined.
If neither MQCNO_STANDARD_BINDING nor MQCNO_FASTPATH_BINDING is specified, you can use MQCNO_NONE, which defaults to MQCNO_STANDARD_BINDING.
_________________
Regards,
Jatin Kakkar
IBM WMQ V5.3 System Administrator Certified
Brainbench Master Certification in WebSphere MQ
Sun Certified Java Programmer
Sun Certified Web Component Developer
IBM Certified AIX Specialist
Java Brainbench Certified |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Wed Oct 05, 2005 11:53 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Fastpath binding means that the app runs in the the same memory space as the qmgr. Such an app potentially has the ability to crash the qmgr, and even corrupt it to such an extent that it cannot be restarted and all the msgs are lost. Note that IBM will probably decline support for a qmgr which has crashed because of a bug in a fastbound app.
If you are completely confident that your app has no bugs that could cause it to overwrite memory, or will never crash, and you do ont mind it running under the mqm user so that it has full authority to all qmgr objects, then use fastpath bindings, otherwise use standard.
IMO the increase in performance is not worth the risk of compromising the qmgr data.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Oct 06, 2005 6:47 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
|
| 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
|
|
|
|
