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
