Date   

Using Qpid Broker

macrux
 

Hi there,

I'm trying to use the Java Qpid Broker implementation with OpenMAMA 2.4.0. On the web management console of the broker I have created a queue called "test" and I've bound it to the "amqp.topic" exchange (that is there by default). As a binding key I'm using "MAMA.*". When I run the mamapublisherc with:

mamapublisherc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/8c60fd18-07db-11e6-b2bd-d8fc939b9a65 : (null)

And it seems to connect correctly, but when I subscribe a client with:

mamasubscriberc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/b45ca894-07db-11e6-8de4-d8fc939b9a65 : (null)

And although it seems to connect correctly to the broker, it doesn't receive anything.

I haven't modified anything in the mama.properties file, so I have an error in the configuration of the broker, I suppose.

Could anyone please give me a hand with this? Thanks in advance.

Nestor.


Re: Using Qpid Broker

macrux
 

Hi, its me again, I have resolved this just creating a new topic exchange called "MAMA". That's all. Thanks anyway.

Kind regards,

Nestor.

On 21 April 2016 at 11:21, Macrux <kmacrux@...> wrote:
Hi there,

I'm trying to use the Java Qpid Broker implementation with OpenMAMA 2.4.0. On the web management console of the broker I have created a queue called "test" and I've bound it to the "amqp.topic" exchange (that is there by default). As a binding key I'm using "MAMA.*". When I run the mamapublisherc with:

mamapublisherc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/8c60fd18-07db-11e6-b2bd-d8fc939b9a65 : (null)

And it seems to connect correctly, but when I subscribe a client with:

mamasubscriberc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/b45ca894-07db-11e6-8de4-d8fc939b9a65 : (null)

And although it seems to connect correctly to the broker, it doesn't receive anything.

I haven't modified anything in the mama.properties file, so I have an error in the configuration of the broker, I suppose.

Could anyone please give me a hand with this? Thanks in advance.

Nestor.



Re: [Openmama-dev] Using Qpid Broker

Frank Quinn <fquinn.ni@...>
 

Thanks for the update, Nestor, glad to see you got to the bottom of it!

Cheers,
Frank

On Thu, Apr 21, 2016 at 5:45 PM, Macrux <kmacrux@...> wrote:
Hi, its me again, I have resolved this just creating a new topic exchange called "MAMA". That's all. Thanks anyway.

Kind regards,

Nestor.


On 21 April 2016 at 11:21, Macrux <kmacrux@...> wrote:
Hi there,

I'm trying to use the Java Qpid Broker implementation with OpenMAMA 2.4.0. On the web management console of the broker I have created a queue called "test" and I've bound it to the "amqp.topic" exchange (that is there by default). As a binding key I'm using "MAMA.*". When I run the mamapublisherc with:

mamapublisherc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/8c60fd18-07db-11e6-b2bd-d8fc939b9a65 : (null)

And it seems to connect correctly, but when I subscribe a client with:

mamasubscriberc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/b45ca894-07db-11e6-8de4-d8fc939b9a65 : (null)

And although it seems to connect correctly to the broker, it doesn't receive anything.

I haven't modified anything in the mama.properties file, so I have an error in the configuration of the broker, I suppose.

Could anyone please give me a hand with this? Thanks in advance.

Nestor.



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



Gitter vs IRC

Frank Quinn <fquinn.ni@...>
 

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


Re: [Openmama-dev] Gitter vs IRC

Damian Maguire <d.maguire@...>
 

Having toyed with it a bit, as well as many of the alternatives, I think Gitter is a really good option – public, easy to use for new users (beats IRC on that front), enough platform support for regular users to work with, preserves history (again beats IRC default), much more open than Slack etc. Integrations might need some work (CI notifications in the IRC channel are nice for example), but I think we can work around that.

 

So yeah, my vote is go for it (with some sort of plan for deprecating Freenode of course).

 

Cheers,

 

D

 

Damian Maguire

Senior Sales Engineer

Desk (Direct): +4428 9568 0298

 

From: <openmama-dev-bounces@...> on behalf of Frank Quinn <fquinn.ni@...>
Date: Tuesday, May 31, 2016 at 9:05 PM
To: openmama-dev <openmama-dev@...>, "openmama-users@..." <openmama-users@...>
Subject: [Openmama-dev] Gitter vs IRC

 

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


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


Re: [Openmama-dev] 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


OpenMAMA End of Support for Avis

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

I'd like too propose that we stop maintaining the avis bridge for OpenMAMA and that the release which just went out (2.4.1) is the last to support avis, which may then be removed from the code base.

This has already been agreed by the Steering Committee, but I want to put it out there to the users and dev mailing lists to see if there are any further objections, or if anyone would like to step up and take ownership of the bridge (e.g. split out an external OpenMAMA-avis project).

There are several reasons for wanting to retire support for avis:

1. To the best of my knowledge, nobody is using it (we never hear of it on the mailing list any more).
2. Avis itself hasn't been updated in 7 years
3. It's a resource drain on any new functionality we may add for zero return.
4. Even today, doesn't pass all unit tests because the payload doesn't support all OpenMAMA functionality.

It's all about focus - I want to make sure that we spend time focusing on what people are actively using.

If anyone has any sentimental attachment to the avis bridge, please speak up now.

We are currently scheduling the removal of avis from the codebase on 25th July.

Cheers,
Frank


Re: OpenMAMA End of Support for Avis

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

Last call on this - if I hear no word back, it's getting taken out on Monday.

Cheers,
Frank

On Sat, Jul 16, 2016 at 7:18 PM, Frank Quinn <fquinn.ni@...> wrote:
Hi Folks,

I'd like too propose that we stop maintaining the avis bridge for OpenMAMA and that the release which just went out (2.4.1) is the last to support avis, which may then be removed from the code base.

This has already been agreed by the Steering Committee, but I want to put it out there to the users and dev mailing lists to see if there are any further objections, or if anyone would like to step up and take ownership of the bridge (e.g. split out an external OpenMAMA-avis project).

There are several reasons for wanting to retire support for avis:

1. To the best of my knowledge, nobody is using it (we never hear of it on the mailing list any more).
2. Avis itself hasn't been updated in 7 years
3. It's a resource drain on any new functionality we may add for zero return.
4. Even today, doesn't pass all unit tests because the payload doesn't support all OpenMAMA functionality.

It's all about focus - I want to make sure that we spend time focusing on what people are actively using.

If anyone has any sentimental attachment to the avis bridge, please speak up now.

We are currently scheduling the removal of avis from the codebase on 25th July.

Cheers,
Frank


Re: [Openmama-dev] OpenMAMA End of Support for Avis

Frank Quinn <fquinn.ni@...>
 

Cheers Damian,

With that in mind, I just created: https://github.com/OpenMAMA/OpenMAMA-avis including a README explaining the situation.

As I have heard no objections, we'll be be removing avis from the core code and updating the documentation and website etc. over the next week or so.

Cheers,
Frank

On Mon, Jul 25, 2016 at 10:19 AM, Damian Maguire <dmaguire@...> wrote:

For what it's worth, I'm fully supportive of this move, as was everyone I spoke to about it. I think Avis is a distraction for core OpenMAMA that we don't need - the CI work, build system changes, core code changes, unit tests etc all have additional costs when taking Avis into account, and I think it's actually very confusing for end users of the API. 


I do wonder if it would be worth extracting the code to a separate repo anyway, with a deprecation notice - at least it remains visible and available to other users who are interested (and might be an opportunity to firm up the process/framework for non-core bridges). 


Cheers, 


D



DAMIAN MAGUIRE 

Senior Sales Engineer 

 

M. +44 783 584 4770 

 

Adelaide Exchange Building2nd Floor, 24-26 Adelaide StreetBelfast, BT2 8GD  

velatradingtech.com | @vela_tt


1467620971571_PastedImage


From: openmama-dev-bounces@... <openmama-dev-bounces@...> on behalf of Frank Quinn <fquinn.ni@...>
Sent: 22 July 2016 09:35:41
To: openmama-dev; openmama-users@...
Subject: Re: [Openmama-dev] OpenMAMA End of Support for Avis
 
Hi Folks,

Last call on this - if I hear no word back, it's getting taken out on Monday.

Cheers,
Frank

On Sat, Jul 16, 2016 at 7:18 PM, Frank Quinn <fquinn.ni@...> wrote:
Hi Folks,

I'd like too propose that we stop maintaining the avis bridge for OpenMAMA and that the release which just went out (2.4.1) is the last to support avis, which may then be removed from the code base.

This has already been agreed by the Steering Committee, but I want to put it out there to the users and dev mailing lists to see if there are any further objections, or if anyone would like to step up and take ownership of the bridge (e.g. split out an external OpenMAMA-avis project).

There are several reasons for wanting to retire support for avis:

1. To the best of my knowledge, nobody is using it (we never hear of it on the mailing list any more).
2. Avis itself hasn't been updated in 7 years
3. It's a resource drain on any new functionality we may add for zero return.
4. Even today, doesn't pass all unit tests because the payload doesn't support all OpenMAMA functionality.

It's all about focus - I want to make sure that we spend time focusing on what people are actively using.

If anyone has any sentimental attachment to the avis bridge, please speak up now.

We are currently scheduling the removal of avis from the codebase on 25th July.

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. Vela Trading Technologies LLC


Solace OpenMAMA tutorials available

Dmitri Fedorov
 

Hi all,

Solace Systems has started publishing a series of OpenMAMA tutorials, helping developers to adapt OpenMAMA and get a better understanding of proper configuration of the Solace Middleware Bridge for OpenMAMA.

The posts are meant to complement existing OpenMAMA samples and documentation. 

This is the first two posts:

If you have any feedback about these posts and/or wishes for the following posts topics, please don't hesitate to email it to me by replying to this email.

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 6.1.0 En Route

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

In the interest of simplifying version compatibility, OpenMAMA's next release version is going to be 6.1.0. I appreciate it's a big jump but it should make the following things clear to the community and anyone watching the project:
  1. OpenMAMA is the equivalent to Vela's "MAMA 6" (Vela have also agreed to move to 6.1.x to align with OpenMAMA).
  2. Users of both Vela's Enterprise release of MAMA and OpenMAMA can easily see what equivalent versions will be.
  3. Users upgrading from MAMA 5 can have more sane #ifdefs in their code if they're trying to support both versions during migration.
I plan on taking the cut within the next week, so if anyone has any issues that they would like to be included or patches you would like to be included in the next release, please reply to this thread with details.

Cheers,
Frank


Re: [Openmama-dev] OpenMAMA 6.1.0 En Route

Dmitri Fedorov
 

Hi Frank,

This is a cut from the "next" branch, right? The one that was going to be 2.4.2 and planned for the end of summer?

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.

On 29 July 2016 at 14:54, Frank Quinn <fquinn.ni@...> wrote:
Hi Folks,

In the interest of simplifying version compatibility, OpenMAMA's next release version is going to be 6.1.0. I appreciate it's a big jump but it should make the following things clear to the community and anyone watching the project:
  1. OpenMAMA is the equivalent to Vela's "MAMA 6" (Vela have also agreed to move to 6.1.x to align with OpenMAMA).
  2. Users of both Vela's Enterprise release of MAMA and OpenMAMA can easily see what equivalent versions will be.
  3. Users upgrading from MAMA 5 can have more sane #ifdefs in their code if they're trying to support both versions during migration.
I plan on taking the cut within the next week, so if anyone has any issues that they would like to be included or patches you would like to be included in the next release, please reply to this thread with details.

Cheers,
Frank

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



Re: [Openmama-dev] OpenMAMA 6.1.0 En Route

Frank Quinn <fquinn.ni@...>
 

Hi Dmitri,

Yes this is the release that we were going to call 2.4.2 and ideally release at the end of next month.

Cheers,
Frank


On Fri, 29 Jul 2016, 20:19 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hi Frank,

This is a cut from the "next" branch, right? The one that was going to be 2.4.2 and planned for the end of summer?

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.

On 29 July 2016 at 14:54, Frank Quinn <fquinn.ni@...> wrote:
Hi Folks,

In the interest of simplifying version compatibility, OpenMAMA's next release version is going to be 6.1.0. I appreciate it's a big jump but it should make the following things clear to the community and anyone watching the project:
  1. OpenMAMA is the equivalent to Vela's "MAMA 6" (Vela have also agreed to move to 6.1.x to align with OpenMAMA).
  2. Users of both Vela's Enterprise release of MAMA and OpenMAMA can easily see what equivalent versions will be.
  3. Users upgrading from MAMA 5 can have more sane #ifdefs in their code if they're trying to support both versions during migration.
I plan on taking the cut within the next week, so if anyone has any issues that they would like to be included or patches you would like to be included in the next release, please reply to this thread with details.

Cheers,
Frank

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


Solace OpenMAMA Publish/Subscribe tutorial is available

Dmitri Fedorov
 

Hi all,

Solace Systems publishes a series of OpenMAMA tutorials, helping developers to adapt OpenMAMA and get a better understanding of proper configuration of the Solace Middleware Bridge for OpenMAMA.

The posts are meant to complement existing OpenMAMA samples and documentation. 

Publish/Subscribe tutorial has been posted:


If you have any feedback about these posts and/or wishes for the following posts topics, please don't hesitate to email it to me by replying to this email.

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 6.1.0 Released

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

We are pleased to announce the final release of OpenMAMA 6.1.0 is now available:

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.1.0

This mostly a maintenance / bugfix release, but it also jumps the version number from 2.4.1 to 6.1.0. I appreciate it's a big jump but it should make the following things clear to the community and anyone watching the project:

  • OpenMAMA is the equivalent to Vela's "MAMA 6" (Vela have also agreed to move to 6.1.x to align with OpenMAMA).
  • Users of both Vela's Enterprise release of MAMA and OpenMAMA can easily see what equivalent versions will be.
  • Users upgrading from Vela's older MAMA 5 can have more sane #ifdefs in their code if they're trying to support both versions during migration.
Note that bridge has not been changed as part of this release so all bridges and plugins which worked with 2.4.x will also work with 6.1.x.

At a high level, the main new functionality is in the following areas:
  • Removed all known valgrind reported memory leaks from our CI test bed and API
  • Avis now removed (see the mailing list entry)
  • Added Payload and Middleware unit tests on Visual Studio projects
  • Added ability to provide a separate timeout for recaps
  • Fixed issue where book recaps were being ignored duing FT takeover
  • Fixed issue where wildcard subscription OnMsg callback is called with NULL instead of topic
  • Wired up mamamsg vector price and vector datetime field types
  • Qpid support to stop publishing to departed subscribers added
  • Fixed core on startup where no entitlements were defined
  • Fixed race condition deadlock in mamaDispatcher_destroy

For a complete list of all 69 issues and pull requests included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/5?closed=1

As well as new functionality, we have also continued with a few devops changes since the last OpenMAMA Release:
  • New python script in place to do jenkins CI builds
  • Qpid proton build script now modified to include the qpid proton DLL on windows scons builds
  • Modified release generating script to allow binary drops for RC releases
  • Added Fedora 24 RPM and removed Fedora 21 RPM
  • Github landing page has gotten a bit of a facelift including CI status
A special thanks to all developers, contributors and testers who helped is getting this out door.

Cheers,
Frank


New Technical Documentation Resource for OpenMAMA

Frank Quinn <fquinn.ni@...>
 

Hi folks,

As we have discussed before, documentation is something that we are all keen to make improvements upon. With that in mind, I am pleased to announce the launch of our new technical documentation website https://openmama.github.io.

There's not much there at the moment that doesn't already exist, but going forward, it should be considered the new home for:

- Reference documentation
- Application Developer Guides
- Bridge Developer Guides
- Plugin Developer guides
- Tutorials
- Example Code walkthroughs
- RFCs
- Any other technical documentation (e.g. contents of current wiki)

In the coming months, we'll be aggregating all existing technical documentation to this website and building out additional content as we go. We'll also be updating links etc.

You are all encouraged to get involved - anyone can pull down the git repository behind this site (https://github.com/OpenMAMA/openmama.github.io) and run it locally using instructions provided in the Contribute section or make minor changes (e.g. to RFCs) using the Edit functionality to participate.

If you have any problems, drop in on our Gitter channel and let us know.

Cheers,
Frank


OpenMAMA-6.2.0-rc1 Now Available

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

We are pleased to announce the first release candidate for OpenMAMA 6.2.0 is now available including binary releases:

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

This release bumps the version of OpenMAMA up to 6.2.0 due to recent MAMA Payload changes which could potentially break the bridge for payload bridges which treat mamaDateTime as a U64 pointer and attempt direct access. See the RFC on the change for for more details.

Payload bridge developers in particular are encouraged to rigorously test their bridges with this release.

Key changes and bugfixes included in this release:

  • New extended MamaDateTime changes to support date ranges beyond the 2038 problem
  • Added thread pinning for process thread affinity
  • Performance improvements made for mamaDqPublisher_send
  • Fixed transient access violation issues in windows when using wtimegm
  • New MAMA methods for looking up middleware and payload bridges
  • Performance improvements to mamaproducerc_v2
  • Added new document generating script for updating openmama.github.io
  • Added new helper method for finding a file in a delimited path (e.g. PATH or WOMBAT_PATH)
  • Added new helper method for loading in a MAMA format symbol file in a standard way

For a complete list of all 22 issues and pull requests included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/6?closed=1

Cheers,
Frank

181 - 200 of 232