X-Report-Abuse-To: spam-RAvZ+8ubYLwZD488Lvc0IA6ISnHq+hSGQ0cMyQF+***@public.gmane.org
X-Filter-Fingerprint: IFrWXGses7OKB5S5G8/dJdF8bCbRCAhGucQF+2hmonpA3cTUQ1R++keuE7RDJ8Kg3RbMLUalw1oC
mj99/u+Poh38tEMU4IgC4sNz49qn3HHnhRv/ZJ3kEy8bfiAr+Fb/UpndEJ0YoaLytXXo8BMTaX2p
Mk7LBarWD9Fj4R3eIu5amSKkALoA6KDzkQ8jq89Qglr+eUaqsXi6ilYykBRNmy1w3rhXI7ypWHcC
zReLskSoC1jzfYuYzO5TaopJL1l0EkXKTCB9mgAH2nNvM1GFDcH5C2MO7hTENZJE35bUvwAX-Originating-IP: 184.154.225.7
X-SpamExperts-Domain: siteground247.com
X-SpamExperts-Username: 184.154.225.7
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.04)
X-Recommended-Action: accept
X-PMX-Version: 6.1.0.2415318, Antispam-Engine: 2.7.2.2107409,
Antispam-Data: 2014.9.11.215120
X-PMX-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' AT_TLD 0.1,
FROM_NAME_ONE_WORD 0.05, HTML_00_01 0.05, HTML_00_10 0.05,
BODY_ENDS_IN_URL 0, BODY_SIZE_5000_5999 0, BODY_SIZE_7000_LESS 0,
DATE_TZ_NA 0, FORGED_MUA_OUTLOOK 0, WEBMAIL_SOURCE 0,
WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0,
__BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0,
__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0,
__HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IN_REP_TO 0,
__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __OUTLOOK_MUA 0,
__OUTLOOK_MUA_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0,
__TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NS ,
__USER_AGENT_MS_GENERIC 0'
Sender: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
Comments: To: Frank Swarbrick <frank.swarbrick-/***@public.gmane.org>
In-Reply-To: <1410460060.67228.YahooMailNeo-+Evgq5RrxhYeBhY5O9xny5EhsgyP+***@public.gmane.org>
Precedence: list
List-Help: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>,
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?body=INFO%20MQSERIES>
List-Unsubscribe: <mailto:MQSERIES-unsubscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Subscribe: <mailto:MQSERIES-subscribe-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Owner: <mailto:MQSERIES-request-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
List-Archive: <http://listserv.meduniwien.ac.at/cgi-bin/wa?LIST=MQSERIES>
Archived-At: <http://permalink.gmane.org/gmane.network.mq.devel/18155>
Post by Frank SwarbrickMy first post to this list, so please be gentle!
You've obviously mistaken us for MQSeries.net where the mood is a little
more...let's say raucous.
Post by Frank SwarbrickAnd is there no real way to say "don't bother to
write to the queue because no one is there to read it"?
The whole point of async messaging was to decouple writer and reader of
messages. In other words, the ability to write messages when there was
nothing on the other end to read them was one of the primary design goals.
So, no, there is no instrumentation for that. Even for the things for which
we do have instrumentation the standard advice is to keep the business app
and the network monitoring/management apps separated like church and state.
So there is a whole category of questions for which the answer is DON'T DO
THAT! These include...
* How does my program tell if the channel is running before writing a
message?
* How does my program tell if the queue at the other end is full?
* How does my program tell if the other QMgr is running?
The answer to all these things is "it doesn't!" You may have monitoring
that looks for depth in the XMit or app input queues, or looks for input
handles on app in put queues, or any number of other indicators, just don't
make the business logic do those things.
Post by Frank SwarbrickMy question is, what is the best way to handle the situation where the
peer has
* Expire the messages if they are synchronous and have no useful life in a
short time.
* Consider the different reporting messages such as COA, COD or reports on
exception.
* Make the protocol between the apps a bit chattier.
Post by Frank SwarbrickWith TCP sockets it's simple. When the peer goes away the socket
is closed. Thus you get an immediate error when attempting to write to
the socket.
Actually, the behavior depends on whether the app is reading or writing from
the socket. The sending app generally knows quickly but the receiving app
may need to wait on heartbeats or the TCP global time-out which is generally
two hours. When MQ rides over TCP/IP it is possible to use WMQ's internal
heartbeats and channel tuning to make it even more responsive on inbound
side than is the underlying TCP socket.
Post by Frank SwarbrickBut with MQ I can't see any way to determine if a peer has gone away and
is not
Post by Frank Swarbrickreading from the request queue. Is that "just the way it is"? Obviously
we need
Post by Frank Swarbricktimeout handling anyway, in case the peer is slow to respond. Is it just
this same
Post by Frank Swarbricklogic that is used in this case?
For an example of how this is done really, REALLY well, I'd suggest looking
at the MQ MFT internals. (You may need to search for the older name 'FTE'
to find the conference presentations.) MQ's Managed File Transfer is a
point-to-point connection between two agents connected through one or more
QMgrs. The agents are aware of each other's state and negotiate between
themselves on the file transfer specifications. Once started, they stream
the file between agents but are capable of throttling the transfer up or
down depending on the state of the other agent. It is the best example I've
ever seen of a synchronous app running over async messaging.
It is worth noting that when the apps are aware of each others' state then
they can use non-persistent messages, and in fact this is what MQ MFT does.
This allows for much higher performance in the messaging layer and more than
offsets the added overhead of a slightly chattier protocol.
You may have by now spotted the fulcrum between these design approaches: who
holds the state? If the applications hold the state you can do synchronous
comms over async messaging reliably, though perhaps with a slightly higher
level of difficulty. If the QMgr holds the state (i.e. you are using
persistent messages) than by definition the application should *NOT* do so
and should not know or care about the thing on the other side.
Did that help? Was I too harsh? ;-)
Kind regards,
-- T.Rob
T.Robert Wyatt, Managing partner
IoPT Consulting, LLC
+1 704-443-TROB
https://ioptconsulting.com
https://twitter.com/tdotrob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Frank Swarbrick
Sent: Thursday, September 11, 2014 14:28 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: synchronous communication and MQ
My first post to this list, so please be gentle!
We just got MQ recently, and as of yet are only using it for async message
passing. We have a requirement to use it for request/reply type comms. For
the most part it seems relatively simple. Two queues, one for placing
requests (read by the peer) and one for the peer to place its responses
(read by us).
My question is, what is the best way to handle the situation where the peer
has "gone away"? With TCP sockets it's simple. When the peer goes away the
socket is closed. Thus you get an immediate error when attempting to write
to the socket. But with MQ I can't see any way to determine if a peer has
gone away and is not reading from the request queue. Is that "just the way
it is"? Obviously we need timeout handling anyway, in case the peer is slow
to respond. Is it just this same logic that is used in this case? And is
there no real way to say "don't bother to write to the queue because no one
is there to read it"?
Thanks!
Frank Swarbrick
Mainframe Applications Architect
FirstBank - Lakewood, CO USA
________________________________________
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES