Re: Handling REFRESH messages in DQ publisher manager


Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

BTW, I noticed the following description for MAMA_MSG_TYPE_NULL in mamaMsgType. I did not see this message type having special logic associated with it in OpenMAMA MAMC/MAMACPP.

From msgtype.h:

/** Keep alive message. */
MAMA_MSG_TYPE_NULL = 175,

Is this message type suitable for this case?

--Alireza

-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-
dev-bounces@lists.openmama.org] On Behalf Of Yury Batrakov
Sent: Tuesday, April 14, 2015 11:03 AM
To: Glenn McClements; Ian Bell; openmama-dev@lists.openmama.org
Subject: Re: [Openmama-dev] Handling REFRESH messages in DQ publisher
manager

Classification: Public

Thanks Glenn,

BTW what is best practice of implementing custom messages? I mean what is
to return for mamaMsg_get(MdMsgType, 1), any integer which is not in
standard list of update types?


-----Original Message-----
From: Glenn McClements [mailto:g.mcclements@srtechlabs.com]
Sent: Tuesday, April 14, 2015 4:53 PM
To: Ian Bell; Yury Batrakov; openmama-dev@lists.openmama.org
Subject: Re: [Openmama-dev] Handling REFRESH messages in DQ publisher
manager

Thanks Ian, you beat me to it!

First of all Yury, welcome to the list and thanks for your question.

As Ian mentions one of the issues here is that you are implementing a
middleware level mechanism using OpenMAMA messages, so the solution is
not to modify dqpublishermanager to handle the new use of REFRESHs, but
to make sure that whatever messages are used for heartbeats are never
passed up to the core OpenMAMA level.


I’d also be against adding a new HEARTBEAT OpenMAMA message type for
this use case as would imply that heartbeats would be
sent/received/processed the OpenMAMA level (which is something we may
add at some point) and *not* at the middleware level. That’s not to say you
can’t add a new specific message type for your own heartbeats, but it should
be middleware/bridge specific.

Also a minor point is that mamaDQPublisher_sendReply() to me implies
replying to an mamaInbox, and for refreshes there is (currently) no inbox to
reply to.

Thanks,
Glenn

On 14/04/2015 14:34, "Ian Bell" <ian.bell@hapsoftconsulting.co.uk> wrote:

Hi Yury

The MAMA level refreshes are generally separate from the middleware
heartbeat functionality. Specially they operate at a higher level although
they can be similar in nature.

Normal operation would be to have the transport clean up the client
context information as the clients went away using its own heartbeat
functionality and let MAMA inform the client application of subscribers using
its own refresh messages. The refresh timeout is an hour so this is generally
a lot higher than a transport heartbeat timeout.

The dqpublisher specifically does a send rather than a sendReply to reduce
the heartbeat traffic as well as to allow for transports which don't maintain
subscriber lists.

I.e. If you have 4 clients on 1 symbol each will send a refresh message once
an hour less a random period of time, however the client refresh timeout is
reset on receiving a refresh response from a publisher, so what actually
happens is that the first client to timeout sends a refresh and then the rest of
the clients reset their timeouts on the refresh response from the publisher.
So the publisher only processes a single refresh message per topic as
opposed to 1 for every client on every topic.

Thanks,
Ian Bell

Hapsoft Consulting Ltd
138 Belmont Road, Belfast, BT4 2AQ
Office: +447481866051
Web: www.hapsoftconsulting.co.uk



-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org
[mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Yury
Batrakov
Sent: 14 April 2015 13:43
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] Handling REFRESH messages in DQ publisher
manager

Classification: Public

Hi team,

I'm implementing new OpenMAMA transport bridge and have a question
about Advanced publishing. In my middleware a publisher keeps track of all
subscribers connected to it. A publisher and subscribers exchange with
heartbeat messages posted to a single topic providing a string with session id
in heartbeats' payload. When a publisher receives a heartbeat it sends a
reply with the same session ID. Once heartbeat is not received by publisher it
stops sending data and cleans up the resources allocated for a subscriber.
I tried implementing heartbeats with MAMA_SUBSC_REFRESH messages
but
the following problem occurs: in dqpublishermanager.c there is a
handler for REFRESHES

switch (msgType)
{
case MAMA_SUBSC_REFRESH:
if (!impl->mRefreshResponseMsg)
{
*Here MAMA creates empty reply message*
mamaMsg_create(&impl->mRefreshResponseMsg);
mamaMsg_addU8(impl->mRefreshResponseMsg, NULL,
MamaFieldMsgStatus.mFid, MAMA_MSG_STATUS_MISC);
mamaMsg_addU8(impl->mRefreshResponseMsg, NULL,
MamaFieldMsgType.mFid,
MAMA_MSG_TYPE_REFRESH);

}
*And sends it via the bridge*
mamaDQPublisher_send(info->pub, impl-
mRefreshResponseMsg);
impl-
mUserCallbacks.onRefresh((mamaDQPublisherManager)impl,
info, subType,
msgType, msg );


The problem is that in the bridge we cannot restore the context of
communication i.e. session id as mRefreshResponseMsg doesn't have any
fields set. Thus we force users to implement a part of underlying protocol by
handling refreshes themselves.

I'd propose the following change to fix that:

- mamaDQPublisher_send(info->pub, impl->mRefreshResponseMsg);
+ mamaDQPublisher_sendReply(info->pub, msg, impl-
mRefreshResponseMsg);

Or could you advise how to workaround it?

Thanks,
Yury.


---
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for
additional EU corporate and regulatory disclosures and to
http://www.db.com/unitedkingdom/content/privacy.htm for information
about privacy.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev
_______________________________________________
Openmama-dev mailing list
Openmama-dev@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev

---
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for
additional EU corporate and regulatory disclosures and to
http://www.db.com/unitedkingdom/content/privacy.htm for information
about privacy.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev

Join Openmama-dev@lists.openmama.org to automatically receive all group messages.