Re: Asynchronous publisher events

Glenn McClements <g.mcclements@...>

Hi Tom, Sam,
Before you responded I was considering the use of an inbox as a solution
to Sam’s query but I wasn’t overly keen on it. The reason being that being
rejected by the broker felt very much like a middleware level event, not
an application or market data event so it feels better to me that the
error comes from the middleware as a callback.

Also, responding with a MamaMsg to the sender means assuming the
connection is up and alive, whereas a middleware ACL policy might actually
prevent this from happening. It could be that you form the message on the
client side in the bridge, but this itself feels incorrect as it’s
translating from a middleware level even into a data message. (Also a
minor point is that the MAMA_MSG_TYPE_SEC_STATUS relates to security
status events on a exchange). This is not to say that a message response
is incorrect for RMDS posts however, it’s just a different type of event.

For Sam’s point I do prefer the idea of currently returning a
MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and the transport is currently the
best/only place to do this.

Going forward we could add callbacks to the MamaPublisher object to inform
the client asynchronously of events like this, and
MAMA_TRANSPORT_TOPIC_PUBLISH_DENIED seems reasonable though we would need
to consider how this would be used/interact with the higher level concept
of market data entitlements.

Another related concept is guaranteed or acknowledged messaging, which
would generate other asynchronous event on a publishers. Like the original
issue, this *could* be done at a high level with MamaMsgs being passed
back to acknowledge delivery, but generally this is implemented at the
middleware level so again a publisher callback would be better (with a
handle to the original message as well for context).


On 07/11/2014 14:20, "Tom Doust" <tom.doust@...> wrote:


In the Tick42 RMDS bridge we address this problem by allowing
applications to use the sendFromInbox methods on a publisher and where
applicable converting the an asynchronous response from the RMDS into a
mama message which is delivered to the inbox.

Although this is intended to support the RMDS message "post" publishing
model that will ACK (or NAK) every message I think it will work for any
middleware that has an asynchronous response mechanism; other publishing
models on RMDS do not have a message reponse.

The message sent to the inbox is arbitrary but it would make sense if
other bridges that used this technique used the same message structure.

The message we use is formed as follows

mamaMsg_addI32(msg, "MdMsgType", 1, MAMA_MSG_TYPE_SEC_STATUS);

mamaMsgStatus status = MAMA_MSG_STATUS_OK;
if(nakCode != RSSL_NAKC_NONE)
status = RsslNakCode2MamaMsgStatus(nakCode);

mamaMsg_addI32(msg, "MdMsgStatus", 2, status);
mamaMsg_addString(msg, "wSymbol",470, symbol_.c_str());

As you can see we just convert an rssl NAK code to an equivalent mama
code, or use an OK status in the case of an ACK. These include states
a number of others. Obviously the set of code and the mappings are
platform specific

The one thing I think is missing here is a field containing a text string
which could carry more information relevant to the client application.

We would propose that everyone addressing the issue of processing
asynchronous publishing responses takes this approach and that as a
community we agree on a convention for the message content.

Best Regards

Tom Doust

-----Original Message-----
From: openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...] On Behalf Of Sam Wilson
Sent: 06 November 2014 7:45 PM
To: openmama-dev@...
Subject: [Openmama-dev] Asynchronous publisher events

Hey all,

We're looking for a way to notify a mama application asynchronously of
errors while publishing, specifically when the published message was
rejected by the message broker's ACL.

Our API assumes the messages were accepted, and returns immediately.
After some time you might get a connection-level event callback informing
the application that its messages were rejected.

I have two questions.

First off, what is the best way to represent this situation in 2.3.1?
We've been tossing around the idea of just tearing down the connection,
giving the application a MAMA_TRANSPORT_DISCONNECT or a
MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and logging the error. Since the
application or the environment is incorrectly configured, there's not
much that can be done by the application anyways.

Secondly, if openmama were to be extended in the future to support these
kind of events, what would such extensions look like? Perhaps adding a

Openmama-dev mailing list
Openmama-dev mailing list

Join to automatically receive all group messages.