1. Openmama-dev@lists.openmama.org
  2. Messages
   Date   
Re: OpenMAMA and Enterprise Mama

Glenn McClements <g.mcclements@...>
 

Issues around the entitlements were brought up on the OpenMAMA Steering Committee call yesterday, so we’ll be discussing it in the next Technical Committee meeting and get a plan together. 

Glenn 

From: Gary Molloy <g.molloy@...>
Date: Friday, 16 January 2015 11:26
To: "Alpert, Reed" <reed.alpert@...>, "openmama-dev@..." <openmama-dev@...>
Subject: Re: [Openmama-dev] OpenMAMA and Enterprise Mama

Hi Reed,

 

Thanks for your email, sorry for the delay in reply. 

 

I think you have touched upon 2 items here:

1.       When /are there any plans for Enterprise MAMA and OpenMAMA to come into sync?

2.       Is it possible for have multiple entitlements bridges?

 

To answer your first question. 

We have made a concerted effort over the last 6 months to bring these into sync and have made substantial progress with this.

With the latest release of OpenMAMA Enterprise Edition, 6.0.3f, there are very few differences with the current OpenMAMA RC 2.3.2 rc1 and we will continue to keep these in line going forwarded with regular synced up releases.

 

To answer your second question, MAMA is currently only built to handle 1 set of entitlements. 

If we were to extend this to cover 3 (or more) bridges we would need to consider a few things:

·         We would need to be able to tie entitlements with a particular topic or source (most likely the source?) – currently we only have 1 set of global entitlements options so the properties would need extended (or re-thought).

·         Would every source have to have entitlements enabled?  How can we enforce entitlements for 1 bridge and not another?

·         We need to be careful in this area for compliance reasons.

·         Seems like we would need the entitlement bridging first, and then the ability to specify entitlement bridges for a source.

 

Thanks,

Gary

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed
Sent: 15 December 2014 21:21
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA and Enterprise Mama

 

Hi,

 

What is the plan for OM and EM?

The entitlements in EM are not available in OM, and it looks like turning on entitlements in mama layer is for all of the loaded bridges.

Are patches to OM made available in EM (and vice-versa) – how long does the dev cycle take for that?

 

Our concern is that we run 3 bridges : wombat, tick42/rmds, and solace.

For entitlements we use dart for wombat (our DF5/6/mamacache env), and dacs for tick42/rmds and solace.

We’d like to run OM for all of this (or EM if that is the best way to go).

 

Thanks,

 

Reed.

 

Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198  | M: 917.414.4613 | reed.alpert@...

 

Alternate Contact:  CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

Re: OpenMAMA and Enterprise Mama

Gary Molloy <g.molloy@...>
 

Hi Reed,

 

Thanks for your email, sorry for the delay in reply. 

 

I think you have touched upon 2 items here:

1.       When /are there any plans for Enterprise MAMA and OpenMAMA to come into sync?

2.       Is it possible for have multiple entitlements bridges?

 

To answer your first question. 

We have made a concerted effort over the last 6 months to bring these into sync and have made substantial progress with this.

With the latest release of OpenMAMA Enterprise Edition, 6.0.3f, there are very few differences with the current OpenMAMA RC 2.3.2 rc1 and we will continue to keep these in line going forwarded with regular synced up releases.

 

To answer your second question, MAMA is currently only built to handle 1 set of entitlements. 

If we were to extend this to cover 3 (or more) bridges we would need to consider a few things:

·         We would need to be able to tie entitlements with a particular topic or source (most likely the source?) – currently we only have 1 set of global entitlements options so the properties would need extended (or re-thought).

·         Would every source have to have entitlements enabled?  How can we enforce entitlements for 1 bridge and not another?

·         We need to be careful in this area for compliance reasons.

·         Seems like we would need the entitlement bridging first, and then the ability to specify entitlement bridges for a source.

 

Thanks,

Gary

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed
Sent: 15 December 2014 21:21
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA and Enterprise Mama

 

Hi,

 

What is the plan for OM and EM?

The entitlements in EM are not available in OM, and it looks like turning on entitlements in mama layer is for all of the loaded bridges.

Are patches to OM made available in EM (and vice-versa) – how long does the dev cycle take for that?

 

Our concern is that we run 3 bridges : wombat, tick42/rmds, and solace.

For entitlements we use dart for wombat (our DF5/6/mamacache env), and dacs for tick42/rmds and solace.

We’d like to run OM for all of this (or EM if that is the best way to go).

 

Thanks,

 

Reed.

 

Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198  | M: 917.414.4613 | reed.alpert@...

 

Alternate Contact:  CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

Transport callbacks when a middleware bridge automatically reconnects a transport

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Hi Folks,

 

Some middleware bridges may have the capability to automatically reconnect to their messaging infrastructure after a connection failure, for example at the TCP/socket layer. In OpenMAMA C layer, there is the mamaTransportCB and the mamaTransportEvent enum to allow notification about different transport conditions from the middleware bridge to OpenMAMA layer and to the application. In MAMA C++, there is MamaTransportCallback which provides similar notification for a C++ application, for example using onConnect, onDisconnect, onReconnect, and onQuality. There are similar notification mechanisms for the application for other OpenMAMA supported language bindings such as Java and C#.

 

I was looking at what would be a commonly expected and accepted behaviour when the middleware bridge automatically reconnects the connection and was hoping to get your input.

 

Consider the case that a middleware bridge notices a connection failure on a previously established connection. The middleware bridge that is capable of automatically reconnecting then automatically starts a retry mechanism for a predefined number of attempts and may eventually either succeed or fail to reestablish the connection. A middleware that is not capable of automatically reconnecting would provide a disconnect event to the application.

 

For this scenario there are several conceivable options for the middleware bridge and OpenMAMA to provide notifications to the application:

 

One option is the following:

(a)    When connection is lost, provide a MAMA_TRANSPORT_QUALITY event.

(b)   If the connection is successfully reestablished, at the time it is reestablished, provide MAMA_TRANSPORT_RECONNECT event.

(c)    If all reconnect attempts fail, at the time of the last reconnect failure, provide a MAMA_TRANSPORT_DISCONNECT.

 

Another option is that for condition (a),  provide a MAMA_TRANSPORT_DISCONNECT event (instead  of MAMA_TRANSPORT_QUALITY).

 

Yet another option is that for condition (b), provide a MAMA_TRANSPORT_QUALITY event (instead of MAMA_TRANSPORT_RECONNECT). For this option (a) and (b) are differentiated by the application using different values for ‘cause’ in the callback and transport quality is changed accordingly.

 

Here are the above three options summarized using the C++ callback names as shorthand. There are other options, but I think these three illustrate the flexibility / interpretation and the need for elaborating in this area.

 

Option (1):          (a) onQuality(cause=1)                  (b) onReconnect

Option (2):          (a) onDisconnect                              (b) onReconnect

Option (3):          (a) onQuality(cause=1)                  (b) onQuality(cause=0)

 

For option (1) there may also be an onQuality(cause=0) after  the connection is reestablished if the transport has a marketdata subscription with recover gaps and new messaging arrive do not have gaps.

 

We had initially been thinking about implementing option (1) in the Solace OpenMAMA Middleware Bridge. One concern we had with using option (2) was that the onDisconnect may result in a typical application itself to clean up the transport and possibly take transport reconnect actions rather than allowing a middleware (that is capable of doing the automatic reconnect) to perform its reconnect attempts.

 

Another option is enhance the transport callback. For example, to provide a onReconnecting callback when a connection is lost and the middleware is in the state of “reconnecting” the lost connection. However, adding a new callback would require a new OpenMAMA version and may be a longer term possibility to think about.

 

It is valuable to provide a consistent and clear behaviour to the applications in this area, specially across different middleware bridge types. What is the expected behaviour and design of OpenMAMA for these notifications and what do other bridges do in these cases?

 

Regards,

 

--Alireza
[PATCH 2.3.2rc1] COMMON: Darwin port Update for Yosemite

Philip Preston
 

Mac OSX 10.10 introduces htonll and ntohll macros in system headers, and as such we get redefine errors when compiling. Changed port.h to only define thefunctions if below Mac OSX 10.10.

Also added 10.10 to the available mac os x versions in scons

Signed-off-by: Phil Preston <philippreston@...>
---
common/c_cpp/src/c/darwin/port.h | 3 +++
site_scons/community/command_line.py | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/common/c_cpp/src/c/darwin/port.h b/common/c_cpp/src/c/darwin/port.h
index c2458ad..3a56cb4 100644
--- a/common/c_cpp/src/c/darwin/port.h
+++ b/common/c_cpp/src/c/darwin/port.h
@@ -45,6 +45,7 @@
#include <inttypes.h>
#include <pwd.h>
#include <stdlib.h>
+#include <AvailabilityMacros.h>

#include "wConfig.h"

@@ -66,6 +67,7 @@ typedef void* LIB_HANDLE;
#define LIB_EXTENSION ".dylib"

/* Network conversion function */
+#if MAC_OS_X_VERSION_MAX_ALLOWED <= MAC_OS_X_VERSION_10_9
#if __BYTE_ORDER == __LITTLE_ENDIAN
#define htonll(x) \
((uint64_t)htonl((uint32_t)((x)>>32)) | (uint64_t)htonl((uint32_t)(x))<<32)
@@ -75,6 +77,7 @@ typedef void* LIB_HANDLE;
#define htonll(x) ((uint64_t)(x))
#define ntohll(x) ((uint64_t)(x))
#endif
+#endif

/* For delimiting multiple paths in env variables properties */
#define PATH_DELIM ':'
diff --git a/site_scons/community/command_line.py b/site_scons/community/command_line.py
index e1791e2..606e448 100644
--- a/site_scons/community/command_line.py
+++ b/site_scons/community/command_line.py
@@ -79,7 +79,7 @@ def get_command_line_opts( host, products, VERSIONS ):
EnumVariable( 'compiler', 'Compiler to use for building OpenMAMA',
'default', allowed_values=('default', 'clang', 'clang-analyzer')),
EnumVariable('osx_version', 'OS X Version to target build at', 'current',
- allowed_values=('current','10.8','10.9')),
+ allowed_values=('current','10.8','10.9','10.10')),
)

return opts
--
1.9.3 (Apple Git-50)

?
0001-COMMON-Darwin-port-Update-for-Yosemite.patch

Re: OpenMAMA-2.3.2-rc1

Lee Skillen <lskillen@...>
 

Hi Gary,

Have you tried looking into an alternative tool for building binary
distributions?

We use FPM with great success internally (humourously entitled F'ing
Package Manager, no doubt because packages are a joy to work with).

Introduction: http://www.semicomplete.com/blog/geekery/fpm.html
GitHub: https://github.com/jordansissel/fpm

It's capable of turning gem (ruby), pypi (python), pear (php),
directories and tarballs into deb/rpm (and more) packages.

Basic usage is to build from source and install into a different
prefix that represents the relative install root (e.g.
prefix=/tmp/openmama/usr/local).

Then you can do something like: fpm -s dir -t rpm -n openmama -v
2.3.2-rc1 -d libuuid-devel --iteration 1 --description "OpenMAMA
2.3.2-rc1" -C /tmp/openmama .

Which should generate an rpm such as: openmama-2.3.2_rc1-1.x86_64.rpm

There's a ton of other options that might be useful and are worth
looking into. Good luck!

As for the RC itself - We don't specifically utilise RCs but we do
utilise the next branch. If any issues crop up we'll let you know.

Cheers,
Lee

On 14 January 2015 at 16:58, Gary Molloy <g.molloy@...> wrote:
Hi Guys,



It’s looking like a fix for the RPM stuff might take a little while longer,
so in the interim I’d like to get started with testing of the RC. If you’re
interested and happy to get testing, either building yourself or with a
binary release, can you drop me a email.



Depending on the availability of testers, we’ll look at reviewing the status
the week of the 26th, and decide then if we’re going to require a second RC.



Thanks,

Gary





Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...



From: Gary Molloy
Sent: 08 January 2015 11:56
To: openmama-dev@...
Subject: RE: OpenMAMA-2.3.2-rc1



Hi Guys,



I have cut the new OpenMAMA-2.3.2 branch and created the OpenMAMA-2.3.2-rc1
tag, and this is currently available for testing.



The RPM’s will be delayed unfortunately. It seems that the Fedora
repository has updated the default version of proton, to 0.8, and this
doesn’t contain the “proton/util.h” header file anymore. This is causing
the mock RPM’s to fail as we look for this include file in a few places. I
don’t believe that we actually use any of the functions that were in the
util.h header, but I will investigate this further, correct it and get the
RPMs out as soon as possible.



Thanks,

Gary







Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...



From: Gary Molloy
Sent: 06 January 2015 13:57
To: openmama-dev@...
Subject: OpenMAMA-2.3.2-rc1



Hi Guys,



I will be cutting RC1 for the next release, 2.3.2, this afternoon.



This will contain a handful of minor issues, unit tests updates, enterprise
issues etc…



If there are any issues in particular you would like to see included in the
next release, please feel free to reply and we can review any issue for
inclusion.



Thanks,

Gary



Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...




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

Vulcan Financial Technologies
1st Floor, 47 Malone Road, Belfast, BT9 6RY

Office: +44 (0)28 95 817888
Web: www.vulcanft.com
Re: OpenMAMA-2.3.2-rc1

Gary Molloy <g.molloy@...>
 

Hi Guys,

 

It’s looking like a fix for the RPM stuff might take a little while longer, so in the interim I’d like to get started with testing of the RC.  If you’re interested and happy to get testing, either building yourself or with a binary release, can you drop me a email. 

 

Depending on the availability of testers, we’ll look at reviewing the status the week of the 26th, and decide then if we’re going to require a second RC.

 

Thanks,

Gary

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 

From: Gary Molloy
Sent: 08 January 2015 11:56
To: openmama-dev@...
Subject: RE: OpenMAMA-2.3.2-rc1

 

Hi Guys,

 

I have cut the new OpenMAMA-2.3.2 branch and created the OpenMAMA-2.3.2-rc1 tag, and this is currently available for testing.

 

The RPM’s will be delayed unfortunately.  It seems that the Fedora repository has updated the default version of proton, to 0.8, and this doesn’t contain the “proton/util.h” header file anymore.  This is causing the mock RPM’s to fail as we look for this include file in a few places.  I don’t believe that we actually use any of the functions that were in the util.h header, but I will investigate this further, correct it and get the RPMs out as soon as possible.

 

Thanks,

Gary

 

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 

From: Gary Molloy
Sent: 06 January 2015 13:57
To: openmama-dev@...
Subject: OpenMAMA-2.3.2-rc1

 

Hi Guys,

 

I will be cutting RC1 for the next release, 2.3.2, this afternoon.

 

This will contain a handful of minor issues, unit tests updates, enterprise issues etc…

 

If there are any issues in particular you would like to see included in the next release, please feel free to reply and we can review any issue for inclusion.

 

Thanks,

Gary

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 
Re: OpenMAMA-2.3.2-rc1

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Gary,

 

Is it possible to include the fix for the following issues in the 2.3.2? There is a patch available for each of these.

 

Bug 176 - MAMAC: Missing actions for snapshot subscriptions transition to deactivate state

Bug 169 - Wombat queue has no separate deallocate method

Bug 166 - Wombat: wInterlocked_set inconsistent return value

 

Thanks.

 

--Alireza

 

From: Gary Molloy [mailto:g.molloy@...]
Sent: Tuesday, January 06, 2015 10:02 AM
To: Alireza Assadzadeh
Cc: openmama-dev@...
Subject: RE: OpenMAMA-2.3.2-rc1

 

Hi Alireza,

 

Yes, it will include the current contents of the next branch.

 

Thanks,

Gary

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 

From: Alireza Assadzadeh [mailto:Alireza.Assadzadeh@...]
Sent: 06 January 2015 14:10
To: Gary Molloy; openmama-dev@...
Subject: RE: OpenMAMA-2.3.2-rc1

 

Hi Gary,

 

Is the current content of ‘next’ branch what you had in mind for the 2.3.2 release?

 

Regards,

 

--Alireza

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Gary Molloy
Sent: Tuesday, January 06, 2015 8:57 AM
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA-2.3.2-rc1

 

Hi Guys,

 

I will be cutting RC1 for the next release, 2.3.2, this afternoon.

 

This will contain a handful of minor issues, unit tests updates, enterprise issues etc…

 

If there are any issues in particular you would like to see included in the next release, please feel free to reply and we can review any issue for inclusion.

 

Thanks,

Gary

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 
Re: OpenMAMA-2.3.2-rc1

Gary Molloy <g.molloy@...>
 

Hi Guys,

 

I have cut the new OpenMAMA-2.3.2 branch and created the OpenMAMA-2.3.2-rc1 tag, and this is currently available for testing.

 

The RPM’s will be delayed unfortunately.  It seems that the Fedora repository has updated the default version of proton, to 0.8, and this doesn’t contain the “proton/util.h” header file anymore.  This is causing the mock RPM’s to fail as we look for this include file in a few places.  I don’t believe that we actually use any of the functions that were in the util.h header, but I will investigate this further, correct it and get the RPMs out as soon as possible.

 

Thanks,

Gary

 

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 

From: Gary Molloy
Sent: 06 January 2015 13:57
To: openmama-dev@...
Subject: OpenMAMA-2.3.2-rc1

 

Hi Guys,

 

I will be cutting RC1 for the next release, 2.3.2, this afternoon.

 

This will contain a handful of minor issues, unit tests updates, enterprise issues etc…

 

If there are any issues in particular you would like to see included in the next release, please feel free to reply and we can review any issue for inclusion.

 

Thanks,

Gary

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 
Re: OpenMAMA-2.3.2-rc1

Gary Molloy <g.molloy@...>
 

Hi Alireza,

 

Yes, it will include the current contents of the next branch.

 

Thanks,

Gary

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 

From: Alireza Assadzadeh [mailto:Alireza.Assadzadeh@...]
Sent: 06 January 2015 14:10
To: Gary Molloy; openmama-dev@...
Subject: RE: OpenMAMA-2.3.2-rc1

 

Hi Gary,

 

Is the current content of ‘next’ branch what you had in mind for the 2.3.2 release?

 

Regards,

 

--Alireza

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Gary Molloy
Sent: Tuesday, January 06, 2015 8:57 AM
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA-2.3.2-rc1

 

Hi Guys,

 

I will be cutting RC1 for the next release, 2.3.2, this afternoon.

 

This will contain a handful of minor issues, unit tests updates, enterprise issues etc…

 

If there are any issues in particular you would like to see included in the next release, please feel free to reply and we can review any issue for inclusion.

 

Thanks,

Gary

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 
Re: OpenMAMA-2.3.2-rc1

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Hi Gary,

 

Is the current content of ‘next’ branch what you had in mind for the 2.3.2 release?

 

Regards,

 

--Alireza

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Gary Molloy
Sent: Tuesday, January 06, 2015 8:57 AM
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA-2.3.2-rc1

 

Hi Guys,

 

I will be cutting RC1 for the next release, 2.3.2, this afternoon.

 

This will contain a handful of minor issues, unit tests updates, enterprise issues etc…

 

If there are any issues in particular you would like to see included in the next release, please feel free to reply and we can review any issue for inclusion.

 

Thanks,

Gary

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 
OpenMAMA-2.3.2-rc1

Gary Molloy <g.molloy@...>
 

Hi Guys,

 

I will be cutting RC1 for the next release, 2.3.2, this afternoon.

 

This will contain a handful of minor issues, unit tests updates, enterprise issues etc…

 

If there are any issues in particular you would like to see included in the next release, please feel free to reply and we can review any issue for inclusion.

 

Thanks,

Gary

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

g.molloy@...

 
[PATCH 2.3.1 1/1] TESTTOOLS: capturereplayc does not need to send reply when the received mama subscription request is not from inbox.

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

If subscription message is not from inbox, then there is no need to
publish the initial image when processing onNewRequest or onRequest.
For example, in the case of a real time market data subscription that
has disabled the receipt of initial image.

Test Plan:
- Checked with capturereplayc and mamalistenc.
- Used qpid middleware bridge for regression testing.
- Used solace middleware bridge for the case of real time market
data subscription with receipt of initial image disabled.

Signed-off-by: Alireza Assadzadeh <Alireza.Assadzadeh@...>
---

The patches are against 'next' branch. They are tested by using sample and
testtool programs: capturereplayc and mamalistenc.

.../src/testtools/capturereplay/c/capturereplayc.c | 26 +++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c b/mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c
index e4b1ed0..c420384 100644
--- a/mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c
+++ b/mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c
@@ -478,8 +478,16 @@ subscriptionHandlerOnNewRequestCb (mamaDQPublisherManager manager,
MamaFieldMsgType.mFid,
MAMA_MSG_TYPE_INITIAL);
}
- mamaDQPublisher_sendReply (gSubscriptionList[index].pub, msg,
- gSubscriptionList[index].cachedMsg);
+ /* If subscription message is from inbox, then send reply to inbox.
+ * Otherwise, there is no need to publish the initial image. For
+ * example, in the case of a real time market data subscription that
+ * has disabled the receipt of initial image.
+ */
+ if (mamaMsg_isFromInbox (msg))
+ {
+ mamaDQPublisher_sendReply (gSubscriptionList[index].pub, msg,
+ gSubscriptionList[index].cachedMsg);
+ }
break;
default:
mama_log (MAMA_LOG_LEVEL_NORMAL, "Publishing MAMA_MSG_TYPE_RECAP");
@@ -529,9 +537,17 @@ subscriptionHandlerOnRequestCb (mamaDQPublisherManager manager,
MamaFieldMsgType.mFid,
MAMA_MSG_TYPE_INITIAL);
}
- mamaDQPublisher_sendReply (gSubscriptionList[index].pub,
- msg,
- gSubscriptionList[index].cachedMsg);
+ /* If subscription message is from inbox, then send reply to inbox.
+ * Otherwise, there is no need to publish the initial image. For
+ * example, in the case of a real time market data subscription that
+ * has disabled the receipt of initial image.
+ */
+ if (mamaMsg_isFromInbox (msg))
+ {
+ mamaDQPublisher_sendReply (gSubscriptionList[index].pub,
+ msg,
+ gSubscriptionList[index].cachedMsg);
+ }
break;
case MAMA_SUBSC_DQ_SUBSCRIBER:
case MAMA_SUBSC_DQ_PUBLISHER:
--
1.9.3

?
0001-TESTTOOLS-capturereplayc-does-not-need-to-send-reply.patch

[PATCH 2.3.1 1/1] MAMAC: Missing actions for snapshot subscriptions transition to deactivate state

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

For snapshot subscriptions, there is no bridge subscription callback
to be called later with mamaSubscriptionImpl_onSubscriptionDestroyed.
Therefore, add code to perform the additional actions for deactivated
state in mamaSubscription_deactivate. Namely, add code to decrement
the queue object count.

Test Plan:
- Check with capturereplayc and mamalistenc using -shutdown option.
Use mama.properties: mama.queue.object_lock_tracking=1 and
mama.logging.level=finest.
- Build and run unit tests (UnitTestCommon*, UnitTestsMama*).

Signed-off-by: Alireza Assadzadeh <Alireza.Assadzadeh@...>
---

I have raised bug http://bugs.openmama.org/show_bug.cgi?id=176 to track
this issue and attached the patches to the bug.

The patches are against 'next' branch. They are tested by using gunittests,
and sample programs (capturereplayc, mamalistenc and bookticker).

Before this fix the problem is observable when calling mama_close after
earlier having created and destroyed a snapshot subscription (either
dictionary snapshot normal/book snapshot subscription). The mamaQueue_destory
for default queue times out since there are left over open objects in the queue
due to the missing call to mamaQueue_decrementObjectCount.
For example, using the mamalistenc with -shutdown option with qpid, the mama_close
takes 5 seconds to complete with the following finest log "Entering
mamaQueue_destroy for queue 0x<pointer>" repeated every 10ms (500 times) and
finally timing out with log "mamaQueue_destroy(): timed out destroying queue.".

mama/c_cpp/src/c/subscription.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

diff --git a/mama/c_cpp/src/c/subscription.c b/mama/c_cpp/src/c/subscription.c
index c809257..1f78746 100644
--- a/mama/c_cpp/src/c/subscription.c
+++ b/mama/c_cpp/src/c/subscription.c
@@ -2616,7 +2616,19 @@ mama_status mamaSubscription_deactivate(mamaSubscription subscription)
ret = mamaSubscription_deactivate_internal(impl);
if (impl->mSubscMsgType == MAMA_SUBSC_DDICT_SNAPSHOT ||
impl->mSubscMsgType == MAMA_SUBSC_SNAPSHOT)
+ {
+ /* Snapshot subscriptions don't have a bridge and are transitioned to deactivated
+ * immediately after deactivating.
+ * Also, since there is no bridge subscription callback to be called later with
+ * mamaSubscriptionImpl_onSubscriptionDestroyed, the necessary actions for deactivated
+ * state are performed here. Namely the queue object count is decremented.
+ */
+ if(NULL != impl->mQueue)
+ {
+ mamaQueue_decrementObjectCount(&impl->mLockHandle, impl->mQueue);
+ }
mamaSubscriptionImpl_setState(impl, MAMA_SUBSCRIPTION_DEACTIVATED);
+ }
break;

case MAMA_SUBSCRIPTION_DEACTIVATING:
--
1.9.3

?
0001-MAMAC-Missing-actions-for-snapshot-subscriptions-tra.patch

Re: OpenMAMA and Enterprise Mama

Lee Skillen <lskillen@...>
 

Quick addendum ...

If you can't access Google Docs (seems to be banned everywhere), I've
also prepared a "document pack" zip-file with all of the
aforementioned docs. Available at the following URI :-

http://static.vulcanft.com/prod/files/openmama_librarymanager.zip

On 15 December 2014 at 22:19, Lee Skillen <lskillen@...> wrote:
Hi Reed,

I'm not sure about the current ongoings/plans with OpenMAMA or
EnterpriseMAMA but VFT released a draft for an extensible library
manager earlier this year.

We also have an unreleased draft of an entitlement manager based upon
the draft library manager work which is incomplete but in a usable
state.

The GitHub branch and some documentation for the library manager :-

1. Library Manager Branch :- feature-librarymanager
2. First Draft (0.1) :-
https://docs.google.com/document/d/1sg2i84NnhJO90z8DECYeGf799wDUzY4B_uXNsCpFuac/edit?usp=sharing
3. Second Draft (0.2) :-
https://docs.google.com/document/d/1ZLZjpiu3A7MPNauOQWLFKVxnoR6jdAp3Vas91PqWhnY/edit?usp=sharing
4. Developer Docs (Incomplete) :-
https://docs.google.com/document/d/10Y9ebCeCDPeBrVgaqE4MrcOc6zgittJGVchMSO2lKrs/edit?usp=sharing

The GitHub branch and some documentation for the entitlement manager :-

1. Entitlement Bridge Branch :- feature-entitlementbridge
2. Brief Overview :-
https://docs.google.com/document/d/1Nw_TetxADez5PR1COaOBhbkQhQcdc0BgH7HEnfQyBjI/edit?usp=sharing

It doesn't support it atm but it wouldn't be difficult to extend the
entitlement bridge code to apply different bridges to different
transports.

Unfortunately the projects have stalled for the moment but we'd be
happy to pick it back up again if some momentum is gained.

We'd love to hear any feedback about any aspects of the proposed code
- We'd also accept patches, pull requests and issues.

If you have any problems viewing any of the documents I could also
render them as PDF and send them out separately.

Cheers,
Lee

On 15 December 2014 at 21:21, Alpert, Reed <reed.alpert@...> wrote:
Hi,



What is the plan for OM and EM?

The entitlements in EM are not available in OM, and it looks like turning on
entitlements in mama layer is for all of the loaded bridges.

Are patches to OM made available in EM (and vice-versa) – how long does the
dev cycle take for that?



Our concern is that we run 3 bridges : wombat, tick42/rmds, and solace.

For entitlements we use dart for wombat (our DF5/6/mamacache env), and dacs
for tick42/rmds and solace.

We’d like to run OM for all of this (or EM if that is the best way to go).



Thanks,



Reed.



________________________________

Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P.
Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T:
718.242.5198 | M: 917.414.4613 | reed.alpert@...



Alternate Contact: CIB PIM Trading Technology Solutions NA |
CIB_PIM_Trading_Technology_Solutions_NA@...



This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market
prices, data and other information are not warranted as to completeness or
accuracy and are subject to change without notice. Any comments or
statements made herein do not necessarily reflect those of JPMorgan Chase &
Co., its subsidiaries and affiliates. This transmission may contain
information that is proprietary, privileged, confidential and/or exempt from
disclosure under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or use of
the information contained herein (including any reliance thereon) is
STRICTLY PROHIBITED. Although this transmission and any attachments are
believed to be free of any virus or other defect that might affect any
computer system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and no
responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and
affiliates, as applicable, for any loss or damage arising in any way from
its use. If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety, whether in
electronic or hard copy format. Thank you. Please refer to
http://www.jpmorgan.com/pages/disclosures for disclosures relating to
European legal entities.


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


--
Lee Skillen

Vulcan Financial Technologies
1st Floor, 47 Malone Road, Belfast, BT9 6RY

Office: +44 (0)28 95 817888
Web: www.vulcanft.com
--
Lee Skillen

Vulcan Financial Technologies
1st Floor, 47 Malone Road, Belfast, BT9 6RY

Office: +44 (0)28 95 817888
Web: www.vulcanft.com
Re: OpenMAMA and Enterprise Mama

Lee Skillen <lskillen@...>
 

Hi Reed,

I'm not sure about the current ongoings/plans with OpenMAMA or
EnterpriseMAMA but VFT released a draft for an extensible library
manager earlier this year.

We also have an unreleased draft of an entitlement manager based upon
the draft library manager work which is incomplete but in a usable
state.

The GitHub branch and some documentation for the library manager :-

1. Library Manager Branch :- feature-librarymanager
2. First Draft (0.1) :-
https://docs.google.com/document/d/1sg2i84NnhJO90z8DECYeGf799wDUzY4B_uXNsCpFuac/edit?usp=sharing
3. Second Draft (0.2) :-
https://docs.google.com/document/d/1ZLZjpiu3A7MPNauOQWLFKVxnoR6jdAp3Vas91PqWhnY/edit?usp=sharing
4. Developer Docs (Incomplete) :-
https://docs.google.com/document/d/10Y9ebCeCDPeBrVgaqE4MrcOc6zgittJGVchMSO2lKrs/edit?usp=sharing

The GitHub branch and some documentation for the entitlement manager :-

1. Entitlement Bridge Branch :- feature-entitlementbridge
2. Brief Overview :-
https://docs.google.com/document/d/1Nw_TetxADez5PR1COaOBhbkQhQcdc0BgH7HEnfQyBjI/edit?usp=sharing

It doesn't support it atm but it wouldn't be difficult to extend the
entitlement bridge code to apply different bridges to different
transports.

Unfortunately the projects have stalled for the moment but we'd be
happy to pick it back up again if some momentum is gained.

We'd love to hear any feedback about any aspects of the proposed code
- We'd also accept patches, pull requests and issues.

If you have any problems viewing any of the documents I could also
render them as PDF and send them out separately.

Cheers,
Lee

On 15 December 2014 at 21:21, Alpert, Reed <reed.alpert@...> wrote:
Hi,



What is the plan for OM and EM?

The entitlements in EM are not available in OM, and it looks like turning on
entitlements in mama layer is for all of the loaded bridges.

Are patches to OM made available in EM (and vice-versa) – how long does the
dev cycle take for that?



Our concern is that we run 3 bridges : wombat, tick42/rmds, and solace.

For entitlements we use dart for wombat (our DF5/6/mamacache env), and dacs
for tick42/rmds and solace.

We’d like to run OM for all of this (or EM if that is the best way to go).



Thanks,



Reed.



________________________________

Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P.
Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T:
718.242.5198 | M: 917.414.4613 | reed.alpert@...



Alternate Contact: CIB PIM Trading Technology Solutions NA |
CIB_PIM_Trading_Technology_Solutions_NA@...



This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market
prices, data and other information are not warranted as to completeness or
accuracy and are subject to change without notice. Any comments or
statements made herein do not necessarily reflect those of JPMorgan Chase &
Co., its subsidiaries and affiliates. This transmission may contain
information that is proprietary, privileged, confidential and/or exempt from
disclosure under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or use of
the information contained herein (including any reliance thereon) is
STRICTLY PROHIBITED. Although this transmission and any attachments are
believed to be free of any virus or other defect that might affect any
computer system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and no
responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and
affiliates, as applicable, for any loss or damage arising in any way from
its use. If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety, whether in
electronic or hard copy format. Thank you. Please refer to
http://www.jpmorgan.com/pages/disclosures for disclosures relating to
European legal entities.


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

Vulcan Financial Technologies
1st Floor, 47 Malone Road, Belfast, BT9 6RY

Office: +44 (0)28 95 817888
Web: www.vulcanft.com
OpenMAMA and Enterprise Mama

Alpert, Reed <reed.alpert@...>
 

Hi,

 

What is the plan for OM and EM?

The entitlements in EM are not available in OM, and it looks like turning on entitlements in mama layer is for all of the loaded bridges.

Are patches to OM made available in EM (and vice-versa) – how long does the dev cycle take for that?

 

Our concern is that we run 3 bridges : wombat, tick42/rmds, and solace.

For entitlements we use dart for wombat (our DF5/6/mamacache env), and dacs for tick42/rmds and solace.

We’d like to run OM for all of this (or EM if that is the best way to go).

 

Thanks,

 

Reed.

 

Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198  | M: 917.414.4613 | reed.alpert@...

 

Alternate Contact:  CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

Re: Error handling in market data subscription activation and error notification to application

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Hi Gary,

 

Thanks a lot for your response on this. Your suggestions sound good.

 

Please see my comments to your mail inline marked with [AA:].

 

--Alireza

 

From: Gary Molloy [mailto:g.molloy@...]
Sent: Friday, December 12, 2014 12:50 PM
To: Alireza Assadzadeh; openmama-dev@...
Subject: RE: [Openmama-dev] Error handling in market data subscription activation and error notification to application

 

Hi Alireza,

 

Thanks for your email.

 

I think that you have touched upon 2 issues here:

 

1.       Synchronous Fails – if the create fails within the mamaSubscription_initialize() function it should be handled at this point.  We should probably add in a return code and check what is being passed back from the call to self->mBridgeImpl->bridgeMamaSubscriptionCreate() where we could then invoked the onError() callback and stop the creation of the subscription continuing (and prevent onCreate() from being invoked).  Some things that may need consideration:

a.       Return codes – would the common set of MAMA return codes cover this or would they require expanding?

 

[AA:] For the MW Bridge error conditions, I think the MAMA_STATUS_PLATFORM_ERROR in conjunction with mamaSubscription_getPlatformError should be fine. I think we need to check any additional error cases that are not from the MW-Bridge and see if the existing codes properly cover the failure case. Overall, there may be value in providing more specific or additional mama_status codes.

 

b.      Threading - this will cause the onError() to be invoked from the default thread as opposed to the subscription thread.  However this may not be a problem as the subscription will not be active…

 

[AA:] This seems ok to me, since also the onCreate() was called from the same thread and also subscription is not active (as you pointed out).

 

2.       Asynchronous Fails – I agree with you that mamaSubscription_processErr() is the correct function to use here.  We have used this previously for in-house bridges for the same scenario.  There is a transport function, mamaTransport_getDeactivateSubscriptionOnError(), that can be used to determine whether or not to deactivate the subscription on an error.  A few additional things to consider also:

a.       These events must be fired from the correct queue by the middleware bridge.

b.      There is an issue with the mamaSubscription_processErr() function in that it always sends out a timeout with status ok.  Again may need to look at the available return codes?

 

[AA:] Agreed, I noticed that issue too with mamaSubscription_processErr(). I think the status code and platform error need to be changed to provide other errors that may occur.

 

Would you agree with this take on your proposed solution(s)?

 

[AA:] Yes. that sounds good to me.

 

Specially for the synchronous fail, I believe it is a better approach for the Mama layer to examine error conditions and call onError versus onCreate. This helps in providing a common error notification for the sync case to the application independent of the various MW-Bridge implementations.

 

Should there be anything else to consider?

 

[AA:] Other items that come to mind

a)      I am wondering about other cases that constitute a subscription activation failure. We have covered the MW Bridge bridgeMamaSubscription_create case here. There is the case of the subscription request for initial (if requires initial is set) failing which may fail in the MW-Bridge mamaPublisher_sendFromInboxByIndex. So, we need to examine other failure cases and determine for each case if it should result in the subscription activation failure and invoking onError.

b)      Backward compatibility for changing the synchronous failure notification mechanism also needs some thought. For synchronous failure, since OpenMAMA 2.3.1 does not provide the error notification of MW-Bridge errors, should the MW-Bridge provide the error notification to the application itself to work around this? If so, then when OpenMAMA new version provides the notification to the application, then the MW-Bridge should not anymore (to avoid having the onError() callback called twice).

 

Thanks,

Gary

 

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

Tel: +44 28 9099 7580  Ext 3397

g.molloy@...

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alireza Assadzadeh
Sent: 09 December 2014 19:21
To: openmama-dev@...
Subject: [Openmama-dev] Error handling in market data subscription activation and error notification to application

 

Hi Folks,

 

I have noticed that in Mama C subscription, if a market data subscription activation callback (i.e. createAction) fails the error is not propagated in Mama subscription layer to the application through the onError user callback for the subscription. For example, a throttled market data subscription may fail to activate due to Middleware Bridge create subscription failure.

 

Specifically for the Middleware Bridge failure case, looking at mamaSubscriptionImpl_completeMarketDataInitialisation, the call to mamaSubscription_initialize may have failed for example in birdgeMamaSubscriptionCreate call. The return code is not examined in the Mama Subscription and the subscription is always transitioned to activated state and the onCreate user callback is called. The onCreate user callback is called because the subscription creation (activation) is completed from the creation throttle.

 

This seems to be the design intent and there is no expectation that the Mama subscription would be calling the onError user callback in such failure cases. Can you please confirm and/or let me know your opinion on this?

 

Assuming this is the design intent, I think in the Middleware Bridge create subscription failure case, it follows that it is the responsibility of Middleware Bridge to notify the Mama C layer and the application about such errors asynchronously (beyond the function return status code for birdgeMamaSubscriptionCreate). The Middleware Bridge can provide the error notification through a subscription queue event error callback which will then perform the Mama subscription deactivation (optionally) and the call to the user onError callback. In other words, the Middleware Bridge may enqueue an event for mamaSubscription_processErr or a similar callback of its own to deactivate the Mama subscription (optionally) and call the user onError callback.

 

Note that there are cases where the Middleware Bridge may determine immediately in the bridge subscription create call that it is going to fail the subscription create call. There are also other cases where the Middleware Bridge (depending on its capabilities) may determine at later point in time, in an asynchronously fashion, that the Middleware Bridge subscription creation  process encountered an error subsequently. So, for such cases, the Middleware Bridge may already have a mechanism in place to deactivate the Mama subscription and call the user onError callback.

 

Regards,

 

--Alireza
Re: Error handling in market data subscription activation and error notification to application

Gary Molloy <g.molloy@...>
 

Hi Alireza,

 

Thanks for your email.

 

I think that you have touched upon 2 issues here:

 

1.       Synchronous Fails – if the create fails within the mamaSubscription_initialize() function it should be handled at this point.  We should probably add in a return code and check what is being passed back from the call to self->mBridgeImpl->bridgeMamaSubscriptionCreate() where we could then invoked the onError() callback and stop the creation of the subscription continuing (and prevent onCreate() from being invoked).  Some things that may need consideration:

a.       Return codes – would the common set of MAMA return codes cover this or would they require expanding?

b.      Threading - this will cause the onError() to be invoked from the default thread as opposed to the subscription thread.  However this may not be a problem as the subscription will not be active…

 

2.       Asynchronous Fails – I agree with you that mamaSubscription_processErr() is the correct function to use here.  We have used this previously for in-house bridges for the same scenario.  There is a transport function, mamaTransport_getDeactivateSubscriptionOnError(), that can be used to determine whether or not to deactivate the subscription on an error.  A few additional things to consider also:

a.       These events must be fired from the correct queue by the middleware bridge.

b.      There is an issue with the mamaSubscription_processErr() function in that it always sends out a timeout with status ok.  Again may need to look at the available return codes?

 

Would you agree with this take on your proposed solution(s)?

 

Should there be anything else to consider?

 

Thanks,

Gary

 

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

Tel: +44 28 9099 7580  Ext 3397

g.molloy@...

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alireza Assadzadeh
Sent: 09 December 2014 19:21
To: openmama-dev@...
Subject: [Openmama-dev] Error handling in market data subscription activation and error notification to application

 

Hi Folks,

 

I have noticed that in Mama C subscription, if a market data subscription activation callback (i.e. createAction) fails the error is not propagated in Mama subscription layer to the application through the onError user callback for the subscription. For example, a throttled market data subscription may fail to activate due to Middleware Bridge create subscription failure.

 

Specifically for the Middleware Bridge failure case, looking at mamaSubscriptionImpl_completeMarketDataInitialisation, the call to mamaSubscription_initialize may have failed for example in birdgeMamaSubscriptionCreate call. The return code is not examined in the Mama Subscription and the subscription is always transitioned to activated state and the onCreate user callback is called. The onCreate user callback is called because the subscription creation (activation) is completed from the creation throttle.

 

This seems to be the design intent and there is no expectation that the Mama subscription would be calling the onError user callback in such failure cases. Can you please confirm and/or let me know your opinion on this?

 

Assuming this is the design intent, I think in the Middleware Bridge create subscription failure case, it follows that it is the responsibility of Middleware Bridge to notify the Mama C layer and the application about such errors asynchronously (beyond the function return status code for birdgeMamaSubscriptionCreate). The Middleware Bridge can provide the error notification through a subscription queue event error callback which will then perform the Mama subscription deactivation (optionally) and the call to the user onError callback. In other words, the Middleware Bridge may enqueue an event for mamaSubscription_processErr or a similar callback of its own to deactivate the Mama subscription (optionally) and call the user onError callback.

 

Note that there are cases where the Middleware Bridge may determine immediately in the bridge subscription create call that it is going to fail the subscription create call. There are also other cases where the Middleware Bridge (depending on its capabilities) may determine at later point in time, in an asynchronously fashion, that the Middleware Bridge subscription creation  process encountered an error subsequently. So, for such cases, the Middleware Bridge may already have a mechanism in place to deactivate the Mama subscription and call the user onError callback.

 

Regards,

 

--Alireza
Re: OpenMAMA RPM Release Scripts

Gary Molloy <g.molloy@...>
 

Hi Reed,

 

Thanks for your feedback, we appreciate your input with this.

 

The name of the directory was just arbitrarily chosen and we can certainly change it to be something else.

 

Thanks,

Gary

 

 

Gary Molloy – SR Labs

Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD

Tel: +44 28 9099 7580  Ext 3397

g.molloy@...

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed
Sent: 18 November 2014 16:55
To: Damian Maguire; openmama-dev@...
Subject: Re: [Openmama-dev] OpenMAMA RPM Release Scripts

 

Hi Damian,

 

Just a note: the release subdir is also used by Vlsual Studio for its output, so there will be the rpm scripts and lib/dll/pdb files from the builds.

Our Windows git looks like this after running both Visual Studio and scons builds:

 

 

Thanks,

 

Reed.

 

Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198  | M: 917.414.4613 | reed.alpert@...

 

Alternate Contact:  CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Damian Maguire
Sent: Wednesday, November 12, 2014 9:31 AM
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA RPM Release Scripts

 

Folks,

 

Some of you may have noticed a few commits which have just landed in next which relate to the OpenMAMA RPM builds. These are tools which I've been using internally to help facilitate the OpenMAMA release process by automating some of the steps involved. At present they are pretty rough around the edges, however after talking to a few people about them I believe there is some value in having them out there for others to review/enhance. 

 

The primary one of interest to most people is likely to be the openmama.spec file, which resides under the 'release' directory. This is the specification file used by rpmbuild to generate the base RPM and SRPMs, which can then used to generate other RPMs for alternative platforms. 

 

If you clone down next (and assuming you have met the base requirements - running RHEL6 or derivative, have all the OpenMAMA pre-reqs, have rpmbuild and mock installed etc), you should be able to perform a full build yourself by simply entering the release directory and executing:

 

    $ ./openmama-rpm.sh

 

As I say, it's all a little rough, and still quite heavily tailored to my own build environment, but I would appreciate any feedback/bug fixes/issues etc.

 

Cheers, 

 

D

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

Error handling in market data subscription activation and error notification to application

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Hi Folks,

 

I have noticed that in Mama C subscription, if a market data subscription activation callback (i.e. createAction) fails the error is not propagated in Mama subscription layer to the application through the onError user callback for the subscription. For example, a throttled market data subscription may fail to activate due to Middleware Bridge create subscription failure.

 

Specifically for the Middleware Bridge failure case, looking at mamaSubscriptionImpl_completeMarketDataInitialisation, the call to mamaSubscription_initialize may have failed for example in birdgeMamaSubscriptionCreate call. The return code is not examined in the Mama Subscription and the subscription is always transitioned to activated state and the onCreate user callback is called. The onCreate user callback is called because the subscription creation (activation) is completed from the creation throttle.

 

This seems to be the design intent and there is no expectation that the Mama subscription would be calling the onError user callback in such failure cases. Can you please confirm and/or let me know your opinion on this?

 

Assuming this is the design intent, I think in the Middleware Bridge create subscription failure case, it follows that it is the responsibility of Middleware Bridge to notify the Mama C layer and the application about such errors asynchronously (beyond the function return status code for birdgeMamaSubscriptionCreate). The Middleware Bridge can provide the error notification through a subscription queue event error callback which will then perform the Mama subscription deactivation (optionally) and the call to the user onError callback. In other words, the Middleware Bridge may enqueue an event for mamaSubscription_processErr or a similar callback of its own to deactivate the Mama subscription (optionally) and call the user onError callback.

 

Note that there are cases where the Middleware Bridge may determine immediately in the bridge subscription create call that it is going to fail the subscription create call. There are also other cases where the Middleware Bridge (depending on its capabilities) may determine at later point in time, in an asynchronously fashion, that the Middleware Bridge subscription creation  process encountered an error subsequently. So, for such cases, the Middleware Bridge may already have a mechanism in place to deactivate the Mama subscription and call the user onError callback.

 

Regards,

 

--Alireza
901 - 920 of 2318