The client connection has a performance disadvantage, mostly because of network overhead. After all, every API request (and any messages it conveys) must pass over the network to get between the MQ client and the qmgr. The server channel agent, acting on behalf of the client, uses local bindings and should experience about the same performance as the application using local bindings. But the exchange of API requests between the MQ client and the server channel agent is extra work.
I am not in a position to quantify it, though, and I expect it would depend greatly on your network configuration. -----Original Message----- From: Gurney, Matthew [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 12:48 AM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux What would the performance difference of using MQClient connections to connect to a local Queue manager on the same Unix host, compared to using a local bindings direct connection to the local Queue manager. I understand that for Pavel's situation, this be be irrelevant, but I am concerned with the general case? Matt. -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: 01 September 2004 01:13 To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux I understand your hesitance to use MQ client for such an app. But think about what you are really asking. An app on one server with MQM credentials for other servers? An app on one server with access to MQM internals on another server? Hmmm... I'm sure you know that without MQ-Client, you cannot even connect to a single QMgr across servers, much less multitudes of them. So, if your thinking about monitoring even one qmgr by an app running on a different system, you are talking about some sort of client model, by definition. But it needn't necessarily be the MQ client. You could for example, write a monitoring agent and run it locally on each qmgr. The user interface for your monitoring app is then a client to these agents, requesting services and receiving replies from them. If you are so-inclined, you can even conduct the request/reply exchanges using local connections and MQ messages (although, depending on what you are doing, one might question the wisdom of running a monitoring application in-band like that). It is somewhat analagous to how the command server works, only customized to your specific requirements. -----Original Message----- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 1:31 PM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Thanks Dennis, This is a low-level monitoring application (requiring mqm credentials, by the way). Making it an MQ client makes running listener or configured a pre-requisite to operate the app even if there is no business purpose for them to be there and creates a whole number of security issues with the too-far-going implications of their possible solutions. I will have to either live with these consequences or go for running several instances of the app instead (which is not ideal for my cause, either..). Pavel "Miller, Dennis" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OM> cc: Sent by: MQSeries Subject: Re: Connecting to more than one queue managers on solaris, linux List <[EMAIL PROTECTED] n.AC.AT> 08/31/2004 04:05 PM Please respond to MQSeries List Yes, you can do it in the server app. Just use the MQ client. A server app from the perspective of the application architecture can be a client from the perspective of MQ. -----Original Message----- From: Pavel Tolkachev [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 31, 2004 10:30 AM To: [EMAIL PROTECTED] Subject: Re: Connecting to more than one queue managers on solaris, linux Thanks David, Is there absolutely no way to do it in the Server app? What is so different between Windows and Unix that you can do it on one but not the other? Thanks, Pavel "David C. Partridge" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: RIMEUR.COM> Subject: Re: Connecting to more than one queue managers on solaris, linux Sent by: MQSeries List <[EMAIL PROTECTED] .AC.AT> 08/31/2004 11:58 AM Please respond to MQSeries List Using MQ Client you can do this - each thread can own a connection to different QM. 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 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. 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 ======================================================================== ====== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ======================================================================== ====== 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
