Some ideas... o The letter from Stephen provides good rules of thumb. Especially about separating channels for differing messages and types.
o I have seen where non-persistent messages over "FAST" channels can get lost. Add the MQ Internet Pass-Thru support pac, MS81, between 2 QMgrs and one can reproduce lost messages quickly. I had an open call with the Hursley developer and the problem was answered as an MQ feature. o What about "pipelining" the MCA. This feature was provided with v5.2. o This thread has kind-of lost scope. Can someone summarize where things are? What questions have been answered? o Lastly... Remember there is a reason why non-persistent messages exist. They can be lost. Therefore, if you can't afford messages to be lost then don't make it non-persistent. -B Brian Bumpass Wachovia Bank Enterprise Infrastructure [EMAIL PROTECTED] Phone - (704) 590-5620 Pager - (800) 425-2613 -----Original Message----- From: Stephan C. Moen [mailto:[EMAIL PROTECTED] Sent: Sunday, June 08, 2003 4:37 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages In regards to sending a "100 MB lunker" I certainly wouldn't want to be sending messages of this size on a production channel with a regular volume of messages to transmit - especially one that handled interactive applications and/or required predictable response times. Instead, a second channel needs to be created to handle messages of this size. Therefore the question about "a higher priority message will somehow jump over the big one" is a moot point. It will never happen because you would never design a system this way. To answer your question directly, once a message is being transmitted, it can't be interrupted by a higher-priority message. In regards to "if the MCA is busy, priority will not help", I beg to differ. It may not help in all cases, but it definitely improves the situation from the spoke's perspective. The only time where priority does not work is if a higher-priority message comes in after a message is actively being transmitted. Once that message is transmitted, the same sequence of events applies again; highest priority messages get transmitted first in a FIFO order. Since the MCA takes messages out of the highest-priority queue down to the lowest priority queue (10 queues in all; 0-9), if the NP messages are tagged with a higher-priority then your persistent messages, the NP messages get transmitted first. This is a better solution then having NP and persistent messages intertwined on the same priority queue - since they get transmitted on a FIFO basis. Though I have never looked into the specific case of NP messages being sent with persistent messages within a channel batch job, I always assumed (according to the MQ documentation) that NP messages sent on a FAST channel fall outside the channel batch mechanism (BATCHINT, BATCHSZ), and don't have to wait for the end of the batch (and associated MQCMIT) before the application sees the messages; they are sent immediately without waiting for completion of the current batch (sent out of syncpoint). That is why NP messages aren't counted against batch values (BATCHSZ, BATCHINT), since they don't use sequence numbers (sequence number is not advanced when a NP messages is sent) and are immediately visible on the receiver side. The side effect for this performance trade-off is that this may cause NP messages to be processed out-of-order or lost due to transmission failures. If this is not true, somebody please correct my erroneous assertion. In regards to Question 1 ("is there any data/messages being written to disk by QMHUB as the messages fly thru"), since the ORIGINAL question referenced ALIAS queues on QMHUB and since an alias queue is not a real queue (and therefore has no filename or disk allocated to it), I can only assume that if an NP message on MQHUB encounters disk I/O, it must be related to PAGING I/O (not enough memory on this box to handle the workload currently configured). Remember the original question refers to disk I/O on QMHUB - not the spokes. If this is the case (someone please prove me wrong), then whatever you do to the MQSeries configuration, won't make any difference. The only solution is to add more memory to that box OR configure your memory (if the OS will allow you to; use the 'vmtune' command on AIX) so that more memory is allocated to computational memory (e.g., process working set) versus persistent memory (e.g., files that have a hard disk location). With the exception of the XMIT queues on QMHUB, 'qalias' definitions don't have an associated 'DefaultQBufferSize' attribute have some have stated, and therefore don't apply as a solution to this issue. For the case referenced earlier in this thread where the local queue file grew to 1+ GB in size, that is expected since 1 GB of messages were transmitted to it. If the amount of shared memory used to hold NP messages (default is 64KBs) is exceeded, overflow messages are forced to go to disk - hence why you see the size of the local queue file growing. If this alias queue is not associated with a local queue but a remote queue on another node, it is completely normal to see paging activity occur since there is no disk file for overflow messages to be directed to, hence the only resource available for storing messages yet to be processed is memory. I'm sure a closer inspection of this situation would bear this out. In regards to how to 'minimize' the impact of disk I/O with NP messages, another point of concern is "how are receiver channels created on the MQHUB". I bring this up because I believe IBM recommends using the 'runmqlsr' daemon on all distributed platforms to start requestor channels (ala receiver). This daemon is a multi-threaded listener program that will execute as one process only, and runs multiple receiver channels as separate individual threads. If a thread (one of the spoke channels) is suspended waiting for disk I/O to complete AND the daemon process has not yet consumed it's entire CPU timeslot, then the CPU is granted to another thread within that process. Therefore, work is still performed and minimal idle time is spent by NP messages that are waiting for disk I/O to complete generated by persistent messages. If your using the 'inetd' daemon to spawn off new channels (e.g., amqcrsta), once that process has to write to disk, that process is suspended and put back on the CPU run queue. From my perspective, using 'runmqlsr' eliminates the need to have BOTH 'fast' and 'normal' channels. No matter what solution you pick, you are not going to completely eliminate NP disk I/O. These 'suggestions' has minimal impact from a configuration and administration perspective and that is why they were volunteered. -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, Dennis Sent: Friday, June 06, 2003 1:16 PM To: [EMAIL PROTECTED] Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages Didn't see your response before I sent mine. An MCA issues an I/O request to the OS. I do not believe that THAT MCA is brave enough to do other work asynchronously while the I/O is pending. All work with respect to that MCA stops, the CPU is thus freed to serve other MCA's that may not require disk. > -----Original Message----- > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 7:08 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi stent messages > > An application is sending NP messages, priority 9. Another app sends P > messages, priority 1. Odds are both apps are sending messages somewhat > regularly. When things are fine, the NP messages jump to the head of the > line and zoom across. But sooner or later, those persistent messages are > going get their turn in line and be shipped. And if the other side is having > disk problems, what happens then? Are NP messages produced after this point > stuck waiting, because the MCA is busy with the persistent message, waiting > for a response? Or are you saying that they will pass the stuck persistent > message? > > Same question when everything is OK. If a 100MEG lunker is taking its time > to be shipped, are you saying that a higher priority message will somehow > jump over the big one? > > I gotta think that if the MCA is busy (either moving a big message or stuck > waiting for I/O), Priority will not help. > > -----Original Message----- > From: Stephan C. Moen [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 9:23 AM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / > non-persi stent messages > > > For those mixing non-persistent messages with persistent messages, if you > want to avoid this, simply raise the priority one level higher than your > persistent messages. The higher priority messages will be transmitted PRIOR > to the lower priority messages. This also eliminates response time problems > with VERY LARGE messages or a batch run of many messages, causing response > time delays to INTERACTIVE application that require more real-time > responses, and minimizes the disk I/O issues that this thread has been > talking about. This ASSUMES that queues are defined as PRIORITY versus > FIFO. > > > -----Original Message----- > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Miller, > Dennis > Sent: Friday, May 30, 2003 5:41 PM > To: [EMAIL PROTECTED] > Subject: Re: How a MQSeries Hub does its thing with persistent / non-persi > stent messages > > Here's my mindset. Assuming non-persistent messages do not require disk I/O, > then they should continue to flow even when your disk I/O sub-system is > temporarily unavailable. Since you experiencing something else, there must > be conditions under which NP messages are dependent on the disk. I was both > attempting to identify some of likely causes and, > somewhat-confusingly-in-the-same-breath, suggest that if the logs are on the > unavailable disk, you might be heading upstream with a broom stick for a > paddle. > > I stand by my first point, even if there are as few as two messages in a > batch. If one is persistent, then non-persistent msgs in the same batch > will be blocked until the logs are available. Similarly, the qmgr may at > times suspend all activity until it can access the logs. The lesson is to > put logs on high-performance, high-availability media--redundant, > hot-swapable raid or the like. Putting logs on media that is routinely > taken out of service is paramount to drilling holes in your broomstick. > > I am not necessarily an advocate for separate channels, but I do think it > could improve the odds that non-persistent messages will flow when the SAN > is unavailable. Generally, while one qmgr process waits for I/O, the others> > may be dispatched to make good use of the available time, including their > own disk I/O and, hopefully, network I/O for non-persistent messages that do > not require disk. Tasks waiting on I/O do not consume--they are overlapped > with those needing CPU, lest a staggering percentage of the CPU resource > would go to waste. The notion of being a CPU being "busy waiting" is > silly--faster machines don't wait at twice the speed! > > > Point #1. If a server is dealing with persistent and non persistent > messages, the persistent ones have to negatively effect the non > persistent > ones, at a hardware level (disk and CPU). It does not matter whether > you > have separate QMs on that server split between persistent and non > persistent. Both QMs share the CPU and disk. It does not matter > whether you > have separate channels or not. All MCAs share the same CPU and disk. > > Only true if there is contention for one of the resources: CPU, memory, or > I/O. If you can dedicate a task (either by separate Qmgrs or separate > channels) to non-persistent messages that are not dependent on disk I/O, > then you do not have competion for that resource and there would not be an > adverse affect with respect to it. > > > Point #2. If the disk is temporarily unavailable, then persistent > messages > are effected, and due to point #1, non persistent ones are effected as well. > > I agree (in a contrary way): > > If tasks handling non-persistent messages are dependent on disk, then they > may be adversely affected by the unavailable disk. > > If tasks handling non-persistent messages are not dependent on disk, then > they may be favorably affected by the unavailable disk! This occurs because > other tasks waiting on disk are not competing for CPU. > > > > -----Original Message----- > > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > > Sent: Friday, May 30, 2003 1:01 PM > > To: [EMAIL PROTECTED] > > Subject: Re: How a MQSeries Hub does its thing with persistent / > non-persi stent messages > > > > Hi Dennis. > > > > I agree that non-persistent and persistent messages in a batch will be > > available at the same time. But my batches are of 1 or 2 messages. Since > my > > BATCHINT is zero, and the channel can keep the XMIT queue at zero, I doubt > I > > am incurring any performance hit. 1 or 2 messages are sent across, > maaaaybe > > message #1 is a nonpersistent that is held back until the batch completes, > > but the batch completes almost immediately, since no more message have yet > > arrived and the BATCHINT expires. At this point I am still not convinced, > in > > my scenario, that this setting has an effect for the above reason.> > > > > It has also been mentioned more than once to make a separate channel for > > persistent vs. non-persistent messages. I don't see how that makes a > > difference. So I make 2 separate channels from SPOKEQM1 to HUBQM. As far > as > > the hub and its receiving MCAs are concerned, big deal. The HUB already > had > > 50 other receiving MCAs and channels for all the other spokes. If the HUB > QM > > is slowing down because its SAN is temporarily unavailable, does it really > > matter if you have 1,2 or 20 channels between a particular spoke and the > > HUB? The HUB still has to deal with the other 50 spokes, and if they are > > sending persistent messages, then the HUBQM has to service them as well, > and > > it makes no diff that you bothered to separate the channels from any one > > particular spoke. All these Receiving MCAs have to compete for 1 or 2 > CPUs, > > and if any of those CPUs are busy waiting because the SAN is N/A, then a > > whole bunch of MCAs are effected. > > > > > > I wonder what everyone thinks of the following: > > > > Point #1. If a server is dealing with persistent and non persistent > > messages, the persistent ones have to negatively effect the non persistent> > > ones, at a hardware level (disk and CPU). It does not matter whether you > > have separate QMs on that server split between persistent and non > > persistent. Both QMs share the CPU and disk. It does not matter whether > you > > have separate channels or not. All MCAs share the same CPU and disk. > > > > Point #2. If the disk is temporarily unavailable, then persistent messages > > are effected, and due to point #1, non persistent ones are effected as > well. > > > > > > > > > > > > > > > > -----Original Message----- > > From: Miller, Dennis [mailto:[EMAIL PROTECTED] > > Sent: Friday, May 30, 2003 1:55 PM > > To: [EMAIL PROTECTED] > > Subject: Re: How a MQSeries Hub does its thing with persistent / > > non-persistent messages > > > > > > Peter, > > If you use NPMSPEED=normal, non-persistent and persistent messages in the > > same batch all become available at the same time. You can infer from that, > > that performance of non-persistent messages is dependent on I/O for > > persistent messages, though I believe it is more likely to be the > > (synchronous) log I/O rather than (asynchronous) queue I/O. > > > > Segregating persistent and non-persistent messages on different channels > > relieves the above dependency. If one channel is waiting for the log, > > another should be able to continue transmitting messages until such time > as > > it also needs the log or until the qmgr decides a checkpoint is in order. > > > > > > Bottom line: > > If your logs are on the SAN, there is a distinct probability that your > spoke > > channels will take a break when that "device" is not available. > > > > my .02 sense (pun intentional). > > > > > > > -----Original Message----- > > > From: Potkay, Peter M (PLC, IT) [SMTP:[EMAIL PROTECTED] > > > Sent: Friday, May 30, 2003 7:21 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: How a MQSeries Hub does its thing with persistent > / > > non-persi stent messages > > > > > > So here is my real question, which is what makes me wonder exactly how a > > QM > > > handles messages. > > > > > > Our HUB server is using Veritas. The disk that is being written to > > (whenever > > > that may be) is actually on the Storage Area Network (SAN). > > > > > > The HUB is also clustered with 2 queue managers dedicated to MQSI. The > HUB > > > acts simply as a gateway queue manager for this MQSI cluster. THE MQSI > > boxes > > > are in 2 separate locations, with Veritas, and both again also write to > > the > > > SAN. > > > > > > > > > Whenever we make bin changes to the SAN, that change ripples across the > > > fabric, making the SAN unavailable for a tiny bit of time. > > > > > > Now, we have an app that is counting milliseconds in its roundtrip of > the > > > message. This message starts on one of the spokes, comes to the HUB, is > > > round robined to one of the MQSI boxes, the processed message comes > back> > > to > > > the HUB, which then sends it down to the receiving spoke. It processes > the > > > message, sends it back to the hub, round robined into MQSI for > processing > > > the reply, the processed reply goes back to the hub, which then sends > the > > > reply back to the originating spoke. For 99.99% of the time, this > > roundtrip > > > takes under 500 milliseconds. The app waits up to 2000 milliseconds for > > the > > > reply. The messages are non persistent and about 25K in size. > > > > > > Whenever the bin changes to the SAN take place, we start getting > messages > > > that take longer than 2000 milliseconds, and now we have orphaned > replies. > > > These are non persistent messages that are under 64K, so why does a > change > > > that makes the disk unavailable cause these messages to slow down? My > > guess > > > is that the persistent messages the HUB is processing at the same time > (or > > > the >64K Nonpersistent ones) must somehow be effecting the performance > of > > > the non persistent ones. And I also assume that channel speed has> > nothing > > to > > > do with this. > > > > > > So the angle I am after here is how can I increase the performance of my > > > messages for this app so that changes to the SAN don't effect it. > > > > > > > > > > > > -----Original Message----- > > > From: John Scott [mailto:[EMAIL PROTECTED] > > > Sent: Friday, May 30, 2003 10:18 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: How a MQSeries Hub does its thing with persistent / > > > non-persi stent messages > > > > > > > > > This would be true for the smallest unit of execution (normally a > thread, > > > not a process). Thus if a thread of execution was committing data to > disk, > > > that thread would not continue until the commit was completed. However, > > > another thread within the same process would get CPU if it was able to > > > execute some code. > > > > > > It all depends on whether the MQ processes are multi-threaded or not. > > > > > > Regards > > > John. > > > > > > -----Original Message----- > > > From: Potkay, Peter M (PLC, IT) [mailto:[EMAIL PROTECTED]> > > > Sent: 30 May 2003 12:50 > > > To: [EMAIL PROTECTED] > > > Subject: Re: How a MQSeries Hub does its thing with persistent / > non-persi > > > stent messages > > > > > > > > > Gary, > > > About a queue manager, or any process that runs on any computer, > I > > > have always assumed, maybe incorrectly, that a CPU on a box can only do > > one > > > thing at a time. It may be incredibly fast, giving the illusion of many > > > things happening at once, but when you get right down to it, everything > > has > > > to wait its turn for the CPU to do its thing. > > > > > > And if the CPU is waiting to interact with the disk to write a > persistent > > > (or bigger than 64k non-persistent) message (I guess even if that > message > > is > > > going to blink in and out of a QM Alias or XMITQ???) then the CPU cant > go > > on > > > to handle non persistent messages. > > > > > > ??? > > > > > > > > > -----Original Message----- > > > From: Gary Ward [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, May 29, 2003 7:47 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: How a MQSeries Hub does its thing with persistent / > > > non-persistent messages > > > > > > > > > Peter, > > > > > > I'll gladly defer to any IBM MQ Developers lurking on the list since > this > > is > > > getting really 'down and dirty', but in the meantime I'll give you > another > > > $.02... > > > > > > Right about my answer to Q2... I guess I missed your point. Having read > > > your follow-up, I would offer this theory. I think the queue manager > MUST > > > be able to do more than a single task at once. That's why it's made up > of > > > many individual processes which have dedicated tasks. I would think at > > any > > > one moment there's a bunch of messages floating around in various > states. > > If > > > the messages are non-persistent, they're not logged and hence can be > > > available immediately (if they're not IN SYNCPOINT with persistent > > > messages). Non-persistent messages only get written to disk when > there's> > > > not enough memory available to hold them on an individual queue. I'm > not > > > sure about persistent messages always going right to the queue file > > system, > > > but my gut feeling is that they do. > > > > > > If your non-persistent messages are 100K and you have your queues set at > > the > > > 64KB default, I'm pretty sure they go right to disk. That's why you > > should > > > tune that non-persistent message buffer. Hopefully something is already > > > waiting for these non-persistent messages so they get handed off > directly > > in > > > the manner that T. Rob and I mentioned earlier in this thread. Then > > there's > > > no I/O at all. > > > > > > Hope this helps... any IBMer's want to comment???? > > > > > > > > > -----Original Message----- > > > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Potkay,> > > > Peter M (PLC, IT) > > > Sent: Thursday, May 29, 2003 6:11 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: How a MQSeries Hub does its thing with persistent / > non-persi > > > st m essages > > > > > > > > > Gary, > > > I think you answer to Q2 pertains more to when a message is > about > > to > > > leave a server to go onto the next one. That setting tells the receiving > > > side how soon it can have the Nonpersistent message in relation to the > > batch > > > of messages coming across the channel. > > > > > > I am curious about once the messages have already been accepted on the > > HUB. > > > Whether they were persistent or not, regardless of the channel speed > > > setting, at any given moment on our busy HUB, the QM finds itself with > > lots > > > and lots of messages that it now has complete control over. As it routes > > > them thru the QMAliases and the XMITQs, it has to "stop" and log the > > > persistent messages. I feel that this activity must somehow also effect > > the > > > non persistent ones as well, since the QM can only do one thing at a > time, > > > regardless how fast it does it. If it is busy logging a persistent > > message, > > > it can't route a non persistent one at that exact moment, correct? > > > > > > > > > Regarding the queue buffer setting, if my messages are less than 64K, > and > > > because due to high activity all my channels in a particular > > SPOKE-HUB-SPOKE > > > route are running, then a non persistent message would go in and out of > > each> > > > XMIT queue, in and out of each QM Alias queue and in and out of each > > > application queue (assuming the app has an outstanding GET with wait) > with > > > no I/O to the disk? > > > > > > What if the messages are 100K non persistent ones and the buffer setting > > is > > > still at default? Are you saying that a non persistent message is still > > > written to disk? If yes, to me that sounds like there is no reason to > not > > > use persistence always on any message larger than 64K. Surely that can't > > be > > > the case! Or is it like T.Rob suggested: Nonpersistent gets written to > > > disk, persistent gets written to disk AND log, for a double I/O??? > > > > > > > > > > > > -----Original Message----- > > > From: Gary Ward [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, May 29, 2003 1:19 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: How a MQSeries Hub does its thing with persistent / > non-persi > > > st m essages > > > > > > > > > Let me throw in my $.02 - which is actually less in Euros lately ;) > > > > > > Q1. There "could" be I/O to the queue filesystem... see more below > > > > > > Q2. The non-persistent messages will not be "affected" by the > persistent > > > ones as long as you are using NPMSPEED(FAST) on your channels. They do > > not > > > wait for a syncpoint. Paul Clarke could further discuss this with you > I'm > > > sure! Consider using channel pipelining as well. > > > > > > Q3. Related to Q1, yes you will eventually see I/O under certain > > > circumstances... > > > > > > The certain circumstances have to do with arrival and processing rates > of > > > your non-persistent messages along with the setting of your > > > DefaultQBufferSize. Each queue by default only has 64K of memory for> > > > non-persistent messages. So, if you're flooded with data or in the case > > of > > > your 1GB of non-persistent data coming through, I'm sure you had some > > spill > > > to the disk filesystem. You can augment the DefaultQBufferSize by > setting > > > it in the qm.ini in the TuningParameters stanza. HOWEVER, be sure to do > > > this correctly!!! You need to set the parameter, restart the QM, define > > your > > > queues that should have the extra large buffer, remove the stanza entry, > > and > > > then restart the QM. You don't want to leave this set for all queues > > being > > > created! The max size for the buffer is 1MB. Details about this> > > parameter > > > and usage can be found in the various performance report SupportPacs. > > > > > > Also, T.Rob was correct about in-memory transfer, but this only occurs > > > between applications putting and getting from a queue simulataneously. > > The > > > messages MUST NOT be IN_SYNCPOINT and they must be non-persistent. The > > > applications will directly exchange the message in-memory and satisfy > the > > MQ > > > API calls on both ends (the PUT and the GET). > > > > > > Hope this helps! > > > Gary > > > > > > ------------------------------ > > > Gary J. Ward > > > Senior Consulting Engineer > > > Information Design, Inc. > > > A Premier IBM Business Partner > > > > > > > > > -------- Original Message -------- > > > > > > ==> From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> > > > ==> Date: Thu, 29 May 2003 11:28:59 -0500 > > > > > > Peter, > > > > > > I remember seeing a response from one of the IBM folks who said that > some > > > non-persistent message exchanges happen as an in-memory transfer. In > > > general though, assume your non-persistent messages are written to disk > > but > > > not logged. Persistent messages are written to disk AND to the log. > > > > > > -- T.Rob > > > > > > -----Original Message----- From: Potkay, Peter M (PLC, IT) > > > [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 11:43 > > AM > > > To: [EMAIL PROTECTED] Subject: How a MQSeries Hub does its thing > > with > > > persistent / non-persist m essages > > > > > > Imagine if you will a Hub and Spoke architecture. > > > > > > QMHUB sits in the middle on a 2 CPU server. 1.3gig CPU, 2 gig RAM > > MQVersion > > > 5.2.1 CSD05 QM1....QM20 are spokes. > > > > > > On QMHUB, there are no application queues. Only queue manager aliases > and > > > XMIT queues. There is a QMAlias for QM1 called QM1, and it directs > > messages > > > to QM1.XMITQ, which is serviced by the SNDR channel off to QM1. This > > QMAlias> > > > / XMITQ / SNDR setup is present for every spoke. And there is also a > RCVR > > > channel as well from every spoke. > > > > > > On day 1 there is only non persistent message traffic for all the > spokes. > > > On day 2 a pair of the spokes starts exchanging persistent messages. > > > > > > 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). > > > > > > 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? > > > > > > 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? > > > > > > > > > > > > More details.............. Batch Interval = 0 Batch Size = 50 Non > > > Persistent Message Speed = Normal There is an MQCluster involved, which > is > > > why we have the QMAliases (can't cluster XMIT queues). I don't think > this> > > > effects any of the answers to the above, but I can expound if need be. > > > > > > > > > > > > Peter Potkay MQSeries Specialist The Hartford Financial Services > > > [EMAIL PROTECTED] x77906 IBM MQSeries Certified > > > > > > > > > > > > This communication, including attachments, is for the exclusive use of > > > addressee and may contain proprietary, confidential or privileged> > > > information. If you are not the intended recipient, any use, copying, > > > disclosure, dissemination or distribution is strictly prohibited. If you > > are > > > not the intended recipient, please notify the sender immediately by > return > > > email and delete this communication and destroy all copies. > > > > > > 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 > > > > > > > > > ********************************************************************** > > > > > > 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 > > > > > > 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 > _______________________________________________________________ > This message was content-scanned by GatewayDefender > 5/30/2003 - 6:52:10 PM - BA037d283f.00000001.mml > > 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 _______________________________________________________________ This message was content-scanned by GatewayDefender 6/6/2003 - 2:27:14 PM - BB03633bd6.00000001.mml 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
