Re: Asynchronous publisher events

Tom Doust

Hi Glenn

In many cases publishing a message is transactional and can succeed or fail. Failure does not mean that the connection (for the transport or the item is at fault) in which case connection level call-backs are not the appropriate way to signal a transaction failure.

Even with the ACL failure condition described by Sam could recover without a reconnect from the client if the Solace server supports dynamic changes to the ACL.

On RMDS/TREP a common cause for receiving a NAK is that the user is not permissioned to publish this particular symbol on this source. The may be entitled on other symbols

I'm inclined to agree with you about the use of callbacks over messages but in practical terms the "send-from-inbox / reply-to-inbox" mechanism is in place and is consistently available in the c/cpp, java and .net apis; that’s not true of call-backs. It's also true that messages are generally easier to manage in an asynchronous, multi-threaded environment.

Best regards


-----Original Message-----
From: Glenn McClements [mailto:g.mcclements@...]
Sent: 07 November 2014 3:57 PM
To: Tom Doust; Sam Wilson; openmama-dev@...
Subject: Re: [Openmama-dev] Asynchronous publisher events

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
amongst 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
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
mamaTransportTopicEvent enumeration?

Openmama-dev mailing list
Openmama-dev mailing list

Join to automatically receive all group messages.