Rick and Bill,

Many thanks for your responses.  I agree with you recommendation (unprompted
you agreed with mine!) - use a server because it reduces the message
traffic, and gives the channel initiator an opportunity to optimise (i.e.
re-block) that traffic when it marshals it over the wire, and it allows
_some_ opportunity for tuning.  If compressing the client messages doesn't
do the business, that is the way we'll go.


Cheers, Alan

-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Rick
Tsujimoto
Sent: 05 October 2004 19:06
To: [EMAIL PROTECTED]
Subject: Re: MQ SupportPack MO02 Compression Exit on Client Channels


Bill,

That sounds reasonable, except if there's an app design constraint, e.g.
committing DB updates with MQPUTs.  Hey Alan, wanna pony up for a server
license?




             MQ-SERIES
             <[EMAIL PROTECTED]
             CA.COM>                                                    To
             Sent by: MQSeries         [EMAIL PROTECTED]
             List                                                       cc
             <[EMAIL PROTECTED]
             n.AC.AT>                                              Subject
                                       Re: MQ SupportPack MO02 Compression
                                       Exit on Client Channels
             10/05/2004 01:51
             PM


             Please respond to
               MQSeries List
             <[EMAIL PROTECTED]
                 n.AC.AT>






Rick,

I've been resistant about using the client over WAN at my shop. With the
Client, every API call causes traffic between the client and the server.
(you can see this when watching the status of the client svrconn channel).

For each MQI call you have to wait for a round trip communication. Ex.
Conn, open, put, close. This would cause 4 round trip "communications"
between client and server.  The put would be the big one, including the data
for the message.

If you use server to server communication over the WAN then there would be
(for the most part) one round trip communication, which would be the message
itself.

What we do is set up "HUB" servers, where the clients talk over the LAN to
the server, and then go server to server over the WAN.

MO02 could help however between the servers, depending upon the data and how
well it'll compress.

anyway,

hope that helps

Bill

>>> [EMAIL PROTECTED] 10/5/2004 11:23:30 AM >>>
Rick,

Thank you for responding.

Indeed, compression might not be a solution.  The problem arises because the
s/390 is being re-sited, changing the client connections from a happy high
capacity LAN to a slower and sadder WAN.  The change has pushed up response
times beyond the pain threshold.  A number of other avenues are being
investigated, but the compression exit scores high on 'can we try it and see
today?' criteria.  My hope is that my request about MO02 & clients throws up
any gotcha's others wish to share.


Alan

-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Rick
Tsujimoto
Sent: 05 October 2004 15:59
To: [EMAIL PROTECTED]
Subject: Re: MQ SupportPack MO02 Compression Exit on Client Channels


Alan,

What sort of network problems are you experiencing?  Compressing the data
may not be a solution.




             "Lovett, Alan J"
             <[EMAIL PROTECTED]
             COM>
To
             Sent by: MQSeries         [EMAIL PROTECTED]
             List
cc
             <[EMAIL PROTECTED]
             n.AC.AT>
Subject
                                       MQ SupportPack MO02 Compression
                                       Exit on Client Channels
             10/05/2004 10:44
             AM


             Please respond to
               MQSeries List
             <[EMAIL PROTECTED]
                 n.AC.AT>






Hi,

We have a network problem between AIX clients talking to S/390 servers.  We
are considering using the MO02 compression exit on the server/client
connection channels, to reduce network traffic.  Does anyone else do this?
Any problems we should be aware of?

Many thanks for any replies.


Alan

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

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

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

Reply via email to