Re: Use channel exits or not?
Is this something that you will need always from this point forward, or is this a one time deal just to get an idea? If all you want to know is how long name resolution takes place on the MQ Hub this one time, I would do the following: Do this off hours. Create a new channel into the Hub, and a new channel out of the hub. STOP the channel into the Hub. Preload the XMIT queue feeding the channel into the Hub with 100,000 persistent messages of an average size for your shop. Record the time and start the channel. When the last message finally resolves thru the hub and the depth hits 100,000 on the other side, record the time. Subtract the 2 times, and divide by 100,000. Your answer is the average time that a message took to get through the hub. Sorry if I keep shying away from answering your exit questions. One I don't know the first thing about exits, and 2, if there is a simple, not so glamorous way to get an answer, why not? :-) -Original Message-From: Kulbir S. Thind [mailto:[EMAIL PROTECTED]Sent: Tuesday, March 23, 2004 12:51 PMTo: [EMAIL PROTECTED]Subject: Re: Use channel exits or not?Gentlemen, A few points: The timings are captured on the hub and there is only a single hub so we shouldn't have any issues. We want to use circular logs as they are easier to maintain. By "shared channel exit" I'm suggesting that we have a channel exit created and make a physical copy of it for each channel instance that we have. Is this approach going to give us better performance and be safer? Does it require more resources rather than having a single channel exit (i.e. dll) that is used by all channel instances?Cheers, Kulbir. "Rick Tsujimoto" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 23-Mar-2004 15:04 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Use channel exits or not?If the timings are captured on different boxes, and the machine clocks arenot synchronized, then you could have some interesting results."David C.Partridge" To: [EMAIL PROTECTED]<[EMAIL PROTECTED] cc:RIMEUR.COM> Subject: Re: Use channel exits or not?Sent by: MQSeriesList<[EMAIL PROTECTED].AC.AT> 03/23/2004 08:23AMPlease respond toMQSeries List Additional comments:Acquire the storage for you structure at MQXR_INIT time, and store thepointer in MQCXP.ExitUserArea.Make sure that you release the storage and clear the pointer at MQXR_TERMtime.Do whatever processing you need at MQXR_MSG time (you'll probably want toknow whether the message is inbound or outbound on the channel - look atMQCD.ChannelType to determine what type of channel this is.DaveInstructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archiveInstructions for managing your mailing list subscription are provided inthe Listserv General Users Guide available at http://www.lsoft.comArchive: http://vm.akh-wien.ac.at/MQSeries.archive 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.
Re: Use channel exits or not?
Gentlemen, A few points: The timings are captured on the hub and there is only a single hub so we shouldn't have any issues. We want to use circular logs as they are easier to maintain. By "shared channel exit" I'm suggesting that we have a channel exit created and make a physical copy of it for each channel instance that we have. Is this approach going to give us better performance and be safer? Does it require more resources rather than having a single channel exit (i.e. dll) that is used by all channel instances? Cheers, Kulbir. "Rick Tsujimoto" <[EMAIL PROTECTED]> Sent by: "MQSeries List" <[EMAIL PROTECTED]> 23-Mar-2004 15:04 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Use channel exits or not? If the timings are captured on different boxes, and the machine clocks are not synchronized, then you could have some interesting results. "David C. Partridge" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RIMEUR.COM> Subject: Re: Use channel exits or not? Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 03/23/2004 08:23 AM Please respond to MQSeries List Additional comments: Acquire the storage for you structure at MQXR_INIT time, and store the pointer in MQCXP.ExitUserArea. Make sure that you release the storage and clear the pointer at MQXR_TERM time. Do whatever processing you need at MQXR_MSG time (you'll probably want to know whether the message is inbound or outbound on the channel - look at MQCD.ChannelType to determine what type of channel this is. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Use channel exits or not?
Indeed so! :-) Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Use channel exits or not?
If the timings are captured on different boxes, and the machine clocks are not synchronized, then you could have some interesting results. "David C. Partridge" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RIMEUR.COM> Subject: Re: Use channel exits or not? Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 03/23/2004 08:23 AM Please respond to MQSeries List Additional comments: Acquire the storage for you structure at MQXR_INIT time, and store the pointer in MQCXP.ExitUserArea. Make sure that you release the storage and clear the pointer at MQXR_TERM time. Do whatever processing you need at MQXR_MSG time (you'll probably want to know whether the message is inbound or outbound on the channel - look at MQCD.ChannelType to determine what type of channel this is. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]
Kulbir, my exit is on os/390, its written in assembler and the number of channels it is used in is about 20, so i am afraid i have to stop giving hints at this point because your environment differs too much (and i am not a unix guru). Using an exit in 600 channels (or 200) could maybe be a mess. i also do not understand what you mean by "shared channel exit" . if you put in a channel exit, it is used by each mca, but every mca has its own data... ?!? or do you want to create the same program with a different name for each channel ?!? hard to recommend anything for me. i would try to go for an "offline" solution, like using linear logs which are analyzed later i know there are some third party log tools around. Regards, Stefan "Kulbir S. Thind" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 23.03.2004 12:31 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked] . Stefan, We will be developing on Windows and using this in production on Sun Solaris. Also, would you share the same channel exit across channels or have separate instances on each channel? We may have up to 600 channels in total connected to 3 queue managers on the hub. We're worried about sharing a channel exit across so many instances and ensuring that the handles do not get mixed up with one another. Are we better off just having multiple instances of the same channel exit or should we go for a shared channel exit? What is safer, better for performance? Also, does having multiple channel exits effect resource requirements? Thanks for your assistance, Kulbir. [EMAIL PROTECTED] Sent by: "MQSeries List" <[EMAIL PROTECTED]> 23-Mar-2004 10:52 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked] Kulbir, persistent messages are in the log, so log analysis may still be an approach, but (again) hard to implement. using the applidentity data to match incoming and outgoing message will work, but you must be sure it is not used anywhere else in the application and you must be sure the value you put in there is unique. if the exit is written properly there should be no data loss. if the exit is in error in most cases the channel terminates or does not start. you can also tune your exit e.g. by keeping your workarea (allocate at channel start, free at channel end, keep and pass address in exituserarea) to minimize performance impact (depending on OS and programming language). in my statistic exit, i also set a bit if i detect an error during processing (e.g. channel statistic queue full), and - if called again - i check this bit first. if previous error, i leave the exit immediate. this will result in the loss of my statistic data, but the error will not impact message flow. what operating system is used for the hub? regards, stefan "Kulbir S. Thind" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 23.03.2004 11:03 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked] . Stefan, Thanks for the response. Unfortunately because of the validated environment we work in (Pharmaceutical regulations) we need to use persistent messages no matter what approach we take. We will match the incoming messages with the outgoing messages by using the ApplIdentityData field in the MQMD, we cannot use the MsgId field and CorrelId fields as the MsgId field is definitely being used by the applications and the CorrelId field may be already being used or can be used in the future. The channel exit will modify the incoming message to allocate a value for the ApplIdentityData field, I believe if you code the channel exit correctly you can ensure you have no message loss, do you agree? Cheers, Kulbir. [EMAIL PROTECTED] Sent by: "MQSeries List" <[EMAIL PROTECTED]> 23-Mar-2004 09:32 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] Kulbir, are the messages persistent? mayby a log analysis could be an approach (just an idea, but i think this well be hard to implement be
Re: Use channel exits or not?
Each instance of a channel exit can hang any structures (or control blocks) that it needs to maintain state across invocations in MQCXP.ExitUserArea (store a pointer in here). You can store in this structure any hconn (n.b. you'll get MQRC_ALREADY_CONNECTED when you do the MQCONN, so just remember that you DO NOT do an MQDISC in this case) and any hobj's that you need (for writing to your audit queue e.g.). Therefore each instance of a channel exit is isolated from other instances even in a threaded channel model as in MQ 5.3 using the shared channel agent - just make sure your code is naturally re-entrant and don't store stuff between invocations anywhere but in the control block you store the pointer to in MQCXP.ExitUserArea (put another way don't use static variables or expect stack variables to hang around). Cheers Dave Partridge Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Use channel exits or not?
Additional comments: Acquire the storage for you structure at MQXR_INIT time, and store the pointer in MQCXP.ExitUserArea. Make sure that you release the storage and clear the pointer at MQXR_TERM time. Do whatever processing you need at MQXR_MSG time (you'll probably want to know whether the message is inbound or outbound on the channel - look at MQCD.ChannelType to determine what type of channel this is. Dave Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked]
Stefan, We will be developing on Windows and using this in production on Sun Solaris. Also, would you share the same channel exit across channels or have separate instances on each channel? We may have up to 600 channels in total connected to 3 queue managers on the hub. We're worried about sharing a channel exit across so many instances and ensuring that the handles do not get mixed up with one another. Are we better off just having multiple instances of the same channel exit or should we go for a shared channel exit? What is safer, better for performance? Also, does having multiple channel exits effect resource requirements? Thanks for your assistance, Kulbir. [EMAIL PROTECTED] Sent by: "MQSeries List" <[EMAIL PROTECTED]> 23-Mar-2004 10:52 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked] Kulbir, persistent messages are in the log, so log analysis may still be an approach, but (again) hard to implement. using the applidentity data to match incoming and outgoing message will work, but you must be sure it is not used anywhere else in the application and you must be sure the value you put in there is unique. if the exit is written properly there should be no data loss. if the exit is in error in most cases the channel terminates or does not start. you can also tune your exit e.g. by keeping your workarea (allocate at channel start, free at channel end, keep and pass address in exituserarea) to minimize performance impact (depending on OS and programming language). in my statistic exit, i also set a bit if i detect an error during processing (e.g. channel statistic queue full), and - if called again - i check this bit first. if previous error, i leave the exit immediate. this will result in the loss of my statistic data, but the error will not impact message flow. what operating system is used for the hub? regards, stefan "Kulbir S. Thind" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 23.03.2004 11:03 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked] . Stefan, Thanks for the response. Unfortunately because of the validated environment we work in (Pharmaceutical regulations) we need to use persistent messages no matter what approach we take. We will match the incoming messages with the outgoing messages by using the ApplIdentityData field in the MQMD, we cannot use the MsgId field and CorrelId fields as the MsgId field is definitely being used by the applications and the CorrelId field may be already being used or can be used in the future. The channel exit will modify the incoming message to allocate a value for the ApplIdentityData field, I believe if you code the channel exit correctly you can ensure you have no message loss, do you agree? Cheers, Kulbir. [EMAIL PROTECTED] Sent by: "MQSeries List" <[EMAIL PROTECTED]> 23-Mar-2004 09:32 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] Kulbir, are the messages persistent? mayby a log analysis could be an approach (just an idea, but i think this well be hard to implement because log details are not known to the "normal" mq users). i use a channel exit in a similiar situation, i wanted to be able to see what messages (target queue, target queuemanager) are passing the channels that are connected to a gateway queuemanager (sending and receiving ends). i do not record the messages itself, but take some values (target queue, target qmgr, channel name, put time, application name, ...) to build a statistic message which is put into a statistic queue. thisqueue is triggered by depth and copied to a flat file by a small REXX procedure (all on os/390). analyzing the statistic messages in the flat file i am able to see what messages passed the gateway, i am also able to compute the time a message takes from creation (put time of the message) till passing the gateway queuemanager (put time of the statistic message). the statistic messages are non persistent, to minimise performance impact. no matter what kind of measuring you will implement, it will cost you some performance anyway. i prefer the exit solution because i do not have to touch the application, and - if written properly - there should be no message loss, because
Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked]
Kulbir, persistent messages are in the log, so log analysis may still be an approach, but (again) hard to implement. using the applidentity data to match incoming and outgoing message will work, but you must be sure it is not used anywhere else in the application and you must be sure the value you put in there is unique. if the exit is written properly there should be no data loss. if the exit is in error in most cases the channel terminates or does not start. you can also tune your exit e.g. by keeping your workarea (allocate at channel start, free at channel end, keep and pass address in exituserarea) to minimize performance impact (depending on OS and programming language). in my statistic exit, i also set a bit if i detect an error during processing (e.g. channel statistic queue full), and - if called again - i check this bit first. if previous error, i leave the exit immediate. this will result in the loss of my statistic data, but the error will not impact message flow. what operating system is used for the hub? regards, stefan "Kulbir S. Thind" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 23.03.2004 11:03 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] [Deutsche Boerse Systems:Virus checked] . Stefan, Thanks for the response. Unfortunately because of the validated environment we work in (Pharmaceutical regulations) we need to use persistent messages no matter what approach we take. We will match the incoming messages with the outgoing messages by using the ApplIdentityData field in the MQMD, we cannot use the MsgId field and CorrelId fields as the MsgId field is definitely being used by the applications and the CorrelId field may be already being used or can be used in the future. The channel exit will modify the incoming message to allocate a value for the ApplIdentityData field, I believe if you code the channel exit correctly you can ensure you have no message loss, do you agree? Cheers, Kulbir. [EMAIL PROTECTED] Sent by: "MQSeries List" <[EMAIL PROTECTED]> 23-Mar-2004 09:32 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] Kulbir, are the messages persistent? mayby a log analysis could be an approach (just an idea, but i think this well be hard to implement because log details are not known to the "normal" mq users). i use a channel exit in a similiar situation, i wanted to be able to see what messages (target queue, target queuemanager) are passing the channels that are connected to a gateway queuemanager (sending and receiving ends). i do not record the messages itself, but take some values (target queue, target qmgr, channel name, put time, application name, ...) to build a statistic message which is put into a statistic queue. thisqueue is triggered by depth and copied to a flat file by a small REXX procedure (all on os/390). analyzing the statistic messages in the flat file i am able to see what messages passed the gateway, i am also able to compute the time a message takes from creation (put time of the message) till passing the gateway queuemanager (put time of the statistic message). the statistic messages are non persistent, to minimise performance impact. no matter what kind of measuring you will implement, it will cost you some performance anyway. i prefer the exit solution because i do not have to touch the application, and - if written properly - there should be no message loss, because you do not manipulate the message data, just get some values and leave the message as it is. Whats the plattform for the Hub? if you use a channel exit, how will you match the incoming and outgoing message (will they have the same MSGID , same message data, ?!?) Regards, Stefan "Kulbir S. Thind" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 22.03.2004 23:33 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] . 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 w
Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]
Stefan, Thanks for the response. Unfortunately because of the validated environment we work in (Pharmaceutical regulations) we need to use persistent messages no matter what approach we take. We will match the incoming messages with the outgoing messages by using the ApplIdentityData field in the MQMD, we cannot use the MsgId field and CorrelId fields as the MsgId field is definitely being used by the applications and the CorrelId field may be already being used or can be used in the future. The channel exit will modify the incoming message to allocate a value for the ApplIdentityData field, I believe if you code the channel exit correctly you can ensure you have no message loss, do you agree? Cheers, Kulbir. [EMAIL PROTECTED] Sent by: "MQSeries List" <[EMAIL PROTECTED]> 23-Mar-2004 09:32 Please respond to "MQSeries List" <[EMAIL PROTECTED]> To: MQSERIES cc: Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] Kulbir, are the messages persistent? mayby a log analysis could be an approach (just an idea, but i think this well be hard to implement because log details are not known to the "normal" mq users). i use a channel exit in a similiar situation, i wanted to be able to see what messages (target queue, target queuemanager) are passing the channels that are connected to a gateway queuemanager (sending and receiving ends). i do not record the messages itself, but take some values (target queue, target qmgr, channel name, put time, application name, ...) to build a statistic message which is put into a statistic queue. thisqueue is triggered by depth and copied to a flat file by a small REXX procedure (all on os/390). analyzing the statistic messages in the flat file i am able to see what messages passed the gateway, i am also able to compute the time a message takes from creation (put time of the message) till passing the gateway queuemanager (put time of the statistic message). the statistic messages are non persistent, to minimise performance impact. no matter what kind of measuring you will implement, it will cost you some performance anyway. i prefer the exit solution because i do not have to touch the application, and - if written properly - there should be no message loss, because you do not manipulate the message data, just get some values and leave the message as it is. Whats the plattform for the Hub? if you use a channel exit, how will you match the incoming and outgoing message (will they have the same MSGID , same message data, ?!?) Regards, Stefan "Kulbir S. Thind" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 22.03.2004 23:33 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] . 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 Please respond to "MQSeries List" <[EMAIL PROTECTED]>
Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked]
Kulbir, are the messages persistent? mayby a log analysis could be an approach (just an idea, but i think this well be hard to implement because log details are not known to the "normal" mq users). i use a channel exit in a similiar situation, i wanted to be able to see what messages (target queue, target queuemanager) are passing the channels that are connected to a gateway queuemanager (sending and receiving ends). i do not record the messages itself, but take some values (target queue, target qmgr, channel name, put time, application name, ...) to build a statistic message which is put into a statistic queue. thisqueue is triggered by depth and copied to a flat file by a small REXX procedure (all on os/390). analyzing the statistic messages in the flat file i am able to see what messages passed the gateway, i am also able to compute the time a message takes from creation (put time of the message) till passing the gateway queuemanager (put time of the statistic message). the statistic messages are non persistent, to minimise performance impact. no matter what kind of measuring you will implement, it will cost you some performance anyway. i prefer the exit solution because i do not have to touch the application, and - if written properly - there should be no message loss, because you do not manipulate the message data, just get some values and leave the message as it is. Whats the plattform for the Hub? if you use a channel exit, how will you match the incoming and outgoing message (will they have the same MSGID , same message data, ?!?) Regards, Stefan "Kulbir S. Thind" <[EMAIL PROTECTED]> Sent by: MQSeries List <[EMAIL PROTECTED]> 22.03.2004 23:33 Please respond to MQSeries List To: [EMAIL PROTECTED] cc: (bcc: Stefan Raabe/DBS/GDB) Subject: Re: Use channel exits or not? [Deutsche Boerse Systems:Virus checked] . 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 Please respond to "MQSeries List" <[EMAIL PROTECTED]> 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 exi
Re: Use channel exits or not?
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 Please respond to "MQSeries List" <[EMAIL PROTECTED]> 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.
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 PMTo: [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 lossThe 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.
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.