I think I joined the thread part way through. Now I'm playing catchup. I've read you original message which I'll add my 2p (English money) in revers(ish) order:
Q3. I then defined a local queue on QMHUB and used one of the spoke QMs to send non-persistent message to it. 1 GIG worth actually. Now these are not written to disk, cause they are not persistent, so where are they, in memory? I see the queue file grew by over a GIG, so doesn't that mean they are on disk, even though they are non persistent? A3: I would expect these to remain in memory until you exceed the amount of memory allocated to hold these messages, after which MQ must store them on disk, surely? Q1. On day 1, is there any data being written to disk by QMHUB as the messages fly thru? I assume no, since they are not persistent (but see Q3 below [ above - J]). A1: See question 1. Messages may get logged to disk if MQ runs out of allocated cache memory. Q2. On day 2, even though we have 2 CPUs, we still have only 1 QM, so I assume all the non persistent messages throughput must be affected by the persistent messages. My reasoning is, as the persistent messages go in and out of the QMAliases, and in and out of the XMIT queues, it has to "stop" and log, right? And if it has to stop and log, then it can't be handling the non persistent ones at the same time right? They have to wait? A3: Elsewhere you mentioned changing the channels to normal rather thanfast. To me this means non-psist messages get sent in sequence and are acknowledged by the channels. Now your messages sit in transmission queues and get read in turn and sent (again waiting for acks from the receiving end). You want this to stop losing messages (though exactly why I'm not sure since they're not psistent and will die if the QM is restarted - another discussion). Since you now have non & psistent messages mixed in a XMITQ, I would expect the psistent onces to "get in the way" of non-persisten ones since they'll be read in batches and sent and acknowledged by the receiving end. However, these are only mixed by XMITQ. Thus if you have all persistent going to SPOKEQM1 and all non-persistent going to SPOKEQM2, I would not expect SPOKEQM2's messages to be delayed by SPOKEQM1's persistent messages. Regards John. -----Original Message----- From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED] Sent: 30 May 2003 15:18 To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages The HUB has dozens of channels to and from each spoke. My question is if one pair of spokes is exchanging Nonpersistent messages and another pair starts sending persistent, will they hurt each other. I don't think dedicating channels to be persistent or not between a spoke QM and the HUB will make a difference, since either way, the HUB QM has to deal with dozens of channels either way. It may make a difference on how fast a message gets from a particular spoke to the HUB, but not what happens once it is already there. <SNIP/> ********************************************************************** Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the intended addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using your reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail maybe accessed. ********************************************************************** 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
