Hi Peter,
Thanks for this but I'm afraid that may be the question was not clear enough. We have existing applications that will connect to a new broker. We wanted to implement channel exits on the broker for the receiving channels from the applications and the sending channels to the applications, this was so we could record how long the messages are taking to get processed in the WBI MB flows on the hub. We have a constraint on us that we are not allowed to change the application platforms or deploy new applications on to them.
We wanted to use channel exits as it meant no change to the flows that we are migrating over and we believed the channel exits would give us the best performance. The channel exits would also give us a more accurate timing as it would take into account the time in the flows as well as time on the MQSeries queues on the hub. However, we were put off by a couple of statements that were made:
- this will degrade channel performance
- an error in the exit could cause message loss
The alternatives to the channel exit design given our constraints are:
- Use a message get MQ exit
- Use a stand-alone program
- Add a metrics node into the message flow.
The main problems with the above approaches are that they will not give us a true indication of the amount of time the messages have spent in a hub. My other concerns are that the alternative approaches will not provide better performance than using channel exits. I would like to get peoples views on the two negative comments regarding use of channel exits and advise on what they would do and why to achieve what we want to do.
Cheers,
Kulbir.
| "Potkay, Peter M (PLC, IT)"
<[EMAIL PROTECTED]>
Sent by: "MQSeries List" <[EMAIL PROTECTED]> 22-Mar-2004 19:23
|
To: MQSERIES cc: Subject: Re: Use channel exits or not? |
Application connects to QMSpoke1.
QMSpoke1 hosts a RemoteQueueA, pointing at RemoteQueueB, which lives on QMHub.
RemoteQueueB on QMHub points back at LocalQueue1 on SpokeQM1.
Application connects to QMSpoke1, and Opens RemoteQueueA for putting, and opens LocalQueue1 for getting.
Put a message into RemoteQueueA.
Record the time.
Application immediatly MQGets from LocalQueue1.
Record the time.
Subtract the two times, and you have the amount of time a message takes to get thru the hub. Yes it includes time spent on the channels, but that is relevant. Put both QMs on the same box, and have your channels already running to eliminate these variables as much as possible.
Do the test again by changing RemoteQueueA to point right to LocalQueue1 to see what a difference there is if you eliminate the channel/HUB hops.
-----Original Message-----
From: Kulbir S. Thind [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 2:00 PM
To: [EMAIL PROTECTED]
Subject: Use channel exits or not?
Hi,
We are planning on having a hub and spoke architecture that will see 100's of applications connect into the WBI MB hub we will implement. We have a requirement to be able to determine the amount of time that the messages have spent in the hub. We thought we would do this by implementing some auditing functionality using channel exits to copy the messages to another destinations as it arrives and as it leaves.
We have had some worrying comments regarding using channel exits for this purpose, these comments are:
- this will degrade channel performance
- an error in the exit could cause message loss
The alternatives to this approach are as follows:
- Use a message get MQ exit
- Use a stand-alone program
- Add a metrics node into the message flow.
The main problems with the above approach are that they will not give us a true indication of the amount of time the messages have spent in a hub. My other concerns are that the alternative approaches will not provide better performance than using channel exits.
Would anyone like to comment on this?
Cheers,
Kulbir.
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.
