Take the suit off, too many bulls eyes and not enough amunition!!!! :-)
From: "Wyatt, T Rob" <[EMAIL PROTECTED]>
Reply-To: MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT>
To: MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: QM or MQ Client Argument
Date: Fri, 29 Jul 2005 09:21:42 -0400
Hi Michelle,
We may be a bit conservative in that we prefer full QMgrs with local
bindings here for several reasons as follows:
With local bindings you get trusted authentication at the OS and
authorization with the OAM. With SVRCONN channels you cannot trust the
authentication unless you use SSL and take precautions to secure the
certificate stores on the client hosts. In addition, SVRCONN channels do
not provide authorization unless you use an MCAUSER value or an exit such
as BlockIP2 which will filter out privileged IDs like mqm or blanks. By
default a SVRCONN channel opens up full admin privileges to the whole
world.
With a SVRCONN channel the MCA puts the full MQ API under control of the
remote program which may or may not be well-behaved. With server-to-server
channels the MCA is IBM's code. In the most mild case you can get clients
who do not use FAIL_IF_QUIESCING and prevent a clean shutdown of your QMgr.
In the worst case you can get clients who bring your QMgr to it's knees.
We had a vendor-written client with a reconnect loop that had no sleep.
Everything was fine for a while then one day it hiccupped and get into the
reconnect loop. Tried to reconnect about 1000 times per second. Filled
the listener backlog, prevented all attempts to connect to the QMgr by
other channels (including our administrative tools) failed. Since we were
using inetd, we could not keep the amqcrsta processes down long enough to
restart the QMgr. Nowadays if we let clients connect at all, it is to a
client concentrator QMgr and not our major application QMgrs.
When using clients if you get a 2009 Connection Broken response you do not
know if the connection was broken before or after it reached the agent at
the QMgr. If you did a GET or PUT outside of syncpoint and get a 2009 you
may - or may not - have completed the call on the QMgr. So let's assume
you are doing everything under syncpoint and get a 2009 on the COMMIT. If
you had removed messages from the queue and the COMMIT never made it to the
agent, you will get them back again. Hopefully you coded to recognize them
as dupes. In the case of a PUT, you really do not know if the PUT was
successful. You can get around this with code by placing a message into a
sync queue outside of syncpoint. Then you GET the same message under
syncpoint and do any other GETs or PUTs for your transaction. If you get a
2009 on the COMMIT you can check the sync queue to see if the token message
is there or not. Of course it may sit under syncpoint for several minutes
before being rolled back when the channel agent times out.
In general, we have found that having a full QMgr is less costly than
making the client robust enough for our application requirements. I
believe this is in fact the basis for IBM charging as much for the
transactional client as a full QMgr. The exceptions in our shop are things
like inquiry transactions or applications which have the capability to
resynch themselves automatically and do not store state in the messages.
Hope that helps,
-- T.Rob (I'm donning my asbestos suit in anticipation of a firestorm
now!)
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf
Of Michelle Russell
Sent: Friday, July 29, 2005 2:40 AM
To: MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT
Subject: QM or MQ Client Argument
Time and time again I get involved in new projects that want to utilise MQ.
I have to work out the initial design of how the new project will use MQ.
The dilemma we have is do we use an MQSeries Client or opt for a full blown
Websphere MQ Manager. Can somebody point me in the direction of any
material that will give me an overview of the 'for's' and 'against' for
each.
Regards
Michelle
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
