fields MdSubscMsgType and MdMsgType in message


Dmitri Fedorov <dfedorov.solace@...>
 

Hi,

When a message has this field:
 MdSubscMsgType:61

and also it has this field:
 MdMsgType:1

am I right to assume that MdMsgType is the real message type?

In other words, does MdMsgType take precedence over MdSubscMsgType?

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

Thank you.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


Frank Quinn <fquinn.ni@...>
 

Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,
Frank

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi,

When a message has this field:
 MdSubscMsgType:61

and also it has this field:
 MdMsgType:1

am I right to assume that MdMsgType is the real message type?

In other words, does MdMsgType take precedence over MdSubscMsgType?

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

Thank you.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev



Dmitri Fedorov <dfedorov.solace@...>
 

Hi Frank,

I see these messages in a dictionary publish case, when MdSubscMsgType is a dictionary entry (yes, I know it's a reserved word and shouldn't be used, this was not my idea to use it).

I can easily identify this message by its type (50), but I want to filter out other cases when this is NOT a subscription request message, but can legitimately have this MdSubscMsgType field.

BTW, what do you think is the best way to identify a subscription request (or non-subscription request message, if it's easier)? By presence of both fields MamaFieldSubscriptionType and MamaFieldSubscSymbol?

Thank you
Dmitri

On 1 June 2016 at 03:29, Frank Quinn <fquinn.ni@...> wrote:
Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,
Frank

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi,

When a message has this field:
 MdSubscMsgType:61

and also it has this field:
 MdMsgType:1

am I right to assume that MdMsgType is the real message type?

In other words, does MdMsgType take precedence over MdSubscMsgType?

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

Thank you.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev




Frank Quinn <f.quinn@...>
 

Again, where are you seeing this message?

 

It sounds like your data source is publishing things that it shouldn’t. I can think of no good reason to publish MdSubscMsgType for anything other than a request of some kind. If you’re caching it, you shouldn’t because it will end up being specific to a single subscriber anyway.

 

The topic is also a big clue – subscription request come in on _MD.*

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Wednesday, June 1, 2016 2:28 PM
To: Frank Quinn <fquinn.ni@...>
Cc: openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] fields MdSubscMsgType and MdMsgType in message

 

Hi Frank,

 

I see these messages in a dictionary publish case, when MdSubscMsgType is a dictionary entry (yes, I know it's a reserved word and shouldn't be used, this was not my idea to use it).

 

I can easily identify this message by its type (50), but I want to filter out other cases when this is NOT a subscription request message, but can legitimately have this MdSubscMsgType field.

 

BTW, what do you think is the best way to identify a subscription request (or non-subscription request message, if it's easier)? By presence of both fields MamaFieldSubscriptionType and MamaFieldSubscSymbol?

 

Thank you

Dmitri

 

On 1 June 2016 at 03:29, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,

Frank

 

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:

Hi,

 

When a message has this field:

 MdSubscMsgType:61

 

and also it has this field:

 MdMsgType:1

 

am I right to assume that MdMsgType is the real message type?

 

In other words, does MdMsgType take precedence over MdSubscMsgType?

 

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

 

Thank you.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

 

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Dmitri Fedorov <dfedorov.solace@...>
 

The messages I'm talking about are published on _MDDD.<bridge>.DATA_DICT

So if a message 1) is coming on _MD.* and 2) its MamaFieldSubscMsgType is MAMA_SUBSC_* that is a subscription request, right?

Cheers,
Dmitri

On 1 June 2016 at 10:31, Frank Quinn <f.quinn@...> wrote:

Again, where are you seeing this message?

 

It sounds like your data source is publishing things that it shouldn’t. I can think of no good reason to publish MdSubscMsgType for anything other than a request of some kind. If you’re caching it, you shouldn’t because it will end up being specific to a single subscriber anyway.

 

The topic is also a big clue – subscription request come in on _MD.*

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Wednesday, June 1, 2016 2:28 PM
To: Frank Quinn <fquinn.ni@...>
Cc: openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] fields MdSubscMsgType and MdMsgType in message

 

Hi Frank,

 

I see these messages in a dictionary publish case, when MdSubscMsgType is a dictionary entry (yes, I know it's a reserved word and shouldn't be used, this was not my idea to use it).

 

I can easily identify this message by its type (50), but I want to filter out other cases when this is NOT a subscription request message, but can legitimately have this MdSubscMsgType field.

 

BTW, what do you think is the best way to identify a subscription request (or non-subscription request message, if it's easier)? By presence of both fields MamaFieldSubscriptionType and MamaFieldSubscSymbol?

 

Thank you

Dmitri

 

On 1 June 2016 at 03:29, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,

Frank

 

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:

Hi,

 

When a message has this field:

 MdSubscMsgType:61

 

and also it has this field:

 MdMsgType:1

 

am I right to assume that MdMsgType is the real message type?

 

In other words, does MdMsgType take precedence over MdSubscMsgType?

 

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

 

Thank you.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

 

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Frank Quinn <fquinn.ni@...>
 

Well it might be depending on the value of the subsc type. See the dqpublisher code for more details.

On Wed, 1 Jun 2016, 18:41 Dmitri Fedorov, <dfedorov.solace@...> wrote:
The messages I'm talking about are published on _MDDD.<bridge>.DATA_DICT

So if a message 1) is coming on _MD.* and 2) its MamaFieldSubscMsgType is MAMA_SUBSC_* that is a subscription request, right?

Cheers,
Dmitri

On 1 June 2016 at 10:31, Frank Quinn <f.quinn@...> wrote:

Again, where are you seeing this message?

 

It sounds like your data source is publishing things that it shouldn’t. I can think of no good reason to publish MdSubscMsgType for anything other than a request of some kind. If you’re caching it, you shouldn’t because it will end up being specific to a single subscriber anyway.

 

The topic is also a big clue – subscription request come in on _MD.*

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Wednesday, June 1, 2016 2:28 PM
To: Frank Quinn <fquinn.ni@...>
Cc: openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] fields MdSubscMsgType and MdMsgType in message

 

Hi Frank,

 

I see these messages in a dictionary publish case, when MdSubscMsgType is a dictionary entry (yes, I know it's a reserved word and shouldn't be used, this was not my idea to use it).

 

I can easily identify this message by its type (50), but I want to filter out other cases when this is NOT a subscription request message, but can legitimately have this MdSubscMsgType field.

 

BTW, what do you think is the best way to identify a subscription request (or non-subscription request message, if it's easier)? By presence of both fields MamaFieldSubscriptionType and MamaFieldSubscSymbol?

 

Thank you

Dmitri

 

On 1 June 2016 at 03:29, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,

Where are you seeing this message? This will be driven by the data source, but MdSubscMsgType is typically only included in subscription request messages (as suggested in the comment in subscmsgtype.h). I wouldn't expect it to provide any relevant information when sent in an update (in fact it probably shouldn't be included in updates).

Cheers,

Frank

 

On Tue, May 31, 2016 at 10:27 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:

Hi,

 

When a message has this field:

 MdSubscMsgType:61

 

and also it has this field:

 MdMsgType:1

 

am I right to assume that MdMsgType is the real message type?

 

In other words, does MdMsgType take precedence over MdSubscMsgType?

 

Do we have a legal/illegal combinations of MdMsgType and MdSubscMsgType?

 

Thank you.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

 

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC