Date   

Re: [PATCH 2/2] [MAMADOTNET] Add getName() to MamaTransport

Matt Mulhern
 

Hi,

This is a quick notification that this has been pushed to the OpenMAMA::next branch.

Thanks,
Matt Mulhern

On 21/05/2015 17:29, Gary Molloy wrote:

Testing Strategy

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

 

Modify the MamaPublisherCS.cs example application and add the following after you have created your publisher:

 

            publisher.create(transport, outboundTopic);

 

            MamaTransport aTransport = new MamaTransport();

            aTransport = publisher.getTransport();

            string tportName = aTransport.getName();

            Console.WriteLine("TEST:: getTransport name {0}.", tportName);

 

You can expect to see the following output:

 

> MamaPublisher.exe -m wmw -tport tcp_sub

Created inbound subscription.
TEST:: getTransport name tcp_sub. <--------------------------- test output
Publishing message to MAMA_TOPIC.
Publishing message to MAMA_TOPIC.
Publishing message to MAMA_TOPIC.
Publishing message to MAMA_TOPIC.

 

 

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

 

From 3abc196ba5a09beecbe000463c015c086c86fbea Mon Sep 17 00:00:00 2001

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

Date: Mon, 18 May 2015 13:55:43 +0100

Subject: [PATCH 2/2] [MAMADOTNET] Add getName() to MamaTransport

 

Function already exists for C / C++ / JNI

 

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

---

mama/dotnet/src/cs/MamaTransport.cs | 15 +++++++++++++++

1 file changed, 15 insertions(+)

 

diff --git a/mama/dotnet/src/cs/MamaTransport.cs b/mama/dotnet/src/cs/MamaTransport.cs

index fee71cb..11a8f71 100644

--- a/mama/dotnet/src/cs/MamaTransport.cs

+++ b/mama/dotnet/src/cs/MamaTransport.cs

@@ -260,6 +260,18 @@ namespace Wombat

                                  GC.KeepAlive(callback);

       }        

 

+      /// <summary>

+      /// Get the name of the transport.

+      /// </summary>

+      public string getName()

+      {

+                             // Get the transport name from the native layer

+                               IntPtr ret = IntPtr.Zero;

+                               CheckResultCode(NativeMethods.mamaTransport_getName(nativeHandle, ref ret));

+

+                               // Convert to an ANSI string

+                               return Marshal.PtrToStringAnsi(ret);

+      }

 

                               #region Implementation details

 

@@ -430,6 +442,9 @@ namespace Wombat

             [DllImport(Mama.DllName, CallingConvention = CallingConvention.Cdecl)]

             public static extern int mamaTransport_getQuality(IntPtr transport,

                                                               ref MamaQuality qual);

+            [DllImport(Mama.DllName, CallingConvention = CallingConvention.Cdecl)]

+            public static extern int mamaTransport_getName(IntPtr transport,

+                                                           ref IntPtr ret);

                                }

 

                               // state

--

2.1.0

 

 

 

Gary Molloy – SR Labs

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

g.molloy@...

 



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


Re: Socket pair used for timer addition

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

Just to update the list (update was already provided on the BZ ticket), the socketpair problem is currently being tracked via https://github.com/OpenMAMA/OpenMAMA/issues/26

 

Cheers,

Frank

 

From: Duane Pauls [mailto:Duane.Pauls@...]
Sent: 22 September 2015 16:46
To: Frank Quinn <f.quinn@...>; openmama-dev@...
Cc: David McKay <David.McKay@...>
Subject: RE: Socket pair used for timer addition

 

Hi Frank,

 

Thanks for picking up the patch.  I’ve attached another patch to bug 220 which applies the same fix to avis timers, if that saves you any effort.

 

I’ve created bug 222 to track the socketpair problem.  I’ve also attached a patch to the bug, which addresses the problem.  We run the unit tests regularly and haven’t seen an issue since applying the patch.

 

Cheers,

Duane

 

From: Frank Quinn [mailto:f.quinn@...]
Sent: Tuesday, September 22, 2015 3:54 AM
To: Duane Pauls;
openmama-dev@...
Cc: David McKay
Subject: RE: Socket pair used for timer addition

 

Thanks Duane,

 

Just realized we never informed the list but this was merged into next last week as well:

 

https://github.com/OpenMAMA/OpenMAMA/commit/a4a684e3ab0ce1ec6a2d5eff3c95c29c7cffee2f

 

Wrt the EAGAIN change, that sounds like a separate issue which just happens to be in the same area to me so I think a separate patch / pull request / github ticket would be appropriate here.

 

Also for future reference (we’ll do it this time via issue #25), could you also include avis fixes for code which is currently (and regrettably) duplicated such as the middleware bridge timer code?

 

Cheers.

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Duane Pauls
Sent: 04 September 2015 15:17
To:
openmama-dev@...
Cc: David McKay <
David.McKay@...>
Subject: Re: [Openmama-dev] Socket pair used for timer addition

 

One other note related to this: While debugging, I read 4 bytes from the socket (so that the number of bytes available dropped from 423 to 419), then continued the program.  This cleared the busy loop/deadlock condition and the unit test passed.  So it supports the theory that the socket was full and couldn’t be written.

 

This occurred on CentOS 6.5.

 

Duane

 

From: Duane Pauls
Sent: Friday, September 04, 2015 10:13 AM
To:
openmama-dev@...
Cc: David McKay
Subject: Socket pair used for timer addition

 

I’ve been running the timer unit tests repeatedly for over a week with the patch submitted in bug 220:

http://bugs.openmama.org/show_bug.cgi?id=220

 

MamaTimerTestCPP.ForTimer recently entered a busy loop + deadlock.  After debugging the problem, I don’t think the problem I’m seeing is specific to the patched OpenMAMA.  I’d like to open a quick discussion to see if my proposed fix sounds reasonable.

 

I saw that the socket write in _addTimer (a new function in the patch, but the same logic as the wwrite in the original OpenMAMA) was failing due to ‘EAGAIN’, so _addTimer entered a busy loop continually trying to write to the socket that was full.  The reader is unable to read from the socket since the lock is being held for the duration of the write, and the reader tries to take the lock before reading.  By calling ioctl(heapImpl->mSockPair[0], FIONREAD, buf), I determined there were 423 bytes available for reading.  It seems this is the maximum number of records that can be written to a socket pair in Linux.  See:

http://stackoverflow.com/questions/10899814/af-unix-socket-overhead

 

I’m thinking that to fix this, we can simply ignore EAGAIN (and for maximum portability EWOULDBLOCK as well).  If the socket is full, there are plenty of records there to wake up the reader, so it isn’t necessary to add another ‘wake-up’ record.  Since the lock was taken before the new timer was added and continues to be held through the write, we can just release the lock knowing the reader has something to wake it up.

 

If there are no objections, I’ll submit another patch along with bug 220.  Or should I open a separate bug?

 

I’m also interested to know if anyone can provide a timeline for applying the patch in bug 220 to a release.

 

Cheers,

Duane


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


OpenMAMA Roadmap - Round 2

Damian Maguire
 

Hey all,

As noted a few weeks ago, we have another OpenMAMA Roadmap discussion
coming up later this week, on Thursday 24th in Central London. As
before there's a few of the core team going to be floating around and
leading the discussions, as well as representation from both the
Steering Committee and Advisory Groups, so hopefully a few of you will
be able to take the time to pop down and join the discussions.

Agenda this time around:

Source Discovery:

Discussion and design of a mechanism to allow OpenMAMA applications to
advertise query sources and symbols on an OpenMAMA platform.

- - Break - -

Publisher Events:

New feature to allow delivery or non-delivery notifications for
published messages.

- - Break - -

Local Data Sharing:

Discussion and design of a mechanism to allow “consuming" OpenMAMA
applications to share data locally.

We're also hosting a few drinks after the discussion, kicking off
around 5:30pm in Corney and Barrow, City Point, London EC2Y 9HT.
Someone said Jamie was picking up the tab, so best get in while the
going is good.

Hope to see you all there,

Cheers,

The OpenMAMA Steering Committee and Advisory Group


Re: Socket pair used for timer addition

Duane Pauls <Duane.Pauls@...>
 

Hi Frank,

 

Thanks for picking up the patch.  I’ve attached another patch to bug 220 which applies the same fix to avis timers, if that saves you any effort.

 

I’ve created bug 222 to track the socketpair problem.  I’ve also attached a patch to the bug, which addresses the problem.  We run the unit tests regularly and haven’t seen an issue since applying the patch.

 

Cheers,

Duane

 

From: Frank Quinn [mailto:f.quinn@...]
Sent: Tuesday, September 22, 2015 3:54 AM
To: Duane Pauls; openmama-dev@...
Cc: David McKay
Subject: RE: Socket pair used for timer addition

 

Thanks Duane,

 

Just realized we never informed the list but this was merged into next last week as well:

 

https://github.com/OpenMAMA/OpenMAMA/commit/a4a684e3ab0ce1ec6a2d5eff3c95c29c7cffee2f

 

Wrt the EAGAIN change, that sounds like a separate issue which just happens to be in the same area to me so I think a separate patch / pull request / github ticket would be appropriate here.

 

Also for future reference (we’ll do it this time via issue #25), could you also include avis fixes for code which is currently (and regrettably) duplicated such as the middleware bridge timer code?

 

Cheers.

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Duane Pauls
Sent: 04 September 2015 15:17
To: openmama-dev@...
Cc: David McKay <David.McKay@...>
Subject: Re: [Openmama-dev] Socket pair used for timer addition

 

One other note related to this: While debugging, I read 4 bytes from the socket (so that the number of bytes available dropped from 423 to 419), then continued the program.  This cleared the busy loop/deadlock condition and the unit test passed.  So it supports the theory that the socket was full and couldn’t be written.

 

This occurred on CentOS 6.5.

 

Duane

 

From: Duane Pauls
Sent: Friday, September 04, 2015 10:13 AM
To: openmama-dev@...
Cc: David McKay
Subject: Socket pair used for timer addition

 

I’ve been running the timer unit tests repeatedly for over a week with the patch submitted in bug 220:

http://bugs.openmama.org/show_bug.cgi?id=220

 

MamaTimerTestCPP.ForTimer recently entered a busy loop + deadlock.  After debugging the problem, I don’t think the problem I’m seeing is specific to the patched OpenMAMA.  I’d like to open a quick discussion to see if my proposed fix sounds reasonable.

 

I saw that the socket write in _addTimer (a new function in the patch, but the same logic as the wwrite in the original OpenMAMA) was failing due to ‘EAGAIN’, so _addTimer entered a busy loop continually trying to write to the socket that was full.  The reader is unable to read from the socket since the lock is being held for the duration of the write, and the reader tries to take the lock before reading.  By calling ioctl(heapImpl->mSockPair[0], FIONREAD, buf), I determined there were 423 bytes available for reading.  It seems this is the maximum number of records that can be written to a socket pair in Linux.  See:

http://stackoverflow.com/questions/10899814/af-unix-socket-overhead

 

I’m thinking that to fix this, we can simply ignore EAGAIN (and for maximum portability EWOULDBLOCK as well).  If the socket is full, there are plenty of records there to wake up the reader, so it isn’t necessary to add another ‘wake-up’ record.  Since the lock was taken before the new timer was added and continues to be held through the write, we can just release the lock knowing the reader has something to wake it up.

 

If there are no objections, I’ll submit another patch along with bug 220.  Or should I open a separate bug?

 

I’m also interested to know if anyone can provide a timeline for applying the patch in bug 220 to a release.

 

Cheers,

Duane


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: [PATCH 2.3.3] mamac: added enums for HMS middleware

Frank Quinn <f.quinn@...>
 

Hi Jorg,

 

This is now merged into the next branch.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Matt Mulhern
Sent: 08 September 2015 09:29
To: Jörg Hansper <joerg.hansper@...>; openmama-dev@...
Subject: Re: [Openmama-dev] [PATCH 2.3.3] mamac: added enums for HMS middleware

 

Hi Jörg,
Thanks for the patch. We'll get this into the next branch as soon as possible.

Thanks,
Matt Mulhern

On 01/09/2015 19:39, Jörg Hansper wrote:

This patch follows an official request for OpenMAMA enumerations for HMS

(Hardware based Messaging System) developed by BCC Group.

The new enum values (based on the recent version 2.3.3) are:

1. for mamaMiddleware:

MAMA_MIDDLEWARE_HMS=17 (corresponding string: “hms”)

2. for mamaPayloadType:

MAMA_PAYLOAD_HMS='H' (corresponding string: “HMS”)

 

Submitted by:

Jörg Hansper joerg.hansper@...

 

From 268494fe9b999f6cfa371ecb6e45e9a6974f00f8 Mon Sep 17 00:00:00 2001

From: Joerg Hansper <joerg.hansper@...>

Date: Tue, 1 Sep 2015 18:47:50 +0200

Subject: [PATCH] Added enums for HMS

 

---

mama/c_cpp/src/c/mama/middleware.h | 3 ++-

mama/c_cpp/src/c/mama/msg.h        | 1 +

mama/c_cpp/src/c/middleware.c      | 9 +++++++--

mama/c_cpp/src/c/msg.c             | 2 ++

4 files changed, 12 insertions(+), 3 deletions(-)

 

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

index 51225a2..6a0d028 100644

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

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

@@ -50,7 +50,8 @@ typedef enum mamaMiddleware_

     MAMA_MIDDLEWARE_INRUSH  = 14,

     MAMA_MIDDLEWARE_LBMKOMODO = 15,

     MAMA_MIDDLEWARE_UMDSKOMODO = 16,

-    MAMA_MIDDLEWARE_MAX     = 17,

+    MAMA_MIDDLEWARE_HMS     = 17,

+    MAMA_MIDDLEWARE_MAX     = 18,

    MAMA_MIDDLEWARE_UNKNOWN = 99

} mamaMiddleware;

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

index 2fbbe6b..7026da7 100644

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

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

@@ -47,6 +47,7 @@ typedef enum mamaPayloadType_

     MAMA_PAYLOAD_AVIS       = 'A',

     MAMA_PAYLOAD_TICK42BLP  = 'B',

     MAMA_PAYLOAD_FAST       = 'F',

+    MAMA_PAYLOAD_HMS        = 'H',

     MAMA_PAYLOAD_RAI        = 'I',

     MAMA_PAYLOAD_KWANTUM    = 'K',

     MAMA_PAYLOAD_UMS        = 'L',

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

index f966491..5980ec0 100644

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

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

@@ -79,7 +79,10 @@ mamaMiddleware_convertFromString (const char*  str)

     if (strcasecmp (str, "umdskomodo") == 0)

         return MAMA_MIDDLEWARE_UMDSKOMODO;

-

+   

+    if (strcasecmp (str, "hms") == 0)

+        return MAMA_MIDDLEWARE_HMS;

+   

     return MAMA_MIDDLEWARE_UNKNOWN;

}

@@ -123,7 +126,9 @@ mamaMiddleware_convertToString (mamaMiddleware  middleware)

             return "lbmkomodo";

         case MAMA_MIDDLEWARE_UMDSKOMODO:

             return "umdskomodo";

-        default:

+        case MAMA_MIDDLEWARE_HMS:

+            return "hms";       

+             default:

             return "unknown";

     }

}

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

index 3fa30a1..f589883 100644

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

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

@@ -378,6 +378,8 @@ mamaPayload_convertToString (mamaPayloadType payloadType)

             return "TICK42BLP";

         case MAMA_PAYLOAD_FAST:

             return "FAST";

+        case MAMA_PAYLOAD_HMS:

+            return "HMS";

         case MAMA_PAYLOAD_RAI:

             return "rai";

         case MAMA_PAYLOAD_UMS:

--

1.8.3.1

 




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

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: Socket pair used for timer addition

Frank Quinn <f.quinn@...>
 

Thanks Duane,

 

Just realized we never informed the list but this was merged into next last week as well:

 

https://github.com/OpenMAMA/OpenMAMA/commit/a4a684e3ab0ce1ec6a2d5eff3c95c29c7cffee2f

 

Wrt the EAGAIN change, that sounds like a separate issue which just happens to be in the same area to me so I think a separate patch / pull request / github ticket would be appropriate here.

 

Also for future reference (we’ll do it this time via issue #25), could you also include avis fixes for code which is currently (and regrettably) duplicated such as the middleware bridge timer code?

 

Cheers.

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Duane Pauls
Sent: 04 September 2015 15:17
To: openmama-dev@...
Cc: David McKay <David.McKay@...>
Subject: Re: [Openmama-dev] Socket pair used for timer addition

 

One other note related to this: While debugging, I read 4 bytes from the socket (so that the number of bytes available dropped from 423 to 419), then continued the program.  This cleared the busy loop/deadlock condition and the unit test passed.  So it supports the theory that the socket was full and couldn’t be written.

 

This occurred on CentOS 6.5.

 

Duane

 

From: Duane Pauls
Sent: Friday, September 04, 2015 10:13 AM
To: openmama-dev@...
Cc: David McKay
Subject: Socket pair used for timer addition

 

I’ve been running the timer unit tests repeatedly for over a week with the patch submitted in bug 220:

http://bugs.openmama.org/show_bug.cgi?id=220

 

MamaTimerTestCPP.ForTimer recently entered a busy loop + deadlock.  After debugging the problem, I don’t think the problem I’m seeing is specific to the patched OpenMAMA.  I’d like to open a quick discussion to see if my proposed fix sounds reasonable.

 

I saw that the socket write in _addTimer (a new function in the patch, but the same logic as the wwrite in the original OpenMAMA) was failing due to ‘EAGAIN’, so _addTimer entered a busy loop continually trying to write to the socket that was full.  The reader is unable to read from the socket since the lock is being held for the duration of the write, and the reader tries to take the lock before reading.  By calling ioctl(heapImpl->mSockPair[0], FIONREAD, buf), I determined there were 423 bytes available for reading.  It seems this is the maximum number of records that can be written to a socket pair in Linux.  See:

http://stackoverflow.com/questions/10899814/af-unix-socket-overhead

 

I’m thinking that to fix this, we can simply ignore EAGAIN (and for maximum portability EWOULDBLOCK as well).  If the socket is full, there are plenty of records there to wake up the reader, so it isn’t necessary to add another ‘wake-up’ record.  Since the lock was taken before the new timer was added and continues to be held through the write, we can just release the lock knowing the reader has something to wake it up.

 

If there are no objections, I’ll submit another patch along with bug 220.  Or should I open a separate bug?

 

I’m also interested to know if anyone can provide a timeline for applying the patch in bug 220 to a release.

 

Cheers,

Duane


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: [PATCH] QPID Fix For Missing Method Name

Frank Quinn <f.quinn@...>
 

Thanks Phil,

 

That’s merged into the next branch now.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Philip Preston
Sent: 21 September 2015 23:46
To: Frank Quinn <fquinn.ni@...>
Cc: OpenMAMA Dev List <openmama-dev@...>
Subject: Re: [Openmama-dev] [PATCH] QPID Fix For Missing Method Name

 

https://github.com/OpenMAMA/OpenMAMA/pull/24

 

On 21 Sep 2015, at 23:06, Frank Quinn <fquinn.ni@...> wrote:

 

Thanks Phil,

Yeah that works - another small, related change.

Cheers,
Frank

 

On Mon, 21 Sep 2015 23:02 Philip Preston <philippreston@...> wrote:

Can do via pull request.

 

 

Another minor one - local to Darwin.

 

 

On 21 Sep 2015, at 22:54, Frank Quinn <fquinn.ni@...> wrote:

 

Thanks Phil - both look good.

You want to do this via pull request or the old fashioned way?

https://github.com/OpenMAMA/OpenMAMA/wiki/Submission-Process

Cheers,
Frank

 

On Mon, 21 Sep 2015 22:41 Philip Preston <philippreston@...> wrote:

Missing method name in transport.c

Signed-off-by: Phil Preston <philippreston@...>
---
 mama/c_cpp/src/c/bridge/qpid/transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mama/c_cpp/src/c/bridge/qpid/transport.c b/mama/c_cpp/src/c/bridge/qpid/transport.c
index ab9755c..8b5ceba 100644
--- a/mama/c_cpp/src/c/bridge/qpid/transport.c
+++ b/mama/c_cpp/src/c/bridge/qpid/transport.c
@@ -938,7 +938,7 @@ qpidBridgeMamaTransportImpl_start (qpidTransportBridge* impl)
                           "Error Subscribing to %s : %s",
                           impl->mIncomingAddress,
                           PN_MESSENGER_ERROR(impl->mIncoming));
-                (impl->mIncoming);
+                qpidBridgeMamaTransportImpl_stopProtonMessenger(impl->mIncoming);
                 return MAMA_STATUS_PLATFORM;
             }
         }
--
2.3.2 (Apple Git-55)



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

 

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: [PATCH] QPID Fix For Missing Method Name

Philip Preston
 

On 21 Sep 2015, at 23:06, Frank Quinn <fquinn.ni@...> wrote:

Thanks Phil,

Yeah that works - another small, related change.

Cheers,
Frank


On Mon, 21 Sep 2015 23:02 Philip Preston <philippreston@...> wrote:
Can do via pull request.


Another minor one - local to Darwin.


On 21 Sep 2015, at 22:54, Frank Quinn <fquinn.ni@...> wrote:

Thanks Phil - both look good.

You want to do this via pull request or the old fashioned way?

https://github.com/OpenMAMA/OpenMAMA/wiki/Submission-Process

Cheers,
Frank


On Mon, 21 Sep 2015 22:41 Philip Preston <philippreston@...> wrote:
Missing method name in transport.c

Signed-off-by: Phil Preston <philippreston@...>
---
 mama/c_cpp/src/c/bridge/qpid/transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mama/c_cpp/src/c/bridge/qpid/transport.c b/mama/c_cpp/src/c/bridge/qpid/transport.c
index ab9755c..8b5ceba 100644
--- a/mama/c_cpp/src/c/bridge/qpid/transport.c
+++ b/mama/c_cpp/src/c/bridge/qpid/transport.c
@@ -938,7 +938,7 @@ qpidBridgeMamaTransportImpl_start (qpidTransportBridge* impl)
                           "Error Subscribing to %s : %s",
                           impl->mIncomingAddress,
                           PN_MESSENGER_ERROR(impl->mIncoming));
-                (impl->mIncoming);
+                qpidBridgeMamaTransportImpl_stopProtonMessenger(impl->mIncoming);
                 return MAMA_STATUS_PLATFORM;
             }
         }
--
2.3.2 (Apple Git-55)



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



Re: [PATCH] QPID Fix For Missing Method Name

Frank Quinn <fquinn.ni@...>
 

Thanks Phil,

Yeah that works - another small, related change.

Cheers,
Frank


On Mon, 21 Sep 2015 23:02 Philip Preston <philippreston@...> wrote:
Can do via pull request.


Another minor one - local to Darwin.


On 21 Sep 2015, at 22:54, Frank Quinn <fquinn.ni@...> wrote:

Thanks Phil - both look good.

You want to do this via pull request or the old fashioned way?

https://github.com/OpenMAMA/OpenMAMA/wiki/Submission-Process

Cheers,
Frank


On Mon, 21 Sep 2015 22:41 Philip Preston <philippreston@...> wrote:
Missing method name in transport.c

Signed-off-by: Phil Preston <philippreston@...>
---
 mama/c_cpp/src/c/bridge/qpid/transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mama/c_cpp/src/c/bridge/qpid/transport.c b/mama/c_cpp/src/c/bridge/qpid/transport.c
index ab9755c..8b5ceba 100644
--- a/mama/c_cpp/src/c/bridge/qpid/transport.c
+++ b/mama/c_cpp/src/c/bridge/qpid/transport.c
@@ -938,7 +938,7 @@ qpidBridgeMamaTransportImpl_start (qpidTransportBridge* impl)
                           "Error Subscribing to %s : %s",
                           impl->mIncomingAddress,
                           PN_MESSENGER_ERROR(impl->mIncoming));
-                (impl->mIncoming);
+                qpidBridgeMamaTransportImpl_stopProtonMessenger(impl->mIncoming);
                 return MAMA_STATUS_PLATFORM;
             }
         }
--
2.3.2 (Apple Git-55)



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


Re: [PATCH] QPID Fix For Missing Method Name

Philip Preston
 

Can do via pull request.


Another minor one - local to Darwin.


On 21 Sep 2015, at 22:54, Frank Quinn <fquinn.ni@...> wrote:

Thanks Phil - both look good.

You want to do this via pull request or the old fashioned way?

https://github.com/OpenMAMA/OpenMAMA/wiki/Submission-Process

Cheers,
Frank


On Mon, 21 Sep 2015 22:41 Philip Preston <philippreston@...> wrote:
Missing method name in transport.c

Signed-off-by: Phil Preston <philippreston@...>
---
 mama/c_cpp/src/c/bridge/qpid/transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mama/c_cpp/src/c/bridge/qpid/transport.c b/mama/c_cpp/src/c/bridge/qpid/transport.c
index ab9755c..8b5ceba 100644
--- a/mama/c_cpp/src/c/bridge/qpid/transport.c
+++ b/mama/c_cpp/src/c/bridge/qpid/transport.c
@@ -938,7 +938,7 @@ qpidBridgeMamaTransportImpl_start (qpidTransportBridge* impl)
                           "Error Subscribing to %s : %s",
                           impl->mIncomingAddress,
                           PN_MESSENGER_ERROR(impl->mIncoming));
-                (impl->mIncoming);
+                qpidBridgeMamaTransportImpl_stopProtonMessenger(impl->mIncoming);
                 return MAMA_STATUS_PLATFORM;
             }
         }
--
2.3.2 (Apple Git-55)



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


Re: [PATCH] QPID Fix For Missing Method Name

Frank Quinn <fquinn.ni@...>
 

Thanks Phil - both look good.

You want to do this via pull request or the old fashioned way?

https://github.com/OpenMAMA/OpenMAMA/wiki/Submission-Process

Cheers,
Frank


On Mon, 21 Sep 2015 22:41 Philip Preston <philippreston@...> wrote:
Missing method name in transport.c

Signed-off-by: Phil Preston <philippreston@...>
---
 mama/c_cpp/src/c/bridge/qpid/transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mama/c_cpp/src/c/bridge/qpid/transport.c b/mama/c_cpp/src/c/bridge/qpid/transport.c
index ab9755c..8b5ceba 100644
--- a/mama/c_cpp/src/c/bridge/qpid/transport.c
+++ b/mama/c_cpp/src/c/bridge/qpid/transport.c
@@ -938,7 +938,7 @@ qpidBridgeMamaTransportImpl_start (qpidTransportBridge* impl)
                           "Error Subscribing to %s : %s",
                           impl->mIncomingAddress,
                           PN_MESSENGER_ERROR(impl->mIncoming));
-                (impl->mIncoming);
+                qpidBridgeMamaTransportImpl_stopProtonMessenger(impl->mIncoming);
                 return MAMA_STATUS_PLATFORM;
             }
         }
--
2.3.2 (Apple Git-55)



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


[PATCH] QPID Fix For Missing Method Name

Philip Preston
 

Missing method name in transport.c

Signed-off-by: Phil Preston <philippreston@...>
---
mama/c_cpp/src/c/bridge/qpid/transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mama/c_cpp/src/c/bridge/qpid/transport.c b/mama/c_cpp/src/c/bridge/qpid/transport.c
index ab9755c..8b5ceba 100644
--- a/mama/c_cpp/src/c/bridge/qpid/transport.c
+++ b/mama/c_cpp/src/c/bridge/qpid/transport.c
@@ -938,7 +938,7 @@ qpidBridgeMamaTransportImpl_start (qpidTransportBridge* impl)
"Error Subscribing to %s : %s",
impl->mIncomingAddress,
PN_MESSENGER_ERROR(impl->mIncoming));
- (impl->mIncoming);
+ qpidBridgeMamaTransportImpl_stopProtonMessenger(impl->mIncoming);
return MAMA_STATUS_PLATFORM;
}
}
--
2.3.2 (Apple Git-55)


[PATCH] QPID Fixed Compile Error for double const

Philip Preston
 

With the macros for Vector of types, with the const char being passed into the macro, a further const is on the type in the macros, got compiler error in Clang for double const

Signed-off-by: Phil Preston <philippreston@...>
---
mama/c_cpp/src/c/payload/qpidmsg/field.c | 2 +-
mama/c_cpp/src/c/payload/qpidmsg/payload.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/mama/c_cpp/src/c/payload/qpidmsg/field.c b/mama/c_cpp/src/c/payload/qpidmsg/field.c
index ae988e9..3429838 100644
--- a/mama/c_cpp/src/c/payload/qpidmsg/field.c
+++ b/mama/c_cpp/src/c/payload/qpidmsg/field.c
@@ -1238,7 +1238,7 @@ qpidmsgFieldPayload_getAsString (const msgFieldPayload field,
}
case MAMA_FIELD_TYPE_VECTOR_STRING:
{
- EXPAND_PRINT_VECTOR_MACROS (const char*, String, "%s", const char*);
+ EXPAND_PRINT_VECTOR_MACROS (char*, String, "%s", const char*);
break;
}
case MAMA_FIELD_TYPE_VECTOR_U8:
diff --git a/mama/c_cpp/src/c/payload/qpidmsg/payload.c b/mama/c_cpp/src/c/payload/qpidmsg/payload.c
index 0418305..dc4cb24 100644
--- a/mama/c_cpp/src/c/payload/qpidmsg/payload.c
+++ b/mama/c_cpp/src/c/payload/qpidmsg/payload.c
@@ -3767,7 +3767,7 @@ qpidmsgPayloadImpl_addFieldToPayload (msgPayload msg,
ADD_VECTOR_FIELD_VALUE_TO_MESSAGE(F64, mama_f64_t);
break;
case MAMA_FIELD_TYPE_VECTOR_STRING:
- ADD_VECTOR_FIELD_VALUE_TO_MESSAGE(String, const char*);
+ ADD_VECTOR_FIELD_VALUE_TO_MESSAGE(String, char*);
break;
case MAMA_FIELD_TYPE_VECTOR_MSG:
{
--
2.3.2 (Apple Git-55)


Notes from Workshop Session 3-Sep-2015

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

On 3rd September, we had a productive workshop session in London focused around Dynamic Bridge Loading, Entitlements Bridges and Acceptance Test Suites.

 

We had great representation from software vendors, customers, contributors and users. I would like to take this opportunity to thank everyone who attended to help make it worthwhile, and to extend this invite to anyone else who may want to attend the next session on 24th September.

 

The notes from the session are listed below:

 

Dynamic Bridge Loading

 

Implementation Notes:

 

·         Mechanisms should be put in place during the bridge loading process to enable MAMA to reject incompatible bridges and for bridges to reject incompatible versions of MAMA. In future, this could potentially allow MAMA-to-bridge behaviour to be changed between major MAMA releases as it would mandate a recompile rather than risk a crash. Debatable at the moment as to whether to implement this in a manner consistent with the existing ‘internal properties’ mechanism or to create explicit functions specifically for version validation.

o   Option A is to use a known struct containing version information as part of the handshaking

o   Option B is to use the existing internal properties hash map to store the version information as a string and provide utility functions to parse it

·         The mechanism already in place for a middleware bridge to specify a list of supported (or certified) payloads should remain in place.

·         A configurable 'default payload' should be a configuration parameter applying primarily to the publishing API to allow it to determine which payload to use where none is specified in code, and the middleware supports multiple payloads.

·         Where multiple payload types are supported, the same transport should be able to decode any payload type received (for the use case where a publishing application knows that different payload formats may be more efficient for different message types).

·         As general approach, loading of transport and payload (and entitlements) bridges should be configuration-driven. Earlier loading of mama.properties should allow for this. Internal structures that are required containing payload/middleware identifiers should be populated on loading from configuration. Introduction of a new middleware transport/payload (or entitlements bridge) should require only a configuration change and placing the new libraries in a location where they can be found.

·         The latest implementation of this which is a hybrid of a few submitted approaches can be found in this github fork / branch

 

Related Notes:

·         Details of the currently favoured implementation can be found at http://review.openmama.org/D15 and may get merged into a feature branch shortly also.

·         MAMA Middleware should never refer specifically to payload types.

·         Payload should also never refer directly to external payload types where a mama message object is provided.

·         Where a middleware bridge recognizes that it has received an attempt to publish a known unsupported payload format, the message should be dropped.

·         The approach of taking the responsibility of creating the bridge implementation away from the middleware bridge developer was deemed acceptable.

 

Entitlements Bridge

 

Implementation Notes

·         The entitlements bridge should be a standalone bridge which has no dependencies on the middleware implementation which may or may not underpin it.

·         Does not necessarily need to be based on the generic plugin API.

·         The entitlements bridge has sole responsibility for managing entitlements and taking decisions on whether any attempt to subscribe or publish data is allowed. In the exceptional (not default) case it may be desirable to defer entitlements checks to a middleware transport bridge (where that middleware has built-in entitlements controls). To allow for this, it would be useful to pass some identification or reference to the middleware being used to the entitlements bridge when making entitlement checks. It is up to the entitlement bridge implementation to decide whether it wishes to defer checks or not – this cannot be overridden by the middleware transport bridge.

·         All calls to the entitlements bridge should include a handle to the middleware bridge where applicable so (for example) in future bridge implementations, it could confirm from the bridge whether it is in fact deferred or not.

·         Which entitlements implementation to use may be Global (as they are today), bridge-specific, transport specific or even source-specific, so deferring to the entitlements bridge implementation should allow it to make this decision and manage all related state.

·         Needs to be run-time as opposed to compile time configurable. This means that all of the #ifdef WITH_ENTITLEMENTS stuff gets removed, so this is not optional, replaced by function calls to the loaded entitlements bridge. An entitlements bridge MUST be loaded.

·         A bridge specification for this should be published to allow third party vendors to implement their own hooks.

·         Publish side entitlements is required.

 

Tick42 Acceptance Testing Notes

 

Implementation Notes

·         Proposal would involve a series of tests that can be run on a MAMA bridge to ensure an application developer can easily know which bridge supports which range of functionality.

·         Test suite may need to be based on canned data if possible to validate expected content rather than simply checking whether or not content was received.

·         Test suite would be open sourced.

 

Related Notes

·         Agreed that the list of bridge-specific features was fairly comprehensive though it may grow with time.

·         Agreed that the main use case for this would be a large table of reference published on an OpenMAMA page detailing compatibility for all known resources.

·         For bridges which map message fields to traditional 'w' fields and corresponding types, these mappings should be made public so that any applications which wish to integrate with the bridge can understand the field mappings while doing so.

 

Tangents and Wish Lists

·         In some bridge implementations existing at the moment, meta data such as the ability to clear a cache which would be useful for the MAMA application to receive does not currently propagate to the application. Investigation would be required to see if message types alone would be sufficient to cover related use cases. Potential suggestion for Meta data being moved outside of the MAMA Message itself if message types are insufficient and instead, meta data accessor functions are required.

·         Review process for OpenMAMA is currently opaque as it is subject to Engineering process. SR to have a discussion surrounding this with moving to Github and carrying out code reviews there being a potential option.

·         OpenMAMA Source discovery support was raised. Suggestion that taking the DATA_DICT approach of simply having a special topic which the bridge can expose to the application in a standard way may be sufficient to solve this, if the approach is standardised and documented.

·         MAMA Date time is not safe for the year 2038 problem - something which is already being hit for some expiry dates.

·         MAMA Date time also suffers from some precision and hint problems in .NET.

·         Bridge specific latency measurements would be a useful tool to analyse latency being introduced as a result of the bridge implementation rather than the middleware itself.

 

Cheers,

Frank

 


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: MamaDQPublisherManager methods difference between OpenMAMA and EnterpriseMAMA

Stuart Beattie <s.beattie@...>
 

Hi Reed,

 

Apologies for the delay on responding.  I am currently looking into the exact status of these functions and why there is a discrepancy between versions.

 

Thanks

Stuart

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed via Openmama-dev
Sent: 14 September 2015 19:35
To: openmama-dev@...
Cc: Vernik, Vadim <vadim.vernik@...>
Subject: [Openmama-dev] MamaDQPublisherManager methods difference between OpenMAMA and EnterpriseMAMA

 

Hi,

 

OM 2.3.3 and EM 6.0.3 have the same methods for class MamaDQPublisherManager.

 

But EM 5.0.7 has these additional methods:

    virtual MamaDQPublisher* getPublisher (const char *symbol);

    virtual void*            getCache (const char *symbol);

    PublisherIterator        begin();

    PublisherIterator        end();

 

Have these been deprecated/removed from OM and EM since EM 5.0.7 ?

 

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 (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


OpenMAMA ZeroMQ Bridge

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

Over the past few weeks, I have taken on a personal project to write a ZeroMQ bridge for OpenMAMA which I have just open sourced on github: https://github.com/fquinner/OpenMAMA-zmq

It supports both basic and market data subscriptions. You can read more about it here: https://github.com/fquinner/OpenMAMA-zmq/blob/master/README.md

I've also posted my first blog post on the project here if you're interested:

http://fquinner.github.io/2015/09/13/so-it-begins

Note that this project is not affiliated with nor supported by OpenMAMA or SR Labs.

Cheers,
Frank


MamaDQPublisherManager methods difference between OpenMAMA and EnterpriseMAMA

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

Hi,

 

OM 2.3.3 and EM 6.0.3 have the same methods for class MamaDQPublisherManager.

 

But EM 5.0.7 has these additional methods:

    virtual MamaDQPublisher* getPublisher (const char *symbol);

    virtual void*            getCache (const char *symbol);

    PublisherIterator        begin();

    PublisherIterator        end();

 

Have these been deprecated/removed from OM and EM since EM 5.0.7 ?

 

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 (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


OpenMAMA Windows release - mamda include file locations vary by platform

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

Hi,

 

In the OpenMAMA release file (Windows 7 x86 Binaries) the mamda include files are in subdirs, but the sample programs do not reflect this.

 

For MamdaBookAtomicListener.cpp:

#include <mamda/MamdaBookAtomicBookHandler.h>

 

But this file is in a subdir of mamda:

openmama_install_2.3.3_WIN64-dynamic\include\mamda\orderbooks\MamdaBookAtomicBookHandler.h

 

For the Linux release that header file is not in a subdir, so the example does compile correctly.

Is the plan to migrate the include files to subdirs or keep them as linux is now?

 

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 (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


Re: Proposed minor change to allow specifying named symbol lists

Keith Rudd
 

Classification: Public

To clarify, on

“For your feature are you suggesting that when you request ABC, or would send back a list of either ABC.L, ABCD or both?”

Answer is that either is possible, or something else.

 

I’m not suggesting that we define the semantics of what any particular list contains related to the list symbol name.

I just want it to be possible to pass on a symbol list name to the middleware bridge.

What the list actually represents for that middleware source and if it exists at all, can be middleware-specific and up to the relevant transport to respond on.

All I’m saying when subscribing is “Give me the contents of the symbol list named XXX please”

The symbol list XXX could contain anything or nothing – I have to wait for the response to find out.

 

I don’t think it’s wise to try to specify any universal standard semantics implied in the naming of symbol lists and what they should represent.

Avoid this to allow maximum flexibility to adapt the support for lists to any middleware.

For a middleware/source that supports wildcards it might interpret the ‘*’ char (or others) in a symbol list name as a wildcard, if it is able to support that, but on another source ‘*’ might just be ‘*’.

 

Regards,

Keith

 

From: Glenn McClements [mailto:g.mcclements@...]
Sent: 07 September 2015 12:55
To: Keith Rudd; 'Openmama-dev@...'
Subject: Re: [Openmama-dev] Proposed minor change to allow specifying named symbol lists

 

>I’m not really sure on the semantics of why you need different types of list requests for BOOK or GROUP symbols – is the returned data not still just a list of symbols in field ‘MamaSymbolList’ ?

 

It is, but for feed handlers that support L1 and L2 (and GROUP), then you can restrict the symbol set that is provided. 

 

>So if I specify say source ‘LSE’, symbol ‘VOD’ for my SYMBOL_LIST request, my expected response might be the list of all symbols representing options for ‘VOD’ from source ‘LSE’.

 

So is this effectively VOD.*, or VOD*? It’s possible that a symbol from a publisher is a sub string of another symbol. Consider the symbols below:

ABC

ABC.L

ABCD  

 

For your feature are you suggesting that when you request ABC, or would send back a list of either ABC.L, ABCD or both?

 

Just trying to formalise this a bit so there’s no ambiguity with publishers – a set of examples would help as well. 

 

Cheers,

Glenn 

 

Glenn McClements, SVP Engineering 

Adelaide Exchange, 24-26 Adelaide Street,  Belfast, UK, BT2 8GD

www.srtechlabs.com

 

SR.LABS Proven High Speed Electronic Trading Solutions 

 

From: Keith Rudd
Date: Thursday, 3 September 2015 11:25
To: Glenn McClements, "'Openmama-dev@...'"
Subject: RE: [Openmama-dev] Proposed minor change to allow specifying named symbol lists

 

Classification: Public

Glenn,

 

Thanks for explaining this a bit.

 

I’m not really sure on the semantics of why you need different types of list requests for BOOK or GROUP symbols – is the returned data not still just a list of symbols in field ‘MamaSymbolList’ ?

Maybe some of the feed handlers need to know this if symbols only exist as L1 or L2, not both?

(You could handle that with different symbol names – e.g. “ALL_L1”, “ALL_L2” – whatever the source publisher wanted to support)

 

The ‘source’ field is still used and required.

So if I specify say source ‘LSE’, symbol ‘VOD’ for my SYMBOL_LIST request, my expected response might be the list of all symbols representing options for ‘VOD’ from source ‘LSE’.

The actual symbol list names supported and what they represent for any given source would be up to the feed handler (source publisher).

 

You could certainly allow a wildcard char to be specified within the ‘symbol’ parameter, but again it would be up to source publishers whether they recognized and supported requests for symbol lists (or groups) with names containing wildcards. Nothing extra is required here in the MAMA layer to include/exclude support for wildcard symbol names.

 

Regards,

Keith

 

 

From: Glenn McClements [mailto:g.mcclements@...]
Sent: 02 September 2015 16:43
To: Keith Rudd; 'Openmama-dev@...'
Subject: Re: [Openmama-dev] Proposed minor change to allow specifying named symbol lists

 

Hi Keith,

"Also, there are actually two similar subscription types that can be used:

MAMA_SUBSC_TYPE_SYMBOL_LIST and MAMA_SUBSC_TYPE_SYMBOL_LIST_NORMAL

The intended different use for these is not clear – they both are processed exactly the same.

Can anyone shed light on the reason for both existing?

 

MAMA_SUBSC_TYPE_SYMBOL_LIST_NORMAL is a hint to the publisher on what type of symbols should be returned, NORMAL is L1 data.  The symbol list sub types map tot he may to the subscription types of NORMAL, BOOK and GROUP, ie. 

                               - MAMA_SUBSC_TYPE_SYMBOL_LIST_NORMAL
        - MAMA_SUBSC_TYPE_SYMBOL_LIST_GROUP
        - MAMA_SUBSC_TYPE_SYMBOL_LIST_BOOK

MAMA_SUBSC_TYPE_SYMBOL_LIST was the original type (replaced by the ones above) but can still be used for backward compatibility. 

 

With regards to your suggested change it makes sense. My main thoughts would be how the logic around how the “symbol” field is mapped to a “source”? 

Should this be made more explicit with a “source” field? 

Should it be of the format “SOURCE" or "SOURCE.”?

Should wildcards or regex be supported or explicitly not supported (for now)?

 

Cheers,

Glenn 

 

 

Glenn McClements, SVP Engineering 

Adelaide Exchange, 24-26 Adelaide Street,  Belfast, UK, BT2 8GD

www.srtechlabs.com

 

SR.LABS Proven High Speed Electronic Trading Solutions

 

From: <openmama-dev-bounces@...> on behalf of Keith Rudd
Date: Wednesday, 2 September 2015 11:20
To: "'Openmama-dev@...'"
Subject: [Openmama-dev] Proposed minor change to allow specifying named symbol lists

 

Classification: Public

With the current OpenMAMA functionality for symbol list type requests (MAMA_SUBSC_TYPE_SYMBOL_LIST), it is not possible to request a named symbol list.

 

Any symbol name specified is ignored and overwritten by “SYMBOL_LIST_NORMAL”.

The assumed semantics is that you always want a list of the entire list of symbols available for the specified source.

 

This is unnecessarily restrictive. There is no reason why the middleware might not support symbol lists representing other named subsets of the source data, such as all the options for an underlier or all the contracts for a future.

(TREP sources typically do support this for example, but the concept of named symbol lists is by no means TREP-specific)

 

With a very simple modification, this could be supported.

Just by not overwriting the symbol name if one is specified.

The current behavior can be preserved as the default for backwards-compatibility, by still overwriting with “SYMBOL_LIST_NORMAL” if no symbol is specified.

 

Also, there are actually two similar subscription types that can be used:

MAMA_SUBSC_TYPE_SYMBOL_LIST and MAMA_SUBSC_TYPE_SYMBOL_LIST_NORMAL

The intended different use for these is not clear – they both are processed exactly the same.

Can anyone shed light on the reason for both existing?

One of these could also be preserved as is for another backward-compatibility option.

 

A minor change to subscription.c only is required.

Optionally, minor change to subscriptiontype.c, subsctype.c to differentiate between the two types of symbol list request.

 

I can’t actually contribute to GIT repository myself, so hope someone else will look kindly on this proposed change to implement it!

 

I can see no downside.

 

Regards,

Keith

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


OpenMAMA now available on GitHub!

Matt Mulhern
 

Hi Folks,

After reviewing our current process and the number of disparate systems that we use to track and maintain OpenMAMA (Git, Bugzilla, Phabricator and Jira services), we have decided to move the hosting of the OpenMAMA source code to GitHub instead of our own dedicated git server effective immediately.

The old git server will remain online until the end of the month but will be treated as read-only. On 14th September, git.openmama.org will be fully retired.

Updating your existing repository to point to the new server is a very straightforward process. Simply run the following if you're already a GitHub user with ssh access:

git remote set-url origin https://github.com/OpenMAMA/OpenMAMA.git

This will allow you to pull down the latest source, but not push any changes. If you want to keep your changes somewhere else, I would highly recommend forking the GitHub repository. This has the advantage of being able to use pull requests instead of the usual email patch submission process.

The patch submission process will remain the same as it did before, but with the newly available option of pull requests which we're in the process of documenting.

The code review process will now be done in the open through GitHub as will ticket tracking. We'll be migrating any existing Bugzilla tickets over to the Github issue tracking system over the next few weeks as well as updating our documentation to reflect the new processes and URLs.

If you have any questions, comments or concerns, please let us know.

Cheers,
Matt

701 - 720 of 2312