Openmama-dev@lists.openmama.org

Re: Missing transport status in C++ code

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

Hi,

The context is that for the Tick42 bridge when the user is not valid (not in DACS) then the bridge sends MAMA_TRANSPORT_CONNECT_FAILED to the transport callback, but the C++ app does not get a callback.

Thanks,

Reed.

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

Show quoted text

From: Adrienne Ambrose [mailto:a.ambrose@...]
Sent: Monday, March 30, 2015 12:57 PM
To: Alpert, Reed; openmama-dev@...
Subject: RE: Missing transport status in C++ code

Hi Reed,

On second thoughts, the callbacks are the internal MamaQueue.

Possibly it may have been added for Avis [which is deprecated] let us look into it a bit more.

Thanks,

Adrienne

From: Adrienne Ambrose
Sent: 30 March 2015 17:49
To: 'Alpert, Reed'; openmama-dev@...
Subject: RE: Missing transport status in C++ code

Hi Reed,

Thanks for your email.

In regards to the status codes

- MAMA_TRANSPORT_CONNECT_FAILED

- MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK

- MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK

The Water Marks have not been ported across because they are not necessary.

C++ and Java have their own implementation callbacks “onHighWatermarkExceeded” etc, whereas within C we need to specifically set the callbacks, but if you require these please feel free to submit a patch for consideration.

Transport failed was historically used in an old middleware, but is now no longer required so therefore has not been ported to C++ or Java, but again please feel free to submit a patch.

Thanks,

Adrienne

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed
Sent: 30 March 2015 15:46
To: openmama-dev@...
Subject: [Openmama-dev] Missing transport status in C++ code

Hi,

In MamaTransport.cpp:83 the status codes MAMA_TRANSPORT_CONNECT_FAILED/MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK/MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK are missing from the list. Java is the same as C++.

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

Thanks,

Reed.

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 (collectively, "JPMC"). 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. 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. Although this transmission and any attachments are believed to be free of 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 JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

Re: Question about queue's reusable message

Gary Molloy <g.molloy@...>

#1456

Hi Sam,

Thanks for your email.

Typical scenarios and use cases that we have encountered, the queue is not usually destroyed that often, so we could very well have missed this during our internally testing.

This area of the code is very 'tricky' and we try to be very careful when looking to make changes here.

Could I ask you to raise a Bugzilla ticket with all your findings and tests and we can look into this for you?

Thanks,
Gary

Gary Molloy - SR Labs
Adelaide Exchange | 24-26 Adelaide Street | Belfast | BT2 8GD
g.molloy@...

Show quoted text

-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Sam Wilson
Sent: 27 March 2015 16:06
To: openmama-dev@...
Subject: [Openmama-dev] Question about queue's reusable message

Hey all,

I'm tracking down a memory leak in our bridge, and I am trying to understand why mamaMsg_setMsgBuffer doesn't set the owner flag in the message. When the queue destroys the reusable message, it doesn't clean up the payload.

Since there is a comment around line 561 of msg.c
(http://tinyurl.com/msg-c-561) I assume this is intended behaviour. How should we go about cleaning up the payload in this case?

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

Re: Missing transport status in C++ code

Adrienne Ambrose <a.ambrose@...>

#1455

Hi Reed,

On second thoughts, the callbacks are the internal MamaQueue.

Possibly it may have been added for Avis [which is deprecated] let us look into it a bit more.

Thanks,

Adrienne

Show quoted text

From: Adrienne Ambrose
Sent: 30 March 2015 17:49
To: 'Alpert, Reed'; openmama-dev@...
Subject: RE: Missing transport status in C++ code

Hi Reed,

Thanks for your email.

In regards to the status codes

- MAMA_TRANSPORT_CONNECT_FAILED

- MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK

- MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK

The Water Marks have not been ported across because they are not necessary.

C++ and Java have their own implementation callbacks “onHighWatermarkExceeded” etc, whereas within C we need to specifically set the callbacks, but if you require these please feel free to submit a patch for consideration.

Transport failed was historically used in an old middleware, but is now no longer required so therefore has not been ported to C++ or Java, but again please feel free to submit a patch.

Thanks,

Adrienne

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed
Sent: 30 March 2015 15:46
To: openmama-dev@...
Subject: [Openmama-dev] Missing transport status in C++ code

Hi,

In MamaTransport.cpp:83 the status codes MAMA_TRANSPORT_CONNECT_FAILED/MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK/MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK are missing from the list. Java is the same as C++.

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

Thanks,

Reed.

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 (collectively, "JPMC"). 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. 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. Although this transmission and any attachments are believed to be free of 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 JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

Re: Missing transport status in C++ code

Adrienne Ambrose <a.ambrose@...>

#1457

Hi Reed,

Thanks for your email.

In regards to the status codes

- MAMA_TRANSPORT_CONNECT_FAILED

- MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK

- MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK

The Water Marks have not been ported across because they are not necessary.

C++ and Java have their own implementation callbacks “onHighWatermarkExceeded” etc, whereas within C we need to specifically set the callbacks, but if you require these please feel free to submit a patch for consideration.

Transport failed was historically used in an old middleware, but is now no longer required so therefore has not been ported to C++ or Java, but again please feel free to submit a patch.

Thanks,

Adrienne

Show quoted text

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed
Sent: 30 March 2015 15:46
To: openmama-dev@...
Subject: [Openmama-dev] Missing transport status in C++ code

Hi,

In MamaTransport.cpp:83 the status codes MAMA_TRANSPORT_CONNECT_FAILED/MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK/MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK are missing from the list. Java is the same as C++.

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

Thanks,

Reed.

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 (collectively, "JPMC"). 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. 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. Although this transmission and any attachments are believed to be free of 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 JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

Missing transport status in C++ code

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

#1454

Hi,

In MamaTransport.cpp:83 the status codes MAMA_TRANSPORT_CONNECT_FAILED/MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK/MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK are missing from the list. Java is the same as C++.

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

Thanks,

Reed.

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 (collectively, "JPMC"). 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. 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. Although this transmission and any attachments are believed to be free of 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 JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

[Patch 2.3.2] Scons: fixes for Windows and Linux

Reed Alpert <reed.alpert@...>

#1453

Hi,

These are against the next branch.

Fixes for Windows build using docs, testtools, and unittests.
Fixes for using DOS commands instead of GNU/Linux commands.
Remove reference to 'enterprise' in path names.
Add junit_home as a cmd line parm.
Add Visual Studio 11 and 12 as options (leave 10 as default).
Add MSVS_VERSION (along with existing MSVC_VERSION) to tell scons what Visual Studio version to use.

Thanks,

Reed.

diff --git a/mama/c_cpp/SConscript.win b/mama/c_cpp/SConscript.win

index 77e3157..ece0710 100644

--- a/mama/c_cpp/SConscript.win

+++ b/mama/c_cpp/SConscript.win

@@ -121,14 +121,13 @@ if env['with_testtools'] == True and 'dynamic' in env['build']:

if ( not Media.has_key('mama/c_cpp/docs')

and env['build'] == 'dynamic'

and not env.GetOption('clean')

+ and env['product'] == 'mama'

and env['with_docs'] == True ):

cdoc = env.Doxygen('doxyconfig-c.in')

cppdoc = env.Doxygen('doxyconfig-cpp.in')

- env.Command( '$prefix/doc/mama/images', cdoc, 'mkdir $TARGET && cp -rf %s\mama\c_cpp\doc\images\* $TARGET' % ( env['TOPLEVEL'] ) )

- env.Command( '$prefix/doc/mama/c/html', cdoc, 'mkdir $TARGET && cp -rf %s\mama\c_cpp\doc\c\html\* $TARGET' % ( env['TOPLEVEL'] ) )

- env.Command( '$prefix/doc/mama/cpp/html', cppdoc, 'mkdir $TARGET && cp -rf %s\mama\c_cpp\doc\cpp\html\* $TARGET' % ( env['TOPLEVEL'] ) )

+ env.Command( '$prefix/doc/mama', '', 'mkdir $TARGET && xcopy /q /s /e /y %s\mama\c_cpp\doc\* $TARGET' % ( env['TOPLEVEL'] ) )

env.Clean( cdoc, '%s/mama/c_cpp/doc/c' % (env['TOPLEVEL']) )

env.Clean( cppdoc, '%s/mama/c_cpp/doc/cpp' % (env['TOPLEVEL']) )

diff --git a/mama/c_cpp/doxyconfig-c.in b/mama/c_cpp/doxyconfig-c.in

index 9e03518..b92b005 100644

--- a/mama/c_cpp/doxyconfig-c.in

+++ b/mama/c_cpp/doxyconfig-c.in

@@ -754,7 +754,7 @@ WARN_LOGFILE =

# spaces.

# Note: If this tag is empty the current directory is searched.

-INPUT = ./src/c/mama ./src/enterprise/c/mama

+INPUT = ./src/c/mama ./src/c/mama

# This tag can be used to specify the character encoding of the source files

# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses

diff --git a/mama/jni/SConscript b/mama/jni/SConscript

index 6d4173d..61a3570 100644

--- a/mama/jni/SConscript

+++ b/mama/jni/SConscript

@@ -20,6 +20,9 @@ testtools_source = Split("""

testtools = []

+unittest_source = Glob('src/junittests')

+unittest = []

+

jExamples = Glob('src/com/wombat/mama/examples/*java')

version = env['versions']['mama']['releaseString']

@@ -43,14 +46,20 @@ if env['with_testtools'] == True:

for t in testtools_source:

testtools.append( env.Java( 'classes', t ) )

+if env['with_unittest'] == True:

+ for t in unittest_source:

+ unittest.append( env.Java( 'classes', t ) )

+ env.Append(JAVACLASSPATH = ('$junit_home/junit.jar'))

+

env.Depends( mama_classes, common_classes )

env.Depends( testtools, mama_classes )

+env.Depends( unittest, mama_classes )

# Builds all of the header files which is unnecessary but no reason not to

# do this

headers = env.JavaH(target=Dir('src/c/mamajni').abspath,source= [ mama_classes, common_classes ])

-env.Depends( headers, [ mama_classes, common_classes, testtools ] )

+env.Depends( headers, [ mama_classes, common_classes, testtools, unittest ] )

jar = env.Jar(target='mamajni.jar', source='classes', JARCHDIR = Dir('classes').abspath )

diff --git a/mamda/c_cpp/SConscript.win b/mamda/c_cpp/SConscript.win

index 4c63b51..0a67d48 100644

--- a/mamda/c_cpp/SConscript.win

+++ b/mamda/c_cpp/SConscript.win

@@ -113,7 +113,7 @@ if env['with_unittest'] == True:

if ( env['with_docs'] == True and not Media.has_key('mamda/c_cpp/docs') and env['build'] == 'dynamic' and not env.GetOption('clean') ):

cppdoc = env.Doxygen('doxyconfig-cpp.in')

- env.Command( '$prefix/doc/mamda/cpp/html', cppdoc, 'mkdir $TARGET && cp -rf %s\mamda\c_cpp\doc\cpp\html\* $TARGET' % ( env['TOPLEVEL'] ) )

+ env.Command( '$prefix/doc/mamda', cppdoc, 'mkdir $TARGET && xcopy /q /s /e /y %s\mamda\c_cpp\doc\* $TARGET' % ( env['TOPLEVEL'] ) )

env.Clean( cppdoc, '%s/mamda/c_cpp/doc/cpp' % (env['TOPLEVEL']) )

diff --git a/site_scons/community/command_line.py b/site_scons/community/command_line.py

index e1791e2..4bbacc5 100644

--- a/site_scons/community/command_line.py

+++ b/site_scons/community/command_line.py

@@ -26,6 +26,7 @@ def get_command_line_opts( host, products, VERSIONS ):

BoolVariable('with_examples','Build with test tools',True),

BoolVariable('entitled','Whether the build is entitled or unentitled',False),

PathVariable('gtest_home','Path to Google Test home',None, PathVariable.PathIsDir),

+ PathVariable('junit_home','Path to Junit home',None, PathVariable.PathIsDir),

ListVariable('middleware','Middleware(s) to be compiled in', 'avis', names = ['avis', 'qpid'] ),

('jobs', 'Number of scons threads to spawn, if n is passed the number of availabe cores is calculated and used', '1'),

@@ -39,7 +40,7 @@ def get_command_line_opts( host, products, VERSIONS ):

PathVariable('qpid_home', 'Path to QPID Proton Libraries',

'c:\\proton', PathVariable.PathAccept),

EnumVariable('vsver','Visual Studio Version to use', '10.0',

- allowed_values=('8.0','9.0','10.0')),

+ allowed_values=('8.0','9.0','10.0','11.0','12.0')),

EnumVariable('product', 'Product to be built', 'mamda',

allowed_values=( products )),

EnumVariable('dotnet_version', 'Dotnet Version used to determine framework directory', '2.0',

@@ -63,6 +64,8 @@ def get_command_line_opts( host, products, VERSIONS ):

EnumVariable('product', 'Product to be built', 'mamda',

#mamda all is a windows only build

allowed_values=( [ x for x in products if x != "mamdaall" ] )),

+ EnumVariable('target_arch', 'Specifies if the build should target 32 or 64 bit architectures.',

+ host['arch'], allowed_values=['x86', 'x86_64']),

EnumVariable( 'compiler', 'Compiler to use for building OpenMAMA',

'default', allowed_values=('default', 'gcc', 'clang', 'clang-analyzer')),

)

diff --git a/site_scons/community/windows.py b/site_scons/community/windows.py

index 362f697..80c241d 100644

--- a/site_scons/community/windows.py

+++ b/site_scons/community/windows.py

@@ -64,8 +64,10 @@ class Windows:

env = Environment(ENV={

'JAVA_HOME': '%s' % (optsEnv['java_home']),

'PATH': '%s:%s\\bin' % (os.environ['PATH'], optsEnv['java_home']),

- 'MSVC_VERSION' : '%s' %(optsEnv['vsver'])},

+ },

tools = tools,

+ MSVC_VERSION = optsEnv['vsver'],

+ MSVS_VERSION = optsEnv['vsver'],

TARGET_ARCH = optsEnv['target_arch'])

#ConfigureJNI searches os.env for java_home not env['ENV']['JAVA_HOME']

@@ -78,7 +80,7 @@ class Windows:

env['JAVAH'] = 'javah'

else:

- env = Environment(ENV={'PATH': '%s' % (os.environ['PATH'])}, MSVC_VERSION = optsEnv['vsver'], tools = tools, TARGET_ARCH = optsEnv['target_arch'])

+ env = Environment(ENV={'PATH': '%s' % (os.environ['PATH'])}, MSVC_VERSION = optsEnv['vsver'], MSVS_VERSION = optsEnv['vsver'], tools = tools, TARGET_ARCH = optsEnv['target_arch'])

env['SPAWN'] = logger.log_output

env['PRINT_CMD_LINE_FUNC'] = logger.log_command

@@ -196,7 +198,7 @@ class Windows:

# Configures all of the appropriate environment variables for windows.

def configure(self, env ):

env.Append( CPPDEFINES = ['WIN32'] )

- env.Append( CCFLAGS = ['-EHsc','/GR','/FIwombat\\targetsxs.h'] )

+ env.Append( CCFLAGS = ['/EHsc','/GR','/FIwombat\\targetsxs.h'] )

env.Append( LINKFLAGS =['/MANIFEST'] )

env.Append( CCPDBFLAGS = '/Fd${TARGET}.pdb' )

env.Append( PDB = '${TARGET.base}.pdb')

scons.patch

Question about queue's reusable message

Sam Wilson <Sam.Wilson@...>

#1452

Hey all,

I'm tracking down a memory leak in our bridge, and I am trying to 
understand why mamaMsg_setMsgBuffer doesn't set the owner flag in the 
message. When the queue destroys the reusable message, it doesn't clean 
up the payload.

Since there is a comment around line 561 of msg.c 
(http://tinyurl.com/msg-c-561) I assume this is intended behaviour. How 
should we go about cleaning up the payload in this case?

Thanks,
Sam

Re: [Openmama-users] OpenMAMA, OpenMAMDA and OpenMDM

Adrienne Ambrose <a.ambrose@...>

#1451

Good Afternoon,

Firstly most of our email correspondence is on the openmama-dev@... channel, this is the best place to open new topics for discussion.

OpenMamda is a framework running on top of OpenMAMA which provides a market data specific API abstracting quotes, trades, order books, option chains and more, and which provides significant functionality to simplify development of trading applications.

OpenMDM is the mapping for Market Data into a normalised format.

All of which are still alive and actively developed in the open source version as well as an enterprise product maintained by SR Labs.

OpenMAMA is well established a platform for market data consumption and as a foundation for trading applications therefore should be applicable to your needs.

Thanks,

Adrienne

Show quoted text

From: openmama-users-bounces@... [mailto:openmama-users-bounces@...] On Behalf Of Macrux
Sent: 26 March 2015 14:59
To: openmama-users@...
Subject: [Openmama-users] OpenMAMA, OpenMAMDA and OpenMDM

Hi there,

First of all, thanks in advance for your help. In second place, I want to know which is the relation between openMAMA, openMAMDA and OpenMDM and if are those projects still alive or have they been forgotten.

In third place, I'm trying to develop an algorithmic trading system that could be feeded by several data sources (live and historical) like bloomberg market data service, FIX 4.4 market data, among others, and I would like to know if openMAMA is the right option.

Again, thanks for your comments and answers!

Re: onError from image request inbox lost

Ian Bell <i.bell@...>

#1450

Hi

None of the enterprise bridges implement this functionality and the timeout is always relied upon to invoke the error call-back.
That said I did look into this at one stage for a similar scenario but we ended up going with an alternate solution.
Some of the things that cropped up during that investigation and need thought about here as well

1) Threading - Subscription requests are sent from the default thread, whereas the subscription call-backs (ie onError) happen off the subscription thread.
2) Subscription clean-up - Effects of this slightly different scenario need to considered in terms of its impact on the subscription state-machine.
3) Race conditions - There are already a few race conditions around the sending of multiple requests and replies happening at the same time as the timeout especially when the queue is backed up, again new scenarios might make this a more frequent occurance.
4) Imagerequest destruction - The cleanup of the objects needs to be handled carefully and I'm not convinced its completely correct as it is.

Also it feels like there is a sort of overlap with this and the publisher events discussion as in this a msg being sent and an error being returned. 

Ian

Show quoted text

-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Tom Doust
Sent: 25 March 2015 08:46
To: Sam Wilson; openmama-dev@...
Subject: Re: [Openmama-dev] onError from image request inbox lost

Hi Sam

Interesting question. 

I have been looking at a similar issue with snapshot subscriptions on our TREP bridge. The problem is a bit more general in that it includes conditions such as handling a bad symbol name but nevertheless the problem is how to notify on a callback.

I don't have any answers at the moment as I haven't been able to allocate any time to it but I had kind of assumed that there should be a way of calling the mamaSubscription OnError callback.

It would be interesting to know what mama client applications expect to happen and also what does the wmw bridge do in this situation

Best regards

Tom

-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Sam Wilson
Sent: 23 March 2015 17:42
To: openmama-dev@...
Subject: [Openmama-dev] onError from image request inbox lost

Hey,

I've got a (hopefully) quick question for you guys.

First off, our scenario: instead of getting initials and recaps from an interactive publisher, our middleware bridge allows market data subscribers to get initials/recaps from a cache. The cache can report a condition where there is no data for a particular subject, and we'd like to give that information to applications.  Currently our bridge does nothing in this case, and eventually the image request times out.

Now my question: I'm attempting to deliver an onError from the inbox of an image request in a market data subscription to the application, but the image request does not provide an onError callback to the subscription. (See http://tinyurl.com/ld8cwfh) Is this intentional, or would it make sense to pass the onError callback through? If passing the onError through is correct, what is the right way to handle the destroy handle?

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

C# DQPublisher Manager

Mathias Kim

#1449

Hi guys,

we continued wrapping the dqpublishermanager class in C# but got stuck again. We can create a dqpublishermanager and I also get the onCreate callback. Now, we try to notify the dqpm that there is interest in a certain symbol.

We try to connect to the dqpm via a qpid bridge. Unfortunately, the request never arrives at the dqpm so the OnNewRequest callback never gets called. However, the transport class recognizes the request and notifies us on the console. It even remembers that we previously shows interest in the same symbol. Therefore we like to know whether our implementation is faulty or whether we need to route the request from the transport to the dqpm ourselves.

How does this generally work?

Hope you can help us.

Best regards

Mathias Kim

ETF Analyst

Phone +49 89 442327-191
Mobile +49 171 4152665
mathias.kim@...
www.crossflow.de

Crossflow Financial Advisors GmbH
Sonnenstraße 19
D-80331 München
Local Court of Munich HRB 186408
Managing Directors: Markus Deffner, Juergen Fritzen, Erol Steiner

The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this e-mail may be unlawful. If you have received this e-mail in error, please notify the sender immediately and delete it from your system. E-mail transmission cannot be guaranteed to be secure or error free, as messages can be intercepted, corrupted, contain viruses, arrive late or incomplete.

Re: onError from image request inbox lost

Tom Doust

#1448

Hi Sam

Interesting question. 

I have been looking at a similar issue with snapshot subscriptions on our TREP bridge. The problem is a bit more general in that it includes conditions such as handling a bad symbol name but nevertheless the problem is how to notify on a callback.

I don't have any answers at the moment as I haven't been able to allocate any time to it but I had kind of assumed that there should be a way of calling the mamaSubscription OnError callback.

It would be interesting to know what mama client applications expect to happen and also what does the wmw bridge do in this situation

Best regards

Tom

Show quoted text

-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Sam Wilson
Sent: 23 March 2015 17:42
To: openmama-dev@...
Subject: [Openmama-dev] onError from image request inbox lost

Hey,

I've got a (hopefully) quick question for you guys.

First off, our scenario: instead of getting initials and recaps from an interactive publisher, our middleware bridge allows market data subscribers to get initials/recaps from a cache. The cache can report a condition where there is no data for a particular subject, and we'd like to give that information to applications.  Currently our bridge does nothing in this case, and eventually the image request times out.

Now my question: I'm attempting to deliver an onError from the inbox of an image request in a market data subscription to the application, but the image request does not provide an onError callback to the subscription. (See http://tinyurl.com/ld8cwfh) Is this intentional, or would it make sense to pass the onError callback through? If passing the onError through is correct, what is the right way to handle the destroy handle?

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

onError from image request inbox lost

Sam Wilson <Sam.Wilson@...>

#1447

Hey,

I've got a (hopefully) quick question for you guys.

First off, our scenario: instead of getting initials and recaps from an 
interactive publisher, our middleware bridge allows market data 
subscribers to get initials/recaps from a cache. The cache can report a 
condition where there is no data for a particular subject, and we'd like 
to give that information to applications.  Currently our bridge does 
nothing in this case, and eventually the image request times out.

Now my question: I'm attempting to deliver an onError from the inbox of 
an image request in a market data subscription to the application, but 
the image request does not provide an onError callback to the 
subscription. (See http://tinyurl.com/ld8cwfh) Is this intentional, or 
would it make sense to pass the onError callback through? If passing the 
onError through is correct, what is the right way to handle the destroy 
handle?

Thanks,
Sam

[PATCH] SCons: OpenMAMA will not build on windows

Gary Molloy <g.molloy@...>

#1446

BZ-183

Testing:-

Not middleware specific.

Applies to Windows only.

With the patch applied it will be possible to build mama on windows using scons.

Here is a very basic config (omama.conf) to test with:

middleware = 'none'

jobs = 'n'

buildtype = 'dynamic-debug'

=========================================================================================================

From 6cbd365157b53c8203e2d1459b695d12fb9da1ca Mon Sep 17 00:00:00 2001

From: Gary Molloy <g.molloy@...>

Date: Thu, 12 Mar 2015 12:47:38 -0400

Subject: [PATCH] SCons: OpenMAMA will not build on windows

It is currently not possible to build using scons on windows

due to a few files that were removed during the last release.

Signed-off-by: Gary Molloy <g.molloy@...>

---

mama/c_cpp/src/c/SConscript.win | 2 --

1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/mama/c_cpp/src/c/SConscript.win b/mama/c_cpp/src/c/SConscript.win

index cbae5b1..77e3e18 100644

--- a/mama/c_cpp/src/c/SConscript.win

+++ b/mama/c_cpp/src/c/SConscript.win

@@ -75,9 +75,7 @@ playback/playbackcapture.c

playback/playbackFileParser.c

playback/playbackpublisher.c

fieldcache/fieldcachefield.c

-fieldcache/fieldcachemapbinary.c

fieldcache/fieldcachemaparray.c

-fieldcache/fieldcachemapmonitor.c

fieldcache/fieldcacheimpl.c

fieldcache/fieldcachemap.c

fieldcache/fieldcacheiterator.c

--

1.7.1

Gary Molloy – SR Labs

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

g.molloy@...

0001-SCons-OpenMAMA-will-not-build-on-windows.patch

[PATCH 2/2] Mama Java: Add java MamaDateTime::getAsFormattedString() method.

Adrienne Ambrose <a.ambrose@...>

#1445

Bugzilla Ticket :- Bug 182

Testing:-

Not middleware or O/S specific.

Attached modified MamaListen.java application to the Bugzilla ticket, which instead of using the normal print function will now call the new
datetime.getAsFormattedString() function.

Example of code added :
MamaTimeZone tz = new MamaTimeZone ("EST");
System.out.println (datetime.formatString ("%F %T", null));
System.out.println (datetime.formatString ("%F %T", tz));

Prints out the following :-
wQuoteTime | 442 | TIME | 2015-03-10 15:18:51 <-------- normal time
2015-03-10 10:18:51 <-------- EST timezone.

=========================================================================================================

From 1b1b07a6062c2b7d7e200a95a25458d80bfe889d Mon Sep 17 00:00:00 2001

From: A Ambrose <a.ambrose@...>

Date: Wed, 11 Mar 2015 11:36:36 +0000

Subject: [PATCH 2/2] Mama Java: Add java MamaDateTime::getAsFormattedString()

method.

Method currently missing from Java implementation.

Add new MamaDateTime::getAsFormattedString() method.

Signed-off-by: A Ambrose <a.ambrose@...>

---

mama/jni/src/c/mamadatetimejni.c | 53 ++++++++++++++++++++++++++

mama/jni/src/com/wombat/mama/MamaDateTime.java | 11 +++++-

2 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/mama/jni/src/c/mamadatetimejni.c b/mama/jni/src/c/mamadatetimejni.c

index 8664df9..768aefc 100644

--- a/mama/jni/src/c/mamadatetimejni.c

+++ b/mama/jni/src/c/mamadatetimejni.c

@@ -714,6 +714,59 @@ JNIEXPORT jstring JNICALL Java_com_wombat_mama_MamaDateTime_getAsString

/*

* Class: com_wombat_mama_MamaDateTime

+ * Method: getAsFormattedString

+ * Signature: ()Ljava/lang/String

+ */

+JNIEXPORT jstring JNICALL Java_com_wombat_mama_MamaDateTime_getAsFormattedString

+ (JNIEnv* env, jobject this, jstring str, jstring timeZone)

+{

+ jlong pDateTime = 0;

+ jlong pTimeZone = 0;

+ const char* c_Str = NULL;

+ mama_status status = MAMA_STATUS_OK;

+ char ret_c [MAX_DATE_TIME_STR_LEN+1];

+ char errorString [UTILS_MAX_ERROR_STRING_LENGTH];

+

+ pDateTime = (*env)->GetLongField (env,this,dateTimePointerFieldId_g);

+ MAMA_THROW_NULL_PARAMETER_RETURN_VALUE(pDateTime,

+ "Null parameter, MamaDateTime may have already been destroyed.", NULL) ;

+

+ if (NULL != timeZone)

+ {

+ pTimeZone = (*env)->GetLongField (env,this,tzFieldObjectFieldId_g);

+ if (0 == pTimeZone)

+ {

+ pTimeZone = createTimeZone (env, this);

+ assert (0!=pTimeZone);

+ }

+ timeZone_set (env, pTimeZone, timeZone);

+ }

+

+ c_Str = (*env)->GetStringUTFChars(env,str,0);

+

+ if (!c_Str ||

+ MAMA_STATUS_OK!=(status=mamaDateTime_getAsFormattedStringWithTz(

+ CAST_JLONG_TO_POINTER(mamaDateTime,pDateTime),

+ ret_c,

+ MAX_DATE_TIME_STR_LEN,

+ c_Str,

+ timeZone

+ ? CAST_JLONG_TO_POINTER (mamaTimeZone, pTimeZone)

+ : NULL)))

+ {

+ utils_buildErrorStringForStatus(

+ errorString,

+ UTILS_MAX_ERROR_STRING_LENGTH,

+ "Error calling MamaDateTime.getAsStringWithTz().",

+ status);

+ utils_throwExceptionForMamaStatus (env,status,errorString);

+ return 0;

+ }

+ return (*env)->NewStringUTF (env, ret_c);

+}

+

+/*

+ * Class: com_wombat_mama_MamaDateTime

* Method: getTimeAsString

* Signature: ()Ljava/lang/String

*/

diff --git a/mama/jni/src/com/wombat/mama/MamaDateTime.java b/mama/jni/src/com/wombat/mama/MamaDateTime.java

index c46ae60..010b77b 100644

--- a/mama/jni/src/com/wombat/mama/MamaDateTime.java

+++ b/mama/jni/src/com/wombat/mama/MamaDateTime.java

@@ -100,8 +100,14 @@ public class MamaDateTime implements Comparable

return getAsString ();

}

+ public String formatString (String str,

+ MamaTimeZone tz)

+ {

+ return getAsFormattedString (str, (tz!=null ? tz.tz():null));

+ }

+

public int compareTo (Object obj)

- {

+ {

// If comparison is not possible this will throw a ClassCastException

// which is what the Comparable spec requires.

MamaDateTime time = (MamaDateTime) obj;

@@ -283,6 +289,9 @@ public class MamaDateTime implements Comparable

public native String getAsString ();

+ private native String getAsFormattedString (String format,

+ String tz);

+

public native String getTimeAsString ();

public native String getDateAsString ();

--

2.1.0

0002-Mama-Java-Add-java-MamaDateTime-getAsFormattedString.patch

[PATCH 1/2] Mama Java: Java subscription setup fix - it loses the closure.

Adrienne Ambrose <a.ambrose@...>

#1444

Bugzilla Ticket :- Bug-181

Testing:-

Not middleware or O/S specific.

I have attached a modified MamaListen.java application to the Bugzilla ticket, which instead of using the createSubscription() we are now calling
setupSubscription() followed by an activate.

You can pass anything in as your closure and then use the getClosure() to return the closure.

======================================================================================================

From bdbf154c17e1f12778bc2904b2fb68f6daed9418 Mon Sep 17 00:00:00 2001

From: A Ambrose <a.ambrose@...>

Date: Wed, 11 Mar 2015 11:19:40 +0000

Subject: [PATCH 1/2] Mama Java: Java subscription setup fix - it loses the

closure.

On setupSubscription() the closure is never stored, this patch will

correct this issue.

Signed-off-by: A Ambrose <a.ambrose@...>

---

mama/jni/src/com/wombat/mama/MamaSubscription.java | 5 ++++-

1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mama/jni/src/com/wombat/mama/MamaSubscription.java b/mama/jni/src/com/wombat/mama/MamaSubscription.java

index 6916434..fc7bbe6 100644

--- a/mama/jni/src/com/wombat/mama/MamaSubscription.java

+++ b/mama/jni/src/com/wombat/mama/MamaSubscription.java

@@ -292,13 +292,16 @@ public class MamaSubscription

// Save the source in the Java layer to prevent a context switch to C

mySource = source;

+ // Save the closure

+ myClosure = closure;

+

// Create the native subscription

setupNativeSubscription(

callback,

queue,

source,

symbol,

- closure);

+ null);

}

public void setAppDataType (MamaMdDataType type)

--

2.1.0

0001-Mama-Java-Java-subscription-setup-fix-it-loses-the-c.patch

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

Alireza Assadzadeh <Alireza.Assadzadeh@...>

#1443

Hi Gary,

I created this Bugzilla to track this issue: http://bugs.openmama.org/show_bug.cgi?id=180

I’ll propose a patch in the next little while for the same.

Regards

--Alireza

Show quoted text

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alireza Assadzadeh
Sent: Monday, December 15, 2014 2:34 PM
To: Gary Molloy; openmama-dev@...
Subject: Re: [Openmama-dev] Error handling in market data subscription activation and error notification to application

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: Subscription onDestroy Callback

Sam Wilson <Sam.Wilson@...>

#1442

Hey Reed,

It does seem like onDestroy is intended to be used that way. When the bridge calls onDestroy, it causes OpenMAMA to switch the subscription's state from any of the "ING" states to the "ED" states, which lets the mama subscription be reused.

If you enqueue the onDestroy, mamaconsumer_v2 will hang while it is cleaning up. It stops the dispatcher with mama_stop, then waits for all the onDestroy events in consumerShutdown. If the dispatcher is stopped, no queued events can be delivered, so no onDestroy calls are made.

Cheers,
Sam

On 15-02-20 12:34 PM, Alpert, Reed wrote:

Show quoted text

Hi,

Does the onDestroy() guarantee that no more callbacks will be made for that subscription?

Similar to Reuters completion event.

To guarantee this it seems it must be posted as an event on the sub queue, and no more sent after that.

For destroy/create use case:

sub->destroy();

wait for onDestroy();

sub->create(>..);

What issues did the sample apps have?

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

-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Sam Wilson
Sent: Wednesday, February 18, 2015 3:05 PM
To: openmama-dev@...
Subject: [Openmama-dev] Subscription onDestroy Callback

Hey everyone,

I spoke quickly with Damien about this on IRC, but I thought I should raise the question with the community at large.

What thread should the subscription's onDestroy callback be called from?

We recently switched from calling it on a thread controlled by the bridge to enqueuing it on the subscription's queue, but that seems to cause a lot of trouble for the sample applications.

Section 9 of the OpenMAMA Developer's Guide for C leaves out the onDestroy callback.

Thanks,

Sam

_______________________________________________

Openmama-dev mailing list

Openmama-dev@...

https://lists.openmama.org/mailman/listinfo/openmama-dev

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

Gary Molloy <g.molloy@...>

#1441

Hi Guys,

We have updated some of the tickets being considered for this release asking for some addition information.

If you would like to have other issues to be considered for this upcoming release we will require a Bugzilla ticket to be submitted first (following the submission guidelines, http://wiki.openmama.org/index.php/Patch_submission)

We would appreciate your timely responses on these.

Thanks,

Gary

Gary Molloy – SR Labs

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

g.molloy@...

Show quoted text

From: Gary Molloy
Sent: 23 February 2015 15:47
To: Openmama-dev@...
Subject: OpenMAMA-2.3.3

Hi Guys,

We are currently planning the next release of OpenMAMA - OpenMAMA-2.3.3.

Please find below the initial list of issues that are currently scheduled for inclusion in this release:

BZ166 Make wInterlocked_set return the prior value

BZ164 MAMAJNI: MamaPublisher: Overload the MamaPublisher Create Method

BZ169 Wombat queue has no separate deallocate method

BZ176 MAMAC: Missing actions for snapshot subscriptions transition to deactivate state

BZ168 MAMA: Complete support for Vector Bool and Vector Char field types

BZ156 COMMON: Variable expansion in property value on the last line of properties file fails

BZ125 Payload and Middleware Unit-test in Visual Studio

BZ-114 MAMA JNI crash in MamaListen.java when using platformInfo.toString()

BZ-178 Problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

BZ-179 OpenMAMA mock RPM's fail to build

If there are any issues in particular you would like to see included in the next release, please feel free to reply (with a prioritised list) and we can review them 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

Glenn McClements <g.mcclements@...>

#1440

Yep, looks good, please proceed.

Glenn

From: Gary Molloy
Date: Monday, 23 February 2015 14:42
To: "openmama-dev@..."
Subject: Re: [Openmama-dev] OpenMAMA-2.3.2-rc1

Hi Guys,

This reply is a bit later than I anticipated, but I did received some positive feedback from the testing of OpenMAMA-2.3.2-rc1 and so we are ready to make this release final.

The issue with the RPM’s is still unresolved, but this will be resolved and included in the next release.

Glenn, do we have your permission for sign-off?

Thanks,

Gary

Gary Molloy – SR Labs

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

g.molloy@...

Show quoted text

From: Gary Molloy
Sent: 14 January 2015 16:59
To: openmama-dev@...
Subject: RE: OpenMAMA-2.3.2-rc1

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

Gary Molloy <g.molloy@...>

#1439

Hi Guys,

We are currently planning the next release of OpenMAMA - OpenMAMA-2.3.3.

Please find below the initial list of issues that are currently scheduled for inclusion in this release:

BZ166 Make wInterlocked_set return the prior value

BZ164 MAMAJNI: MamaPublisher: Overload the MamaPublisher Create Method

BZ169 Wombat queue has no separate deallocate method

BZ176 MAMAC: Missing actions for snapshot subscriptions transition to deactivate state

BZ168 MAMA: Complete support for Vector Bool and Vector Char field types

BZ156 COMMON: Variable expansion in property value on the last line of properties file fails

BZ125 Payload and Middleware Unit-test in Visual Studio

BZ-114 MAMA JNI crash in MamaListen.java when using platformInfo.toString()

BZ-178 Problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

BZ-179 OpenMAMA mock RPM's fail to build

If there are any issues in particular you would like to see included in the next release, please feel free to reply (with a prioritised list) and we can review them for inclusion.

Thanks,

Gary

Gary Molloy – SR Labs

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

g.molloy@...