We have a similar environment with about 600 NT clients, and we chose
option 2. We use a single permanent dynamic model queue as the source for
the reply queues, and the applications make the user's ID part of the
permanent queue name. We had thought about option 1, but it can be useful
to be able to examine the messages sent to one specific user. It also lets
us see who's connected at any particular time by checking IPPROCS on the
queues.

Administration's no big deal. As I said, we only have a single model queue.
And periodically we run a script that blindly tries to delete all of these
reply queues. We've found that the queue manager restarts much faster
without these 600 queues. And our application will simply recreate the
queue the next time the user connects, so we're OK with deleting it. If the
queue is open, or if it has messages on it, the queue won't be deleted, so
the script just tries to delete everything.




                      Steve Muller
                      <[EMAIL PROTECTED]>        To:       [EMAIL PROTECTED]
                      Sent by: MQSeries        cc:
                      List                     Subject:  One or Many reply queues for 
Clients?
                      <MQSERIES@AKH-WIE
                      N.AC.AT>


                      07/05/2002 10:17
                      AM
                      Please respond to
                      MQSeries List






Hi all,

Part of our MQ environment is OS/390 (2.1) and NT
(5.2). We will have about 190 NT clients connected to
OS/390. These NT client apps will send a request and
get their replies from OS/390, based on a correlid.
More than 90% of these requests will be queries. We
are estimating that, for all the 190 clients combined,
 there will be about 50 requests and  roughly
50-10000 replies per sec. The turn-around time is
expected  by the user to be 2-12 sec based on the
importance of the request.

I am thinking that we can have either:
1-      One reply queue that would be serviced by all the
clients, OR
2-      A dedicated reply queue for each client.

In the scenario 1:  I know that a  qualified GET
would be slower from a queue with a high Q-depth (I
know indexing could be used ). As far as I can see,
the major downside to this approach would be if
something goes wrong with this queue all the clients
would suffer.

In  the scenario 2: If we have a dedicated reply queue
for each client, MQ admin would not be very happy but
the retrieval of the  msgs would be faster (even if we
used qualified Gets). And a problem with one queue
would not effect the rest of the reply queues


What do you think?   Your insights would be much
appreciated.

Regards,

Steve




__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

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