Date   

Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] PLAT-318: No BOOK RECAP during FT takeover when dqstrategy=ignoredups
	mama/c_cpp/src/c/dqstrategy.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #81
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[dfedorov.solace] Wildcard subscription OnMsg callback is called with NULL instead of
	mama/c_cpp/src/c/subscription.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #80
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Re: subscription is using destroyed publisher

Frank Quinn <f.quinn@...>
 

Hi Dmitri,

 

Did you folks get everything that you needed from Gitter around this one or is this a different issue?

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: Friday, June 10, 2016 7:30 PM
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] subscription is using destroyed publisher

 

Hello gents, could you please confirm that the following looks like a MAMA layer issue, or maybe our bridge is not acting properly?

The issue: there is a subscription in process of activation or deactivation on one thread, and in that process it is trying to use a publisher that is in process of being destroyed or was already destoroyed in a different threat.

We would expect this publisher not being used (as it clearly has a state different from LIVE).

What do you think?

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.


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


Re: Gitter vs IRC

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

All links on the openmama website have now been updated to point to Gitter rather than IRC (and a few pages have been cleaned up during the review). If anyone spots any stale references to IRC, please let me know.

 

I am pleased to say it really has grown to be quite lively - we already have more active participants than we ever had on IRC so I think it was the right move.

 

We also just updated wiki.openmama.org to point to the github wiki rather than the old mediawiki installation to avoid duplication and forking of our development documentation.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: Monday, June 13, 2016 9:26 AM
To: openmama-dev <openmama-dev@...>; openmama-users@...
Subject: Re: [Openmama-dev] Gitter vs IRC

 

Hi folks,

As we have heard no objections, we'll be going ahead with the move to gitter. It is ready to go right now and you'll find the usual IRC folks in Gitter. Meanwhile we'll work on updating all documentation etc to point to gitter rather than freenode.

Cheers,

Frank

 

On Tue, May 31, 2016 at 9:05 PM, Frank Quinn <fquinn.ni@...> wrote:

Hi folks,

We're currently looking at gitter as a potential IRC compatible replacement and my personal opinion is that we should go with it.

 

You can already mess about in the proposed channel; you can read anonymously, or use a github or twitter account to contribute: 

 

https://gitter.im/OpenMAMA/OpenMAMA

It has several great features:

1. Instant messages are persisted to the room, so you will see history when you log in
2. Sensible concurrent login access with no username1 nonsense
3. Web front end comes for free
4. Provided by github so integrates very nicely into the project wiki etc
5. Native client provided for Mac, windows, Linux, iPhone and android
6. Also compatible with standard IRC clients

Downsides:

1. It increases the github lock-in
2. You'll need a github or twitter account to contribute

If anyone has any feedback about making the move, please speak up now. I'm sending this to both users and developers because it will impact both and I'll welcome and consider all responses. I'd hope that we can agree a decision one way or another by 7th June, then (if necessary) take the plunge.

Cheers,
Frank

 


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


Re: OpenMAMA-2.4.1 (hotfix release for deferred entitlements)

Frank Quinn <f.quinn@...>
 

Hi Folks,


I can confirm that 2.4.1 is now available – see:

 

https://github.com/OpenMAMA/OpenMAMA/releases

 

Cheers,

Frank

 

From: Frank Quinn
Sent: Monday, June 13, 2016 1:23 PM
To: openmama-dev <openmama-dev@...>; 'openmama-users@...' <openmama-users@...>
Subject: OpenMAMA-2.4.1 (hotfix release for deferred entitlements)

 

Hi Folks,

 

We will be cutting a release shortly which is a hot fix release to include following change:

 

https://github.com/OpenMAMA/OpenMAMA/commit/daf1478b6ecc25b0dd453a56a826bc9b95dc7b18

 

Note that if you have fallen victim to this issue, you will not be able to subscribe to anything, so if you can subscribe to data sources and receive data today, you don’t need to upgrade.

 

Only users of middleware bridges which use deferred entitlements will require this change (i.e. Qpid, Avis, ZeroMQ and SR Labs bridges are unaffected).

 

I am aiming to get binaries available within the next day or two. Alternatively if you build your own, you can go ahead and build off the OpenMAMA-2.4.1 release branch.

 

Cheers,

Frank


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


Code change just landed on origin/master (Successful)

jenkins@...
 

Some changes have just been added to the origin/master branch!

[Matt Mulhern] CLANG Compilation issues
	mama/c_cpp/src/c/mamainternal.h
	mama/c_cpp/src/c/mama/entitlement.h

[Matt Mulhern] SCONS: Darwin build flag changed
	site_scons/community/darwin.py

[Matt Mulhern] MAMAC: Windows build scons fix for entitlements.
	mama/c_cpp/src/c/SConscript.win

[Matt Mulhern] Issue #151 - Adding call to mama_shutdownPlugins() in mama_close
	mama/c_cpp/src/c/mama.c

[Matt Mulhern] Adding CONTRIBUTING.md ISSUE_TEMPLATE.md and PULL_REQUEST_TEMPLATE.md
	.github/ISSUE_TEMPLATE.md
	.github/CONTRIBUTING.md
	.github/PULL_REQUEST_TEMPLATE.md

[Matt Mulhern] Issue #147: removing arg config and old README files.
	.arcconfig
	README

[Frank Quinn] TESTTOOLS: Capture replay bug fix for playbacks with multiple
	mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c

[Matt Mulhern] ENTITLEMENTS: General tidy up of entitlements checking from issues
	mama/c_cpp/src/c/subscription.c
	mama/c_cpp/src/c/listenermsgcallback.c

[Matt Mulhern] Moving declaration to top of scope for wiindows build compatability.
	mama/c_cpp/src/c/listenermsgcallback.c

[Matt Mulhern] ---------------------------------------------------------- COMMONC:
	common/c_cpp/src/c/windows/port.c

[Frank Quinn] RPM: Fixed rpm script to support new README file name
	release_scripts/openmama.spec
	release_scripts/openmama-rpm.sh

[Matt Mulhern] CAPTUREREPLAY: Gracefully shutting down if unable to create transport.
	mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c

[Frank Quinn] ENT: Fixed bug with OEA bridge and market data sub
	mama/c_cpp/src/c/mama.c
	mama/c_cpp/src/c/entitlement/noop/noop.h
	mama/c_cpp/src/c/entitlement/oea/oea.c
	mama/c_cpp/src/c/subscription.c
	mama/c_cpp/src/c/entitlement/oea/oea.h
	mama/c_cpp/src/c/mamainternal.h
	mama/c_cpp/src/c/entitlement/noop/noop.c

[Frank Quinn] MAMACPP: Prevention of double destroy callback in CPP application
	mama/c_cpp/src/cpp/MamaSubscription.cpp

[Frank Quinn] QPID: Added implementation for publisher callbacks in qpid bridge
	mama/c_cpp/src/gunittest/c/publishertest.cpp
	mama/c_cpp/src/c/bridge/qpid/qpidbridgefunctions.h
	mama/c_cpp/src/gunittest/cpp/MamaPublisherTest.cpp
	mama/c_cpp/src/c/bridge/qpid/publisher.c

[Frank Quinn] UNITTEST: Fixed valgrind issues with publisher unit tests
	mama/c_cpp/src/c/bridge/qpid/publisher.c
	mama/c_cpp/src/gunittest/cpp/MamaPublisherTest.cpp

[Frank Quinn] QPID: Fixed crash on NULL parameter passed to destroy
	mama/c_cpp/src/c/bridge/qpid/publisher.c

[Matt Mulhern] QPID: Correction order of deletion in
	mama/c_cpp/src/c/bridge/qpid/publisher.c

[Frank Quinn] MAMA: Delete subsctype.c
	mama/c_cpp/src/c/subsctype.c

[Frank Quinn] Solace fix for deferred entitlements MAMA_STATUS_NO_BRIDGE_IMPL error
	mama/c_cpp/src/c/subscription.c

[Frank Quinn] VERSION: Updating version files to 2.4.1
	mama/VERSION.scons
	mama/c_cpp/configure.ac
	mama/jni/build.xml
	mama/c_cpp/src/c/generateMamaSourceFiles.bat
	mamda/VERSION.scons
	mamda/c_cpp/configure.ac
	mamda/c_cpp/src/cpp/generateMamdaVersion.bat
	mamda/java/build.xml


Results for OpenMAMA Master Branch (Qpid Proton) CI run with latest changes:

  • CI Project Name: OpenMAMA Master Branch (Qpid Proton)
  • Build Number: #13
  • Build Status: Successful
  • Total Amount of Tests: 1766
  • Passed: 1766
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


OpenMAMA-2.4.1 (hotfix release for deferred entitlements)

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

We will be cutting a release shortly which is a hot fix release to include following change:

 

https://github.com/OpenMAMA/OpenMAMA/commit/daf1478b6ecc25b0dd453a56a826bc9b95dc7b18

 

Note that if you have fallen victim to this issue, you will not be able to subscribe to anything, so if you can subscribe to data sources and receive data today, you don’t need to upgrade.

 

Only users of middleware bridges which use deferred entitlements will require this change (i.e. Qpid, Avis, ZeroMQ and SR Labs bridges are unaffected).

 

I am aiming to get binaries available within the next day or two. Alternatively if you build your own, you can go ahead and build off the OpenMAMA-2.4.1 release branch.

 

Cheers,

Frank


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


Re: Gitter vs IRC

Frank Quinn <fquinn.ni@...>
 

Hi folks,

As we have heard no objections, we'll be going ahead with the move to gitter. It is ready to go right now and you'll find the usual IRC folks in Gitter. Meanwhile we'll work on updating all documentation etc to point to gitter rather than freenode.

Cheers,
Frank

On Tue, May 31, 2016 at 9:05 PM, Frank Quinn <fquinn.ni@...> wrote:
Hi folks,

We're currently looking at gitter as a potential IRC compatible replacement and my personal opinion is that we should go with it.

You can already mess about in the proposed channel; you can read anonymously, or use a github or twitter account to contribute: 

https://gitter.im/OpenMAMA/OpenMAMA

It has several great features:

1. Instant messages are persisted to the room, so you will see history when you log in
2. Sensible concurrent login access with no username1 nonsense
3. Web front end comes for free
4. Provided by github so integrates very nicely into the project wiki etc
5. Native client provided for Mac, windows, Linux, iPhone and android
6. Also compatible with standard IRC clients

Downsides:

1. It increases the github lock-in
2. You'll need a github or twitter account to contribute

If anyone has any feedback about making the move, please speak up now. I'm sending this to both users and developers because it will impact both and I'll welcome and consider all responses. I'd hope that we can agree a decision one way or another by 7th June, then (if necessary) take the plunge.

Cheers,
Frank


subscription is using destroyed publisher

Dmitri Fedorov <dfedorov.solace@...>
 

Hello gents, could you please confirm that the following looks like a MAMA layer issue, or maybe our bridge is not acting properly?
The issue: there is a subscription in process of activation or deactivation on one thread, and in that process it is trying to use a publisher that is in process of being destroyed or was already destoroyed in a different threat.
We would expect this publisher not being used (as it clearly has a state different from LIVE).
What do you think?
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.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] PLAT-620: loading entitlements Libraries before payloads. (#185)
	mama/c_cpp/src/c/mama.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #79
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] MAMACPP: Keeping track of CPP wrappers to default queue (#174)
	mama/c_cpp/src/cpp/MamaQueue.cpp
	mama/c_cpp/src/cpp/mama/mamacpp.h
	mama/c_cpp/src/cpp/mamacpp.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #78
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] COMMON: Added support for format strings when evaluating properties
	common/c_cpp/src/c/property.h
	common/c_cpp/src/c/property.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #77
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


Mama subscription state machine issue for subscription type basic and state ACTIVATING

cmorgan
 

Hi,

 

I’m currently having an issue when creating a basic type mamaSubscription. I’m trying to create the subscription with a wildcard to cause the bridge to return an invalid argument status and afterwards the state of the subscription is activating. Since the state is activating not activated I cannot deactivate, destroy, recreate(create again) or deallocate.  As a result I leak the memory associated with the subscription. The openmama C dev guide does not show a transition for the subscription state machine for the ACTIVATING state for basic subscriptions according to figure 1 page 32, from http://www.openmama.org/sites/default/files/OpenMAMA%20Developer's%20Guide%20C.pdf. What should be the expected behaviour for this error path?

 

Chris Morgan


Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch!

[fquinn.ni] Feature mamamsg vector price datetime (#163)
	mama/c_cpp/src/c/payload/qpidmsg/qpidpayloadfunctions.h
	mama/c_cpp/src/c/registerfunctions.c
	mama/c_cpp/src/gunittest/c/payload/payloadvectortests.cpp
	mama/c_cpp/src/c/payloadbridge.h
	mama/c_cpp/src/c/msg.c
	mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp
	mama/c_cpp/src/c/mama/msg.h
	mama/c_cpp/src/gunittest/c/mamamsg/msgvectortests.cpp
	mama/c_cpp/src/c/payload/qpidmsg/payload.c
	mama/c_cpp/src/c/payload/qpidmsg/field.c
	mama/c_cpp/src/c/payload/qpidmsg/qpidcommon.h


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #76
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


advisory cause and platform info

Dmitri Fedorov <dfedorov.solace@...>
 

Hi,

What is an intended purpose of the advisory cause and platform info mechanizm in transport and subscription, please?

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.


Re: fields MdSubscMsgType and MdMsgType in message

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


Re: fields MdSubscMsgType and MdMsgType in message

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


Re: fields MdSubscMsgType and MdMsgType in message

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


Re: fields MdSubscMsgType and MdMsgType in message

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




Re: Code change(s) just landed on origin/next (Successful)

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

Please ignore these no changes notifications– this was just testing Jenkins integration with gitter (which is now working).

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of jenkins@...
Sent: Wednesday, June 1, 2016 12:03 PM
To: openmama-dev@...
Subject: [Openmama-dev] Code change(s) just landed on origin/next (Successful)

 

Some changes have just been added to the origin/next branch!

 
No changes
 

Results for OpenMAMA Next Branch (Qpid Proton) CI run with latest changes:

 

  • CI Project Name: OpenMAMA Next Branch (Qpid Proton)
  • Build Number: #64
  • Build Status: Successful
  • Total Amount of Tests: 1767
  • Passed: 1767
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.


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

541 - 560 of 2311