Date   

Re: Adding Blank data representation to MAMA API data types

Keith Rudd
 

 

Hi Nigel,

 

I don’t have a RIC to quote here, but the problem exists for certain data delivered over the Elektron feed, with data from contributors where we have no control over what conventions they use.

For most data sets you only ever see blank values in initial data which is not really a problem. It’s when they are used to update a previously valid field value, distinguishing between a ‘blank’ and a zero (possibly valid) becomes important. The tick42rmds (or any other) adaptor can only really deliver a zero in the MAMA field it renders from the received ‘blank’ as there is no blank representation in MAMA and this is indistinguishable from a valid zero update, even though they are semantically different.

 

Regards,

Keith

 

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 09 December 2019 17:03
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

Hi Keith – what we normally do here is use the relevant getters/setters on the Price and DateTime fields (getIsValidPrice, setIsValidPrice, HasDate, HasTime).  We tell people to render blanks for invalid prices and for DateTimes with no date or time part.  I believe the tick42rmds adaptor for TREP maps these correctly from the native TREP RWF encoding.  Do you have counter examples?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

Certain other market data platforms / APIs (well, TREP) support the concept of ‘blank’ field values.

The price and time field types actually have special blank data representations defined.

This is used in the context where a publisher wants to include a field in a message but with no assigned value, possibly for example to indicate that a price that was previously offered and valid is now no longer available.

(Granted there are other ways to do this, with another price status field etc. but we do see this method used sometimes and with no other indicator of validity)

 

This introduces a conundrum when translating such values to the MAMA API as prices, times, etc. have no such equivalent blank representation in MAMA.

 

So, my proposal is that we might extend MAMA field data types to include such ‘blank’ values.

This would need to be done while preserving backwards-compatibility.

 

A discussion point for now

-  Is this a feature which others see value in?

-  Any feasible suggestions for how it might be achieved and what values would be used for ‘blank’ ?

 

Regards,

Keith

 



---
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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.



---
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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Re: Adding Blank data representation to MAMA API data types

Phelan, Nigel
 

Hi Keith – what we normally do here is use the relevant getters/setters on the Price and DateTime fields (getIsValidPrice, setIsValidPrice, HasDate, HasTime).  We tell people to render blanks for invalid prices and for DateTimes with no date or time part.  I believe the tick42rmds adaptor for TREP maps these correctly from the native TREP RWF encoding.  Do you have counter examples?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

Certain other market data platforms / APIs (well, TREP) support the concept of ‘blank’ field values.

The price and time field types actually have special blank data representations defined.

This is used in the context where a publisher wants to include a field in a message but with no assigned value, possibly for example to indicate that a price that was previously offered and valid is now no longer available.

(Granted there are other ways to do this, with another price status field etc. but we do see this method used sometimes and with no other indicator of validity)

 

This introduces a conundrum when translating such values to the MAMA API as prices, times, etc. have no such equivalent blank representation in MAMA.

 

So, my proposal is that we might extend MAMA field data types to include such ‘blank’ values.

This would need to be done while preserving backwards-compatibility.

 

A discussion point for now

-  Is this a feature which others see value in?

-  Any feasible suggestions for how it might be achieved and what values would be used for ‘blank’ ?

 

Regards,

Keith

 



---
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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.


Adding Blank data representation to MAMA API data types

Keith Rudd
 

Certain other market data platforms / APIs (well, TREP) support the concept of 'blank' field values.
The price and time field types actually have special blank data representations defined.
This is used in the context where a publisher wants to include a field in a message but with no assigned value, possibly for example to indicate that a price that was previously offered and valid is now no longer available.
(Granted there are other ways to do this, with another price status field etc. but we do see this method used sometimes and with no other indicator of validity)

This introduces a conundrum when translating such values to the MAMA API as prices, times, etc. have no such equivalent blank representation in MAMA.

So, my proposal is that we might extend MAMA field data types to include such 'blank' values.
This would need to be done while preserving backwards-compatibility.

A discussion point for now
- Is this a feature which others see value in?
- Any feasible suggestions for how it might be achieved and what values would be used for 'blank' ?

Regards,
Keith



---
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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


OpenMAMA 6.3.0 Released

Frank Quinn
 

Hi Folks,

We are pleased to announce OpenMAMA 6.3.0 is finally here! This is a bridge interface updating release which fixes several outstanding bugs and introduces some new functionality.

  • OpenMAMA middleware "base" bridge now included to reduce the overall development required to write a new middleware bridge.
  • Builds now performed using docker environment
  • New docker image on dockerhub: https://hub.docker.com/r/openmama/openmama (see: https://github.com/OpenMAMA/OpenMAMA/tree/OpenMAMA-6.3.0/docker for documentation)
  • Several other bugs and enhancements
  • Fixes added for missing common headers on windows distribution
  • Payload_addMsg - now expects a mamaMsg rather than a msgPayload. This is to align with other payloads and support potential transcoding in the bridge
  • Payload_updateSubMsg - now expects a mamaMsg rather than a msgPayload for the same reason

For a complete list of all 24 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/10?closed=1

Cheers,

Frank

 

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: OpenMAMA-6.3.0-rc2 Now Available

Frank Quinn
 

Hi Folks,

 

Looks like we will be wrapping this up in the middle of next week – so far no major issues reported.

 

Cut off date is Wednesday next week.

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Frank Quinn
Sent: 23 September 2019 19:30
To: openmama-dev@...; openmama-users@...
Subject: OpenMAMA-6.3.0-rc2 Now Available

 

Hi Folks, RC2 now available with artefacts: https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc2

 

Let’s aim for a 2 week test window so please get testing!

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Frank Quinn
Sent: 16 September 2019 13:14
To: 'openmama-dev@...' <openmama-dev@...>; 'openmama-users@...' <openmama-users@...>
Subject: RE: OpenMAMA-6.3.0-rc1 Now Available

 

NB: Further Bridge Interface change in OpenMAMA 6.3.0

 

Hi Folks,

 

As suggested by Chris over at Solace (and with my agreement), I think this is a good time to correct one of the interface consistencies that bridge developers have needed to deal with since we're currently bumping the versions to an incompatible bridge version anyway. The changes themselves should be easy to implement, but are nevertheless important for users of sub-messages:

 

Payload_addMsg() - now expects a mamaMsg rather than a msgPayload. This is to align with other payloads and support potential transcoding in the bridge

 

Payload_updateSubMsg - now expects a mamaMsg rather than a msgPayload.

 

This will allow us to put to bed a longstanding issue as well in https://github.com/OpenMAMA/OpenMAMA/issues/297

 

I’ll get some more builds together within the next week or two, and extend the aspirational release date to 18th October 2019.

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Frank Quinn
Sent: 11 July 2019 14:31
To: openmama-dev@...; openmama-users@...
Subject: RE: OpenMAMA-6.3.0-rc1 Now Available

 

Sorry just as a quick correction, the list of issues is in this link, not the one in the previous email:

 

https://github.com/OpenMAMA/OpenMAMA/milestone/10?closed=1

 

(thanks Chris)

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Frank Quinn via Lists.Openmama.Org
Sent: 09 July 2019 19:36
To: openmama-dev@...; openmama-users@...
Cc: Openmama-dev@...
Subject: [Openmama-dev] OpenMAMA-6.3.0-rc1 Now Available

 

Hi Folks,

Sorry for the delay I hit a few snags trying to get the release together, but it’s finally ready!

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc1

Note that this changes the minor revision number which reflects a bridge change. This is because although this release doesn’t in itself do anything to break the bridge compatibility, new bridges being built using the new “base bridge” functionality would not be backwards compatible, so the version is being bumped to reflect this.

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

For a complete list of all 20 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/9?closed=1

Please test rigorously particularly for bridge based functionality and feel free to try out the new docker images and ping the mailing list if you have any queries! I’ll leave testing open for 6 weeks, making the aspirational release date be 20th August.

For help on how to raise a ticket, please see:

https://openmama.github.io/openmama_raising_issues.html

Good hunting.

Cheers,
Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


OpenMAMA-6.3.0-rc2 Now Available

Frank Quinn
 

Hi Folks, RC2 now available with artefacts: https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc2

 

Let’s aim for a 2 week test window so please get testing!

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Frank Quinn
Sent: 16 September 2019 13:14
To: 'openmama-dev@...' <openmama-dev@...>; 'openmama-users@...' <openmama-users@...>
Subject: RE: OpenMAMA-6.3.0-rc1 Now Available

 

NB: Further Bridge Interface change in OpenMAMA 6.3.0

 

Hi Folks,

 

As suggested by Chris over at Solace (and with my agreement), I think this is a good time to correct one of the interface consistencies that bridge developers have needed to deal with since we're currently bumping the versions to an incompatible bridge version anyway. The changes themselves should be easy to implement, but are nevertheless important for users of sub-messages:

 

Payload_addMsg() - now expects a mamaMsg rather than a msgPayload. This is to align with other payloads and support potential transcoding in the bridge

 

Payload_updateSubMsg - now expects a mamaMsg rather than a msgPayload.

 

This will allow us to put to bed a longstanding issue as well in https://github.com/OpenMAMA/OpenMAMA/issues/297

 

I’ll get some more builds together within the next week or two, and extend the aspirational release date to 18th October 2019.

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Frank Quinn
Sent: 11 July 2019 14:31
To: openmama-dev@...; openmama-users@...
Subject: RE: OpenMAMA-6.3.0-rc1 Now Available

 

Sorry just as a quick correction, the list of issues is in this link, not the one in the previous email:

 

https://github.com/OpenMAMA/OpenMAMA/milestone/10?closed=1

 

(thanks Chris)

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Frank Quinn via Lists.Openmama.Org
Sent: 09 July 2019 19:36
To: openmama-dev@...; openmama-users@...
Cc: Openmama-dev@...
Subject: [Openmama-dev] OpenMAMA-6.3.0-rc1 Now Available

 

Hi Folks,

Sorry for the delay I hit a few snags trying to get the release together, but it’s finally ready!

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc1

Note that this changes the minor revision number which reflects a bridge change. This is because although this release doesn’t in itself do anything to break the bridge compatibility, new bridges being built using the new “base bridge” functionality would not be backwards compatible, so the version is being bumped to reflect this.

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

For a complete list of all 20 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/9?closed=1

Please test rigorously particularly for bridge based functionality and feel free to try out the new docker images and ping the mailing list if you have any queries! I’ll leave testing open for 6 weeks, making the aspirational release date be 20th August.

For help on how to raise a ticket, please see:

https://openmama.github.io/openmama_raising_issues.html

Good hunting.

Cheers,
Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: OpenMAMA-6.3.0-rc1 Now Available

Frank Quinn
 

NB: Further Bridge Interface change in OpenMAMA 6.3.0

 

Hi Folks,

 

As suggested by Chris over at Solace (and with my agreement), I think this is a good time to correct one of the interface consistencies that bridge developers have needed to deal with since we're currently bumping the versions to an incompatible bridge version anyway. The changes themselves should be easy to implement, but are nevertheless important for users of sub-messages:

 

Payload_addMsg() - now expects a mamaMsg rather than a msgPayload. This is to align with other payloads and support potential transcoding in the bridge

 

Payload_updateSubMsg - now expects a mamaMsg rather than a msgPayload.

 

This will allow us to put to bed a longstanding issue as well in https://github.com/OpenMAMA/OpenMAMA/issues/297

 

I’ll get some more builds together within the next week or two, and extend the aspirational release date to 18th October 2019.

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Frank Quinn
Sent: 11 July 2019 14:31
To: openmama-dev@...; openmama-users@...
Subject: RE: OpenMAMA-6.3.0-rc1 Now Available

 

Sorry just as a quick correction, the list of issues is in this link, not the one in the previous email:

 

https://github.com/OpenMAMA/OpenMAMA/milestone/10?closed=1

 

(thanks Chris)

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Frank Quinn via Lists.Openmama.Org
Sent: 09 July 2019 19:36
To: openmama-dev@...; openmama-users@...
Cc: Openmama-dev@...
Subject: [Openmama-dev] OpenMAMA-6.3.0-rc1 Now Available

 

Hi Folks,

Sorry for the delay I hit a few snags trying to get the release together, but it’s finally ready!

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc1

Note that this changes the minor revision number which reflects a bridge change. This is because although this release doesn’t in itself do anything to break the bridge compatibility, new bridges being built using the new “base bridge” functionality would not be backwards compatible, so the version is being bumped to reflect this.

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

For a complete list of all 20 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/9?closed=1

Please test rigorously particularly for bridge based functionality and feel free to try out the new docker images and ping the mailing list if you have any queries! I’ll leave testing open for 6 weeks, making the aspirational release date be 20th August.

For help on how to raise a ticket, please see:

https://openmama.github.io/openmama_raising_issues.html

Good hunting.

Cheers,
Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: OpenMAMA-6.3.0-rc1 Now Available

Frank Quinn
 

Sorry just as a quick correction, the list of issues is in this link, not the one in the previous email:

 

https://github.com/OpenMAMA/OpenMAMA/milestone/10?closed=1

 

(thanks Chris)

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Frank Quinn via Lists.Openmama.Org
Sent: 09 July 2019 19:36
To: openmama-dev@...; openmama-users@...
Cc: Openmama-dev@...
Subject: [Openmama-dev] OpenMAMA-6.3.0-rc1 Now Available

 

Hi Folks,

Sorry for the delay I hit a few snags trying to get the release together, but it’s finally ready!

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc1

Note that this changes the minor revision number which reflects a bridge change. This is because although this release doesn’t in itself do anything to break the bridge compatibility, new bridges being built using the new “base bridge” functionality would not be backwards compatible, so the version is being bumped to reflect this.

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

For a complete list of all 20 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/9?closed=1

Please test rigorously particularly for bridge based functionality and feel free to try out the new docker images and ping the mailing list if you have any queries! I’ll leave testing open for 6 weeks, making the aspirational release date be 20th August.

For help on how to raise a ticket, please see:

https://openmama.github.io/openmama_raising_issues.html

Good hunting.

Cheers,
Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


OpenMAMA-6.3.0-rc1 Now Available

Frank Quinn
 

Hi Folks,

Sorry for the delay I hit a few snags trying to get the release together, but it’s finally ready!

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc1

Note that this changes the minor revision number which reflects a bridge change. This is because although this release doesn’t in itself do anything to break the bridge compatibility, new bridges being built using the new “base bridge” functionality would not be backwards compatible, so the version is being bumped to reflect this.

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

For a complete list of all 20 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/9?closed=1

Please test rigorously particularly for bridge based functionality and feel free to try out the new docker images and ping the mailing list if you have any queries! I’ll leave testing open for 6 weeks, making the aspirational release date be 20th August.

For help on how to raise a ticket, please see:

https://openmama.github.io/openmama_raising_issues.html

Good hunting.

Cheers,
Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: Proposal to make the cut for OpenMAMA 6.3.0 RC1

Damian Maguire
 

My two cents here, the Docker PR looks solid and I think is good to merge. I suspect the MAMDA QuoteCache fix (392) should be landed before any cut, even if it means a delay, but apart from that I think this is probably a solid time to begin the release process.

All for the removal of scons though, cmake all the way makes sense.

Cheers,

D


On Thu, 23 May 2019 at 23:11, Frank Quinn <fquinn@...> wrote:

Hi Folks,

 

It’s that time again where I think we need to consider making a new OpenMAMA release.

 

I’ve just raised a pull request for Docker which was the last main piece of new functionality that I wanted to get into this release. There is also the https://github.com/OpenMAMA/OpenMAMA/issues/392 issue which I hope to resolve next week.

 

So if anyone else is mid-flight with any changes or has any major showstoppers that they want to include in this release please let me know, otherwise I’ll take a cut towards the end of next week with a mind to release before the summer holidays kick in.

 

Note that this release bumps to version 6.3.0 because APIs which integrate with the new modular bridge functionality will not be backwards compatible with 6.2.x.

 

Also note that this release will finally remove scons in favour of cmake so please test these new builds in RC stage for any missing headers etc.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Proposal to make the cut for OpenMAMA 6.3.0 RC1

Frank Quinn
 

Hi Folks,

 

It’s that time again where I think we need to consider making a new OpenMAMA release.

 

I’ve just raised a pull request for Docker which was the last main piece of new functionality that I wanted to get into this release. There is also the https://github.com/OpenMAMA/OpenMAMA/issues/392 issue which I hope to resolve next week.

 

So if anyone else is mid-flight with any changes or has any major showstoppers that they want to include in this release please let me know, otherwise I’ll take a cut towards the end of next week with a mind to release before the summer holidays kick in.

 

Note that this release bumps to version 6.3.0 because APIs which integrate with the new modular bridge functionality will not be backwards compatible with 6.2.x.

 

Also note that this release will finally remove scons in favour of cmake so please test these new builds in RC stage for any missing headers etc.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: Two Mamda libraries exporting the same symbol

Slade, Michael J
 

Hi Frank,

 

Thanks for your message, and for raising the associated issue in Github.

 

We have discovered that the MamdaQuoteToBookListener.cpp file is not present in the SConscript.win build configuration file – it is only included in the Linux build. For now we are working around this issue by excluding the file from the non-windows SConscript file too.

 

If you could have a look at this issue, that would be great.

 

Many thanks,

 


Mike Slade | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Frank Quinn [mailto:fquinn@...]
Sent: 30 April 2019 14:04
To: Slade, Michael J <michael.j.slade@...>; openmama-dev@...
Subject: RE: Two Mamda libraries exporting the same symbol

 

Hi Mike,

 

This isn’t something that I have seen before but it does look like a bug to me… and one which I imagine you had all sorts of fun tracking down.

 

On the upside, it looks like the struct in question isn’t referenced in the public headers so at least it can be renamed in relative isolation. Is this something that you are in the progress of doing or you want me to have a look?

 

I have raised https://github.com/OpenMAMA/OpenMAMA/issues/392 for tracking.

 

Cheers,

Frank

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Slade, Michael J via Lists.Openmama.Org
Sent: 26 April 2019 09:23
To: Openmama-dev@...
Cc: Openmama-dev@...
Subject: [Openmama-dev] Two Mamda libraries exporting the same symbol

 

Hi all,

 

We have noticed that both mamda/c_cpp/src/cpp/MamdaQuoteListener.cpp and mamda/c_cpp/src/orderbooks/MamdaQuoteToBookListener have implementations of a QuoteCache struct in the Wombat namespace. Therefore, both libmamda and libmamdabook are exporting the same symbol.

 

This is an issue when linking against the two libraries since the order they are dynamically linked determines which one is used. If the wrong QuoteCache struct is used this causes a segfault during construction of the object as the two implementations are different.

 

To me this seems like a bug and one of the two QuoteCache structs should be renamed.

 

Has anyone had an issue with this before / can anyone shed some light on this?

 

Thanks,

 


Mike Slade | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.


Re: Two Mamda libraries exporting the same symbol

Frank Quinn
 

Hi Mike,

 

This isn’t something that I have seen before but it does look like a bug to me… and one which I imagine you had all sorts of fun tracking down.

 

On the upside, it looks like the struct in question isn’t referenced in the public headers so at least it can be renamed in relative isolation. Is this something that you are in the progress of doing or you want me to have a look?

 

I have raised https://github.com/OpenMAMA/OpenMAMA/issues/392 for tracking.

 

Cheers,

Frank

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Slade, Michael J via Lists.Openmama.Org
Sent: 26 April 2019 09:23
To: Openmama-dev@...
Cc: Openmama-dev@...
Subject: [Openmama-dev] Two Mamda libraries exporting the same symbol

 

Hi all,

 

We have noticed that both mamda/c_cpp/src/cpp/MamdaQuoteListener.cpp and mamda/c_cpp/src/orderbooks/MamdaQuoteToBookListener have implementations of a QuoteCache struct in the Wombat namespace. Therefore, both libmamda and libmamdabook are exporting the same symbol.

 

This is an issue when linking against the two libraries since the order they are dynamically linked determines which one is used. If the wrong QuoteCache struct is used this causes a segfault during construction of the object as the two implementations are different.

 

To me this seems like a bug and one of the two QuoteCache structs should be renamed.

 

Has anyone had an issue with this before / can anyone shed some light on this?

 

Thanks,

 


Mike Slade | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.


Two Mamda libraries exporting the same symbol

Slade, Michael J
 

Hi all,

 

We have noticed that both mamda/c_cpp/src/cpp/MamdaQuoteListener.cpp and mamda/c_cpp/src/orderbooks/MamdaQuoteToBookListener have implementations of a QuoteCache struct in the Wombat namespace. Therefore, both libmamda and libmamdabook are exporting the same symbol.

 

This is an issue when linking against the two libraries since the order they are dynamically linked determines which one is used. If the wrong QuoteCache struct is used this causes a segfault during construction of the object as the two implementations are different.

 

To me this seems like a bug and one of the two QuoteCache structs should be renamed.

 

Has anyone had an issue with this before / can anyone shed some light on this?

 

Thanks,

 


Mike Slade | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidentiality, legal privilege, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.


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

ci@...
 

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

[fquinn.ni] Restored conditional in listenermsgcallback.c
	mama/c_cpp/src/c/listenermsgcallback.c


Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #246
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1858
  • Passed: 1858
  • 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 (Still Failing)

ci@...
 

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

[fquinn.ni] Restored conditional in listenermsgcallback.c
	mama/c_cpp/src/c/listenermsgcallback.c


Results for OpenMAMA_Snapshot_Windows CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Windows
  • Build Number: #238
  • Build Status: Still Failing
  • Build Warnings:
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

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


Re: change openmama linux platform implementation to call dlopen with RTLD_LOCAl flag

Igor Kovalenko
 

Classification: Public

Thank you Frank,

 

I confirm changing the dlopen() call to use RTLD_LOCAL fixes the problem for us here, none of our tests are otherwise affected.

Have not looked at split-bridge changes yet but I’m sure that is a good thing to have.

 

--

Kind regards,
Igor Kovalenko
____________________________________________________



Igor Kovalenko

OOO "Deutsche Bank TechCentre"
Global Technology
Business Center Aquamarine, Ozerkovskaya naberezhnaya 24, 115184 Moscow, Russia
Tel. +7 495 783-0313
Email igor.kovalenko@...

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Frank Quinn
Sent: 15 января 2019 г. 13:11
To: Igor Kovalenko <igor.kovalenko@...>
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] change openmama linux platform implementation to call dlopen with RTLD_LOCAl flag

 

Hi Igor,

 

Yes I'm open to the suggestion I can't see any negative side effects of this.

 

As an aside, the new split-bridge changes will also fix your timerheap issue since each bridge will have its own distinct heap allocated object in each bridge if it's used and would be best practice overall since it isolates each bridge and doesn't depend on static externs.

 

Cheers,

Frank

 

On Jan 15 2019, at 10:03 am, Igor Kovalenko <igor.kovalenko@...> wrote:

 

Classification: Public

 

Hi openmama team,

 

 

 

I see that on linux platform openmama uses dlopen() with RTLD_GLOBAL flag to load bridge implementations.

 

What do you think about changing that dlopen() call to use RTLD_LOCAL instead?

 

Using dlopen() with RTLD_LOCAL naturally provides named symbol isolation behavior one would expect from a system which dynamically loads implementations.

 

 

 

I cannot post a patch here yet but otherwise it is a trivial change to src/common/c_cpp/src/c/linux/platform.c line 65

 

 

 

Using RTLD_GLOBAL creates a problem if any two bridge implementations provide the same global symbol name. If loaded simultaneously these will share the same underlying object resolved through the library loaded first.

 

For instance a crash can be reproduced with just loading tick42blp and tick42rmds bridges, and then closing mama. While mama is closing first bridge shutting down will destroy gTimerHeap object, and then last bridge shutting down will attempt to destroy the same gTimerHeap once again.

 

 

 

A workaround would be to carefully examine non-local symbols from each bridge implementation and fix accordingly if bridge sources are available.

 

We can amend either blp or rmds bridge implementation - but this is not always possible and is obviously very inconvenient.

 

 

 

Note that on windows platform implementation already is behaving as non-global due to the fact that you always need explicitly loaded library handle to resolve a symbol.

 

 

 

Thank you!

 

 

 

--

 

Kind regards,

Igor Kovalenko

____________________________________________________

 

Igor Kovalenko

 

OOO "Deutsche Bank TechCentre"

Global Technology

Business Center Aquamarine, Ozerkovskaya naberezhnaya 24, 115184 Moscow, Russia

Tel. +7 495 783-0313

 

 

 

---

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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.



---
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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Re: change openmama linux platform implementation to call dlopen with RTLD_LOCAl flag

Frank Quinn
 

Hi Igor,

Yes I'm open to the suggestion I can't see any negative side effects of this.

As an aside, the new split-bridge changes will also fix your timerheap issue since each bridge will have its own distinct heap allocated object in each bridge if it's used and would be best practice overall since it isolates each bridge and doesn't depend on static externs.

Cheers,
Frank

On Jan 15 2019, at 10:03 am, Igor Kovalenko <igor.kovalenko@...> wrote:
 
Classification: Public

Hi openmama team,

 

I see that on linux platform openmama uses dlopen() with RTLD_GLOBAL flag to load bridge implementations.

What do you think about changing that dlopen() call to use RTLD_LOCAL instead?

Using dlopen() with RTLD_LOCAL naturally provides named symbol isolation behavior one would expect from a system which dynamically loads implementations.

 

I cannot post a patch here yet but otherwise it is a trivial change to src/common/c_cpp/src/c/linux/platform.c line 65

 

Using RTLD_GLOBAL creates a problem if any two bridge implementations provide the same global symbol name. If loaded simultaneously these will share the same underlying object resolved through the library loaded first.

For instance a crash can be reproduced with just loading tick42blp and tick42rmds bridges, and then closing mama. While mama is closing first bridge shutting down will destroy gTimerHeap object, and then last bridge shutting down will attempt to destroy the same gTimerHeap once again.

 

A workaround would be to carefully examine non-local symbols from each bridge implementation and fix accordingly if bridge sources are available.

We can amend either blp or rmds bridge implementation - but this is not always possible and is obviously very inconvenient.

 

Note that on windows platform implementation already is behaving as non-global due to the fact that you always need explicitly loaded library handle to resolve a symbol.

 

Thank you!

 

--

Kind regards,
Igor Kovalenko
____________________________________________________



Igor Kovalenko

OOO "Deutsche Bank TechCentre"
Global Technology
Business Center Aquamarine, Ozerkovskaya naberezhnaya 24, 115184 Moscow, Russia
Tel. +7 495 783-0313

 


---
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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


change openmama linux platform implementation to call dlopen with RTLD_LOCAl flag

Igor Kovalenko
 

Classification: Public

Hi openmama team,

 

I see that on linux platform openmama uses dlopen() with RTLD_GLOBAL flag to load bridge implementations.

What do you think about changing that dlopen() call to use RTLD_LOCAL instead?

Using dlopen() with RTLD_LOCAL naturally provides named symbol isolation behavior one would expect from a system which dynamically loads implementations.

 

I cannot post a patch here yet but otherwise it is a trivial change to src/common/c_cpp/src/c/linux/platform.c line 65

 

Using RTLD_GLOBAL creates a problem if any two bridge implementations provide the same global symbol name. If loaded simultaneously these will share the same underlying object resolved through the library loaded first.

For instance a crash can be reproduced with just loading tick42blp and tick42rmds bridges, and then closing mama. While mama is closing first bridge shutting down will destroy gTimerHeap object, and then last bridge shutting down will attempt to destroy the same gTimerHeap once again.

 

A workaround would be to carefully examine non-local symbols from each bridge implementation and fix accordingly if bridge sources are available.

We can amend either blp or rmds bridge implementation - but this is not always possible and is obviously very inconvenient.

 

Note that on windows platform implementation already is behaving as non-global due to the fact that you always need explicitly loaded library handle to resolve a symbol.

 

Thank you!

 

--

Kind regards,
Igor Kovalenko
____________________________________________________



Igor Kovalenko

OOO "Deutsche Bank TechCentre"
Global Technology
Business Center Aquamarine, Ozerkovskaya naberezhnaya 24, 115184 Moscow, Russia
Tel. +7 495 783-0313
Email igor.kovalenko@...

 



---
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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


OpenMAMA Simplified Base Middleware Bridge Implementation

Frank Quinn
 

Hi Folks,

As you may have heard recently, we have been working on reducing the burden of implementing each of the middleware bridge methods when writing bridges.

The solution we're working on involves:

1. Adding a "base" implementation bridge. This includes io, timer and queue as well as some sane default implementations of methods. This will be dynamically linked by the bridge that wants to make use of the base implementation.
2. The base bridge includes timer, queue and io implementations which will be modified to ensure they're properly encapsulated across middleware bridges (i.e. heap allocated state associated with each bridge).
3. The implementation bridge may then simply declare in its init function that it wants to make use of the base implementaion bridge, then any method which is not implemented by the bridge itself will fall back to the base bridge implementation.
4. Reducing the number of methods which need to be implemented in the bridge from 86 to 20

It's basically inheritance for C structs of function pointers.

You can find the latest development branch here:


We have an implementation currently working with ZeroMQ, and will be updating qpid to support it soon too. It mostly involves migrating methods to the base implementation to avoid duplication.


In the next release this will bump the middle part of the version number (which reflects bridge compatibility). This is because although it is entirely backwards compatible, bridges making use of this functionality will not be backwards compatible.

Cheers,
Frank

-- 
Frank Quinn 
Cascadium 
T: +44 (0) 28 8678 8015 

61 - 80 of 2311