The
simple answer Linda is there is no overhead or resource waste to set a queue
to its architectural limit for a message size. This also has been validated multiple
times by our esteemed friends who have supported this product since its
inception – IBMs MQSeries Support Team.
Stephan
C. Moen
-----Original
Message-----
From: MQSeries
List [mailto:[EMAIL PROTECTED]On
Behalf Of Kinnard.Linda
Sent: Thursday, February 20, 2003 12:52
PM
To:
[EMAIL PROTECTED]
Subject: Re: Maximum size of defined
message
I think another ways
to ask is "is there overhead or resource waste to set queue to it's maximum
architectural limit?"
-----Original
Message-----
From: Stephan C. Moen
[SMTP:[EMAIL PROTECTED]
Sent: Thursday, February
20, 2003 07:02 AM
To: [EMAIL PROTECTED]
Subject: Re: Maximum size of
defined message
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
For
your protection, this e-mail has been scanned for known
viruses and other
damaging content by GatewayDefender.com
