Roger

I think your leaving out a few things, not the least of which are the
Message Descriptor and Get Message Options structures. These are much
larger than 8 bytes. In all your going to send more than 400 bytes
(depending on version). Not to mention all the processing that goes with
polling.

As Peter and Dennis point out, the use of a quit message is a common
solution for this type of service and is an elegant way to shut the
application down while not forcing the application to waste both CPU and
bandwidth with unnecessary polling.

Rick


|---------+--------------------------------------->
|         |   Roger Lacroix                       |
|         |   <[EMAIL PROTECTED]>     |
|         |                                       |
|         |   Sent by: MQSeries List              |
|         |   <[EMAIL PROTECTED]>           |
|         |                                       |
|         |                                       |
|         |                                       |
|         |   Monday August 4, 2003 12:24 PM      |
|         |   Please respond to MQSeries List     |
|         |                                       |
|---------+--------------------------------------->
  
>----------------------------------------------------------------------------------------------------|
  |                                                                                    
                |
  |       To:                                         [EMAIL PROTECTED]                
          |
  |       cc:                                                                          
                |
  |       Subject:   Re: MQGet Blocked Read                                            
                |
  
>----------------------------------------------------------------------------------------------------|




Hi,

Ya, I don't get the comment of "affects bandwidth" either.  Usually I hear
this from a manager who thinks they are a developer.  When a WMQ client
program issues a MQGET, only a few bytes are sent across the network. The 2
major items that are sent are: Connection Handle (4 bytes) and Object
Handle (4 bytes).

In the past, I have used small WaitInterval of 3, 5 and 10 seconds with no
noticeable network hit for a Windows based MQ client program running as a
service.  I mean seriously, if you changed your WaitInterval from 120 to 3
seconds (40 times smaller) then your program would be sending an extra 320
bytes (40 * 8).

You are going to do all this extra work to save less than 1 KB of bandwidth
per every 120 seconds.  I think you should suggest to your manager(s) that
they need  re-evaluate if there is actually a problem with using a smaller
WaitInterval value.

Regards,
Roger Lacroix
Enterprise Architect
Capitalware Inc.


At 12:56 PM 8/4/2003, you wrote:
>Steve,
>I guess we come from different schools; sending a "quit" message seems
>quite elegant to me.  Are you claiming the waitinterval affects bandwidth?
>I don't get it.
>
>
>
> > -----Original Message-----
> > From: Steve D. Perkins [SMTP:[EMAIL PROTECTED]
> > Sent: Saturday, August 02, 2003 3:42 PM
> > To:   [EMAIL PROTECTED]
> > Subject:           MQGet Blocked Read
> >
> > Hello,
> >
> >         I have an application which one of the prerequisites is to call
> MQGET with
> > a minimum 120 second WaitInterval!  This application is using MQSeries
5.3
> > client on a WIN32 platform and runs as a service.  The minimum 120
second
> > interval is there to supposedly keep the bandwidth down to a minimum.
> > However, the problem is with WIN32 the Service Control Manager times
> out and
> > cannot shut down the service in a timely fashion.  MQGET will only
> return if
> > the WaitInterval has expired or a message is received.  My only
solution is
> > to put a message onto the "GET Queue" prior to shutdown to force an
> exit out
> > of the blocked read.  I was hoping for a more elegant solution on
WIN32.
> > Are there any other ways to "signal" a blocked MQI MQGET on Win32 to
exit?
> >
> > Thanks much!
> >
> > Steve
> >
> > 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