| Author |
Message
|
| masteringmq |
 Posted: Sat Feb 14, 2009 8:37 pm Post subject: Binding options |
 |
|
Master
Joined: 20 Oct 2008
Posts: 200
|
Standard binding - If an application uses standard binding to connect to the queue manager it means that a shared memory is being used. This means that the application and the agent processes uses the same address space.
Isolated binding - The application uses its own address space which is seperate from the agent processes.
Fastpath binding - The trusted application is connected directly to the queue manager by passing the agent processes.
Question
If the application is connected to the queue manager using isolated binding and fastpath binding, does it indicated that the chances of a queue manager getting corrupted is low?. This is because if the shared memory is corrupted it means that the queue manager will get corrupted. |
|
| Back to top |
|
 |
| exerk |
| Posted: Sun Feb 15, 2009 2:41 am Post subject: Re: Binding options |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| masteringmq wrote: |
Question
If the application is connected to the queue manager using isolated binding and fastpath binding, does it indicated that the chances of a queue manager getting corrupted is low?. This is because if the shared memory is corrupted it means that the queue manager will get corrupted. |
Only if it's coded correctly! As the manual states, any application that binds 'fastpath' can trash the queue manager if the application crashes, or is badly written - at least that is my interpretation of what is written.
From the manual - as usual:
| Quote: |
Fastpath (trusted) applications
Fastpath applications run in the same process as WebSphere MQ and so are running in the multithreaded environment. In this environment WebSphere MQ handles the synchronous signals SIGSEGV, SIGBUS, SIGFPE, and SIGILL. All other signals must not be delivered to the Fastpath application while it is connected to WebSphere MQ. Instead they must be blocked or handled by the application. If a Fastpath application intercepts such an event, the queue manager must be stopped and restarted, or it may be left in an undefined state. For a full list of the restrictions for Fastpath applications under MQCONNX see Connecting to a queue manager using the MQCONNX call. |
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Feb 15, 2009 4:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There's a reason it's called "standard" binding.
Use it unless you have a good reason not to.
Do not use fastpath bindings unless you can fully, and I mean *fully* test every branch of your own code... or unless you have stringent performance requirements that outweigh any reliability requirements. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Feb 15, 2009 10:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| have stringent performance requirements |
Some history here on fastpath binding.
Long ago, when processors were slow and in short supply, fastpath binding offered MQ users a performance improvement by having an application execute on an existing process/thread (local queue manager agent). This saved a number of processor cycles in launching a new process/thread.
With cheaper servers, faster and multiple cpus, the need for fastpath binding has diminished. Now, the risk far outweighs the benefits.
| Quote: |
| Isolated binding - The application uses its own address space which is seperate from the agent processes. |
No. Read the definition of Isolated binding in the WMQ Application Programming Reference.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| masteringmq |
| Posted: Sun Feb 15, 2009 8:02 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| Quote: |
| No. Read the definition of Isolated binding in the WMQ Application Programming Reference. |
This isolates the applications address space completely from the agent processes. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Feb 15, 2009 9:03 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
From the WMQ APR:
MQCNO_ISOLATED_BINDING The application and the local queue manager agent (the component that manages queuing operations) run in separate units of execution (generally, in separate processes). This arrangement maintains the integrity of the queue manager, that is, it protects the queue manager from errant programs. The application process and the local queue manager agent are isolated from each other in that they do not share resources.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| masteringmq |
| Posted: Sun Feb 15, 2009 10:12 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
It looks like isolated binding is the best  |
|
| Back to top |
|
|
| masteringmq |
| Posted: Sun Feb 15, 2009 10:38 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| Quote: |
| fastpath binding offered MQ users a performance improvement by having an application execute on an existing process/thread (local queue manager agent). |
By contrast, when running as a non Fastpath or Standard application an agent process called amqzlaa provides the separation between the MQ application and queue manager |
|
| Back to top |
|
|
|
|
