Interesting points all around, but to answer your question, I don't think
the reasons you presented to arbitrarily set the max message size are
comprehensive enough. You seem to assume that just because it's easy to
properly design applications to handle arbitrary message sizes that
designers should, would and could. In reality, this is rarely the case.
In addition, applications rarely handle failures properly that may be due
to message anomalies, e.g. poison messages.
Also, when applications are ready to come online, in all likelihood they
requested the max message size limit to protect themselves. By raising the
limit, without their say so, is not good idea.
Lastly, as an MQ admin, your job is to ensure the messages flow properly
and to handle any problems that impact the infrastructure, e.g. DLQ
messages. By raising the max message size, you're passing the
responsibility of handling oversized messages to the applications which
could prove disasterous. By letting oversized messages go the DLQ, you are
at least insuring the proper sized messages reach the applications. The
bad ones get shunted elsewhere, and don't introduce problems unnecessarily.
"Stephan C.
Moen" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
> Subject: Re: Maximum size of defined
message
Sent by:
MQSeries List
<MQSERIES@AKH-Wi
en.AC.AT>
02/20/2003 10:01
AM
Please respond
to MQSeries List
You state four strong points to which most of this audience would agree
with, including myself. But when we get down to the root of my original
question, nobody has yet answered it (maximum message size). All I'm
asking
from fellow contributors, is that whatever size your enterprise settles on
a
maximum message size, it won't take long before you see a message in your
DLQ or ERROR logs that states message too big for queue, channel or queue
manager. So why arbitrarily set it to a value that will eventually be
broken and just set it to it's maximum architectural limit. My point, if
its
going to fail, let the application fail versus having the message transport
fail. If the application isn't designed to accept that size message, that
is what needs to be fixed, or at least the application generating that size
of a message. In Incident Management, the END GOAL is to always find the
'root cause' of the problem, then resolve it. From my perspective, allow
MQSeries to take care of message flow and your applications take
responsibility of message processing. All MQSeries is asked to do is to
route messages to their ultimate destination. Let the application make the
decision what its going to do with the message. It's that simple.
Stephan C. Moen
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert
Broderick
Sent: Thursday, February 20, 2003 6:45 AM
To: [EMAIL PROTECTED]
Subject: Re: Maximum size of defined message
You know, if I was sitting on the right hand of GOD I would heartly agree
with you. But having been around the block a few times and written my fair
share of code and managed others who claim the same. I have noticed:
1 - Programmers never do what they should or supposed to do.
2 - Getting calls at 3AM suck
3 - In the financial world "s-h-i-t" travels downward and you don't want to
be on the bottom of the ladder (DTC saying, but true)
4 - In reality, Technology does not drive the Business, many business
analyist are aware of the expectations, limitations and pitfalls of
technology. After explaining this situation to one good 'business analyst",
see if he/she jumps up and down with joy at the prospect of being
responsible for someone elses mistakes and agrees you should do it that
way.
A good architect WILL not only
design a good system. He/She will also take care of his job security
by
keeping the people who sign the checks happy!! As once
said in a movie somewhere..."You fight the battles you can win!"
>From: "Stephan C. Moen" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Maximum size of defined message
>Date: Thu, 20 Feb 2003 00:14:13 -0600
>
>Bobbee,
>
>I guess I take a different tack. I look for consistency, continuity, and
>simplicity in my operational environment. I don't want to create
>artificial
>limits for my technology stack because I know eventually, those limits
will
>be tested and require changes; that has been proven over time. So why not
>start out by taking those limits off the table. Why should I place
>artificial limits on my infrastructure if I don't have to. Isn't that a
>primary goal of MQSeries - reliability, availability and scalability
(RAS)?
>If the message size is raised ABOVE the maximum limit, the problem will be
>caught at the application ISSUING the call, which is where it should be;
>just following your viewpoint of determining where the BLAME should go.
>
>Lastly, the application can easily be coded to handle large message sizes.
>As we all know, the MQGET call will return the size of the message is has
>or
>tried to retrieve. If your application buffer is too small to accept the
>read message, there are several options that can be done. Following
anyone
>of the steps listed below, will prevent you from waking up at 3AM.
>
>1) perform another MQGET with a dynamically allocated buffer set to the
>message size from the first call
>2) have the application automatically move the message into an ERROR
queue;
>keep the workflow moving..
>3) allow MQGET to truncate the message (not the best option), so a
>poison-loop condition doesn't exist
>4) You can always have your application determine the max message size of
>the queue manager it is connecting to. This will GUARANTEE that the
>application will NEVER receive a message it can't handle because of
message
>size.
>
>To address your point about a good architect, isn't the architect's job to
>MINIMIZE outages and not point fingers. If anything, it's the architect's
>fault for not designing the application to handle this type of situation.
>That's what a GOOD architect would do; eliminate POTENTIAL problems before
>they have a chance to surface. I would assume that is a line-item in
every
>MQSeries Architect's Best Practices Binder.
>
>So I will post the question again, what are the issues? I have yet to
hear
>a reason why this wouldn't be a good idea. And Bobbee, please proof-read
>your reply. I'm not totally sure what you were trying to say on your
first
>reply ( but I responded to what I 'thought' you were saying ) but I'm sure
>your second one will be crystal clear.
>
>
>Stephan C. Moen
>
>
>-----Original Message-----
>From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert
>Broderick
>Sent: Wednesday, February 19, 2003 12:48 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Maximum size of defined message
>
>Well if you think about it....What if a distributed application send you a
>normal size message of 100 bytes. You application processes messages from
>many suppliers that give you messages of the same size. You go ahead and
>set
>the MAX Queue size for a message at 100Meg. Now the distributed
application
>send you a message that is larger than the 100 bytes, actually it send you
>MANY of shuch messages.
>
>Two things come to mind....
>
>Fist of all prior to setting the max size. The problem is theres. now it
is
>yours.
>Second. Your application cannot handle the message so it backs up on the
>queue and all your other suppling systems begin to get constipated toooo.
>This problem is now also yours!!
>
>As I always teach in my design classes. A good architect will design a
>system so that everybody else is to BLAME and you never get awaken at 3AM
>for stupid reasons that could have been avoided by blaming someone
>else!!!!!
>
>
> bobbee
>
>
>
>
>
>
> >From: "Stephan C. Moen" <[EMAIL PROTECTED]>
> >Reply-To: MQSeries List <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Maximum size of defined message
> >Date: Wed, 19 Feb 2003 09:27:25 -0600
> >
> >
> >Why don t we declare the maximum size message for our queue managers,
> >queues, and channels when we FIRST create these objects. From some very
> >preliminary tests conducted on AIX boxes, it appears that size doesn t
> >matter for MQSeries. Testing different size messages with the three
> >mentioned MQ objects, the svmon P <PID> utility showed little variation
>in
> >memory consumption between using the default 4MB message size or a 100MB
> >message except when it was actually being transmitted.
> >
> >Basically the question I m asking is that you might as well define ALL
>your
> >MQSeries objects with the maximum message size and eliminate all the
> >runtime
> >errors associated with message too large for the MQ object it is
>targeted
> >for. It doesn t appear that memory is preallocated for these resources
> >UNTIL
> >it is needed. Looking for some brisk discussion on this. Not looking
for
> >your thoughts, just facts that can either prove or disprove the
statement
> >made above. Thanks.
> >
> >Stephan C. Moen
> >
> >
>
>
>_________________________________________________________________
>Help STOP SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>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
>
>_________________________________________________________________
>For your protection, this e-mail has been scanned for known
>viruses and damaging content by http://GATEWAYDEFENDER.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
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
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
_________________________________________________________________
For your protection, this e-mail has been scanned for known
viruses and damaging content by http://GATEWAYDEFENDER.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
