Date   

Re: [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

Glenn McClements <gmcclements@...>
 

Thanks Chad.

For consistency though with the C++ interface, it should be (publisher, topic, source), not (publisher, source, topic).  

Also consider replacing/extending the existing JNI _create() function rather than having two. This reduces code duplication and you already check for a NULL source being passed down so it should handle both Java methods. 

Glenn 

From: <Meyer>, Chad J <chad.j.meyer@...>
Date: Friday, 5 September 2014 22:42
To: "openmama-dev@..." <openmama-dev@...>
Subject: [Openmama-dev] [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

Hi,

 

Attached is a patch for OpenMAMA JNI that overloads the MamaPublisher create method. For consistency purposes, the new method requires two String parameters, source and symbol, as opposed to a single string currently found in the MamaPublisher class.  

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

index 518bacf..629a51b 100644

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

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

@@ -78,7 +78,7 @@ static void MAMACALLTYPE sendCompleteCB (mamaPublisher publisher,

  * Method:    _create

  * Signature: (Lcom/wombat/mama/Transport;Ljava/lang/String;)V

  */

-JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

+JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create__Lcom_wombat_mama_MamaTransport_2Ljava_lang_String_2

   (JNIEnv* env, jobject this, jobject transport, jstring topic)

{

     mamaPublisher   cPublisher          =   NULL;

@@ -125,6 +125,66 @@ JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

     return;

}

 

+ /*

+ * Class:     com_wombat_mama_MamaPublisher

+ * Method:    _create

+ * Signature: (Lcom/wombat/mama/MamaTransport;Ljava/lang/String;Ljava/lang/String;)V

+ */

+JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create__Lcom_wombat_mama_MamaTransport_2Ljava_lang_String_2Ljava_lang_String_2

+  (JNIEnv* env, jobject this, jobject transport, jstring source, jstring symbol)

+{

+             mamaPublisher   cPublisher          =   NULL;

+    mamaTransport   cTransport          =   NULL;

+    const char*     cSource             =   NULL;

+             const char*     cSymbol             =   NULL;

+    jlong           transportPointer    =   0;

+    mama_status     status              =   MAMA_STATUS_OK;

+    char errorString[UTILS_MAX_ERROR_STRING_LENGTH];

+            

+    /*Get the transport pointer*/

+    assert(transport!=NULL);

+    transportPointer = (*env)->GetLongField(env, transport,

+            transportPointerFieldId_g);

+    cTransport = CAST_JLONG_TO_POINTER(mamaTransport, transportPointer);

+    assert(transportPointer!=0);

+            

+    /*Get the char* from the jstring*/

+    if(NULL!=source)

+    {

+         cSource = (*env)->GetStringUTFChars(env,source,0);

+         if(!cSource)return;

+    }

+             if(NULL!=symbol)

+    {

+         cSymbol = (*env)->GetStringUTFChars(env,symbol,0);

+         if(!cSymbol)return;

+    }

+

+    if(MAMA_STATUS_OK!=(mamaPublisher_create(

+                    &cPublisher,

+                    cTransport,

+                    cSymbol,

+                    cSource,

+                    NULL)))

+    {

+        if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

+                             if(cSymbol)(*env)->ReleaseStringUTFChars(env,symbol, cSymbol);

+        utils_buildErrorStringForStatus(

+                errorString, UTILS_MAX_ERROR_STRING_LENGTH,

+                "Failed to create publisher.", status);

+        utils_throwMamaException(env,errorString);

+        return;

+    }

+

+    (*env)->SetLongField(env,this,publisherPointerFieldId_g,

+                         CAST_POINTER_TO_JLONG(cPublisher));

+       

+    if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

+             if(cSymbol)(*env)->ReleaseStringUTFChars(env,symbol, cSymbol);

+   

+    return;

+}

+

/*

  * Class:     com_wombat_mama_MamaPublisher

  * Method:    _send

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

index 0146945..c1e8dc8 100644

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

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

@@ -39,6 +39,11 @@ public class MamaPublisher

     {

         _create(transport,topic);

     }

+            

+             public void create (MamaTransport transport, String source, String symbol)

+    {

+        _create(transport,source,symbol);

+    }

     public void send (MamaMsg msg)

     {

@@ -77,6 +82,8 @@ public class MamaPublisher

     }

     private native void _create (MamaTransport transport, String topic);

+            

+             private native void _create (MamaTransport transport, String source, String symbol);

     private native void _send (MamaMsg msg);

--

1.8.4.msysgit.0

 

 

Chad Meyer| Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan | 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

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.


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


[PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

Chad Meyer
 

Hi,

 

Attached is a patch for OpenMAMA JNI that overloads the MamaPublisher create method. For consistency purposes, the new method requires two String parameters, source and symbol, as opposed to a single string currently found in the MamaPublisher class.  

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

index 518bacf..629a51b 100644

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

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

@@ -78,7 +78,7 @@ static void MAMACALLTYPE sendCompleteCB (mamaPublisher publisher,

  * Method:    _create

  * Signature: (Lcom/wombat/mama/Transport;Ljava/lang/String;)V

  */

-JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

+JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create__Lcom_wombat_mama_MamaTransport_2Ljava_lang_String_2

   (JNIEnv* env, jobject this, jobject transport, jstring topic)

{

     mamaPublisher   cPublisher          =   NULL;

@@ -125,6 +125,66 @@ JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

     return;

}

 

+ /*

+ * Class:     com_wombat_mama_MamaPublisher

+ * Method:    _create

+ * Signature: (Lcom/wombat/mama/MamaTransport;Ljava/lang/String;Ljava/lang/String;)V

+ */

+JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create__Lcom_wombat_mama_MamaTransport_2Ljava_lang_String_2Ljava_lang_String_2

+  (JNIEnv* env, jobject this, jobject transport, jstring source, jstring symbol)

+{

+             mamaPublisher   cPublisher          =   NULL;

+    mamaTransport   cTransport          =   NULL;

+    const char*     cSource             =   NULL;

+             const char*     cSymbol             =   NULL;

+    jlong           transportPointer    =   0;

+    mama_status     status              =   MAMA_STATUS_OK;

+    char errorString[UTILS_MAX_ERROR_STRING_LENGTH];

+            

+    /*Get the transport pointer*/

+    assert(transport!=NULL);

+    transportPointer = (*env)->GetLongField(env, transport,

+            transportPointerFieldId_g);

+    cTransport = CAST_JLONG_TO_POINTER(mamaTransport, transportPointer);

+    assert(transportPointer!=0);

+            

+    /*Get the char* from the jstring*/

+    if(NULL!=source)

+    {

+         cSource = (*env)->GetStringUTFChars(env,source,0);

+         if(!cSource)return;

+    }

+             if(NULL!=symbol)

+    {

+         cSymbol = (*env)->GetStringUTFChars(env,symbol,0);

+         if(!cSymbol)return;

+    }

+

+    if(MAMA_STATUS_OK!=(mamaPublisher_create(

+                    &cPublisher,

+                    cTransport,

+                    cSymbol,

+                    cSource,

+                    NULL)))

+    {

+        if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

+                             if(cSymbol)(*env)->ReleaseStringUTFChars(env,symbol, cSymbol);

+        utils_buildErrorStringForStatus(

+                errorString, UTILS_MAX_ERROR_STRING_LENGTH,

+                "Failed to create publisher.", status);

+        utils_throwMamaException(env,errorString);

+        return;

+    }

+

+    (*env)->SetLongField(env,this,publisherPointerFieldId_g,

+                         CAST_POINTER_TO_JLONG(cPublisher));

+       

+    if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

+             if(cSymbol)(*env)->ReleaseStringUTFChars(env,symbol, cSymbol);

+   

+    return;

+}

+

/*

  * Class:     com_wombat_mama_MamaPublisher

  * Method:    _send

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

index 0146945..c1e8dc8 100644

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

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

@@ -39,6 +39,11 @@ public class MamaPublisher

     {

         _create(transport,topic);

     }

+            

+             public void create (MamaTransport transport, String source, String symbol)

+    {

+        _create(transport,source,symbol);

+    }

     public void send (MamaMsg msg)

     {

@@ -77,6 +82,8 @@ public class MamaPublisher

     }

     private native void _create (MamaTransport transport, String topic);

+            

+             private native void _create (MamaTransport transport, String source, String symbol);

     private native void _send (MamaMsg msg);

--

1.8.4.msysgit.0

 

 

Chad Meyer | Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan | 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

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.


VectorChar and VectorBool field type enumerator

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Hi folks,

 

I noticed that VectorChar and VectorBool do not have  a field type enumerator  in Mama (i.e. mamaFieldType enum in mama/fielddesc.h). Also, the related code for VectorChar and VectorBool in C/ C++, C#, JNI does not have the type related implementations for these vector types as compared to other vector types, such as VectorU32 (enumerator: MAMA_FIELD_TYPE_VECTOR_U32).

 

I imagine these types may not be widely and there are alternatives field types for them(e.g. Opaque, String and unsinged integer).

 

Should VectorChar and VectorBool  types be included in the mamaFieldType enum? For example with the numbers shown below:

 

<code>

diff --git a/mama/c_cpp/src/c/mama/fielddesc.h b/mama/c_cpp/src/c/mama/fielddesc.h

index e3af6e1..a374489 100644

--- a/mama/c_cpp/src/c/mama/fielddesc.h

+++ b/mama/c_cpp/src/c/mama/fielddesc.h

@@ -90,6 +90,8 @@ typedef enum mamaFieldType_

     MAMA_FIELD_TYPE_PRICE         =   27,

 

     /** Array type support */

+    MAMA_FIELD_TYPE_VECTOR_BOOL   =   29,

+    MAMA_FIELD_TYPE_VECTOR_CHAR   =   30,

     MAMA_FIELD_TYPE_VECTOR_I8     =   34,

     MAMA_FIELD_TYPE_VECTOR_U8     =   35,

     MAMA_FIELD_TYPE_VECTOR_I16    =   36,

</code>

 

And then also have the corresponding type related changes in the rest of Mama codebase?

 

Regards,.

 

--Alireza


Re: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Tom Doust
 

Hi Glenn

 

I’m resubmitting that patch (attached and below). This now conforms with your comments

 

Tom

 

diff --git a/README b/README

index be1ad38..f278d0d 100644

--- a/README

+++ b/README

@@ -2,7 +2,7 @@ OpenMAMA Client Library

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

 Release: 2.3.1

-Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1

+Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release

 Project Page

------------

diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c

index 7f7d605..a4e6cdf 100644

--- a/mama/c_cpp/src/c/dictionary.c

+++ b/mama/c_cpp/src/c/dictionary.c

@@ -495,6 +495,20 @@ mamaDictionary_getDictionaryMessage (

     return MAMA_STATUS_OK;

}

+mama_status mamaDictionary_populateDictionaryMessage(

+             mamaDictionary dictionary,

+             mamaMsg msg)

+{

+             mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary;

+

+             if (!impl) return MAMA_STATUS_NULL_ARG;

+             if (!msg) return MAMA_STATUS_INVALID_ARG;

+

+             populateMessageFromDictionary (impl, msg);

+

+             return MAMA_STATUS_OK;

+}

+

mama_status

mamaDictionary_createFieldDescriptor (

                 mamaDictionary       dictionary,

diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h

index 0eda958..faa7fe8 100644

--- a/mama/c_cpp/src/c/mama/dictionary.h

+++ b/mama/c_cpp/src/c/mama/dictionary.h

@@ -268,6 +268,20 @@ mamaDictionary_getDictionaryMessage (

     mamaMsg* msg);

 /**

+ * Fill a message with the data dictionary.

+ *

+ * An existing mama message is populated fromt he data dictionary

+ * This allows the caller to create the message on a specifc payload

+ *

+ * @param dictionary The Dictionary

+ * @param msg The address of the mamaMsg where the result is to be written

+ */

+MAMAExpDLL extern mama_status mamaDictionary_populateDictionaryMessage (

+    mamaDictionary dictionary,

+    mamaMsg msg);

+

+

+/**

  * Create a new field descriptor and add it to the dictionary.

  * New fields can be added to an existing dictionary obtained

  * from the MAMA infrastructure. This function can also be used

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Tom Doust
Sent: 03 September 2014 4:37 PM
To: Glenn McClements; Openmama-dev@...
Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Hi Glenn

 

Both of those of those points are accepted and I’ll re-submit a patch in a couple of days when I can get this back to the top of my todo list J

 

Is this function ever used anywhere other than in a bridge? We only use it in the context of a bridge building a message from the dictionary in order to publish it

 

Tom

 

From: Glenn McClements [mailto:gmcclements@...]
Sent: 03 September 2014 4:29 PM
To: Tom Doust; Openmama-dev@...
Subject: RE: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Cheers Tom. 

 

I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.

 

Two minor points about the signature: 

 

- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API

- There's no need for it to be pointer to a mamaMsg

 

As always, C++, .Net and Java/JNI will need this to be updated as well. 

 

Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.

 

Glenn 

 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...]
Sent: 03 September 2014 09:56
To: Openmama-dev@...
Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Hi

 

Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.

 

We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)

 

              // Prepare the OpenMAMA dictionary part of the message

#if defined(MAMA_DICTIONARY_PATCH)

              // provided mama has been patched for the new dictionary function we can create our own message on our own payload

              mamaMsg dictMsg=NULL;

              mamaMsg_createForPayload(&dictMsg, 'P');

              mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg);

#else

              mamaMsg dictMsg=NULL;

              mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg);

#endif

 

 

As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.

 

I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject

 

Best regards

 

Tom

 

The patch is also shown below

 

 

 

diff --git a/README b/README

index be1ad38..f278d0d 100644

--- a/README

+++ b/README

@@ -2,7 +2,7 @@ OpenMAMA Client Library

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

 Release: 2.3.1

-Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1

+Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release

 Project Page

------------

diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c

index 7f7d605..8a6d275 100644

--- a/mama/c_cpp/src/c/dictionary.c

+++ b/mama/c_cpp/src/c/dictionary.c

@@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage (

}

 mama_status

+             mamaDictionary_fillDictionaryMessage (

+             mamaDictionary dictionary,

+             mamaMsg* msg)

+{

+             mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary;

+

+             if (!impl) return MAMA_STATUS_NULL_ARG;

+             if (!msg) return MAMA_STATUS_INVALID_ARG;

+

+             populateMessageFromDictionary (impl, *msg);

+

+             return MAMA_STATUS_OK;

+}

+

+mama_status

mamaDictionary_createFieldDescriptor (

                 mamaDictionary       dictionary,

                 mama_fid_t           fid,

diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h

index 0eda958..40f7885 100644

--- a/mama/c_cpp/src/c/mama/dictionary.h

+++ b/mama/c_cpp/src/c/mama/dictionary.h

@@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage (

     mamaMsg* msg);

 /**

+ * Fill a message with the data dictionary.

+ *

+ * An existing mama message is populated fromt he data dictionary

+ * This allows the caller to create the message on a specifc payload

+ *

+ * @param dictionary The Dictionary

+ * @param msg The address of the mamaMsg where the result is to be written

+ */

+MAMAExpDLL

+extern mama_status

+mamaDictionary_fillDictionaryMessage (

+    mamaDictionary dictionary,

+    mamaMsg* msg);

+

+

+/**

  * Create a new field descriptor and add it to the dictionary.

  * New fields can be added to an existing dictionary obtained

  * from the MAMA infrastructure. This function can also be used

 

 

 

 

 

 

From: Tom Doust
Sent: 29 August 2014 10:12 AM
To: Openmama-dev@...
Subject: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Hi

 

mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)

 

 

creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.

 

Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.

 

I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.

 

I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.

 

 

Tom

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | skype:  tom.doust |  http://www.tick42.com


 

 


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.



Re: Enforcing field type on publish

Frank Quinn <fquinn.ni@...>
 

Guessing by your capitalization, I'm guessing this is C++? If so, have you considered mandating that all function calls use MamaFieldDescriptors pulled from a standardized dictionary rather than using string / fid pairs?

Cheers,
Frank


On Thu, Sep 4, 2014 at 9:33 PM, Glenn McClements <gmcclements@...> wrote:
There are a number of places where this *could* be done, but not all make sense to me:

- In the payload library - this doesn't feel right as I feel the payload should be 'dumb' and just trust the caller. Also it would need to be done for each supported payload. 

- In the payload bridge - same points as above

- In MamaMsg - this would work across all supported payloads, but again I think the payload should be trust the caller as to what fields should be what type and act a a simple wrapper 

- In a field cache (e.g. the C & C++ MamaFieldCache) - this makes the most sense to me as the logic for maintaining state about fields and if they have changed is already there, so extra rules and checks would belong here

With the current MamaFieldCache you could do this already if you primed the fields by creating them with the correct type on startup, this would depend on having a well known set of fields though because you don't want to be adding everything in the dictionary. You could also try this technique with the MamaMsg object, but it will be payload specific because some will throw an error if you try to update a field with a new type, and others may replace it.

Glenn 



From: Alpert, Reed [reed.alpert@...]
Sent: 03 September 2014 15:28
To: Glenn McClements; Openmama-dev@...

Subject: RE: Enforcing field type on publish

Hi,

 

Yes, the addString() is from MamaMsg.

 

The cache is our own market data infrastructure, not the MamaFieldCache.

In this case it is either Solace/SolCache or TREP RTIC.

 

We want business app dev groups to be able to look at the dictionary, see a field that is MamaPrice, and be guaranteed that MamaMsg.getPrice() will always work (although MamaPrice.getIsValidPrice() may return false).

A certain number of the type mismatches come from Excel, where a failed formula may populate a cell as #NA, and that gets published into a price/float field.

 

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: Glenn McClements [mailto:gmcclements@...]
Sent: Wednesday, September 03, 2014 3:10 PM
To: Alpert, Reed; Openmama-dev@...
Subject: RE: Enforcing field type on publish

 

Hi Guy,

When you refer to 'addString' below you mention a cache, but this is not a method of the C/C++MamaFieldCache

are you refering to your own cache object or actually a MamaMsg object?

 

Regards,

Glenn 

 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Alpert, Reed [reed.alpert@...]
Sent: 03 September 2014 13:59
To: Openmama-dev@...
Subject: [Openmama-dev] Enforcing field type on publish

Hi,

 

This is regarding a way to check that the field data type being published matches (closely) the dictionary data type.

 

The motivation for this is to prevent our internally published data caches from invalid data.

For example, if a field (name=MARK_PRICE fid=300) is a MamaPrice in the dictionary, and an app uses this:

                addString("MARK_PRICE", 300, "invalid price");

then we have a field that is now a string in the cache, and that causes problems with subscribing apps that use getPrice().

 

Currently we are looking to the bridges that we use (Tick42/TREP & Solace) to enforce these restrictions.

 

Adding this to the OpenMAMA layer is tricky, but allows a single policy to be enforced across multiple bridges. The main question from my point of view being how to set the policy. They can range from none (default), to most strict (published field's type must match dictionary), to common conversions supported (e.g., F32 -> F64), to a custom grid setting exactly what conversions are allowed.

 

I welcome any input from others who have run into this same issue, or found other ways to solve it.

 

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.


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


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.


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

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



Re: Enforcing field type on publish

Glenn McClements <gmcclements@...>
 

There are a number of places where this *could* be done, but not all make sense to me:

- In the payload library - this doesn't feel right as I feel the payload should be 'dumb' and just trust the caller. Also it would need to be done for each supported payload. 

- In the payload bridge - same points as above

- In MamaMsg - this would work across all supported payloads, but again I think the payload should be trust the caller as to what fields should be what type and act a a simple wrapper 

- In a field cache (e.g. the C & C++ MamaFieldCache) - this makes the most sense to me as the logic for maintaining state about fields and if they have changed is already there, so extra rules and checks would belong here

With the current MamaFieldCache you could do this already if you primed the fields by creating them with the correct type on startup, this would depend on having a well known set of fields though because you don't want to be adding everything in the dictionary. You could also try this technique with the MamaMsg object, but it will be payload specific because some will throw an error if you try to update a field with a new type, and others may replace it.

Glenn 



From: Alpert, Reed [reed.alpert@...]
Sent: 03 September 2014 15:28
To: Glenn McClements; Openmama-dev@...
Subject: RE: Enforcing field type on publish

Hi,

 

Yes, the addString() is from MamaMsg.

 

The cache is our own market data infrastructure, not the MamaFieldCache.

In this case it is either Solace/SolCache or TREP RTIC.

 

We want business app dev groups to be able to look at the dictionary, see a field that is MamaPrice, and be guaranteed that MamaMsg.getPrice() will always work (although MamaPrice.getIsValidPrice() may return false).

A certain number of the type mismatches come from Excel, where a failed formula may populate a cell as #NA, and that gets published into a price/float field.

 

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: Glenn McClements [mailto:gmcclements@...]
Sent: Wednesday, September 03, 2014 3:10 PM
To: Alpert, Reed; Openmama-dev@...
Subject: RE: Enforcing field type on publish

 

Hi Guy,

When you refer to 'addString' below you mention a cache, but this is not a method of the C/C++MamaFieldCache

are you refering to your own cache object or actually a MamaMsg object?

 

Regards,

Glenn 

 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Alpert, Reed [reed.alpert@...]
Sent: 03 September 2014 13:59
To: Openmama-dev@...
Subject: [Openmama-dev] Enforcing field type on publish

Hi,

 

This is regarding a way to check that the field data type being published matches (closely) the dictionary data type.

 

The motivation for this is to prevent our internally published data caches from invalid data.

For example, if a field (name=MARK_PRICE fid=300) is a MamaPrice in the dictionary, and an app uses this:

                addString("MARK_PRICE", 300, "invalid price");

then we have a field that is now a string in the cache, and that causes problems with subscribing apps that use getPrice().

 

Currently we are looking to the bridges that we use (Tick42/TREP & Solace) to enforce these restrictions.

 

Adding this to the OpenMAMA layer is tricky, but allows a single policy to be enforced across multiple bridges. The main question from my point of view being how to set the policy. They can range from none (default), to most strict (published field's type must match dictionary), to common conversions supported (e.g., F32 -> F64), to a custom grid setting exactly what conversions are allowed.

 

I welcome any input from others who have run into this same issue, or found other ways to solve it.

 

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.


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


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.


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


Re: Enforcing field type on publish

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

Hi,

 

Yes, the addString() is from MamaMsg.

 

The cache is our own market data infrastructure, not the MamaFieldCache.

In this case it is either Solace/SolCache or TREP RTIC.

 

We want business app dev groups to be able to look at the dictionary, see a field that is MamaPrice, and be guaranteed that MamaMsg.getPrice() will always work (although MamaPrice.getIsValidPrice() may return false).

A certain number of the type mismatches come from Excel, where a failed formula may populate a cell as #NA, and that gets published into a price/float field.

 

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: Glenn McClements [mailto:gmcclements@...]
Sent: Wednesday, September 03, 2014 3:10 PM
To: Alpert, Reed; Openmama-dev@...
Subject: RE: Enforcing field type on publish

 

Hi Guy,

When you refer to 'addString' below you mention a cache, but this is not a method of the C/C++MamaFieldCache

are you refering to your own cache object or actually a MamaMsg object?

 

Regards,

Glenn 

 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Alpert, Reed [reed.alpert@...]
Sent: 03 September 2014 13:59
To: Openmama-dev@...
Subject: [Openmama-dev] Enforcing field type on publish

Hi,

 

This is regarding a way to check that the field data type being published matches (closely) the dictionary data type.

 

The motivation for this is to prevent our internally published data caches from invalid data.

For example, if a field (name=MARK_PRICE fid=300) is a MamaPrice in the dictionary, and an app uses this:

                addString("MARK_PRICE", 300, "invalid price");

then we have a field that is now a string in the cache, and that causes problems with subscribing apps that use getPrice().

 

Currently we are looking to the bridges that we use (Tick42/TREP & Solace) to enforce these restrictions.

 

Adding this to the OpenMAMA layer is tricky, but allows a single policy to be enforced across multiple bridges. The main question from my point of view being how to set the policy. They can range from none (default), to most strict (published field's type must match dictionary), to common conversions supported (e.g., F32 -> F64), to a custom grid setting exactly what conversions are allowed.

 

I welcome any input from others who have run into this same issue, or found other ways to solve it.

 

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.


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


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: Enforcing field type on publish

Glenn McClements <gmcclements@...>
 

Hi Guy,
When you refer to 'addString' below you mention a cache, but this is not a method of the C/C++MamaFieldCache are you refering to your own cache object or actually a MamaMsg object?

Regards,
Glenn 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Alpert, Reed [reed.alpert@...]
Sent: 03 September 2014 13:59
To: Openmama-dev@...
Subject: [Openmama-dev] Enforcing field type on publish

Hi,

 

This is regarding a way to check that the field data type being published matches (closely) the dictionary data type.

 

The motivation for this is to prevent our internally published data caches from invalid data.

For example, if a field (name=MARK_PRICE fid=300) is a MamaPrice in the dictionary, and an app uses this:

                addString("MARK_PRICE", 300, "invalid price");

then we have a field that is now a string in the cache, and that causes problems with subscribing apps that use getPrice().

 

Currently we are looking to the bridges that we use (Tick42/TREP & Solace) to enforce these restrictions.

 

Adding this to the OpenMAMA layer is tricky, but allows a single policy to be enforced across multiple bridges. The main question from my point of view being how to set the policy. They can range from none (default), to most strict (published field's type must match dictionary), to common conversions supported (e.g., F32 -> F64), to a custom grid setting exactly what conversions are allowed.

 

I welcome any input from others who have run into this same issue, or found other ways to solve it.

 

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.


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


Enforcing field type on publish

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

Hi,

 

This is regarding a way to check that the field data type being published matches (closely) the dictionary data type.

 

The motivation for this is to prevent our internally published data caches from invalid data.

For example, if a field (name=MARK_PRICE fid=300) is a MamaPrice in the dictionary, and an app uses this:

                addString("MARK_PRICE", 300, "invalid price");

then we have a field that is now a string in the cache, and that causes problems with subscribing apps that use getPrice().

 

Currently we are looking to the bridges that we use (Tick42/TREP & Solace) to enforce these restrictions.

 

Adding this to the OpenMAMA layer is tricky, but allows a single policy to be enforced across multiple bridges. The main question from my point of view being how to set the policy. They can range from none (default), to most strict (published field's type must match dictionary), to common conversions supported (e.g., F32 -> F64), to a custom grid setting exactly what conversions are allowed.

 

I welcome any input from others who have run into this same issue, or found other ways to solve it.

 

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.


[PATCH 2.3.1 1/1] Common: variable expansion in property value on the last line of properties file fails

Guy <guy.tal@...>
 

Hi,

The properties file parser fails to expand variable if such exists in a value that is also at the last line in the properties file.
For example, Consider <EOF> as the last character in file, if the last property in the file is as follows:
my.property=$(SOME_VALUE)<EOF>
and $(SOME_VALUE)=Hello World, we would expect my.property to be "Hello World", but it doesn't, it remains $(SOME_VALUE)

The properties file parser expandss environment variable if such exist inside a property value, but not if the value is the last one before end-of-file.

The solution is to check if there are key and value already parsed also when reaching end of file.
Plese look at common/c_cpp/src/c/properties.l from line 159:
<<EOF>> { /* Handle EOF right at the end of a */
/* value string */
if ( curKey && curValue )
{
replaceValue = propertiesImpl_ReplaceEnvironmentVariable(curValue); //<- beginning of the missing part
if(replaceValue != NULL)
{
/* Delete the original value */
free(curValue);

/* Copy the replaced value into the
* current value pointer. */
curValue = replaceValue;
} //<- that is all

I opened a bug at:
http://bugs.openmama.org/show_bug.cgi?id=156

I provide here a patch of the lex file for review.

Regards,
Guy Tal
Tick42


Re: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Glenn McClements <gmcclements@...>
 

It would generally be used in publishing applications, but as it's public I've no visibility how much it's used in the wild in other places.

We're also looking at some cross platform macros for deprecating functions, so we can consider mamaDictionary_getDictionaryMessage() to be officially marked as deprecated when _populate is put in. 

Glenn 


From: Tom Doust [tom.doust@...]
Sent: 03 September 2014 11:37
To: Glenn McClements; Openmama-dev@...
Subject: RE: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Hi Glenn

 

Both of those of those points are accepted and I’ll re-submit a patch in a couple of days when I can get this back to the top of my todo list J

 

Is this function ever used anywhere other than in a bridge? We only use it in the context of a bridge building a message from the dictionary in order to publish it

 

Tom

 

From: Glenn McClements [mailto:gmcclements@...]
Sent: 03 September 2014 4:29 PM
To: Tom Doust; Openmama-dev@...
Subject: RE: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Cheers Tom. 

 

I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.

 

Two minor points about the signature: 

 

- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API

- There's no need for it to be pointer to a mamaMsg

 

As always, C++, .Net and Java/JNI will need this to be updated as well. 

 

Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.

 

Glenn 

 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...]
Sent: 03 September 2014 09:56
To: Openmama-dev@...
Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Hi

 

Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.

 

We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)

 

              // Prepare the OpenMAMA dictionary part of the message

#if defined(MAMA_DICTIONARY_PATCH)

              // provided mama has been patched for the new dictionary function we can create our own message on our own payload

              mamaMsg dictMsg=NULL;

              mamaMsg_createForPayload(&dictMsg, 'P');

              mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg);

#else

              mamaMsg dictMsg=NULL;

              mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg);

#endif

 

 

As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.

 

I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject

 

Best regards

 

Tom

 

The patch is also shown below

 

 

 

diff --git a/README b/README

index be1ad38..f278d0d 100644

--- a/README

+++ b/README

@@ -2,7 +2,7 @@ OpenMAMA Client Library

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

 Release: 2.3.1

-Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1

+Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release

 Project Page

------------

diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c

index 7f7d605..8a6d275 100644

--- a/mama/c_cpp/src/c/dictionary.c

+++ b/mama/c_cpp/src/c/dictionary.c

@@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage (

}

 mama_status

+             mamaDictionary_fillDictionaryMessage (

+             mamaDictionary dictionary,

+             mamaMsg* msg)

+{

+             mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary;

+

+             if (!impl) return MAMA_STATUS_NULL_ARG;

+             if (!msg) return MAMA_STATUS_INVALID_ARG;

+

+             populateMessageFromDictionary (impl, *msg);

+

+             return MAMA_STATUS_OK;

+}

+

+mama_status

mamaDictionary_createFieldDescriptor (

                 mamaDictionary       dictionary,

                 mama_fid_t           fid,

diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h

index 0eda958..40f7885 100644

--- a/mama/c_cpp/src/c/mama/dictionary.h

+++ b/mama/c_cpp/src/c/mama/dictionary.h

@@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage (

     mamaMsg* msg);

 /**

+ * Fill a message with the data dictionary.

+ *

+ * An existing mama message is populated fromt he data dictionary

+ * This allows the caller to create the message on a specifc payload

+ *

+ * @param dictionary The Dictionary

+ * @param msg The address of the mamaMsg where the result is to be written

+ */

+MAMAExpDLL

+extern mama_status

+mamaDictionary_fillDictionaryMessage (

+    mamaDictionary dictionary,

+    mamaMsg* msg);

+

+

+/**

  * Create a new field descriptor and add it to the dictionary.

  * New fields can be added to an existing dictionary obtained

  * from the MAMA infrastructure. This function can also be used

 

 

 

 

 

 

From: Tom Doust
Sent: 29 August 2014 10:12 AM
To: Openmama-dev@...
Subject: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Hi

 

mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)

 

 

creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.

 

Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.

 

I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.

 

I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.

 

 

Tom

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | skype:  tom.doust |  http://www.tick42.com


 

 


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


Re: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Tom Doust
 

Hi Glenn

 

Both of those of those points are accepted and I’ll re-submit a patch in a couple of days when I can get this back to the top of my todo list J

 

Is this function ever used anywhere other than in a bridge? We only use it in the context of a bridge building a message from the dictionary in order to publish it

 

Tom

 

From: Glenn McClements [mailto:gmcclements@...]
Sent: 03 September 2014 4:29 PM
To: Tom Doust; Openmama-dev@...
Subject: RE: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Cheers Tom. 

 

I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.

 

Two minor points about the signature: 

 

- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API

- There's no need for it to be pointer to a mamaMsg

 

As always, C++, .Net and Java/JNI will need this to be updated as well. 

 

Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.

 

Glenn 

 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...]
Sent: 03 September 2014 09:56
To: Openmama-dev@...
Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Hi

 

Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.

 

We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)

 

              // Prepare the OpenMAMA dictionary part of the message

#if defined(MAMA_DICTIONARY_PATCH)

              // provided mama has been patched for the new dictionary function we can create our own message on our own payload

              mamaMsg dictMsg=NULL;

              mamaMsg_createForPayload(&dictMsg, 'P');

              mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg);

#else

              mamaMsg dictMsg=NULL;

              mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg);

#endif

 

 

As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.

 

I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject

 

Best regards

 

Tom

 

The patch is also shown below

 

 

 

diff --git a/README b/README

index be1ad38..f278d0d 100644

--- a/README

+++ b/README

@@ -2,7 +2,7 @@ OpenMAMA Client Library

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

 Release: 2.3.1

-Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1

+Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release

 Project Page

------------

diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c

index 7f7d605..8a6d275 100644

--- a/mama/c_cpp/src/c/dictionary.c

+++ b/mama/c_cpp/src/c/dictionary.c

@@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage (

}

 mama_status

+             mamaDictionary_fillDictionaryMessage (

+             mamaDictionary dictionary,

+             mamaMsg* msg)

+{

+             mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary;

+

+             if (!impl) return MAMA_STATUS_NULL_ARG;

+             if (!msg) return MAMA_STATUS_INVALID_ARG;

+

+             populateMessageFromDictionary (impl, *msg);

+

+             return MAMA_STATUS_OK;

+}

+

+mama_status

mamaDictionary_createFieldDescriptor (

                 mamaDictionary       dictionary,

                 mama_fid_t           fid,

diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h

index 0eda958..40f7885 100644

--- a/mama/c_cpp/src/c/mama/dictionary.h

+++ b/mama/c_cpp/src/c/mama/dictionary.h

@@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage (

     mamaMsg* msg);

 /**

+ * Fill a message with the data dictionary.

+ *

+ * An existing mama message is populated fromt he data dictionary

+ * This allows the caller to create the message on a specifc payload

+ *

+ * @param dictionary The Dictionary

+ * @param msg The address of the mamaMsg where the result is to be written

+ */

+MAMAExpDLL

+extern mama_status

+mamaDictionary_fillDictionaryMessage (

+    mamaDictionary dictionary,

+    mamaMsg* msg);

+

+

+/**

  * Create a new field descriptor and add it to the dictionary.

  * New fields can be added to an existing dictionary obtained

  * from the MAMA infrastructure. This function can also be used

 

 

 

 

 

 

From: Tom Doust
Sent: 29 August 2014 10:12 AM
To: Openmama-dev@...
Subject: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Hi

 

mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)

 

 

creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.

 

Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.

 

I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.

 

I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.

 

 

Tom

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | skype:  tom.doust |  http://www.tick42.com


 

 


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.



Re: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Glenn McClements <gmcclements@...>
 

Also having the user create the message makes it explicit who owns the memory which I like as well. 

Glenn 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Glenn McClements [gmcclements@...]
Sent: 03 September 2014 11:28
To: Tom Doust; Openmama-dev@...
Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Cheers Tom. 

I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.

Two minor points about the signature: 

- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API
- There's no need for it to be pointer to a mamaMsg

As always, C++, .Net and Java/JNI will need this to be updated as well. 

Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.

Glenn 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...]
Sent: 03 September 2014 09:56
To: Openmama-dev@...
Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Hi

 

Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.

 

We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)

 

              // Prepare the OpenMAMA dictionary part of the message

#if defined(MAMA_DICTIONARY_PATCH)

              // provided mama has been patched for the new dictionary function we can create our own message on our own payload

              mamaMsg dictMsg=NULL;

              mamaMsg_createForPayload(&dictMsg, 'P');

              mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg);

#else

              mamaMsg dictMsg=NULL;

              mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg);

#endif

 

 

As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.

 

I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject

 

Best regards

 

Tom

 

The patch is also shown below

 

 

 

diff --git a/README b/README

index be1ad38..f278d0d 100644

--- a/README

+++ b/README

@@ -2,7 +2,7 @@ OpenMAMA Client Library

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

 Release: 2.3.1

-Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1

+Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release

 Project Page

------------

diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c

index 7f7d605..8a6d275 100644

--- a/mama/c_cpp/src/c/dictionary.c

+++ b/mama/c_cpp/src/c/dictionary.c

@@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage (

}

 mama_status

+             mamaDictionary_fillDictionaryMessage (

+             mamaDictionary dictionary,

+             mamaMsg* msg)

+{

+             mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary;

+

+             if (!impl) return MAMA_STATUS_NULL_ARG;

+             if (!msg) return MAMA_STATUS_INVALID_ARG;

+

+             populateMessageFromDictionary (impl, *msg);

+

+             return MAMA_STATUS_OK;

+}

+

+mama_status

mamaDictionary_createFieldDescriptor (

                 mamaDictionary       dictionary,

                 mama_fid_t           fid,

diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h

index 0eda958..40f7885 100644

--- a/mama/c_cpp/src/c/mama/dictionary.h

+++ b/mama/c_cpp/src/c/mama/dictionary.h

@@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage (

     mamaMsg* msg);

 /**

+ * Fill a message with the data dictionary.

+ *

+ * An existing mama message is populated fromt he data dictionary

+ * This allows the caller to create the message on a specifc payload

+ *

+ * @param dictionary The Dictionary

+ * @param msg The address of the mamaMsg where the result is to be written

+ */

+MAMAExpDLL

+extern mama_status

+mamaDictionary_fillDictionaryMessage (

+    mamaDictionary dictionary,

+    mamaMsg* msg);

+

+

+/**

  * Create a new field descriptor and add it to the dictionary.

  * New fields can be added to an existing dictionary obtained

  * from the MAMA infrastructure. This function can also be used

 

 

 

 

 

 

From: Tom Doust
Sent: 29 August 2014 10:12 AM
To: Openmama-dev@...
Subject: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Hi

 

mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)

 

 

creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.

 

Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.

 

I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.

 

I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.

 

 

Tom

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | skype:  tom.doust |  http://www.tick42.com


 

 


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


Re: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Glenn McClements <gmcclements@...>
 

Cheers Tom. 

I think this way is cleaner than passing in a payload ID or bridge to the dictionary functions, as it keeps all the payload specific stuff in the mamaMsg calls where it belongs.

Two minor points about the signature: 

- I'd prefer 'populate' rather than 'fill', as populate is used elsewhere in the API
- There's no need for it to be pointer to a mamaMsg

As always, C++, .Net and Java/JNI will need this to be updated as well. 

Also to note that we'll be deprecating the use of the payload enum identifier in favour of a bridge handle. This won't make a difference to this way of doing it though.

Glenn 


From: openmama-dev-bounces@... [openmama-dev-bounces@...] on behalf of Tom Doust [tom.doust@...]
Sent: 03 September 2014 09:56
To: Openmama-dev@...
Subject: Re: [Openmama-dev] problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Hi

 

Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.

 

We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)

 

              // Prepare the OpenMAMA dictionary part of the message

#if defined(MAMA_DICTIONARY_PATCH)

              // provided mama has been patched for the new dictionary function we can create our own message on our own payload

              mamaMsg dictMsg=NULL;

              mamaMsg_createForPayload(&dictMsg, 'P');

              mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg);

#else

              mamaMsg dictMsg=NULL;

              mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg);

#endif

 

 

As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.

 

I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject

 

Best regards

 

Tom

 

The patch is also shown below

 

 

 

diff --git a/README b/README

index be1ad38..f278d0d 100644

--- a/README

+++ b/README

@@ -2,7 +2,7 @@ OpenMAMA Client Library

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

 Release: 2.3.1

-Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1

+Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release

 Project Page

------------

diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c

index 7f7d605..8a6d275 100644

--- a/mama/c_cpp/src/c/dictionary.c

+++ b/mama/c_cpp/src/c/dictionary.c

@@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage (

}

 mama_status

+             mamaDictionary_fillDictionaryMessage (

+             mamaDictionary dictionary,

+             mamaMsg* msg)

+{

+             mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary;

+

+             if (!impl) return MAMA_STATUS_NULL_ARG;

+             if (!msg) return MAMA_STATUS_INVALID_ARG;

+

+             populateMessageFromDictionary (impl, *msg);

+

+             return MAMA_STATUS_OK;

+}

+

+mama_status

mamaDictionary_createFieldDescriptor (

                 mamaDictionary       dictionary,

                 mama_fid_t           fid,

diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h

index 0eda958..40f7885 100644

--- a/mama/c_cpp/src/c/mama/dictionary.h

+++ b/mama/c_cpp/src/c/mama/dictionary.h

@@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage (

     mamaMsg* msg);

 /**

+ * Fill a message with the data dictionary.

+ *

+ * An existing mama message is populated fromt he data dictionary

+ * This allows the caller to create the message on a specifc payload

+ *

+ * @param dictionary The Dictionary

+ * @param msg The address of the mamaMsg where the result is to be written

+ */

+MAMAExpDLL

+extern mama_status

+mamaDictionary_fillDictionaryMessage (

+    mamaDictionary dictionary,

+    mamaMsg* msg);

+

+

+/**

  * Create a new field descriptor and add it to the dictionary.

  * New fields can be added to an existing dictionary obtained

  * from the MAMA infrastructure. This function can also be used

 

 

 

 

 

 

From: Tom Doust
Sent: 29 August 2014 10:12 AM
To: Openmama-dev@...
Subject: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Hi

 

mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)

 

 

creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.

 

Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.

 

I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.

 

I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.

 

 

Tom

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | skype:  tom.doust |  http://www.tick42.com


 

 


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


Re: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Tom Doust
 

Hi

 

Attached is a patch for OpenMAMA that provides an alternative function to populate a mamaMsg with the dictionary. This differs from the existining function by allowing the caller to pass a mamaMsg that has been pre-created on whatever payload is desired.

 

We are currently building and running the Tick42 RMDS bridge against OpenMAMA libraries with the patch applied. The new function is used something like this (with conditional compilation to show the ‘old’ version)

 

              // Prepare the OpenMAMA dictionary part of the message

#if defined(MAMA_DICTIONARY_PATCH)

              // provided mama has been patched for the new dictionary function we can create our own message on our own payload

              mamaMsg dictMsg=NULL;

              mamaMsg_createForPayload(&dictMsg, 'P');

              mama_status res = mamaDictionary_fillDictionaryMessage(dictionary, &dictMsg);

#else

              mamaMsg dictMsg=NULL;

              mama_status res = mamaDictionary_getDictionaryMessage (dictionary, &dictMsg);

#endif

 

 

As I said before, in theory, it shouldn’t matter which payload a dictionary message uses, but in a context when multiple bridges are loaded it’s desirable to know which code is being executed.

 

I’m interested to hear from other bridge developers any thoughts, opiniions or questions on this subject

 

Best regards

 

Tom

 

The patch is also shown below

 

 

 

diff --git a/README b/README

index be1ad38..f278d0d 100644

--- a/README

+++ b/README

@@ -2,7 +2,7 @@ OpenMAMA Client Library

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

 Release: 2.3.1

-Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/OpenMAMA-2.3.1

+Change Log: http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/tags/OpenMAMA-2.3.1-release

 Project Page

------------

diff --git a/mama/c_cpp/src/c/dictionary.c b/mama/c_cpp/src/c/dictionary.c

index 7f7d605..8a6d275 100644

--- a/mama/c_cpp/src/c/dictionary.c

+++ b/mama/c_cpp/src/c/dictionary.c

@@ -496,6 +496,21 @@ mamaDictionary_getDictionaryMessage (

}

 mama_status

+             mamaDictionary_fillDictionaryMessage (

+             mamaDictionary dictionary,

+             mamaMsg* msg)

+{

+             mamaDictionaryImpl* impl = (mamaDictionaryImpl*)dictionary;

+

+             if (!impl) return MAMA_STATUS_NULL_ARG;

+             if (!msg) return MAMA_STATUS_INVALID_ARG;

+

+             populateMessageFromDictionary (impl, *msg);

+

+             return MAMA_STATUS_OK;

+}

+

+mama_status

mamaDictionary_createFieldDescriptor (

                 mamaDictionary       dictionary,

                 mama_fid_t           fid,

diff --git a/mama/c_cpp/src/c/mama/dictionary.h b/mama/c_cpp/src/c/mama/dictionary.h

index 0eda958..40f7885 100644

--- a/mama/c_cpp/src/c/mama/dictionary.h

+++ b/mama/c_cpp/src/c/mama/dictionary.h

@@ -268,6 +268,22 @@ mamaDictionary_getDictionaryMessage (

     mamaMsg* msg);

 /**

+ * Fill a message with the data dictionary.

+ *

+ * An existing mama message is populated fromt he data dictionary

+ * This allows the caller to create the message on a specifc payload

+ *

+ * @param dictionary The Dictionary

+ * @param msg The address of the mamaMsg where the result is to be written

+ */

+MAMAExpDLL

+extern mama_status

+mamaDictionary_fillDictionaryMessage (

+    mamaDictionary dictionary,

+    mamaMsg* msg);

+

+

+/**

  * Create a new field descriptor and add it to the dictionary.

  * New fields can be added to an existing dictionary obtained

  * from the MAMA infrastructure. This function can also be used

 

 

 

 

 

 

From: Tom Doust
Sent: 29 August 2014 10:12 AM
To: Openmama-dev@...
Subject: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

 

Hi

 

mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)

 

 

creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.

 

Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.

 

I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.

 

I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.

 

 

Tom

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | skype:  tom.doust |  http://www.tick42.com  


 

 


Re: C99 support in OpenMama

Damian Maguire
 

Hey Benjamin, 

At present there are no firm plans to move towards full C99 support in OpenMAMA, at least until we see a much broader adoption of VS2013 - we always have to keep in mind the breadth of the current MAMA install base, and ensure that we can always build OpenMAMA to be compatible with it. Unfortunately this limits the scope for adopting newer tool chains/language specs.

In the Linux case, we compile with support for C99, but we don't use a number of the features which are missing within earlier VS versions (mixed declarations being the standard example). This is actually necessary since we rely on some C99 features being available (long long for example), which don't appear with C90. 

Hopefully that makes sense, but fire away if you have any other questions. 

Cheers, 

Damian 




On Tue, Sep 2, 2014 at 9:54 AM, Benjamin Taieb <benjamin.taieb@...> wrote:

Hi everyone,

I noticed that when compiling on Linux, flag -std=gnu99 is set, meaning support for C99.

 

However, on windows, VS started supporting C99 from VS2013:

http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx

 

Is that the intention that windows build will be moved to VS2013 and C99 used ?

 

I have my windows build against VS2012 at the moment, and I'm curious to get others openmamers (I just made that up) thoughts, experiences.

 

Cheers,

Ben.

 


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



Re: Wombat Queue Destroy

Damian Maguire
 

Hey Sam,

Unfortunately this is a weakness in the API for the Wombat Queue implementation - it really should have a wombatQueue_deallocate, but it isn't presently available. If you'd like to raise an issue in bugzilla (bugs.openmama.org) we can look at getting it added. Better yet, we'd be happy to accept a patch which addresses the issue in the queue.

Thanks, 

Damian


On Tue, Sep 2, 2014 at 7:20 PM, Sam Wilson <Sam.Wilson@...> wrote:
Hello!

I'm trying to use Wombat Queue, but I can't figure out how to safely
free a queue when the creation fails. Here's my example:

     wombatQueue queue;
     wombatQueueStatus status = wombatQueue_allocate(&queue);
     if (WOMBAT_QUEUE_OK != status) {
         return; // log the error state or what have you
     }

     status = wombatQueue_create(queue, MAX_SIZE, INITIAL_SIZE,
                                 CHUNK_SIZE);
     if (WOMBAT_QUEUE_OK != status) {
         wombatQueue_destroy(queue); // Doesn't work because the
                                     // queue hasn't been created.

         // So how do I free the memory allocated by
         // wombatQueue_allocate?
     }

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


Wombat Queue Destroy

Sam Wilson <Sam.Wilson@...>
 

Hello!

I'm trying to use Wombat Queue, but I can't figure out how to safely
free a queue when the creation fails. Here's my example:

wombatQueue queue;
wombatQueueStatus status = wombatQueue_allocate(&queue);
if (WOMBAT_QUEUE_OK != status) {
return; // log the error state or what have you
}

status = wombatQueue_create(queue, MAX_SIZE, INITIAL_SIZE,
CHUNK_SIZE);
if (WOMBAT_QUEUE_OK != status) {
wombatQueue_destroy(queue); // Doesn't work because the
// queue hasn't been created.

// So how do I free the memory allocated by
// wombatQueue_allocate?
}

Thanks for your help,
Sam


C99 support in OpenMama

Benjamin Taieb
 

Hi everyone,

I noticed that when compiling on Linux, flag -std=gnu99 is set, meaning support for C99.

 

However, on windows, VS started supporting C99 from VS2013:

http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx

 

Is that the intention that windows build will be moved to VS2013 and C99 used ?

 

I have my windows build against VS2012 at the moment, and I'm curious to get others openmamers (I just made that up) thoughts, experiences.

 

Cheers,

Ben.

 


Re: problem with mamaDictionary_getDictionaryMessage when multiple bridges are loaded

Damian Maguire
 

Hey Tom, 

I think the idea of an additional method for populating a message with a dictionary is spot on - something which passes in a pre-created message and fills it with the dictionary contents as in your second suggestion seems like a good fit to me. If you'd like to put together a patch and send it through to the list, I think that would help get the discussion going and maybe shake out some usecases we haven't thought of. 

Cheers, 

Damian


On Fri, Aug 29, 2014 at 10:12 AM, Tom Doust <tom.doust@...> wrote:

Hi

 

mama_status mamaDictionary_getDictionaryMessage (mamaDictionary dictionary,mamaMsg* msg)

 

 

creates the message it returns using mamaMsg_create (&tempMsg); this creates the message using the default payload which may not be the payload type for the bridge that is trying to populate a message with its dictionary.

 

Now, while in theory it shouldn’t really matter, in the real world it does, for a variety of reasons.

 

I can see 2 possible solutions, one is to extend the existing function signature to carry a payload id (or a bridge) so that a payload specific mamaMsg can be created, or better, implement a second function that allows the caller to pre-create the message that is passed in. This second solution would not affect any existing code.

 

I’ll create and submit a patch, but before I do I’m soliciting comments and proposals for better solutions.

 

 

Tom

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | skype:  tom.doust |  http://www.tick42.com  


 

 


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


981 - 1000 of 2306