Date   

OpenMAMA Now Available on Homebrew (Mac / Linux)

Frank Quinn
 

That’s right Mac users – OpenMAMA has been approved and is now included in homebrew’s set of packages.

 

So to install OpenMAMA on a Mac, simply

 

brew update

brew install openmama

 

…and yes this will also work on the new Apple M1 machines.

 

This also has been verified as working with linuxbrew (if anyone uses that).

 

Any issues please raise an issue on the OpenMAMA github page!

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: The future of CentOS and OpenMAMA

Bill Torpey
 

Hi Frank:

At NYFIX we not too long ago moved from RH to CentOS 7 for our dev and prod installs, and assumed that CentOS 8 would be our eventual upgrade path.  

It’s way too early to say how things shake out, with the exception that we will certainly NOT be moving to CentOS 8 Stream.

Personally I’ve moved my day-to-day development from CentOS to Ubuntu, and I’m quite happy with it.  I now only use CentOS to regression test before pushing changes.

Hope this helps.

Regards,

Bill



On Feb 24, 2021, at 12:34 PM, Frank Quinn <fquinn@...> wrote:

Hi Folks,
 
I’m curious about the community feeling towards the future of CentOS. I’d appreciate a reply with one or a selection of the following for those of you running Red Hat derivative distributions:
 
  1. We will be clinging onto CentOS 7 for dear life since CentOS 8 will be EOL 2021 but CentOS 7 won’t be EOL until 2024
  2. We will be making the jump to CentOS Stream
  3. We will go with one of the CentOS clones
  4. We will bide our time and wait to see which CentOS clone comes out on top
  5. This doesn’t really affect us – we use RHEL everywhere
 
Cheers,
Frank
 
Frank Quinn
Cascadium
T: +44 (0) 28 8678 8015
 


The future of CentOS and OpenMAMA

Frank Quinn
 

Hi Folks,

 

I’m curious about the community feeling towards the future of CentOS. I’d appreciate a reply with one or a selection of the following for those of you running Red Hat derivative distributions:

 

  1. We will be clinging onto CentOS 7 for dear life since CentOS 8 will be EOL 2021 but CentOS 7 won’t be EOL until 2024
  2. We will be making the jump to CentOS Stream
  3. We will go with one of the CentOS clones
  4. We will bide our time and wait to see which CentOS clone comes out on top
  5. This doesn’t really affect us – we use RHEL everywhere

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Goodbye Appveyor, Hello Github Actions

Frank Quinn
 

Hi folks,

I am in the final stages of the effort to migrate from Appveyor to Github Actions. This will reduce the overall build time down from 5 hours to 40 minutes across 14 different development environments including new support for OSX in continuous integration. It also provides much richer options around bringing our own compute should we need to with better support for parallel jobs.

These changes will also (finally) retire the Scons build system so if you are still using it, please use cmake instead as documented here:

https://openmama.finos.org/openmama_build_instructions.html

This will be dropping into the "next" branch at some point over the weekend if anyone finds any issues please let me know!

Cheers,
Frank


CentOS 6 / RHEL 6 Support (Reply Needed)

Frank Quinn
 

Hi Folks,

 

CentOS 6 is reaching its main EOL on the 30th November (10 days time), so I’d like to ask the community where they are in respect to migration.

 

Please feel free to reply to me either directly or via list with one of the below:

 

  1. CentOS 6? How quaint. Kill it with fire.
  2. We are moving off CentOS 6 and expect to be migrated away from it before the next OpenMAMA release in Spring.
  3. I think we’d need CentOS support for at least another year or so until all our systems migrate.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


OpenMAMA contribution to FINOS

Frank Quinn
 

Hi Folks,

 

I am excited to announce that OpenMAMA was successfully contributed to FINOS and it's now available as a FINOS hosted project at https://github.com/finos/OpenMAMA. Any old links and git clones should automatically redirect, but if there are any issues with this please let us know.

 

Our website is now hosted at openmama.finos.org and you can reach out to the project team using any of the channels on our support page.

 

Being part of FINOS gives OpenMAMA a specialist target audience to tap into, and helps raise the visibility and profile of the project directly to where it’s likely to be most relevant. We are hoping it will help continue to drive forward with our core goals of adoption, interoperability and visibility.

 

Many thanks to the FINOS team and to the wider FINOS Community for their warm welcome and support in moving OpenMAMA to its new home!

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Announcing OZ: a production-quality, open-source transport for OpenMAMA using ZeroMQ

Bill Torpey
 

Everyone on this mailing list is already well acquainted with OpenMAMA's awesome-ness, but I want to let you know about something that makes OpenMAMA even more awesome.

One thing that has always been a trouble spot for OpenMAMA is the lack of a reliable, high-performance, open-source transport library. The AVIS bridge was little more than a toy, and while the Qpid bridge was an improvement, there has never been a production-quality, open-source transport bridge for OpenMAMA.

Until now.

NYFIX, a division of Itiviti AB, has recently released an open-source transport for OpenMAMA based on ZeroMQ which we are calling OZ. OZ has been in live production use supporting the NYFIX Marketplace since early March in our data centers in Europe, Asia and the U.S., processing roughly 50 million messages per day.

OZ was designed to support many of the most popular features of typical MOM's:

  • publish/subscribe messaging using topic-based addressing, supporting hierarchical topic namespaces and "wildcard" subscriptions;
  • request/reply (inbox) messaging for transactional interactions;
  • dynamic service discovery with minimal configuration;
  • broker-less architecture for reduced latency and optimum throughput;
  • self-describing messages (thanks to OpenMAMA-omnm).

We recently published a whitepaper describing OZ, but the more technical-minded will probably prefer to check out the docs and/or take a look at the sample code. (In particular, the examples use modern C++ constructs to provide a kinder, gentler introduction to OpenMAMA).

We're hopeful that the OpenMAMA community will find OZ helpful, and we look forward to working with everyone in the community to make OZ, and OpenMAMA itself, even better. We encourage everyone to check out OZ at https://github.com/nyfix/OZ.

Please contact me directly or raise an issue with any comments, suggestions, etc.


OpenMAMA 6.3.1 Released

Frank Quinn
 

Hi Folks,

 

We are pleased to announce OpenMAMA 6.3.1 is finally here and has now propagated to Cloudsmith, Maven central etc!

 

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

 

  • Added experimental .NET core support (including C# on Linux)
  • Updated supported platforms to include CentOS 8, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS
  • Added quickstart / start of tutorial code for all languages
  • Modernized JNI implementation to use javac -h rather than javah
  • Added json and normalized string methods for all language bindings (formerly reserved for only C)
  • Fix multithreaded builds in OpenMAMA and add "experimental" cloudsmith repository automatic upload
  • Added support for clang sanitizers
  • Added code for creating your own Vagrant box for OpenMAMA (and we uploaded our own)
  • Added ansible code for creating a demo environment
  • Fixed a few race conditions, leaks and bugs
  • Improved Mac Support

 

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

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: OpenMAMA 6.3.1 RC1 Released

Frank Quinn
 

Hi folks - a reminder that we are going into the final week of this RC -if any major issues are spotted please raise as a priority!


On Thu, 24 Sep 2020, 18:32 Frank Quinn, <fquinn@...> wrote:

Hi Folks,

 

We (finally) have a new RC ready for testing with compiled artifacts for supported platforms – check it out:

 

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

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

  • Added .NET core support (includig C# on Linux)
  • Updated supported platforms to include CentOS 8, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS
  • Added quickstart / start of tutorial code for all languages
  • Modernized JNI implementation to use javac -h rather than javah
  • Added json and normalized string methods for all language bindings (formerly reserved for only C)
  • Fix multithreaded builds in OpenMAMA and add "experimental" cloudsmith repository automatic upload
  • Added support for clang sanitizers
  • Added code for creating your own Vagrant box for OpenMAMA (and we uploaded our own)
  • Added ansible code for creating a demo environment
  • Fixed a few race conditions, leaks and bugs
  • Improved Mac Support

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

The first RC stage will last for 2 weeks, so if no major issues are found, we will provide the GA release on Monday 12th October 2020.

 

Good hunting.

 

Cheers.

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


New OpenMAMA Website is Live!

Frank Quinn
 

Hi Folks,

 

After a successful testing period (thanks to all who were involved), we are delighted to announce the official launch the new OpenMAMA website which went live yesterday evening: https://openmama.org

 

We will be getting the word out on social media so please like / share our posts to extend our reach! Also please update any existing links etc. to the OpenMAMA website where appropriate.

 

The site is a complete overhaul and has several key improvements over the former site beyond aesthetics:

 

  • It is responsive
  • It is a static, bloat-free website so it should load very quickly
  • You can submit your own suggested changes to the site via pull request because it's all on github
  • It merges the documentation and main marketing website into one
  • It generally tries to de-duplicate information and the content has had a general refresh

 

If there are any issues please raise them at https://github.com/OpenMAMA/openmama.github.io/issues and we hope you enjoy the new site! As usual, we’ll be keeping an eye on gitter if you have any immediate feedback / concerns.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


OpenMAMA 6.3.1 RC1 Released

Frank Quinn
 

Hi Folks,

 

We (finally) have a new RC ready for testing with compiled artifacts for supported platforms – check it out:

 

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

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

  • Added .NET core support (includig C# on Linux)
  • Updated supported platforms to include CentOS 8, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS
  • Added quickstart / start of tutorial code for all languages
  • Modernized JNI implementation to use javac -h rather than javah
  • Added json and normalized string methods for all language bindings (formerly reserved for only C)
  • Fix multithreaded builds in OpenMAMA and add "experimental" cloudsmith repository automatic upload
  • Added support for clang sanitizers
  • Added code for creating your own Vagrant box for OpenMAMA (and we uploaded our own)
  • Added ansible code for creating a demo environment
  • Fixed a few race conditions, leaks and bugs
  • Improved Mac Support

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

The first RC stage will last for 2 weeks, so if no major issues are found, we will provide the GA release on Monday 12th October 2020.

 

Good hunting.

 

Cheers.

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: OpenMAMA Preview Website Launch

Frank Quinn
 

Hi Folks,

 

Quick reminder about the invitation below, and to thank everyone who has checked it out already (I can see a noticeable increase in traffic since sending this out so I know you folks are looking).

 

Particular thanks to our friends at Solace who submitted the first ever pull request to the new website! Others are welcome if appropriate!

 

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: 21 September 2020 09:40
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA Preview Website Launch

 

Hi Folks,

 

It is with great pleasure that I can declare that a new website is on its way.

 

It is currently hosted at https://openmama.github.io as a preview version (the former documentation website address) and therefore I invite the members of the mailing list to have a look, and report any issues back directly to be before its "proper" launch to openmama.org on Monday 28th September.

 

The site is a complete overhaul and has several key improvements over the former site beyond aesthetics:

 

  • It is responsive
  • It is a static, bloat-free website so it should load very quickly
  • You can submit your own suggested changes to the site via pull request because it's all on github
  • It merges the documentation and main marketing website into one
  • It generally tries to de-duplicate information and the content has had a general refresh

 

Anyway if there are any issues please raise them at https://github.com/OpenMAMA/openmama.github.io/issues and I hope you enjoy the new site! As usual, I’ll be keeping an eye on gitter if you have any immediate feedback / concerns.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


OpenMAMA Preview Website Launch

Frank Quinn
 

Hi Folks,

 

It is with great pleasure that I can declare that a new website is on its way.

 

It is currently hosted at https://openmama.github.io as a preview version (the former documentation website address) and therefore I invite the members of the mailing list to have a look, and report any issues back directly to be before its "proper" launch to openmama.org on Monday 28th September.

 

The site is a complete overhaul and has several key improvements over the former site beyond aesthetics:

 

  • It is responsive
  • It is a static, bloat-free website so it should load very quickly
  • You can submit your own suggested changes to the site via pull request because it's all on github
  • It merges the documentation and main marketing website into one
  • It generally tries to de-duplicate information and the content has had a general refresh

 

Anyway if there are any issues please raise them at https://github.com/OpenMAMA/openmama.github.io/issues and I hope you enjoy the new site! As usual, I’ll be keeping an eye on gitter if you have any immediate feedback / concerns.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: Proposal: OpenMAMA Default Branch change to "next"

Frank Quinn
 

Hi Folks,

 

The default branch for OpenMAMA has now been set to “next”. Looks a little more lively already 😊

 

If anyone runs into any issues, let me know. Hopefully overall this will make things a little easier.

 

Cheers,

Frank

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

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Phelan, Nigel via lists.openmama.org
Sent: 25 August 2020 12:49
To: openmama-dev@...
Subject: Re: [Openmama-dev] Proposal: OpenMAMA Default Branch change to "next"

 

Sounds quite sensible to me, Frank.

 

Nigel

 


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

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Frank Quinn
Sent: 25 August 2020 12:35
To: openmama-dev@...
Subject: [Openmama-dev] Proposal: OpenMAMA Default Branch change to "next"

 

Hi Folks,

 

I would like to propose that we change the OpenMAMA github default git branch to “next” instead of “master”.

 

This would mean that:

 

  • When you visit our github page, you will see the latest development code and documentation
  • When you clone the repository, you no longer need to change branch before making feature branches which will eventually become pull requests.

 

Note all existing clones etc would remain unchanged so this won’t actually “break” anything for existing OpenMAMA developers.

 

The rationale being that “master” is reflective of the last stable release, but it’s also the source of the main README output when visitors come to the github page which makes it look like the project is less active than it actually is, repo documentation effectively slows down to match the biannual release cycle etc.

 

The industry in general is also gradually moving away from the “master” nomenclature for branches with linux and github both making noises about moving away from defaulting to that branch name, so this would pave the way for eventual retirement of the branch name (which is actually fine - we can just use our release branches instead as we already do with minimal impact).

 

If anyone has any comments or feedback on this, please respond on this thread.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, malicious content 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: Proposal: OpenMAMA Default Branch change to "next"

Phelan, Nigel
 

Sounds quite sensible to me, Frank.

 

Nigel

 


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

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Frank Quinn
Sent: 25 August 2020 12:35
To: openmama-dev@...
Subject: [Openmama-dev] Proposal: OpenMAMA Default Branch change to "next"

 

Hi Folks,

 

I would like to propose that we change the OpenMAMA github default git branch to “next” instead of “master”.

 

This would mean that:

 

  • When you visit our github page, you will see the latest development code and documentation
  • When you clone the repository, you no longer need to change branch before making feature branches which will eventually become pull requests.

 

Note all existing clones etc would remain unchanged so this won’t actually “break” anything for existing OpenMAMA developers.

 

The rationale being that “master” is reflective of the last stable release, but it’s also the source of the main README output when visitors come to the github page which makes it look like the project is less active than it actually is, repo documentation effectively slows down to match the biannual release cycle etc.

 

The industry in general is also gradually moving away from the “master” nomenclature for branches with linux and github both making noises about moving away from defaulting to that branch name, so this would pave the way for eventual retirement of the branch name (which is actually fine - we can just use our release branches instead as we already do with minimal impact).

 

If anyone has any comments or feedback on this, please respond on this thread.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, malicious content 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.


Proposal: OpenMAMA Default Branch change to "next"

Frank Quinn
 

Hi Folks,

 

I would like to propose that we change the OpenMAMA github default git branch to “next” instead of “master”.

 

This would mean that:

 

  • When you visit our github page, you will see the latest development code and documentation
  • When you clone the repository, you no longer need to change branch before making feature branches which will eventually become pull requests.

 

Note all existing clones etc would remain unchanged so this won’t actually “break” anything for existing OpenMAMA developers.

 

The rationale being that “master” is reflective of the last stable release, but it’s also the source of the main README output when visitors come to the github page which makes it look like the project is less active than it actually is, repo documentation effectively slows down to match the biannual release cycle etc.

 

The industry in general is also gradually moving away from the “master” nomenclature for branches with linux and github both making noises about moving away from defaulting to that branch name, so this would pave the way for eventual retirement of the branch name (which is actually fine - we can just use our release branches instead as we already do with minimal impact).

 

If anyone has any comments or feedback on this, please respond on this thread.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: Last call for OpenMAMA 6.3.1 release candidate

Frank Quinn
 

Hi Folks,

 

Looks like a number of issues are still coming in and I have identified a few things that I want to get in myself, so I’m going to push this back 1 week to the weekend commencing 28-Aug 2020.

 

Cheers,

Frank

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

 

From: Frank Quinn
Sent: 18 August 2020 23:12
To: openmama-users@...
Subject: Last call for OpenMAMA 6.3.1 release candidate

 

Hi Folks,

 

I plan on taking a cut for OpenMAMA 6.3.1 RC1 over the coming weekend (21-Aug 2020). If anyone has anything they want to submit before then please let me know so I can delay the cut if necessary, otherwise I will continue as planned.

 

This release includes some changes to support:

 

  • CentOS 8
  • Fedora 31
  • Fedora 32
  • Ubuntu 20.04 LTS

 

It also effectively drops support for the now EOL:

 

  • Fedora 28
  • Fedora 29
  • Ubuntu 14.04 LTS

 

This is in preparation for a RC that will be cut within the next few weeks which is now set up to include RPMs and Debian packages for these modern distros to make installation easy, take care of dependencies etc.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Last call for OpenMAMA 6.3.1 release candidate

Frank Quinn
 

Hi Folks,

 

I plan on taking a cut for OpenMAMA 6.3.1 RC1 over the coming weekend (21-Aug 2020). If anyone has anything they want to submit before then please let me know so I can delay the cut if necessary, otherwise I will continue as planned.

 

This release includes some changes to support:

 

  • CentOS 8
  • Fedora 31
  • Fedora 32
  • Ubuntu 20.04 LTS

 

It also effectively drops support for the now EOL:

 

  • Fedora 28
  • Fedora 29
  • Ubuntu 14.04 LTS

 

This is in preparation for a RC that will be cut within the next few weeks which is now set up to include RPMs and Debian packages for these modern distros to make installation easy, take care of dependencies etc.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


CentOS 8 + Ubuntu 20.04 LTS Support

Frank Quinn
 

Hi Folks,

 

I have just pushed some changes into the next branch which add some changes to support:

 

  • CentOS 8
  • Ubuntu 20.04

 

It also effectively drops support for the now EOL:

 

  • Fedora 28
  • Fedora 29
  • Ubuntu 14.04 LTS

 

This is in preparation for a RC that will be cut within the next few weeks which is now set up to include RPMs and Debian packages for these modern distros to make installation easy, take care of dependencies etc.

 

If you're a user of these new operating system versions, please It a whirl.

 

Cheers,

Frank

 

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 


Re: Deadlock in mamaSubscription and mamaTransport destroy logic

Slade, Michael J
 

Hi Frank,

 

Thanks for raising the issue in Github.

 

We were able to reproduce this issue on a Linux (RH6) server using mamalistenc.c to subscribe to ~5000 symbols with the tick42rmds middleware bridge. The only modification made to mamalistenc was to reverse the order in which the subscriptions were destroyed. The deadlock would then occur on shutdown.

 

Kind regards,

Mike

 

From: Frank Quinn [mailto:fquinn@...]
Sent: 01 June 2020 22:11
To: Slade, Michael J (CIB Tech, GBR) <michael.j.slade@...>; openmama-dev@...
Subject: RE: Deadlock in mamaSubscription and mamaTransport destroy logic

 

Hi Mike,

 

Have raised https://github.com/OpenMAMA/OpenMAMA/issues/411 For follow up on this one – let’s track there for paper trail / release note reference etc.

 

Could you add some details on the execution environment? Particularly the shutdown sequence in the code, and whether or not this is JNI etc to see if anything unusual is compounding the issue?

 

The transport destroy is not supposed to be attempted by the app until after the subscriptions have all been destroyed and the queues have been drained and destroyed so it sounds like the bridge is still firing callbacks after the subscription has been “destroy”ed to free up the memory.

 

Cheers,

Frank

 

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

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Slade, Michael J via lists.openmama.org
Sent: 27 May 2020 15:41
To: openmama-dev@...
Subject: [Openmama-dev] Deadlock in mamaSubscription and mamaTransport destroy logic

 

Hi OpenMAMA Dev,

 

We have encountered a deadlock situation in mamaSubscription’s and mamaTransport’s teardown logic due to lock ordering when destroying their underlying mamaPublisher. We are able to reliably reproduce this with the tick42 bridge. Could someone take a look at this for us please?

Thanks in advance,

Mike

Deadlock – note that subscription and transport attempt to destroy same publisher:
mamaTransport teardown:

  1. transport.c:         mamaTransport_destroy()
  2. transport.c:         mamaTransportImpl_clearTransportWithPublishers()
  3. list.c:                    list_for_each()Acquires list lock (1)
  4. transport.c:         mamaTransportImpl_clearTransportPublisherCallback()
  5. publisher.c:         mamaPublisherImpl_clearTransport()
  6. publisher.c:         mamaPublisherImpl_destroy()Attempts to acquire publisher lock (2)

 

mamaSubscription teardown

  1. subscription.c:    mamaSubscriptionImpl_onSubscriptionDestroyed()
  2. subscription.c:    mamaSubscription_cleanup()
  3. publisher.c:         mamaPublisherImpl_destroy()Acquires publisher lock (2)
  4. transport.c:         mamaTransport_removePublisher()
  5. list.c:                    list_remove_element()Attempts to acquire list lock (1)

 

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 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.

1 - 20 of 2299