1. Openmama-Dev
  2. Messages

Expanded

Topics Messages Polls
   Date   
OpenMAMA_Snapshot_RPM - Build # 589 - Still Failing!

jenkins@...
 

Some changes have just been added to the origin/next branch! 

[Frank Quinn] Fix for null payload in createReusableMsg
	mama/c_cpp/src/c/msg.c
	mama/c_cpp/src/c/bridge/qpid/SConscript

Results for OpenMAMA_Snapshot_RPM CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_RPM
  • Build Number: #589
  • Build Status: Still Failing
  • Build Warnings:
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.

Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch! 

[Frank Quinn] Fix for null payload in createReusableMsg
	mama/c_cpp/src/c/bridge/qpid/SConscript
	mama/c_cpp/src/c/msg.c

Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #200
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1830
  • Passed: 1830
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.

Re: Recent Addition

Frank Quinn
 

My bad (though a little concerning that passed unit tests - mental note taken to add a test around that) - try again now.

Cheers,
Frank

On Tue, Feb 6, 2018 at 11:25 AM, Aaron Sneddon <asneddon@...> wrote:

Hey Frank,

 

Just to make you aware, we have found an error after taking the latest commit to OpenMAMA/next <2a36e08d701c35d826502acc829a90cb4e1043e6>. We found that during a queue setup a crash occurs, and this does not happen if we revert the commit to the one previous.

Please find attached a stack trace for this, found using a mamalistenc, it cores pretty much straight away.

Regards,

Aaron

 

From: Frank Quinn [mailto:frank@...]
Sent: 03 February 2018 19:55
To: Aaron Sneddon <asneddon@...>
Cc: openmama-dev <openmama-dev@....org>
Subject: RE: [Openmama-dev] RFC DQ Pluggability

 

Thanks Aaron,

 

Just on the plugin-only front, I'll probably appreciate more what you mean when a pull request comes in, but it's my opinion that if the plugin code isn't flexible enough to allow us to handle this, we should consider being more flexible with the plugin code.

 

Maybe that's another task but again it goes into setting aside these prototypes now since I think i'd like to add it soon afterwards if it's not in the PR. I'm not sure what the rest of the dev list things but opinions are welcome?

 

To explain, I'm not sure hooks are much use if you can't attach context specific data to them, because then you'll *always* need to do lookups on firing. For example, I could see something like this being more useful (same for subscription):

 

mama_status dqstrategyMamaPlugin_transportPostCreateHook (mamaPluginInfo pluginInfo,

                                                          mamaTransport  transport,

                                                          void**         closure) {

    *closure = (void*) new Whatever();

}

 

mama_status dqstrategyMamaPlugin_transportEventHook(mamaPluginInfo pluginInfo,

                                                    mamaTransport  transport,

                                                    int            setStale

                                                    void*          closure) {

    Whatever whatever = (Whatever)closure;

}

 

That way you can initialize and attach objects on postcreate hooks which can then be retrieved later in subsequent hooks without requiring any lookups. There are a number of ways to implement this but the easiest is probably an array of pointers for each plugin instance attached to each object.

 

You could then have member variables attached to transports, subscriptions etc to allow plugins to fire data around without having to do its own out of band lookups.

 

Cheers,

Frank

 

On 1 Feb 2018 17:26, "Aaron Sneddon" <asneddon@...> wrote:

Hey Frank,

 

I have taken on board the suggested changes to function signatures, and will have the transport passed to transportPostCreateHook, and mamaTransportEvent to transportEventHook.

With regards to setstale, the transport callback will generally call the transportEventHook, and will take care of the setPossiblyStale stuff.

So, the setStale is there because ‘event’ on its own isn’t enough to differentiate between current disconnect/disconnectNoStale logic.


Also, I’ll update the RFC for this to be clearer.


With regards to:

I'm not sure about what's meant by the Plugin Changes section when it talks about the overriding of the default dq plugin in the plugin code. Instead might it be more straightforward if:

 

1. Additional plugins for dq could simply be loaded and live alongside each other. On-hook the plugin can then decide if it wants to set itself up based on its own configuration standards.

2. The "default" dq plugin could do something similar and decide itself if it wants to take action. This would make it more like a standard plugin rather than a special case for DQ.

3. The transportCreateHook for the dq plugin could then *itself* check a property *there* or on init to decide whether or not it should take action on this transport for the bridge as updates are fired.

 

Ideally we would like to make the DQ plugin stuff as much like normal plugins as possible.  But fitting plugins which may only need to act on particular transports in is a little awkward.  Configuration wise and conceptually it is easier to treat them in the same way as normal plugins, but point 3) is the problem here – the decision about whether or not to take action would surely need to be made on a per-update basis and so would need some sort of lookup to be performed every time.

 

Hope this helps..

 

Thanks,

Aaron

 

 

From: Frank Quinn [mailto:frank@...]
Sent: 31 January 2018 23:13
To: Aaron Sneddon <asneddon@...>
Cc: openmama-dev@....org
Subject: Re: [Openmama-dev] RFC DQ Pluggability

 

Thanks Aaron,

 

Put in a few changes to the document to make the prototypes "pop" a little bit more. A few suggestions / talking points though:

mama_status dqstrategyMamaPlugin_transportPostCreateHook (mamaPluginInfo pluginInfo)

I think it would be useful if this at least included the mamaTransport that has just been created.

mama_status dqstrategyMamaPlugin_transportEventHook(mamaPluginInfo pluginInfo,
                                                    mamaTransport  transport,
                                                    int            setStale)

It reads like setStale will represent something related to the staleness but it's not clear what possible values they may have. I also wonder if the use of mamaTransportEvent might be more useful here? Is it also feasible that this may not be necessary at all if the postCreateHook could set up a standard transport callback?

 

I'm not sure about what's meant by the Plugin Changes section when it talks about the overriding of the default dq plugin in the plugin code. Instead might it be more straightforward if:

 

1. Additional plugins for dq could simply be loaded and live alongside each other. On-hook the plugin can then decide if it wants to set itself up based on its own configuration standards.

2. The "default" dq plugin could do something similar and decide itself if it wants to take action. This would make it more like a standard plugin rather than a special case for DQ.

3. The transportCreateHook for the dq plugin could then *itself* check a property *there* or on init to decide whether or not it should take action on this transport for the bridge as updates are fired.

 

Cheers,

Frank

 

On Wed, Jan 31, 2018 at 11:30 AM, Aaron Sneddon <asneddon@...> wrote:

Thanks for your feedback, I have now added the proposed prototypes to the RFC as requested.
https://openmama.github.io/openmama_rfc_dq_pluggability.html

Just so the group is aware, there is until Thursday now to give feedback before development kicks off so today is your last chance.
You might want to take a look at the document once more, even just to look at the function prototypes since they were only added today.

 

Thanks,

Aaron

 

From: Frank Quinn [mailto:frank@...]
Sent: 30 January 2018 21:04
To: Aaron Sneddon <asneddon@...>
Cc: openmama-dev@....org
Subject: Re: [Openmama-dev] RFC DQ Pluggability

 

Thanks Aaron,

 

Apologies for the delay in getting to read this properly - for reference to the group this is the link to the document:

 

 

From my point of view I think it would be useful to get some visibility on what the proposed function prototypes will look like at the hook points.

 

There are several method names in there which is good but proposed arguments which will be passed to the plugin methods will probably be the thing of most interest to bridge developers who will want to take advantage of this functionality and may want a series of objects to be made available which may be more than what is required for the DQ use case alone.

 

Consider the fact that these plugin methods once created will be fairly set in stone, otherwise we'll end up going down the functionNameEx road again or mandatory bridge changes which nobody wants. It may be a lot easier to add additional arguments (if necessary) at this point even if they aren't required for this use case.

 

Cheers,

Frank

 

On Wed, Jan 17, 2018 at 10:01 AM, Aaron Sneddon <asneddon@...> wrote:

Hey everyone,

You may have noticed that a new RFC has been merged into master of https://github.com/OpenMAMA/openmama.github.io .

This is just to make you aware, if you weren’t already. Feel free to have a look at it under /pages/openmama/openmama_rfc_dq_pluggability.md and
let me know what you think. Comments and suggestions will be happily considered.

Regards,
Aaron


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


_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
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. Vela Trading Technologies 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. Vela Trading Technologies 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. Vela Trading Technologies LLC

Re: Finalizers are dangerous

Yury Batrakov
 

Classification: Public

Hi Frank,

 

Is it this commit https://github.com/OpenMAMA/OpenMAMA/commit/2a36e08d701c35d826502acc829a90cb4e1043e6 ?

I’m not sure if it fully fixes crash in finalizers:

-          It’s only for mamaMsg while there are also finalizers for dictionaries, inboxes, subscriptions etc.

-          Finalizers executed in dedicated thread but destroy method doesn’t acquire a single lock with mama_close so the crash may occur when mama_close() is in progress.

 

 

From: Frank Quinn [mailto:frank@...]
Sent: Sunday, February 04, 2018 12:24 AM
To: Bill Torpey <wallstprog@...>
Cc: Sanjeev Wahi <sawahi@...>; Yury Batrakov <yury.batrakov@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Finalizers are dangerous

 

Hi folks,

 

I have just submitted a change which should resolve this issue, but worth a check in your code to verify it has fixed the issue for your use case. It's in the "next" branch.

 

Cheers,

Frank

 

On Thu, Dec 28, 2017 at 9:01 PM, Frank Quinn <frank@...> wrote:

Hi Bill,

 

Sure sounds good, though these are MAMA bridge level configurations so let's make it:

 

mama.middleware.<id>.unload_on_close=true|false

 

and

 

mama.payload.<id>.unload_on_close=true|false

 

 

The destructor / finalizer approach will fix the GC problem just fine for C# / Java. What is being described there is effectively a bug in those methods. What it won't solve is applications deliberately accessing MAMA payload and middleware methods after close and expecting it to actually function with new messages, iterators etc. However it would certainly stop GC after close from crashing the jvm which sounds like it is Yury's main issue.

 

As much as I would love to just mandate that all Java and C# developers call destroy on all of the objects (it would make my life a lot easier), a lot of developers we have worked with in the past simply don't accept that as a solution for a GC based runtime which is why we need all this finalizer fun to play nicely.

 

Cheers,

Frank

 

On Thu, Dec 28, 2017 at 7:17 PM, Bill Torpey <wallstprog@...> wrote:

Hi Frank:

 

Why don’t we start over here and see if we can make some progress?

 

If you’re OK with a solution based on a mama.properties setting, I can live with that.  

 

 

For the transport it seems to me that a property setting like the following could work:

 

mama.<middleware>.transport.<name>.unload_on_close=0|1

 

 

And for the payload library:

 

mama.payload.<id>.unload_on_close=0|1

 

 

If that works for you, I’ll work up a PR and maybe we can put this bad boy to bed ;-)

 

Or feel free to suggest something different.  (With the caveat that the dtor approach is not something I’m open to — nor does it solve the problem for our friends in Java and .Net land).

 

Regards,

 

Bill

 

P.S.  Note also that short-circuiting the dlclose plays much more nicely with tools like valgrind, which discards symbols when a shared library is closed.

 

 

On Dec 28, 2017, at 1:27 PM, Frank Quinn <frank@...> wrote:

 

I have been quite receptive to your concerns - just not your proposed solution which I think is too coarse.

 

Checking if something exists before trying to access it within a framework is far from a hack - it's simply defensive code. mamaInternal_findPayload is already used in MAMA C++ - this is a solvable problem.

 

I've clearly acknowledged that it's a problem. I'm not sure what makes you think that I think that it's not. The ticket is still open and i'm suggesting solutions including one which will do exactly what you want based on a configuration option rather than forcing it to be the only option when C developers (for example) would have no need for it whatsoever.

 

The other is an attempt to solve the problem in a defensive way which means that application developers don't have to give special consideration to this use case when writing their applications.

 

Cheers,

Frank

 

 

 

On Thu, Dec 28, 2017 at 5:58 PM, Bill Torpey <wallstprog@...> wrote:

Hi Frank:

 

Obviously I would prefer to remain as close as possible to upstream code, so forking is a last resort.  That being said, you’ve been so far quite unreceptive to my concerns about crashing as a result of unloading the payload (and transport, for that matter) library code.

 

The approach of checking if the payload library exists is a bit of a hack, and is not possible currently, since the mamaInternal_findPayload function is not exposed as part of the API.  Are you planning to expose those functions?

 

A better solution I believe would be separating out the unloading of the library code from the other activities needed to do a clean shutdown.  I’ve created a fugly hack for that in the forked OpenMAMA code (see attached), but would much prefer something a bit more “elegant”, which would likely require changing the API, and I don’t want to do that without agreement from you.  But so far you haven’t even agreed that this is a problem.

 

I’m open to ideas, but I think we can do better than what you suggest.

 

Regards,

 

Bill

 

 

 

 

 

On Dec 28, 2017, at 12:21 PM, Frank Quinn <frank@...> wrote:

 

On the contrary I welcome OpenMAMA forks If you want to fork and maintain all fixes etc from the upstream that's entirely your decision and part of the beauty of Open Source software. More power to you.

 

I simply don't agree that always leaking is the right solution when it's avoidable. It's as simple as that.

 

After another look I think the solution should live in the C++ destructor method where it can:

 

1. Cache the payload type in the C++ layer as soon as it is known.

2. On destructor, find out if the bridge referred to in #1 is still active using mamaInternal_findPayload from mamaMsg_destroy. Therefore the destroy calls can intercept bridge specific calls before they are made which would otherwise cause a crash.

 

The mama internal lock may also need to be opened up to avoid race conditions.

 

You can do something similar in Java finalizer methods via a JNI method.

 

Alternatively you could have a mama property which will simply prevent the payload bridges from being deallocated and will instead only destroy the middleware bridges. This way it will do what you want (i.e. always leak memory), but not be turned on for everyone unless they want it.

 

Cheers,

Frank

 

On Thu, Dec 28, 2017 at 4:25 PM, Bill Torpey <wallstprog@...> wrote:

See comments inline …

 

On Dec 28, 2017, at 11:07 AM, Frank Quinn <frank@...> wrote:

 

Hi Bill,

 

We close the bridges because we leak memory if we dont.

 

No, we shut down the bridges to prevent events from firing.  In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which is a Good Thing.

 

 

Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

 

It’s not up to you.  As I said before, it’s my application, and I get to decide what leaks are worth worrying about.  One-time leaks that don’t grow over time don’t concern me, and the cost of eliminating them is not worth it in almost all cases.  (Again, that’s my choice — “Perfect is the enemy of good enough”).

 

 

If you really want control and are happy to leak memory, just don't call mama_close(),

 

As you are well aware, that is not a solution — it doesn’t stop events from firing, which is the real reason for shutting down the transport.

 

or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

 

What configuration option is that?  How would it work?  

 

 

In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

 

I would be happy to submit a PR, but it doesn’t sound like it would be accepted.  If we can agree on an approach I’ll see what I can come up with.

 

In the meantime I gave up and forked the code.  As project maintainer I don’t imagine that’s what you want, but you’re not giving me a choice.

 

 

Cheers,

Frank

 

 

On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:

See comments inline …

 

On Dec 28, 2017, at 11:07 AM, Frank Quinn <frank@...> wrote:

 

Hi Bill,

 

We close the bridges because we leak memory if we dont.

 

No, we shut down the bridges to prevent events from firing.  In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which is a Good Thing.

 

 

Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

 

It’s not up to you.  As I said before, it’s my application, and I get to decide what leaks are worth worrying about.  One-time leaks that don’t grow over time don’t concern me, and the cost of eliminating them is not worth it in almost all cases.  (Again, that’s my choice — “Perfect is the enemy of good enough”).

 

 

If you really want control and are happy to leak memory, just don't call mama_close(),

 

As you are well aware, that is not a solution — it doesn’t stop events from firing, which is the real reason for shutting down the transport.

 

or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

 

What configuration option is that?  How would it work?  

 

 

In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

 

I would be happy to submit a PR, but it doesn’t sound like it would be accepted.  If we can agree on an approach I’ll see what I can come up with.

 

In the meantime I gave up and forked the code.  As project maintainer I don’t imagine that’s what you want, but you’re not giving me a choice.

 

 

Cheers,

Frank

 

 

On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:

HI Frank:

 

And Happy Holidays to you too!

 

A couple of points:

 

  • I’m not aware of any changes to OpenMAMA that affect the issue, so if there are some please point me in the proper direction.  The last reply from you was back in May.
  • As the application developer I get to decide which leaks are acceptable to me, and which are not.  Taking that choice away from me is not OK.
  • You’re confusing and/or conflating the shutdown of the bridge libraries with the unloading of those libraries from memory.  
    • It is not necessary to unload the libraries in order to shut them down:
      • The transport library can be shut down without being unloaded from memory.
      • The payload library doesn’t need to be shut down at all, since it never fires any events.
    • The only reason I can think of for dynamically unloading the libraries is to support some kind of dynamic switching of transports and/or payloads.  I suspect that this feature is an example of YAGNI, but even there is a reasonable use for this feature, forcing the vast majority of applications that don’t need it to pay the price for it is a bad design decision.

 

Short version, it’s my application, and I get to decide how I want it to behave. 

 

Best Regards,

 

Bill 

 

On Dec 28, 2017, at 10:33 AM, Frank Quinn <frank@...> wrote:

 

Happy holidays folks!

 

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

 

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

 

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

 

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

 

Cheers,

Frank

 

 

On Thu, Dec 28, 2017 at 3:17 PM, Sanjeev Wahi <sawahi@...> wrote:


I can suggest a possible fix (by adding extra weak_ptr check) while calling Mama.close()  that can avoid this problem in C11/C11++ when using shared_ptr.
*(assumption is Mama.close() is not called by many threads same time, in that case also use C11 atomic integer counter with this code)

*( I do not know much Java but something similar would work).



1st Approach:
Gat a new shared_ptr, but test for whether it is empty or pointing to something by testing
it for true/false, analogous to what we would do with a built-in pointer that might be zero:

void do_it(weak_ptr<Thing> wp){
        shared_ptr<Thing> sp = wp.lock(); // get shared_ptr from weak_ptr
        if(sp)
                sp->defrangulate(); // tell the Thing to do something
        else
                cout << "The Thing is gone!" << endl;
}



2nd Approach:
We can ask the weak_ptr if it has "expired":

bool is_it_there(weak_ptr<Thing> wp) {
        if(wp.expired()) {
                cout << "The Thing is gone!" << endl;
                return false;
        }
return true;
}





-Sanjeev Wahi




-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Bill Torpey
Sent: Thursday, December 28, 2017 9:39 AM
To: Yury Batrakov <yury.batrakov@...>
Cc: openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] Finalizers are dangerous

Unfortunately, that is not a bug, but a “feature”.

The problem is that mama_close unloads both the transport and payload libraries (via dlclose on Linux).  So, any access to any objects related to either library following mama_close is guaranteed to crash.

This makes OpenMAMA completely unusable for GC languages like Java, and presumably .Net, as well as for reference-counted implementations in other languages (e.g., shared_ptr in C++).

I’ve argued this point with Frank, but so far to no avail:  https://github.com/OpenMAMA/OpenMAMA/issues/264

Perhaps if enough people chime in, we can change Frank’s mind.  Until that time, the only solution I can think of is to fork OpenMAMA and remove or replace the offending code.  That is not a great solution, but as I mention in the bug report, this behavior is a total non-starter for me (and presumably for others as well).


> On Dec 28, 2017, at 6:08 AM, Yury Batrakov <yury.batrakov@...> wrote:
>
> Classification: Public
> Hi team,
>
> Sorry for telling bad news in holidays but I have found a major issue with Java API - JVM may crash if GC comes after Mama.close() method. Here's code sample to reproduce it:
>
> import com.wombat.mama.Mama;
> import com.wombat.mama.MamaMsg;
>
> public class Test {
>    private static MamaMsg getMessage() {
>        return new MamaMsg();
>    }
>
>    public static void main(String[] args) {
>        Mama.loadBridge("...");
>        Mama.open();
>
>        getMessage(); // Creating MamaMsg object without reference
>
>        Mama.close(); // Payload bridge is destroyed here
>        System.gc();
>        System.runFinalization(); // Calling MamaMsg.destroy() which delegates the destruction to deleted payload bridge
>    }
> }
>
> Stack trace:
> #12 0x00007fc494a095f0 in ?? ()
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> #14 0x00007fc496d70b7f in Java_com_wombat_mama_MamaMsg__1destroy (env=0x7fc4b00039f8, this=0x7fc49779d710) at mama/jni/src/c/mamamsgjni.c:3882
> #15 0x00007fc4bae7e494 in ?? ()
>
> Problematic frame:
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> 127             if (MAMA_STATUS_OK != impl->mPayloadBridge->msgPayloadDestroy (impl->mPayload))
>
> impl->mPayloadBridge is destroyed here.
>
> Similar crash occurs when finalizing subscriptions - they also need entitlements bridge to be available but Mama.close() deletes it too.
>
> The workaround is to call destroy() method for each message/subscription created but this actually nullifies the need for finalize() methods. I would delete all them from MAMA code.
>
>
> ---
> 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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
> _______________________________________________
> Openmama-dev mailing list
> Openmama-dev@...
> https://lists.openmama.org/mailman/listinfo/openmama-dev

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

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

 

 

 

 

 

 

 

 

 

 



---
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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

OpenMAMA_Snapshot_RPM - Build # 588 - Still Failing!

jenkins@...
 

Some changes have just been added to the origin/next branch! 

[noreply] MAMA: Added defensive code to mamaMsg_destroy (#264) (#342)
	mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp
	release_scripts/ci-run.py
	release_scripts/intentionalunittestleaks.supp
	mama/c_cpp/src/c/msg.c

Results for OpenMAMA_Snapshot_RPM CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_RPM
  • Build Number: #588
  • Build Status: Still Failing
  • Build Warnings:
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.

Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch! 

[noreply] MAMA: Added defensive code to mamaMsg_destroy (#264) (#342)
	release_scripts/intentionalunittestleaks.supp
	release_scripts/ci-run.py
	mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp
	mama/c_cpp/src/c/msg.c

Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #199
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1830
  • Passed: 1830
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.

Re: Finalizers are dangerous

Frank Quinn
 

Hi folks,

I have just submitted a change which should resolve this issue, but worth a check in your code to verify it has fixed the issue for your use case. It's in the "next" branch.

Cheers,
Frank

On Thu, Dec 28, 2017 at 9:01 PM, Frank Quinn <frank@...> wrote:
Hi Bill,

Sure sounds good, though these are MAMA bridge level configurations so let's make it:

mama.middleware.<id>.unload_on_close=true|false

and

mama.payload.<id>.unload_on_close=true|false


The destructor / finalizer approach will fix the GC problem just fine for C# / Java. What is being described there is effectively a bug in those methods. What it won't solve is applications deliberately accessing MAMA payload and middleware methods after close and expecting it to actually function with new messages, iterators etc. However it would certainly stop GC after close from crashing the jvm which sounds like it is Yury's main issue.

As much as I would love to just mandate that all Java and C# developers call destroy on all of the objects (it would make my life a lot easier), a lot of developers we have worked with in the past simply don't accept that as a solution for a GC based runtime which is why we need all this finalizer fun to play nicely.

Cheers,
Frank

On Thu, Dec 28, 2017 at 7:17 PM, Bill Torpey <wallstprog@...> wrote:
Hi Frank:

Why don’t we start over here and see if we can make some progress?

If you’re OK with a solution based on a mama.properties setting, I can live with that.  


For the transport it seems to me that a property setting like the following could work:

mama.<middleware>.transport.<name>.unload_on_close=0|1


And for the payload library:

mama.payload.<id>.unload_on_close=0|1


If that works for you, I’ll work up a PR and maybe we can put this bad boy to bed ;-)

Or feel free to suggest something different.  (With the caveat that the dtor approach is not something I’m open to — nor does it solve the problem for our friends in Java and .Net land).

Regards,

Bill

P.S.  Note also that short-circuiting the dlclose plays much more nicely with tools like valgrind, which discards symbols when a shared library is closed.


On Dec 28, 2017, at 1:27 PM, Frank Quinn <frank@...> wrote:

I have been quite receptive to your concerns - just not your proposed solution which I think is too coarse.

Checking if something exists before trying to access it within a framework is far from a hack - it's simply defensive code. mamaInternal_findPayload is already used in MAMA C++ - this is a solvable problem.

I've clearly acknowledged that it's a problem. I'm not sure what makes you think that I think that it's not. The ticket is still open and i'm suggesting solutions including one which will do exactly what you want based on a configuration option rather than forcing it to be the only option when C developers (for example) would have no need for it whatsoever.

The other is an attempt to solve the problem in a defensive way which means that application developers don't have to give special consideration to this use case when writing their applications.

Cheers,
Frank



On Thu, Dec 28, 2017 at 5:58 PM, Bill Torpey <wallstprog@...> wrote:
Hi Frank:

Obviously I would prefer to remain as close as possible to upstream code, so forking is a last resort.  That being said, you’ve been so far quite unreceptive to my concerns about crashing as a result of unloading the payload (and transport, for that matter) library code.

The approach of checking if the payload library exists is a bit of a hack, and is not possible currently, since the mamaInternal_findPayload function is not exposed as part of the API.  Are you planning to expose those functions?

A better solution I believe would be separating out the unloading of the library code from the other activities needed to do a clean shutdown.  I’ve created a fugly hack for that in the forked OpenMAMA code (see attached), but would much prefer something a bit more “elegant”, which would likely require changing the API, and I don’t want to do that without agreement from you.  But so far you haven’t even agreed that this is a problem.

I’m open to ideas, but I think we can do better than what you suggest.

Regards,

Bill





On Dec 28, 2017, at 12:21 PM, Frank Quinn <frank@...> wrote:

On the contrary I welcome OpenMAMA forks If you want to fork and maintain all fixes etc from the upstream that's entirely your decision and part of the beauty of Open Source software. More power to you.

I simply don't agree that always leaking is the right solution when it's avoidable. It's as simple as that.

After another look I think the solution should live in the C++ destructor method where it can:

1. Cache the payload type in the C++ layer as soon as it is known.
2. On destructor, find out if the bridge referred to in #1 is still active using mamaInternal_findPayload from mamaMsg_destroy. Therefore the destroy calls can intercept bridge specific calls before they are made which would otherwise cause a crash.

The mama internal lock may also need to be opened up to avoid race conditions.

You can do something similar in Java finalizer methods via a JNI method.

Alternatively you could have a mama property which will simply prevent the payload bridges from being deallocated and will instead only destroy the middleware bridges. This way it will do what you want (i.e. always leak memory), but not be turned on for everyone unless they want it.

Cheers,
Frank

On Thu, Dec 28, 2017 at 4:25 PM, Bill Torpey <wallstprog@...> wrote:
See comments inline …

On Dec 28, 2017, at 11:07 AM, Frank Quinn <frank@...> wrote:

Hi Bill,

We close the bridges because we leak memory if we dont.

No, we shut down the bridges to prevent events from firing.  In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which is a Good Thing.


Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

It’s not up to you.  As I said before, it’s my application, and I get to decide what leaks are worth worrying about.  One-time leaks that don’t grow over time don’t concern me, and the cost of eliminating them is not worth it in almost all cases.  (Again, that’s my choice — “Perfect is the enemy of good enough”).


If you really want control and are happy to leak memory, just don't call mama_close(),

As you are well aware, that is not a solution — it doesn’t stop events from firing, which is the real reason for shutting down the transport.

or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

What configuration option is that?  How would it work?  


In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

I would be happy to submit a PR, but it doesn’t sound like it would be accepted.  If we can agree on an approach I’ll see what I can come up with.

In the meantime I gave up and forked the code.  As project maintainer I don’t imagine that’s what you want, but you’re not giving me a choice.


Cheers,
Frank


On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:
See comments inline …

On Dec 28, 2017, at 11:07 AM, Frank Quinn <frank@...> wrote:

Hi Bill,

We close the bridges because we leak memory if we dont.

No, we shut down the bridges to prevent events from firing.  In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which is a Good Thing.


Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

It’s not up to you.  As I said before, it’s my application, and I get to decide what leaks are worth worrying about.  One-time leaks that don’t grow over time don’t concern me, and the cost of eliminating them is not worth it in almost all cases.  (Again, that’s my choice — “Perfect is the enemy of good enough”).


If you really want control and are happy to leak memory, just don't call mama_close(),

As you are well aware, that is not a solution — it doesn’t stop events from firing, which is the real reason for shutting down the transport.

or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

What configuration option is that?  How would it work?  


In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

I would be happy to submit a PR, but it doesn’t sound like it would be accepted.  If we can agree on an approach I’ll see what I can come up with.

In the meantime I gave up and forked the code.  As project maintainer I don’t imagine that’s what you want, but you’re not giving me a choice.


Cheers,
Frank


On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:
HI Frank:

And Happy Holidays to you too!

A couple of points:

  • I’m not aware of any changes to OpenMAMA that affect the issue, so if there are some please point me in the proper direction.  The last reply from you was back in May.
  • As the application developer I get to decide which leaks are acceptable to me, and which are not.  Taking that choice away from me is not OK.
  • You’re confusing and/or conflating the shutdown of the bridge libraries with the unloading of those libraries from memory.  
    • It is not necessary to unload the libraries in order to shut them down:
      • The transport library can be shut down without being unloaded from memory.
      • The payload library doesn’t need to be shut down at all, since it never fires any events.
    • The only reason I can think of for dynamically unloading the libraries is to support some kind of dynamic switching of transports and/or payloads.  I suspect that this feature is an example of YAGNI, but even there is a reasonable use for this feature, forcing the vast majority of applications that don’t need it to pay the price for it is a bad design decision.

Short version, it’s my application, and I get to decide how I want it to behave. 

Best Regards,

Bill 

On Dec 28, 2017, at 10:33 AM, Frank Quinn <frank@...> wrote:

Happy holidays folks!

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

Cheers,
Frank


On Thu, Dec 28, 2017 at 3:17 PM, Sanjeev Wahi <sawahi@...> wrote:

I can suggest a possible fix (by adding extra weak_ptr check) while calling Mama.close()  that can avoid this problem in C11/C11++ when using shared_ptr.
*(assumption is Mama.close() is not called by many threads same time, in that case also use C11 atomic integer counter with this code)

*( I do not know much Java but something similar would work).



1st Approach:
Gat a new shared_ptr, but test for whether it is empty or pointing to something by testing
it for true/false, analogous to what we would do with a built-in pointer that might be zero:

void do_it(weak_ptr<Thing> wp){
        shared_ptr<Thing> sp = wp.lock(); // get shared_ptr from weak_ptr
        if(sp)
                sp->defrangulate(); // tell the Thing to do something
        else
                cout << "The Thing is gone!" << endl;
}



2nd Approach:
We can ask the weak_ptr if it has "expired":

bool is_it_there(weak_ptr<Thing> wp) {
        if(wp.expired()) {
                cout << "The Thing is gone!" << endl;
                return false;
        }
return true;
}





-Sanjeev Wahi



-----Original Message-----
From: openmama-dev-bounces@...nmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Bill Torpey
Sent: Thursday, December 28, 2017 9:39 AM
To: Yury Batrakov <yury.batrakov@...>
Cc: openmama-dev <openmama-dev@...rg>
Subject: Re: [Openmama-dev] Finalizers are dangerous

Unfortunately, that is not a bug, but a “feature”.

The problem is that mama_close unloads both the transport and payload libraries (via dlclose on Linux).  So, any access to any objects related to either library following mama_close is guaranteed to crash.

This makes OpenMAMA completely unusable for GC languages like Java, and presumably .Net, as well as for reference-counted implementations in other languages (e.g., shared_ptr in C++).

I’ve argued this point with Frank, but so far to no avail:  https://github.com/OpenMAMA/OpenMAMA/issues/264

Perhaps if enough people chime in, we can change Frank’s mind.  Until that time, the only solution I can think of is to fork OpenMAMA and remove or replace the offending code.  That is not a great solution, but as I mention in the bug report, this behavior is a total non-starter for me (and presumably for others as well).


> On Dec 28, 2017, at 6:08 AM, Yury Batrakov <yury.batrakov@...> wrote:
>
> Classification: Public
> Hi team,
>
> Sorry for telling bad news in holidays but I have found a major issue with Java API - JVM may crash if GC comes after Mama.close() method. Here's code sample to reproduce it:
>
> import com.wombat.mama.Mama;
> import com.wombat.mama.MamaMsg;
>
> public class Test {
>    private static MamaMsg getMessage() {
>        return new MamaMsg();
>    }
>
>    public static void main(String[] args) {
>        Mama.loadBridge("...");
>        Mama.open();
>
>        getMessage(); // Creating MamaMsg object without reference
>
>        Mama.close(); // Payload bridge is destroyed here
>        System.gc();
>        System.runFinalization(); // Calling MamaMsg.destroy() which delegates the destruction to deleted payload bridge
>    }
> }
>
> Stack trace:
> #12 0x00007fc494a095f0 in ?? ()
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> #14 0x00007fc496d70b7f in Java_com_wombat_mama_MamaMsg__1destroy (env=0x7fc4b00039f8, this=0x7fc49779d710) at mama/jni/src/c/mamamsgjni.c:3882
> #15 0x00007fc4bae7e494 in ?? ()
>
> Problematic frame:
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> 127             if (MAMA_STATUS_OK != impl->mPayloadBridge->msgPayloadDestroy (impl->mPayload))
>
> impl->mPayloadBridge is destroyed here.
>
> Similar crash occurs when finalizing subscriptions - they also need entitlements bridge to be available but Mama.close() deletes it too.
>
> The workaround is to call destroy() method for each message/subscription created but this actually nullifies the need for finalize() methods. I would delete all them from MAMA code.
>
>
> ---
> 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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
> _______________________________________________
> Openmama-dev mailing list
> Openmama-dev@...g
> https://lists.openmama.org/mailman/listinfo/openmama-dev

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

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...g
https://lists.openmama.org/mailman/listinfo/openmama-dev
Re: RFC DQ Pluggability

Frank Quinn
 

Thanks Aaron,

Just on the plugin-only front, I'll probably appreciate more what you mean when a pull request comes in, but it's my opinion that if the plugin code isn't flexible enough to allow us to handle this, we should consider being more flexible with the plugin code.

Maybe that's another task but again it goes into setting aside these prototypes now since I think i'd like to add it soon afterwards if it's not in the PR. I'm not sure what the rest of the dev list things but opinions are welcome?

To explain, I'm not sure hooks are much use if you can't attach context specific data to them, because then you'll *always* need to do lookups on firing. For example, I could see something like this being more useful (same for subscription):

mama_status dqstrategyMamaPlugin_transportPostCreateHook (mamaPluginInfo pluginInfo,
                                                          mamaTransport  transport,
                                                          void**         closure) {
    *closure = (void*) new Whatever();
}

mama_status dqstrategyMamaPlugin_transportEventHook(mamaPluginInfo pluginInfo,
                                                    mamaTransport  transport,
                                                    int            setStale
                                                    void*          closure) {
    Whatever whatever = (Whatever)closure;
}

That way you can initialize and attach objects on postcreate hooks which can then be retrieved later in subsequent hooks without requiring any lookups. There are a number of ways to implement this but the easiest is probably an array of pointers for each plugin instance attached to each object.

You could then have member variables attached to transports, subscriptions etc to allow plugins to fire data around without having to do its own out of band lookups.

Cheers,
Frank

On 1 Feb 2018 17:26, "Aaron Sneddon" <asneddon@...> wrote:

Hey Frank,

 

I have taken on board the suggested changes to function signatures, and will have the transport passed to transportPostCreateHook, and mamaTransportEvent to transportEventHook.

With regards to setstale, the transport callback will generally call the transportEventHook, and will take care of the setPossiblyStale stuff.

So, the setStale is there because ‘event’ on its own isn’t enough to differentiate between current disconnect/disconnectNoStale logic.


Also, I’ll update the RFC for this to be clearer.


With regards to:

I'm not sure about what's meant by the Plugin Changes section when it talks about the overriding of the default dq plugin in the plugin code. Instead might it be more straightforward if:

 

1. Additional plugins for dq could simply be loaded and live alongside each other. On-hook the plugin can then decide if it wants to set itself up based on its own configuration standards.

2. The "default" dq plugin could do something similar and decide itself if it wants to take action. This would make it more like a standard plugin rather than a special case for DQ.

3. The transportCreateHook for the dq plugin could then *itself* check a property *there* or on init to decide whether or not it should take action on this transport for the bridge as updates are fired.

 

Ideally we would like to make the DQ plugin stuff as much like normal plugins as possible.  But fitting plugins which may only need to act on particular transports in is a little awkward.  Configuration wise and conceptually it is easier to treat them in the same way as normal plugins, but point 3) is the problem here – the decision about whether or not to take action would surely need to be made on a per-update basis and so would need some sort of lookup to be performed every time.

 

Hope this helps..

 

Thanks,

Aaron

 

 

From: Frank Quinn [mailto:frank@...]
Sent: 31 January 2018 23:13
To: Aaron Sneddon <asneddon@...>
Cc: openmama-dev@...g
Subject: Re: [Openmama-dev] RFC DQ Pluggability

 

Thanks Aaron,

 

Put in a few changes to the document to make the prototypes "pop" a little bit more. A few suggestions / talking points though:

mama_status dqstrategyMamaPlugin_transportPostCreateHook (mamaPluginInfo pluginInfo)

I think it would be useful if this at least included the mamaTransport that has just been created.

mama_status dqstrategyMamaPlugin_transportEventHook(mamaPluginInfo pluginInfo,
                                                    mamaTransport  transport,
                                                    int            setStale)

It reads like setStale will represent something related to the staleness but it's not clear what possible values they may have. I also wonder if the use of mamaTransportEvent might be more useful here? Is it also feasible that this may not be necessary at all if the postCreateHook could set up a standard transport callback?

 

I'm not sure about what's meant by the Plugin Changes section when it talks about the overriding of the default dq plugin in the plugin code. Instead might it be more straightforward if:

 

1. Additional plugins for dq could simply be loaded and live alongside each other. On-hook the plugin can then decide if it wants to set itself up based on its own configuration standards.

2. The "default" dq plugin could do something similar and decide itself if it wants to take action. This would make it more like a standard plugin rather than a special case for DQ.

3. The transportCreateHook for the dq plugin could then *itself* check a property *there* or on init to decide whether or not it should take action on this transport for the bridge as updates are fired.

 

Cheers,

Frank

 

On Wed, Jan 31, 2018 at 11:30 AM, Aaron Sneddon <asneddon@...> wrote:

Thanks for your feedback, I have now added the proposed prototypes to the RFC as requested.
https://openmama.github.io/openmama_rfc_dq_pluggability.html

Just so the group is aware, there is until Thursday now to give feedback before development kicks off so today is your last chance.
You might want to take a look at the document once more, even just to look at the function prototypes since they were only added today.

 

Thanks,

Aaron

 

From: Frank Quinn [mailto:frank@...]
Sent: 30 January 2018 21:04
To: Aaron Sneddon <asneddon@...>
Cc: openmama-dev@...g
Subject: Re: [Openmama-dev] RFC DQ Pluggability

 

Thanks Aaron,

 

Apologies for the delay in getting to read this properly - for reference to the group this is the link to the document:

 

 

From my point of view I think it would be useful to get some visibility on what the proposed function prototypes will look like at the hook points.

 

There are several method names in there which is good but proposed arguments which will be passed to the plugin methods will probably be the thing of most interest to bridge developers who will want to take advantage of this functionality and may want a series of objects to be made available which may be more than what is required for the DQ use case alone.

 

Consider the fact that these plugin methods once created will be fairly set in stone, otherwise we'll end up going down the functionNameEx road again or mandatory bridge changes which nobody wants. It may be a lot easier to add additional arguments (if necessary) at this point even if they aren't required for this use case.

 

Cheers,

Frank

 

On Wed, Jan 17, 2018 at 10:01 AM, Aaron Sneddon <asneddon@...> wrote:

Hey everyone,

You may have noticed that a new RFC has been merged into master of https://github.com/OpenMAMA/openmama.github.io .

This is just to make you aware, if you weren’t already. Feel free to have a look at it under /pages/openmama/openmama_rfc_dq_pluggability.md and
let me know what you think. Comments and suggestions will be happily considered.

Regards,
Aaron


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


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...g
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. Vela Trading Technologies 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. Vela Trading Technologies LLC

OpenMAMA_Snapshot_RPM - Build # 587 - Still Failing!

jenkins@...
 

Some changes have just been added to the origin/next branch! 

[noreply] Moved to maven directory structure and added gradle scripts (#341)
	mamda/java/com/wombat/mamda/options/MamdaOptionUnderlying.java
	mama/jni/src/main/java/com/wombat/mama/MamaBasicSubscriptionCallback.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookHandler.java
	mama/jni/src/com/wombat/mama/MamaString.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaPublisherJava.java
	mamda/java/com/wombat/mamda/options/MamdaOptionStrikeSet.java
	mamda/java/com/wombat/mamda/MamdaErrorCode.java
	mamda/java/com/wombat/mamda/MamdaAuctionUpdate.java
	mamda/java/com/wombat/mamda/examples/MamdaMultiSecurityTicker.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicBookHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeRecap.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaErrorCode.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaQuoteTicker.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionFields.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionExpirationDateSet.java
	mamda/java/com/wombat/mamda/MamdaBasicRecap.java
	release_scripts/ci-run.py
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteHandler.java
	mama/jni/src/com/wombat/mama/MamaLogFilePolicy.java
	mamda/java/build.gradle
	mama/jni/src/main/java/com/wombat/mama/MamaDateTimePrecision.java
	mama/jni/src/main/java/com/wombat/mama/MamaFtCallback.java
	mama/jni/src/com/wombat/mama/MamaLong.java
	mama/jni/src/main/java/com/wombat/mama/MamaPrice.java
	mamda/java/com/wombat/mamda/MamdaTradeGap.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChain.java
	mama/jni/src/main/java/com/wombat/mama/MamaFtState.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusQual.java
	mama/jni/src/com/wombat/mama/MamaOpaque.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceRecap.java
	mamda/java/com/wombat/mamda/MamdaQuoteClosing.java
	mamda/java/src/main/java/com/wombat/mamda/locks/MamdaLock.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelHandler.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaBookTicker.java
	mama/jni/src/main/java/com/wombat/mama/MamaQueueEventCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaSubscriptionType.java
	mama/jni/src/main/java/com/wombat/mama/MamaString.java
	mama/jni/src/com/wombat/mama/MamaPayloadBridge.java
	mama/jni/src/main/java/com/wombat/mama/MamaFieldDescriptor.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaOptionChainExample.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogFileCallback.java
	mama/jni/src/com/wombat/mama/MamaMdDataType.java
	mama/jni/src/com/wombat/mama/MamaSourceGroupManager.java
	mama/jni/src/com/wombat/mama/MamaNotEntitledException.java
	mamda/java/junittests/secstatus/MamdaSecStatusTests.java
	mama/jni/src/main/java/com/wombat/mama/MamaTimerCallback.java
	mama/jni/src/com/wombat/mama/MamaLogFileCallback2.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusListener.java
	mama/jni/src/com/wombat/mama/MamaSourceManager.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusRecap.java
	mama/jni/src/com/wombat/mama/MamaMsgField.java
	mama/jni/src/com/wombat/mama/MamaShort.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookMissingEntryException.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelEntryHandler.java
	mamda/java/com/wombat/mamda/MamdaAuctionFields.java
	mama/jni/src/com/wombat/mama/MamaMessage.java
	mamda/java/com/wombat/mamda/MamdaTradeSide.java
	mamda/java/com/wombat/mamda/options/MamdaOptionSeriesUpdate.java
	mamda/java/com/wombat/mamda/options/MamdaOptionExpirationDateSet.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgIterator.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionListener.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicBookHandler.java
	mama/jni/src/main/java/com/wombat/mama/MamaBoolean.java
	mamda/java/junittests/trades/MamdaTradeIdTests.java
	mama/jni/src/main/java/com/wombat/mama/MamaNotEntitledException.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionStrikeSet.java
	mama/jni/src/com/wombat/mama/MamaBuffer.java
	mama/jni/src/com/wombat/mama/examples/MamaInboxJava.java
	mamda/java/com/wombat/mamda/MamdaErrorSeverity.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaBasicRecap.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionContractSet.java
	mama/jni/src/com/wombat/mama/MamaArrayInt.java
	mama/jni/src/main/java/com/wombat/mama/MamaException.java
	mama/jni/src/com/wombat/mama/MamaError.java
	mamda/java/com/wombat/mamda/examples/MamdaQuoteTicker.java
	mama/jni/src/main/java/com/wombat/mama/MamaFieldNotFoundException.java
	mama/jni/src/com/wombat/mama/MamaLogFileCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaPayloadType.java
	mamda/java/com/wombat/mamda/MamdaFundamentalHandler.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaNoEntitlementsForUserException.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookEntryManager.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaDouble.java
	mama/jni/src/com/wombat/mama/MamaPublisherCallback.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookBasicDeltaList.java
	mamda/java/com/wombat/mamda/examples/MamdaBookTicker.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceUpdate.java
	mama/jni/SConscript.win
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaAtomicBookTicker.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookGap.java
	mama/jni/src/main/java/com/wombat/mama/MamaInteger.java
	mama/jni/src/main/java/com/wombat/mama/MamaDictionary.java
	mama/jni/src/main/java/com/wombat/mama/MamaStatus.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMultiParticipantManager.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaComboTicker.java
	mama/jni/src/com/wombat/mama/MamaMdMsgType.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaMsgVectorFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaDQCause.java
	mama/jni/src/com/wombat/mama/MamaReservedFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaQueueMonitorCallback.java
	mama/jni/SConscript
	mama/jni/src/main/java/com/wombat/mama/MamaError.java
	mama/jni/src/com/wombat/mama/MamaPrice.java
	mamda/java/com/wombat/mamda/MamdaErrorListener.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaErrorListener.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookCheckerHandler.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookCheckerHandler.java
	mama/jni/src/main/java/com/wombat/mama/MamaReservedFields.java
	mama/jni/src/junittests/MamaMsgTryMethods.java
	mama/jni/src/com/wombat/mama/MamaFieldNotFoundException.java
	mamda/java/com/wombat/mamda/MamdaUncrossPriceInd.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderbookConcreteComplexDelta.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionRecap.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaBookChurn.java
	mama/jni/src/main/java/com/wombat/mama/MamaChar.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaBookPublisher.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteClosing.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFundamentalListener.java
	mama/jni/src/com/wombat/mama/MamaDictionaryCallback.java
	mamda/java/com/wombat/mamda/MamdaMultiParticipantHandler.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceManager.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusRecap.java
	mama/jni/src/junittests/MamaQueueGroupTest.java
	mama/jni/src/com/wombat/mama/MamaException.java
	mama/jni/src/com/wombat/mama/MamaDateTimePrecision.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogHandler.java
	mama/jni/src/com/wombat/mama/MamaPriceHints.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelEntry.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFieldState.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusUpdate.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMultiParticipantHandler.java
	mama/jni/src/com/wombat/mama/MamaFtMember.java
	mama/jni/src/junittests/MamaMsgGetByteBuffer.java
	mama/jni/src/com/wombat/mama/MamaInboxCallback.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeCancelOrError.java
	mama/jni/src/junittests/MamaMsgAddArrayMsgWithLength.java
	mama/jni/src/com/wombat/mama/MamaSubscription.java
	mama/jni/src/com/wombat/mama/MamaServiceLevel.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteUpdate.java
	mamda/java/com/wombat/mamda/locks/MamdaLock15.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/quotes/MamdaQuoteTests.java
	mama/jni/src/main/java/com/wombat/mama/MamaThrottleInstance.java
	mama/jni/src/junittests/MamaDateTimeSetTimeZone.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusUpdate.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookComplexDelta.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/orderBooks/MamdaBookPublisherTests.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaQueueGroupTest.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceState.java
	mama/jni/src/main/java/com/wombat/mama/MamaFtMember.java
	mamda/java/com/wombat/mamda/examples/MamdaFundamentalTicker.java
	mama/jni/src/com/wombat/mama/MamaBoolean.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/secstatus/MamdaSecStatusTests.java
	mamda/java/junittests/trades/MamdaTradeShortSaleTests.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceType.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaDataException.java
	mama/jni/src/com/wombat/mama/MamaThrottleInstance.java
	mama/jni/src/com/wombat/mama/MamaDQPublisherManagerCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceGroupManager.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/secstatus/MamdaSecStatusShortSaleTests.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionExpirationStrikes.java
	mama/jni/src/main/java/com/wombat/mama/MamaConnection.java
	mama/jni/src/com/wombat/mama/MamaStatus.java
	mamda/java/com/wombat/mamda/locks/MamdaLock14.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicGap.java
	mamda/java/junittests/orderBooks/MamdaBookPublisherTests.java
	mamda/java/com/wombat/mamda/MamdaTradeReport.java
	mama/jni/src/com/wombat/mama/MamaMsgQualifier.java
	mamda/java/com/wombat/mamda/examples/MamdaBookSelfTest.java
	mama/jni/src/main/java/com/wombat/mama/MamaInbox.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeCorrection.java
	mamda/java/com/wombat/mamda/MamdaConcreteBasicEvent.java
	mamda/java/com/wombat/mamda/MamdaAuctionRecap.java
	mama/jni/src/main/java/com/wombat/mama/MamaLong.java
	mamda/java/com/wombat/mamda/MamdaBasicEvent.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceDerivative.java
	mamda/java/com/wombat/mamda/examples/MamdaBookPublisher.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaInboxJava.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteRecap.java
	mama/jni/src/main/java/com/wombat/mama/MamaDQPublisherManagerCallback.java
	mama/jni/src/com/wombat/mama/MamaInteger.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelEntryHandler.java
	mama/jni/src/com/wombat/mama/MamaPayloadType.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookInvalidEntryException.java
	mama/jni/src/com/wombat/mama/MamaTransport.java
	mama/jni/src/com/wombat/mama/MamaFtType.java
	mama/jni/src/com/wombat/mama/MamaMsgIterator.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookWriter.java
	mama/jni/src/com/wombat/mama/MamaDQPublisherManager.java
	mama/jni/src/com/wombat/mama/MamaDQCause.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookChecker.java
	mama/jni/src/main/java/com/wombat/mama/MamaMdDataType.java
	mama/jni/src/com/wombat/mama/MamaByte.java
	mama/jni/src/com/wombat/mama/MamaFtState.java
	mamda/java/com/wombat/mamda/MamdaTradeListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaQueueGroup.java
	mama/jni/src/main/java/com/wombat/mama/MamaDQPublisher.java
	mama/jni/src/main/java/com/wombat/mama/MamaPublisherCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaTransportListener.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaInboxCallback.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicListener.java
	mama/jni/src/com/wombat/mama/MamaLogHandler.java
	mama/jni/src/com/wombat/mama/MamaTimeZone.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookListener.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookMissingEntryException.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaUncrossPriceInd.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFields.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookTypes.java
	mamda/java/src/main/java/com/wombat/mamda/examples/CommandLineProcessor.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteClear.java
	mama/jni/src/com/wombat/mama/testtools/performance/MamaConsumerJava.java
	mamda/java/com/wombat/mamda/MamdaTradeCancelOrError.java
	mama/jni/src/com/wombat/mama/MamaQuality.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusHandler.java
	mama/jni/src/com/wombat/mama/MamaBasicWildCardSubscriptionCallback.java
	mama/jni/src/test/java/com/wombat/mama/junittests/Main.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaMsgGetByteBuffer.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBook.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteSimpleDelta.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaPriceGetRoundedPrice.java
	mama/jni/src/main/java/com/wombat/mama/MamaTimer.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeListener.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookBasicDeltaList.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeSide.java
	mamda/java/com/wombat/mamda/options/MamdaOptionExpirationStrikes.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaMsgTryMethods.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionUpdate.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeHandler.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBook.java
	mamda/java/com/wombat/mamda/MamdaMultiParticipantManager.java
	mamda/java/com/wombat/mamda/MamdaQuoteGap.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaListen.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatus.java
	mama/jni/src/junittests/Main.java
	mama/jni/src/com/wombat/mama/MamaDateTimeHints.java
	mamda/java/com/wombat/mamda/examples/MamdaListen.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaOpenClose.java
	mama/jni/src/main/java/com/wombat/mama/MamaBridge.java
	mamda/java/junittests/secstatus/MamdaSecurityStatusQualTests.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChain.java
	mamda/java/com/wombat/mamda/examples/MamdaOptionChainExample.java
	mamda/java/com/wombat/mamda/examples/MamdaTradeTicker.java
	mama/jni/src/com/wombat/mama/MamaDispatcher.java
	mamda/java/com/wombat/mamda/MamdaFields.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookDelta.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/secstatus/MamdaSecurityStatusQualTests.java
	mamda/java/com/wombat/mamda/MamdaQuoteListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaQuality.java
	mama/jni/src/com/wombat/mama/MamaSubscriptionType.java
	mama/jni/src/main/java/com/wombat/mama/MamaArrayInt.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteRecap.java
	mama/jni/src/com/wombat/mama/MamaArrayString.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogFilePolicy.java
	mama/jni/src/com/wombat/mama/MamaThrottleCallback.java
	mama/jni/src/com/wombat/mama/MamaTransportListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaMdMsgType.java
	mama/jni/src/junittests/MamaSetLogCallback.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionAtTheMoneyCompareType.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookEntryFilter.java
	mamda/java/com/wombat/mamda/examples/MamdaOptionChainViewExample.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaConcreteBasicEvent.java
	mama/jni/src/com/wombat/mama/MamaQueueGroup.java
	mama/jni/src/junittests/MamaPriceGetRoundedPrice.java
	mamda/java/com/wombat/mamda/MamdaMsgListener.java
	mamda/java/com/wombat/mamda/orderbook/BookMsgHolder.java
	mama/jni/src/com/wombat/mama/examples/MamaPublisherJava.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookBasicDelta.java
	mamda/java/com/wombat/mamda/examples/MamdaOrderImbalanceTicker.java
	mamda/java/junittests/orderImbalances/MamdaOrderImbalanceCallBackTests.java
	mamda/java/com/wombat/mamda/MamdaFieldState.java
	mama/jni/src/main/java/com/wombat/mama/MamaFloat.java
	mama/jni/src/main/java/com/wombat/mama/MamaPricePrecision.java
	mamda/java/junittests/quotes/MamdaQuoteTests.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceSide.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookDuplicateEntryException.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookDuplicateEntryException.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogFileCallback2.java
	mama/jni/src/com/wombat/mama/MamaSource.java
	mama/jni/src/com/wombat/mama/MamaSourceGroupListener.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChainView.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgStatus.java
	mamda/java/com/wombat/mamda/MamdaQuoteUpdate.java
	mama/jni/src/com/wombat/mama/Mama.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeGap.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceGroup.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMultiSecurityHandler.java
	mama/jni/src/com/wombat/mama/MamaNoEntitlementsForUserException.java
	mamda/java/com/wombat/mamda/MamdaTradeRecap.java
	mamda/java/com/wombat/mamda/examples/MamdaMultiPartTicker.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookFields.java
	mama/jni/build.gradle
	mama/jni/src/main/java/com/wombat/mama/MamaQueue.java
	mama/jni/src/com/wombat/mama/MamaBasicSubscription.java
	mama/jni/src/main/java/com/wombat/mama/testtools/load/MamaChurnTest.java
	mama/jni/src/main/java/com/wombat/mama/MamaBasicSubscription.java
	mamda/java/com/wombat/mamda/options/MamdaOptionAtTheMoneyCompareType.java
	mama/jni/src/com/wombat/mama/MamaDictionary.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaArrayString.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookRecap.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookChecker.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteGap.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/Main.java
	mama/jni/src/main/java/com/wombat/mama/MamaSubscriptionCallback.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionExchangeUtils.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookHandler.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaMultiPartTicker.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevel.java
	mama/jni/src/com/wombat/mama/MamaFtCallback.java
	mama/jni/src/main/java/com/wombat/mama/testtools/performance/MamaConsumerJava.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusHandler.java
	mama/jni/src/com/wombat/mama/MamaMsg.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookSimpleDelta.java
	mama/jni/src/com/wombat/mama/examples/MamaSymbolListSubscriberJava.java
	mama/jni/src/main/java/com/wombat/mama/MamaDQPublisherManager.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatus.java
	mama/jni/src/com/wombat/mama/MamaMsgFieldIterator.java
	mama/jni/src/com/wombat/mama/MamaFloat.java
	mama/jni/src/main/java/com/wombat/common/WombatException.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/trades/MamdaTradeIdTests.java
	mama/jni/src/com/wombat/mama/testtools/load/MamaChurnTest.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaOrderImbalanceTicker.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookGap.java
	mama/jni/src/com/wombat/mama/MamaBridge.java
	mama/jni/src/main/java/com/wombat/mama/MamaFieldTypeException.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaFundamentalTicker.java
	mama/jni/src/main/java/com/wombat/mama/MamaTransportTopicListener.java
	mamda/java/com/wombat/mamda/MamdaQuoteHandler.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/BookMsgHolder.java
	mamda/java/com/wombat/mamda/MamdaAuctionListener.java
	mama/jni/src/com/wombat/mama/MamaLogLevel.java
	mama/jni/src/main/java/com/wombat/mama/testtools/performance/MamaProducerJava.java
	mamda/java/com/wombat/mamda/MamdaQuality.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceListener.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFundamentalFields.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookPriceLevel.java
	mama/jni/src/main/java/com/wombat/mama/MamaSubscriptionState.java
	mama/jni/src/main/java/com/wombat/mama/MamaPublisher.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaSubscriberJava.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderbookConcreteComplexDelta.java
	mama/jni/src/com/wombat/mama/MamaPublisher.java
	mama/jni/src/com/wombat/mama/MamaQueueMonitorCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaShort.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFundamentals.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteClear.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookInvalidEntryException.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookTypes.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionSeriesUpdate.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaFtMemberJava.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookEntry.java
	mamda/java/com/wombat/mamda/MamdaDataException.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChainListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaDictionaryCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaFtType.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceStateChangeListener.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeClosing.java
	mama/jni/src/main/java/com/wombat/mama/MamaBuffer.java
	mama/jni/src/com/wombat/mama/MamaFIDConflictException.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgField.java
	mama/jni/src/com/wombat/mama/MamaDayOfWeek.java
	mama/jni/src/main/java/com/wombat/mama/MamaTransport.java
	mama/jni/src/junittests/MamaTimerCallbacks.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookPriceLevel.java
	mama/jni/src/com/wombat/mama/MamaSourceState.java
	mama/jni/src/com/wombat/mama/MamaTimerCallback.java
	mamda/java/com/wombat/mamda/options/MamdaOptionExchangeUtils.java
	mama/jni/src/main/java/com/wombat/mama/MamaDispatcher.java
	mama/jni/src/com/wombat/mama/MamaInbox.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaTradeTicker.java
	mama/jni/src/main/java/com/wombat/mama/MamaSource.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaCommonFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceGroupListener.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceFields.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMsgListener.java
	mama/jni/src/com/wombat/mama/MamaQueue.java
	mama/jni/src/com/wombat/mama/MamaChar.java
	mama/jni/src/com/wombat/mama/MamaDQPublisher.java
	mamda/java/settings.gradle
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceUpdate.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookSimpleDelta.java
	mama/jni/src/com/wombat/mama/MamaPricePrecision.java
	mama/jni/build.xml
	mama/jni/src/main/java/com/wombat/mama/MamaStartBackgroundCallback.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelEntry.java
	mamda/java/com/wombat/mamda/MamdaFundamentalListener.java
	mamda/java/com/wombat/mamda/examples/MamdaAuctionTicker.java
	mama/jni/src/com/wombat/mama/MamaFieldDescriptor.java
	mama/jni/src/com/wombat/mama/MamaTransportTopicListener.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaTimerCallbacks.java
	mamda/java/SConscript
	mamda/java/com/wombat/mamda/MamdaFundamentals.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookCheckType.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteListener.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaAuctionTicker.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/trades/MamdaTradeShortSaleTests.java
	mama/jni/src/com/wombat/mama/MamaBasicSubscriptionCallback.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSubscription.java
	mamda/java/com/wombat/mamda/MamdaStaleListener.java
	mama/jni/src/com/wombat/mama/MamaSourceGroup.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChainListener.java
	mamda/java/com/wombat/mamda/MamdaSubscription.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeReport.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookRecap.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaSetLogCallback.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookEntry.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaMultiSecurityTicker.java
	mama/jni/src/main/java/com/wombat/mama/MamaMessage.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaProxy.java
	mamda/java/com/wombat/mamda/examples/MamdaSecStatusTicker.java
	mamda/java/com/wombat/mamda/examples/MamdaBookChurn.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgType.java
	mama/jni/src/main/java/com/wombat/mama/MamaServiceLevel.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookClear.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusListener.java
	mamda/java/com/wombat/mamda/options/MamdaOptionFields.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaListenerBookPublisher.java
	mamda/java/SConscript.win
	mama/jni/src/main/java/com/wombat/mama/Mama.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsg.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaErrorSeverity.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuality.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceHandler.java
	mama/jni/src/main/java/com/wombat/mama/MamaSubscription.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionContract.java
	mamda/java/com/wombat/mamda/examples/CommandLineProcessor.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceRecap.java
	mama/jni/src/main/java/com/wombat/mama/MamaThrottleCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaOpaque.java
	mama/jni/src/com/wombat/mama/MamaFieldTypeException.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChainViewRangeHandler.java
	mama/jni/src/com/wombat/mama/examples/MamaFtMemberJava.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusQual.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChainViewRangeHandler.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaListen.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaAtomicBookBuilder.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaDateTimeSetTimeZone.java
	mama/jni/src/com/wombat/mama/MamaDouble.java
	mamda/java/com/wombat/mamda/MamdaMultiSecurityManager.java
	mama/jni/src/com/wombat/mama/MamaSourceStateChangeListener.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionUnderlying.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceType.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusFields.java
	mamda/java/com/wombat/mamda/MamdaQuoteFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaBasicWildCardSubscriptionCallback.java
	mama/jni/settings.gradle
	mama/jni/src/main/java/com/wombat/mama/MamaByte.java
	mamda/java/com/wombat/mamda/MamdaCommonFields.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceHandler.java
	mama/jni/src/com/wombat/mama/MamaMsgStatus.java
	mama/jni/src/main/java/com/wombat/mama/MamaPayloadBridge.java
	mama/jni/src/com/wombat/mama/examples/MamaSubscriberJava.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaSymbolListSubscriberJava.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgQualifier.java
	mama/jni/src/com/wombat/mama/MamaQueueEventCallback.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookComplexDelta.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteSimpleDelta.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaBasicEvent.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookException.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaMsgAddArrayMsgWithLength.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookDelta.java
	mamda/java/com/wombat/mamda/MamdaMultiSecurityHandler.java
	mamda/java/com/wombat/mamda/examples/MamdaComboTicker.java
	mama/jni/src/main/java/com/wombat/mama/MamaFIDConflictException.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicGap.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookEntryManager.java
	mama/jni/src/junittests/MamaOpenClose.java
	mamda/java/com/wombat/mamda/MamdaTradeCorrection.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookBasicDelta.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChainHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusFields.java
	mamda/java/com/wombat/mamda/MamdaTradeClosing.java
	mama/jni/src/main/java/com/wombat/mama/MamaDateTimeHints.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteRecap.java
	mamda/java/junittests/trades/MamdaTradeSideTests.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFundamentalHandler.java
	mama/jni/src/com/wombat/mama/MamaSubscriptionCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaPriceHints.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevel.java
	mama/jni/src/com/wombat/mama/MamaSubscriptionState.java
	mamda/java/com/wombat/mamda/MamdaQuoteRecap.java
	mama/jni/src/junittests/MamaMsgVectorFields.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicListener.java
	mamda/java/com/wombat/mamda/examples/MamdaAtomicBookTicker.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookCheckType.java
	mama/jni/src/com/wombat/mama/MamaConnection.java
	mama/jni/src/main/java/com/wombat/mama/MamaDayOfWeek.java
	mama/jni/src/com/wombat/mama/MamaArrayMsg.java
	mama/jni/src/main/java/com/wombat/mama/MamaDateTime.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookEntryFilter.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/orderImbalances/MamdaOrderImbalanceCallBackTests.java
	mama/jni/src/com/wombat/mama/MamaMsgType.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgFieldIterator.java
	common/jni/src/com/wombat/common/WombatException.java
	mama/jni/src/main/java/com/wombat/mama/MamaTimeZone.java
	mama/jni/src/com/wombat/mama/examples/MamaProxy.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaStaleListener.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookListener.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookException.java
	mamda/java/com/wombat/mamda/MamdaTradeFields.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/trades/MamdaTradeSideTests.java
	mamda/java/junittests/secstatus/MamdaSecStatusShortSaleTests.java
	mama/jni/src/com/wombat/mama/testtools/performance/MamaProducerJava.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookClear.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaSecStatusTicker.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChainHandler.java
	mamda/java/com/wombat/mamda/MamdaTradeHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMultiSecurityManager.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChainView.java
	mamda/java/com/wombat/mamda/options/MamdaOptionContractSet.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionHandler.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaBookSelfTest.java
	mamda/java/com/wombat/mamda/examples/MamdaAtomicBookBuilder.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionFields.java
	mamda/java/com/wombat/mamda/MamdaAuctionHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteFields.java
	mama/jni/src/com/wombat/mama/MamaStartBackgroundCallback.java
	mamda/java/com/wombat/mamda/examples/MamdaListenerBookPublisher.java
	mama/jni/src/com/wombat/mama/MamaTimer.java
	mama/jni/src/com/wombat/mama/MamaDateTime.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookWriter.java
	mama/jni/src/main/java/com/wombat/mama/MamaArrayMsg.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaOptionChainViewExample.java
	mamda/java/com/wombat/mamda/MamdaFundamentalFields.java
	mamda/java/com/wombat/mamda/options/MamdaOptionContract.java
	mama/jni/src/com/wombat/mama/examples/MamaListen.java
	mamda/java/build.xml
	mamda/java/junittests/orderBooks/MamdaBookIssueRelatedTests.java
	mama/jni/src/com/wombat/mama/MamaSourceDerivative.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceSide.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogLevel.java

Results for OpenMAMA_Snapshot_RPM CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_RPM
  • Build Number: #587
  • Build Status: Still Failing
  • Build Warnings:
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.

Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch! 

[noreply] Moved to maven directory structure and added gradle scripts (#341)
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookTypes.java
	mama/jni/src/com/wombat/mama/examples/MamaPublisherJava.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusRecap.java
	mamda/java/com/wombat/mamda/examples/MamdaSecStatusTicker.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaDateTimeSetTimeZone.java
	mama/jni/src/com/wombat/mama/MamaLogLevel.java
	mamda/java/com/wombat/mamda/MamdaConcreteBasicEvent.java
	mama/jni/src/com/wombat/mama/MamaFieldTypeException.java
	mamda/java/junittests/orderBooks/MamdaBookIssueRelatedTests.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionUnderlying.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookDelta.java
	mamda/java/com/wombat/mamda/MamdaTradeListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceStateChangeListener.java
	mama/jni/src/com/wombat/mama/MamaFtMember.java
	mama/jni/build.xml
	mama/jni/src/com/wombat/mama/MamaPayloadType.java
	mamda/java/com/wombat/mamda/MamdaAuctionFields.java
	mama/jni/src/test/java/com/wombat/mama/junittests/Main.java
	mamda/java/com/wombat/mamda/MamdaMultiParticipantHandler.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelHandler.java
	mamda/java/com/wombat/mamda/options/MamdaOptionExpirationStrikes.java
	mama/jni/src/junittests/MamaMsgAddArrayMsgWithLength.java
	mama/jni/src/main/java/com/wombat/mama/MamaTimeZone.java
	mama/jni/src/main/java/com/wombat/mama/MamaDQPublisherManager.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookEntryFilter.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookEntryManager.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMultiSecurityHandler.java
	mama/jni/src/com/wombat/mama/MamaSourceStateChangeListener.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFundamentals.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookGap.java
	mama/jni/src/main/java/com/wombat/mama/MamaOpaque.java
	mama/jni/src/com/wombat/mama/testtools/performance/MamaConsumerJava.java
	mama/jni/src/main/java/com/wombat/mama/testtools/performance/MamaConsumerJava.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookCheckType.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaQuoteTicker.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaErrorCode.java
	mama/jni/src/main/java/com/wombat/mama/MamaPublisherCallback.java
	mama/jni/src/com/wombat/mama/MamaQuality.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaMsgGetByteBuffer.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookClear.java
	mama/jni/src/main/java/com/wombat/mama/MamaFieldNotFoundException.java
	mama/jni/src/com/wombat/mama/MamaArrayMsg.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaMsgAddArrayMsgWithLength.java
	mama/jni/src/junittests/MamaMsgGetByteBuffer.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionExchangeUtils.java
	mama/jni/src/com/wombat/mama/MamaQueueMonitorCallback.java
	mama/jni/src/com/wombat/mama/MamaBuffer.java
	mama/jni/src/main/java/com/wombat/mama/MamaArrayMsg.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeClosing.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChainView.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookDelta.java
	mama/jni/src/com/wombat/mama/MamaOpaque.java
	mamda/java/SConscript
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaPriceGetRoundedPrice.java
	mama/jni/src/com/wombat/mama/MamaFIDConflictException.java
	mama/jni/src/com/wombat/mama/MamaSubscriptionType.java
	mama/jni/src/main/java/com/wombat/mama/MamaArrayInt.java
	mama/jni/src/main/java/com/wombat/mama/MamaDictionaryCallback.java
	mama/jni/src/com/wombat/mama/MamaMsgType.java
	mamda/java/junittests/secstatus/MamdaSecStatusShortSaleTests.java
	mamda/java/com/wombat/mamda/options/MamdaOptionAtTheMoneyCompareType.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChainViewRangeHandler.java
	mama/jni/src/com/wombat/mama/MamaDictionary.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicGap.java
	mamda/java/com/wombat/mamda/examples/MamdaBookChurn.java
	mamda/java/com/wombat/mamda/MamdaTradeSide.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaOpenClose.java
	mamda/java/com/wombat/mamda/MamdaQuoteUpdate.java
	mama/jni/src/main/java/com/wombat/mama/MamaPriceHints.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChainHandler.java
	mamda/java/com/wombat/mamda/options/MamdaOptionExpirationDateSet.java
	mamda/java/com/wombat/mamda/MamdaTradeFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaFtState.java
	mama/jni/src/main/java/com/wombat/mama/MamaBasicSubscriptionCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaFtType.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceGroupListener.java
	mama/jni/src/com/wombat/mama/MamaBasicWildCardSubscriptionCallback.java
	mama/jni/SConscript.win
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaOptionChainExample.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookTypes.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChain.java
	mama/jni/src/main/java/com/wombat/mama/MamaMdDataType.java
	mama/jni/src/main/java/com/wombat/mama/MamaServiceLevel.java
	mamda/java/com/wombat/mamda/MamdaTradeGap.java
	mama/jni/src/com/wombat/mama/MamaException.java
	mama/jni/src/main/java/com/wombat/mama/MamaTransportListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogHandler.java
	mama/jni/src/main/java/com/wombat/mama/MamaLong.java
	mamda/java/com/wombat/mamda/examples/MamdaBookSelfTest.java
	mama/jni/src/com/wombat/mama/MamaTimer.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceGroup.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusFields.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookBasicDelta.java
	mama/jni/src/com/wombat/mama/MamaError.java
	mama/jni/src/main/java/com/wombat/mama/MamaPayloadBridge.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaListen.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderbookConcreteComplexDelta.java
	mama/jni/src/com/wombat/mama/MamaBasicSubscription.java
	mamda/java/com/wombat/mamda/MamdaTradeRecap.java
	mama/jni/src/com/wombat/mama/MamaSourceManager.java
	mama/jni/src/com/wombat/mama/MamaSubscriptionState.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceRecap.java
	mama/jni/src/main/java/com/wombat/mama/MamaBasicSubscription.java
	mama/jni/src/main/java/com/wombat/mama/MamaFtMember.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookMissingEntryException.java
	mama/jni/src/com/wombat/mama/MamaTimerCallback.java
	mamda/java/com/wombat/mamda/orderbook/BookMsgHolder.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookComplexDelta.java
	mama/jni/src/junittests/MamaMsgTryMethods.java
	mama/jni/SConscript
	mama/jni/src/main/java/com/wombat/mama/MamaTimerCallback.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelEntryHandler.java
	mama/jni/src/com/wombat/mama/MamaQueue.java
	mama/jni/src/main/java/com/wombat/mama/MamaQuality.java
	mamda/java/com/wombat/mamda/examples/MamdaAtomicBookBuilder.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgStatus.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicBookHandler.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaException.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteListener.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/quotes/MamdaQuoteTests.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaListen.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaErrorSeverity.java
	mamda/java/com/wombat/mamda/MamdaTradeCancelOrError.java
	mama/jni/src/com/wombat/mama/MamaPrice.java
	mama/jni/build.gradle
	mama/jni/src/com/wombat/mama/MamaSourceGroupManager.java
	mama/jni/src/main/java/com/wombat/mama/MamaInbox.java
	mama/jni/src/main/java/com/wombat/mama/MamaThrottleInstance.java
	mama/jni/src/com/wombat/mama/MamaQueueEventCallback.java
	mama/jni/src/com/wombat/mama/MamaDQPublisherManagerCallback.java
	mama/jni/src/com/wombat/mama/MamaPricePrecision.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaAuctionTicker.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionFields.java
	mamda/java/com/wombat/mamda/examples/MamdaOrderImbalanceTicker.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionAtTheMoneyCompareType.java
	mamda/java/com/wombat/mamda/examples/MamdaOptionChainViewExample.java
	mamda/java/com/wombat/mamda/MamdaQuoteFields.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaBasicRecap.java
	mamda/java/com/wombat/mamda/MamdaQuoteClosing.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaMultiPartTicker.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookCheckerHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionHandler.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChainListener.java
	mama/jni/src/com/wombat/mama/MamaReservedFields.java
	mamda/java/com/wombat/mamda/options/MamdaOptionContract.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookDuplicateEntryException.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaDataException.java
	mamda/java/com/wombat/mamda/MamdaSubscription.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogFileCallback2.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookCheckType.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgType.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicListener.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookComplexDelta.java
	mama/jni/src/com/wombat/mama/MamaArrayInt.java
	mama/jni/src/com/wombat/mama/MamaNoEntitlementsForUserException.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelHandler.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookChecker.java
	mama/jni/src/main/java/com/wombat/mama/MamaShort.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookFields.java
	mama/jni/src/com/wombat/mama/examples/MamaListen.java
	mama/jni/src/main/java/com/wombat/mama/MamaTransport.java
	mama/jni/src/junittests/MamaMsgVectorFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaBridge.java
	mama/jni/src/main/java/com/wombat/mama/MamaDQCause.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeGap.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeReport.java
	mama/jni/src/main/java/com/wombat/mama/MamaQueue.java
	mamda/java/com/wombat/mamda/options/MamdaOptionContractSet.java
	mama/jni/src/com/wombat/mama/Mama.java
	mama/jni/src/main/java/com/wombat/mama/MamaTimer.java
	mama/jni/src/main/java/com/wombat/mama/MamaInboxCallback.java
	mama/jni/src/com/wombat/mama/MamaBoolean.java
	mamda/java/com/wombat/mamda/examples/MamdaFundamentalTicker.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaSubscriberJava.java
	mamda/java/SConscript.win
	mamda/java/src/test/java/com/wombat/mamda/junittests/secstatus/MamdaSecStatusTests.java
	mama/jni/src/com/wombat/mama/testtools/load/MamaChurnTest.java
	mamda/java/com/wombat/mamda/MamdaFundamentalListener.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceRecap.java
	mama/jni/src/com/wombat/mama/MamaMsgField.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/orderImbalances/MamdaOrderImbalanceCallBackTests.java
	mamda/java/com/wombat/mamda/MamdaFields.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusRecap.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookBasicDeltaList.java
	mamda/java/build.xml
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteClear.java
	mamda/java/com/wombat/mamda/MamdaQuoteRecap.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaSetLogCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgIterator.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicGap.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusQual.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaMultiSecurityTicker.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogLevel.java
	mama/jni/src/com/wombat/mama/MamaFieldNotFoundException.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaBookChurn.java
	mama/jni/src/main/java/com/wombat/mama/MamaTransportTopicListener.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaAtomicBookBuilder.java
	mamda/java/src/main/java/com/wombat/mamda/locks/MamdaLock.java
	mama/jni/src/com/wombat/mama/MamaLogFileCallback.java
	mama/jni/src/com/wombat/mama/MamaTransport.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaFtMemberJava.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChainView.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaBookSelfTest.java
	mamda/java/com/wombat/mamda/examples/MamdaBookTicker.java
	mama/jni/src/com/wombat/mama/MamaMsg.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceState.java
	mama/jni/src/com/wombat/mama/examples/MamaProxy.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteGap.java
	mama/jni/src/com/wombat/mama/MamaPublisher.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookMissingEntryException.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeListener.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFields.java
	mama/jni/src/com/wombat/mama/MamaQueueGroup.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookPriceLevel.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/BookMsgHolder.java
	mama/jni/src/com/wombat/mama/MamaDateTimeHints.java
	mama/jni/src/com/wombat/mama/MamaArrayString.java
	mama/jni/src/main/java/com/wombat/mama/MamaSubscriptionState.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionUpdate.java
	mama/jni/src/com/wombat/mama/MamaByte.java
	mama/jni/src/com/wombat/mama/MamaDateTimePrecision.java
	mama/jni/src/main/java/com/wombat/mama/MamaFIDConflictException.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatus.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionContractSet.java
	mama/jni/settings.gradle
	mama/jni/src/com/wombat/mama/MamaMsgIterator.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaProxy.java
	mama/jni/src/main/java/com/wombat/mama/MamaSubscription.java
	mamda/java/junittests/secstatus/MamdaSecurityStatusQualTests.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevel.java
	mama/jni/src/main/java/com/wombat/mama/MamaFieldDescriptor.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaOptionChainViewExample.java
	mama/jni/src/com/wombat/mama/MamaMsgFieldIterator.java
	mama/jni/src/main/java/com/wombat/mama/MamaDQPublisherManagerCallback.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicListener.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusListener.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookEntry.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookException.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaFundamentalTicker.java
	mamda/java/com/wombat/mamda/examples/MamdaQuoteTicker.java
	mama/jni/src/main/java/com/wombat/mama/MamaArrayString.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevel.java
	mama/jni/src/junittests/MamaQueueGroupTest.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookCheckerHandler.java
	mamda/java/com/wombat/mamda/MamdaAuctionListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsg.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaSecStatusTicker.java
	mama/jni/src/main/java/com/wombat/mama/MamaDateTime.java
	mama/jni/src/com/wombat/mama/MamaFtState.java
	mamda/java/com/wombat/mamda/MamdaBasicEvent.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaQueueGroupTest.java
	mama/jni/src/main/java/com/wombat/mama/MamaBoolean.java
	mama/jni/src/com/wombat/mama/MamaLogFilePolicy.java
	mamda/java/build.gradle
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookEntry.java
	mama/jni/src/com/wombat/mama/MamaTransportTopicListener.java
	mamda/java/com/wombat/mamda/locks/MamdaLock14.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookGap.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookWriter.java
	mama/jni/src/main/java/com/wombat/mama/MamaDispatcher.java
	mama/jni/src/main/java/com/wombat/mama/MamaPrice.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookWriter.java
	mama/jni/src/com/wombat/mama/MamaInbox.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgField.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/Main.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaPublisherJava.java
	mama/jni/src/main/java/com/wombat/mama/testtools/load/MamaChurnTest.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookSimpleDelta.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogFileCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaLogFilePolicy.java
	mama/jni/src/main/java/com/wombat/mama/MamaSource.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteClear.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusQual.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFieldState.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionSeriesUpdate.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaChar.java
	mamda/java/junittests/trades/MamdaTradeShortSaleTests.java
	mama/jni/src/com/wombat/mama/MamaBasicSubscriptionCallback.java
	mamda/java/junittests/trades/MamdaTradeSideTests.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionStrikeSet.java
	mama/jni/src/com/wombat/mama/MamaSourceDerivative.java
	mamda/java/com/wombat/mamda/options/MamdaOptionExchangeUtils.java
	mama/jni/src/com/wombat/mama/MamaConnection.java
	mamda/java/com/wombat/mamda/MamdaFundamentalFields.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeSide.java
	mama/jni/src/main/java/com/wombat/mama/MamaStatus.java
	mamda/java/com/wombat/mamda/MamdaTradeClosing.java
	mamda/java/junittests/secstatus/MamdaSecStatusTests.java
	mama/jni/src/com/wombat/mama/examples/MamaSymbolListSubscriberJava.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuality.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFundamentalListener.java
	mamda/java/com/wombat/mamda/MamdaMultiParticipantManager.java
	mamda/java/com/wombat/mamda/examples/MamdaAtomicBookTicker.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteHandler.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgFieldIterator.java
	mama/jni/src/com/wombat/mama/MamaPublisherCallback.java
	mama/jni/src/com/wombat/mama/MamaThrottleCallback.java
	mama/jni/src/main/java/com/wombat/mama/MamaDouble.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaStaleListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaStartBackgroundCallback.java
	mamda/java/com/wombat/mamda/MamdaQuoteGap.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaListenerBookPublisher.java
	mama/jni/src/com/wombat/mama/MamaDQPublisherManager.java
	mama/jni/src/main/java/com/wombat/mama/MamaMdMsgType.java
	mama/jni/src/com/wombat/mama/MamaSourceState.java
	mama/jni/src/com/wombat/mama/MamaSource.java
	mama/jni/src/main/java/com/wombat/mama/MamaSubscriptionCallback.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaMsgVectorFields.java
	mamda/java/com/wombat/mamda/MamdaTradeHandler.java
	mama/jni/src/main/java/com/wombat/mama/MamaByte.java
	mama/jni/src/com/wombat/mama/MamaFtCallback.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceSide.java
	mama/jni/src/com/wombat/mama/MamaNotEntitledException.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaDateTimePrecision.java
	mamda/java/com/wombat/mamda/examples/CommandLineProcessor.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMultiParticipantManager.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/orderBooks/MamdaBookPublisherTests.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaInboxJava.java
	mama/jni/src/main/java/com/wombat/mama/MamaPublisher.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookHandler.java
	mama/jni/src/main/java/com/wombat/mama/MamaMsgQualifier.java
	mama/jni/src/main/java/com/wombat/mama/MamaDictionary.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/secstatus/MamdaSecStatusShortSaleTests.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/trades/MamdaTradeSideTests.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionRecap.java
	mamda/java/com/wombat/mamda/options/MamdaOptionUnderlying.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookHandler.java
	mamda/java/junittests/orderBooks/MamdaBookPublisherTests.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMultiSecurityManager.java
	mama/jni/src/com/wombat/mama/MamaSourceGroup.java
	mamda/java/com/wombat/mamda/MamdaQuality.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeCorrection.java
	mamda/java/com/wombat/mamda/MamdaMultiSecurityHandler.java
	mama/jni/src/main/java/com/wombat/mama/MamaSubscriptionType.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaOrderImbalanceTicker.java
	mama/jni/src/com/wombat/mama/MamaSourceGroupListener.java
	mamda/java/com/wombat/mamda/MamdaTradeReport.java
	mama/jni/src/main/java/com/wombat/mama/MamaDateTimeHints.java
	mama/jni/src/main/java/com/wombat/mama/testtools/performance/MamaProducerJava.java
	mamda/java/com/wombat/mamda/MamdaTradeCorrection.java
	mama/jni/src/com/wombat/mama/MamaShort.java
	mamda/java/settings.gradle
	mama/jni/src/main/java/com/wombat/mama/MamaError.java
	mama/jni/src/com/wombat/mama/MamaString.java
	mama/jni/src/com/wombat/mama/MamaInboxCallback.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaMsgTryMethods.java
	mama/jni/src/junittests/MamaSetLogCallback.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelEntry.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceManager.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusListener.java
	mama/jni/src/junittests/Main.java
	mama/jni/src/main/java/com/wombat/mama/MamaConnection.java
	mama/jni/src/com/wombat/mama/MamaPayloadBridge.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelEntry.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookEntryFilter.java
	mama/jni/src/main/java/com/wombat/common/WombatException.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookBasicDelta.java
	mama/jni/src/com/wombat/mama/MamaDictionaryCallback.java
	mamda/java/com/wombat/mamda/options/MamdaOptionChainHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusHandler.java
	mama/jni/src/com/wombat/mama/examples/MamaInboxJava.java
	mama/jni/src/com/wombat/mama/MamaDateTime.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFundamentalHandler.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceListener.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatusUpdate.java
	mamda/java/com/wombat/mamda/examples/MamdaBookPublisher.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookRecap.java
	mamda/java/com/wombat/mamda/examples/MamdaAuctionTicker.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaTradeTicker.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/trades/MamdaTradeShortSaleTests.java
	mama/jni/src/com/wombat/mama/examples/MamaFtMemberJava.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookChecker.java
	mama/jni/src/main/java/com/wombat/mama/MamaQueueEventCallback.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMultiParticipantHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaErrorListener.java
	mama/jni/src/com/wombat/mama/MamaBridge.java
	mama/jni/src/com/wombat/mama/MamaStartBackgroundCallback.java
	mamda/java/com/wombat/mamda/examples/MamdaListenerBookPublisher.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBook.java
	mamda/java/com/wombat/mamda/options/MamdaOptionSeriesUpdate.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaString.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaBookPublisher.java
	mama/jni/src/com/wombat/mama/MamaPriceHints.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionExpirationDateSet.java
	mamda/java/com/wombat/mamda/MamdaUncrossPriceInd.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaMsgListener.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookPriceLevel.java
	mama/jni/src/com/wombat/mama/MamaFieldDescriptor.java
	mama/jni/src/com/wombat/mama/MamaSubscriptionCallback.java
	mama/jni/src/com/wombat/mama/MamaMessage.java
	mamda/java/com/wombat/mamda/MamdaFundamentals.java
	mama/jni/src/main/java/com/wombat/mama/MamaDayOfWeek.java
	mamda/java/com/wombat/mamda/examples/MamdaOptionChainExample.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/trades/MamdaTradeIdTests.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaFundamentalFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaFtCallback.java
	mama/jni/src/junittests/MamaOpenClose.java
	mama/jni/src/com/wombat/mama/MamaMsgStatus.java
	mamda/java/com/wombat/mamda/examples/MamdaComboTicker.java
	mama/jni/src/junittests/MamaPriceGetRoundedPrice.java
	mama/jni/src/com/wombat/mama/MamaFtType.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaNoEntitlementsForUserException.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceSide.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceUpdate.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaBasicEvent.java
	mama/jni/src/com/wombat/mama/MamaDQCause.java
	mamda/java/junittests/quotes/MamdaQuoteTests.java
	mamda/java/com/wombat/mamda/MamdaAuctionRecap.java
	mama/jni/src/com/wombat/mama/MamaDQPublisher.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderbookConcreteComplexDelta.java
	mama/jni/src/com/wombat/mama/MamaMdDataType.java
	mamda/java/com/wombat/mamda/MamdaErrorListener.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookInvalidEntryException.java
	mama/jni/src/com/wombat/mama/MamaDouble.java
	mama/jni/src/com/wombat/mama/MamaDispatcher.java
	mamda/java/com/wombat/mamda/examples/MamdaMultiSecurityTicker.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookSimpleDelta.java
	mama/jni/src/main/java/com/wombat/mama/MamaPricePrecision.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookRecap.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteSimpleDelta.java
	mama/jni/src/main/java/com/wombat/mama/Mama.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeCancelOrError.java
	mamda/java/com/wombat/mamda/examples/MamdaMultiPartTicker.java
	mamda/java/com/wombat/mamda/MamdaMultiSecurityManager.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaAuctionListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaSourceGroupManager.java
	mamda/java/com/wombat/mamda/MamdaErrorCode.java
	mama/jni/src/com/wombat/mama/MamaLogHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceType.java
	mama/jni/src/test/java/com/wombat/mama/junittests/MamaTimerCallbacks.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionExpirationStrikes.java
	mama/jni/src/main/java/com/wombat/mama/MamaFieldTypeException.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaUncrossPriceInd.java
	mama/jni/src/com/wombat/mama/MamaSubscription.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaNotEntitledException.java
	mamda/java/src/main/java/com/wombat/mamda/examples/CommandLineProcessor.java
	mama/jni/src/com/wombat/mama/MamaTimeZone.java
	mamda/java/com/wombat/mamda/MamdaQuoteListener.java
	mama/jni/src/com/wombat/mama/MamaStatus.java
	mama/jni/src/main/java/com/wombat/mama/examples/MamaSymbolListSubscriberJava.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteUpdate.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeHandler.java
	mama/jni/src/com/wombat/mama/MamaMsgQualifier.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookBasicDeltaList.java
	mamda/java/com/wombat/mamda/MamdaFieldState.java
	mamda/java/com/wombat/mamda/orderbook/MamdaBookAtomicLevelEntryHandler.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeFields.java
	mamda/java/junittests/trades/MamdaTradeIdTests.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaComboTicker.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteRecap.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBook.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteRecap.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookEntryManager.java
	mamda/java/com/wombat/mamda/locks/MamdaLock15.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChainViewRangeHandler.java
	mama/jni/src/com/wombat/mama/MamaLong.java
	mama/jni/src/com/wombat/mama/MamaDayOfWeek.java
	mamda/java/com/wombat/mamda/MamdaCommonFields.java
	mama/jni/src/com/wombat/mama/MamaChar.java
	mama/jni/src/com/wombat/mama/MamaTransportListener.java
	mama/jni/src/main/java/com/wombat/mama/MamaPayloadType.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaTradeRecap.java
	mamda/java/com/wombat/mamda/MamdaFundamentalHandler.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookDuplicateEntryException.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookInvalidEntryException.java
	mama/jni/src/com/wombat/mama/MamaMdMsgType.java
	mamda/java/com/wombat/mamda/MamdaQuoteHandler.java
	mama/jni/src/com/wombat/mama/MamaLogFileCallback2.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceType.java
	mama/jni/src/main/java/com/wombat/mama/MamaBasicWildCardSubscriptionCallback.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookClear.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaOrderImbalanceListener.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaConcreteBasicEvent.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaBookTicker.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSubscription.java
	mama/jni/src/com/wombat/mama/MamaInteger.java
	mamda/java/com/wombat/mamda/MamdaAuctionUpdate.java
	mama/jni/src/main/java/com/wombat/mama/MamaReservedFields.java
	mamda/java/com/wombat/mamda/MamdaDataException.java
	mama/jni/src/main/java/com/wombat/mama/MamaThrottleCallback.java
	mamda/java/com/wombat/mamda/MamdaBasicRecap.java
	mamda/java/com/wombat/mamda/options/MamdaOptionFields.java
	mamda/java/com/wombat/mamda/MamdaMsgListener.java
	mamda/java/com/wombat/mamda/MamdaSecurityStatus.java
	mamda/java/src/test/java/com/wombat/mamda/junittests/secstatus/MamdaSecurityStatusQualTests.java
	mamda/java/junittests/orderImbalances/MamdaOrderImbalanceCallBackTests.java
	mamda/java/com/wombat/mamda/examples/MamdaListen.java
	mama/jni/src/main/java/com/wombat/mama/MamaFloat.java
	mama/jni/src/main/java/com/wombat/mama/MamaBuffer.java
	common/jni/src/com/wombat/common/WombatException.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChain.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionFields.java
	mama/jni/src/main/java/com/wombat/mama/MamaInteger.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteSimpleDelta.java
	mamda/java/com/wombat/mamda/MamdaErrorSeverity.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaSecurityStatusUpdate.java
	mama/jni/src/main/java/com/wombat/mama/MamaDQPublisher.java
	mamda/java/src/main/java/com/wombat/mamda/examples/MamdaAtomicBookTicker.java
	mama/jni/src/com/wombat/mama/MamaThrottleInstance.java
	mamda/java/com/wombat/mamda/MamdaStaleListener.java
	mama/jni/src/com/wombat/mama/MamaServiceLevel.java
	mama/jni/src/junittests/MamaTimerCallbacks.java
	mama/jni/src/com/wombat/mama/MamaFloat.java
	mama/jni/src/main/java/com/wombat/mama/MamaQueueGroup.java
	mama/jni/src/com/wombat/mama/examples/MamaSubscriberJava.java
	mama/jni/src/main/java/com/wombat/mama/MamaQueueMonitorCallback.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionContract.java
	mama/jni/src/junittests/MamaDateTimeSetTimeZone.java
	mama/jni/src/com/wombat/mama/testtools/performance/MamaProducerJava.java
	mamda/java/src/main/java/com/wombat/mamda/options/MamdaOptionChainListener.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaCommonFields.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookConcreteRecap.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaOrderBookException.java
	release_scripts/ci-run.py
	mama/jni/src/main/java/com/wombat/mama/MamaSourceDerivative.java
	mama/jni/src/main/java/com/wombat/mama/MamaMessage.java
	mamda/java/com/wombat/mamda/examples/MamdaTradeTicker.java
	mamda/java/com/wombat/mamda/MamdaOrderImbalanceUpdate.java
	mamda/java/src/main/java/com/wombat/mamda/MamdaQuoteClosing.java
	mamda/java/com/wombat/mamda/orderbook/MamdaOrderBookFields.java
	mamda/java/src/main/java/com/wombat/mamda/orderbook/MamdaBookAtomicBookHandler.java
	mamda/java/com/wombat/mamda/MamdaAuctionHandler.java
	mamda/java/com/wombat/mamda/options/MamdaOptionStrikeSet.java

Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #198
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.

Re: RFC DQ Pluggability

Frank Quinn
 

Thanks Aaron,

Put in a few changes to the document to make the prototypes "pop" a little bit more. A few suggestions / talking points though:
mama_status dqstrategyMamaPlugin_transportPostCreateHook (mamaPluginInfo pluginInfo)
I think it would be useful if this at least included the mamaTransport that has just been created.
mama_status dqstrategyMamaPlugin_transportEventHook(mamaPluginInfo pluginInfo,
                                                    mamaTransport  transport,
                                                    int            setStale)
It reads like setStale will represent something related to the staleness but it's not clear what possible values they may have. I also wonder if the use of mamaTransportEvent might be more useful here? Is it also feasible that this may not be necessary at all if the postCreateHook could set up a standard transport callback?

I'm not sure about what's meant by the Plugin Changes section when it talks about the overriding of the default dq plugin in the plugin code. Instead might it be more straightforward if:

1. Additional plugins for dq could simply be loaded and live alongside each other. On-hook the plugin can then decide if it wants to set itself up based on its own configuration standards.
2. The "default" dq plugin could do something similar and decide itself if it wants to take action. This would make it more like a standard plugin rather than a special case for DQ.
3. The transportCreateHook for the dq plugin could then *itself* check a property *there* or on init to decide whether or not it should take action on this transport for the bridge as updates are fired.

Cheers,
Frank

On Wed, Jan 31, 2018 at 11:30 AM, Aaron Sneddon <asneddon@...> wrote:

Thanks for your feedback, I have now added the proposed prototypes to the RFC as requested.
https://openmama.github.io/openmama_rfc_dq_pluggability.html

Just so the group is aware, there is until Thursday now to give feedback before development kicks off so today is your last chance.
You might want to take a look at the document once more, even just to look at the function prototypes since they were only added today.

 

Thanks,

Aaron

 

From: Frank Quinn [mailto:frank@...]
Sent: 30 January 2018 21:04
To: Aaron Sneddon <asneddon@...>
Cc: openmama-dev@....org
Subject: Re: [Openmama-dev] RFC DQ Pluggability

 

Thanks Aaron,

 

Apologies for the delay in getting to read this properly - for reference to the group this is the link to the document:

 

 

From my point of view I think it would be useful to get some visibility on what the proposed function prototypes will look like at the hook points.

 

There are several method names in there which is good but proposed arguments which will be passed to the plugin methods will probably be the thing of most interest to bridge developers who will want to take advantage of this functionality and may want a series of objects to be made available which may be more than what is required for the DQ use case alone.

 

Consider the fact that these plugin methods once created will be fairly set in stone, otherwise we'll end up going down the functionNameEx road again or mandatory bridge changes which nobody wants. It may be a lot easier to add additional arguments (if necessary) at this point even if they aren't required for this use case.

 

Cheers,

Frank

 

On Wed, Jan 17, 2018 at 10:01 AM, Aaron Sneddon <asneddon@...> wrote:

Hey everyone,

You may have noticed that a new RFC has been merged into master of https://github.com/OpenMAMA/openmama.github.io .

This is just to make you aware, if you weren’t already. Feel free to have a look at it under /pages/openmama/openmama_rfc_dq_pluggability.md and
let me know what you think. Comments and suggestions will be happily considered.

Regards,
Aaron


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


_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
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. Vela Trading Technologies LLC

Re: RFC DQ Pluggability

Frank Quinn
 

Thanks Aaron,

Apologies for the delay in getting to read this properly - for reference to the group this is the link to the document:


From my point of view I think it would be useful to get some visibility on what the proposed function prototypes will look like at the hook points.

There are several method names in there which is good but proposed arguments which will be passed to the plugin methods will probably be the thing of most interest to bridge developers who will want to take advantage of this functionality and may want a series of objects to be made available which may be more than what is required for the DQ use case alone.

Consider the fact that these plugin methods once created will be fairly set in stone, otherwise we'll end up going down the functionNameEx road again or mandatory bridge changes which nobody wants. It may be a lot easier to add additional arguments (if necessary) at this point even if they aren't required for this use case.

Cheers,
Frank

On Wed, Jan 17, 2018 at 10:01 AM, Aaron Sneddon <asneddon@...> wrote:

Hey everyone,

You may have noticed that a new RFC has been merged into master of https://github.com/OpenMAMA/openmama.github.io .

This is just to make you aware, if you weren’t already. Feel free to have a look at it under /pages/openmama/openmama_rfc_dq_pluggability.md and
let me know what you think. Comments and suggestions will be happily considered.

Regards,
Aaron


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

_______________________________________________
Openmama-dev mailing list
Openmama-dev@....org
https://lists.openmama.org/mailman/listinfo/openmama-dev
Re: Openmama-dev Digest, Vol 73, Issue 4

Aaron Sneddon
 

Hey,

Just to make it easier, here's a direct link to the page: https://openmama.github.io/openmama_rfc_dq_pluggability.html

Thanks,
Aaron

-----Original Message-----
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of openmama-dev-request@...
Sent: 17 January 2018 12:00
To: openmama-dev@...
Subject: Openmama-dev Digest, Vol 73, Issue 4

Send Openmama-dev mailing list submissions to
openmama-dev@...

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openmama.org/mailman/listinfo/openmama-dev
or, via email, send a message with subject or body 'help' to
openmama-dev-request@...

You can reach the person managing the list at
openmama-dev-owner@...

When replying, please edit your Subject line so it is more specific than "Re: Contents of Openmama-dev digest..."


Today's Topics:

1. RFC DQ Pluggability (Aaron Sneddon)


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

Message: 1
Date: Wed, 17 Jan 2018 10:01:31 +0000
From: Aaron Sneddon <asneddon@...>
To: "openmama-dev@..."
<openmama-dev@...>
Subject: [Openmama-dev] RFC DQ Pluggability
Message-ID:
<BN1PR02MB230984B4F5A41340D93B528B3E90@...>

Content-Type: text/plain; charset="us-ascii"

Hey everyone,

You may have noticed that a new RFC has been merged into master of https://github.com/OpenMAMA/openmama.github.io .

This is just to make you aware, if you weren't already. Feel free to have a look at it under /pages/openmama/openmama_rfc_dq_pluggability.md and let me know what you think. Comments and suggestions will be happily considered.

Regards,
Aaron

The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. Vela Trading Technologies LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmama.org/pipermail/openmama-dev/attachments/20180117/e2e1cd43/attachment-0001.html>

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

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


End of Openmama-dev Digest, Vol 73, Issue 4
*******************************************

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

Aaron Sneddon
 

Hey everyone,

You may have noticed that a new RFC has been merged into master of https://github.com/OpenMAMA/openmama.github.io .

This is just to make you aware, if you weren’t already. Feel free to have a look at it under /pages/openmama/openmama_rfc_dq_pluggability.md and
let me know what you think. Comments and suggestions will be happily considered.

Regards,
Aaron


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

Introducing OpenMAMA Integration Headers

Frank Quinn
 

Hi Folks,

 

The first version of OpenMAMA’s integration headers was merged into the development branch ready for 2018’s Q1 release last week.

 

For application developers, this effectively doesn’t change anything – these headers are not for you since they depend on users of them having access and understanding of the internals of OpenMAMA. You will find “there be dragons” style warnings in these headers and they may only be activated by defining a special macro.

 

For bridge and plugin developers however, this means it will now be possible to build bridges and plugins without needing access to OpenMAMA’s core code. This means that you don’t need to compile your own OpenMAMA / qpid / java / .net etc – you can just use OpenMAMA’s own off the shelf binary releases and all the resources will be in one place which should simplify build systems and CI environments. The function prototypes remain unchanged, but there will now be a public API through which you can access them.

 

For further details, see here:

 

https://openmama.github.io/openmama_bridge.html#openmama-integration-headers

 

For an example of the sort of changes which are required to leverage this new API, see:

 

https://github.com/cascadium/OpenMAMA-zmq/commit/4fc1c46212061d66c939dc34a65f87adf9d8622d

 

and

 

https://github.com/cascadium/OpenMAMA-omnm/commit/3cde22a069dccebe39b5bef1769cdb19025f1b2b

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
Recent OpenMAMA RPM Build Failures and Scons

Frank Quinn
 

Hi Folks,

 

I have just submitted a batch of changes which introduce OpenMAMA integration headers (so that bridges and plugins can be compiled without requiring access to OpenMAMA’s code matching the library you’re linking against – more detail on that to come).

 

During CI, an error was spotted in RPM build on RH7 / Fedora but to put everyone’s mind at ease (or not), it looks to be unrelated to recent changes. Instead, it appears to be a bug in scons: http://scons.1086193.n5.nabble.com/more-Java-scons3-issues-td42570.html.

 

Hopefully it will be fixed before the next release since this is how we generate all of our cross platform RPMs. In the meantime if anyone is feeling any particular appetite to try porting OpenMAMA to cmake, please let me know. With the recent vcpkg changes now awaiting merge upstream, that will be the next devops priority. Unfortunately the cracks in scons and our supporting (python 2.x) infrastructure are starting to show as time is moving forward. We are having issues with MSVC detection in recent versions of Visual Studio 2017 too, so this may become pressing fairly soon.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
OpenMAMA_Snapshot_RPM - Build # 586 - Failure!

jenkins@...
 

Some changes have just been added to the origin/next branch! 

[noreply] Added public headers for bridge and plugin projects (#339)
	mama/c_cpp/src/c/mama/integration/publisher.h
	mama/c_cpp/src/c/bridge/qpid/transport.c
	mama/c_cpp/src/c/statscollectorinternal.h
	mama/c_cpp/src/cpp/SConscript.win
	mama/c_cpp/src/c/mama/integration/stat.h
	mama/c_cpp/src/c/bridge/qpid/SConscript.win
	mama/jni/src/c/mamajni.c
	mama/c_cpp/src/c/mamainternal.h
	mama/c_cpp/src/c/msgimpl.h
	mama/c_cpp/src/c/mama/integration/subscription.h
	mama/c_cpp/src/c/mama/integration/queue.h
	mama/dotnet/src/testtools/load/MamaChurn/MamaChurnCS.csproj
	OpenMama.sln
	mama/c_cpp/src/c/mama/integration/endpointpool.h
	mama/c_cpp/src/c/endpointpool.c
	mama/c_cpp/src/c/bridge/qpid/SConscript
	mama/c_cpp/src/c/mama/integration/msg.h
	mama/c_cpp/src/c/subscriptionimpl.h
	mama/c_cpp/src/c/mama.c
	mama/c_cpp/src/c/mama/integration/transport.h
	mama/c_cpp/src/c/mamac.vcxproj
	mama/c_cpp/src/c/mama/integration/types.h
	mama/c_cpp/src/c/statinternal.h
	mama/c_cpp/src/c/mama/integration/bridge.h
	mama/c_cpp/src/cpp/SConscript
	mama/c_cpp/src/c/mama/integration/msgutils.h
	mama/c_cpp/src/c/dqstrategy.h
	mama/c_cpp/src/c/bridge/qpid/endpointpool.h
	mama/c_cpp/src/c/mama/integration/inbox.h
	mama/c_cpp/src/c/conflation/manager_int.h
	mama/c_cpp/src/c/transportimpl.h
	mama/c_cpp/src/c/payloadbridge.h
	mama/c_cpp/src/c/queueimpl.h
	mama/c_cpp/src/c/msgutils.h
	mama/dotnet/src/cs/mamadotnet.csproj
	mama/c_cpp/src/c/bridge/qpid/qpiddefs.h
	mama/c_cpp/src/c/bridge/qpid/qpid.vcxproj
	common/c_cpp/src/c/SConscript.win
	mama/c_cpp/src/gunittest/SConscript
	mama/c_cpp/src/c/mama/integration/mama.h
	mama/c_cpp/src/c/mama/integration/statscollector.h
	mama/c_cpp/src/c/bridge.h
	mama/c_cpp/src/c/mama/integration/statsgenerator.h
	mama/c_cpp/src/c/SConscript.win
	mama/c_cpp/src/c/bridge/qpid/publisher.c
	mama/c_cpp/src/c/msgfieldimpl.h
	mama/c_cpp/src/c/throttle.h
	mama/c_cpp/src/c/statsgeneratorinternal.h
	mamda/dotnet/src/cs/mamdadotnet.csproj
	mama/c_cpp/src/c/mama/integration/msgfield.h
	mama/c_cpp/src/c/inboximpl.h
	mama/c_cpp/src/c/publisherimpl.h
	mama/c_cpp/src/c/bridge/qpid/endpointpool.c
	mama/c_cpp/src/c/SConscript
	mama/c_cpp/src/c/imagerequest.h
	mama/c_cpp/src/c/bridge/qpid/subscription.c

Results for OpenMAMA_Snapshot_RPM CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_RPM
  • Build Number: #586
  • Build Status: Failure
  • Build Warnings:
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

You may also check CI console output to view the full results.

Code change(s) just landed on origin/next (Successful)

jenkins@...
 

Some changes have just been added to the origin/next branch! 

[noreply] Added public headers for bridge and plugin projects (#339)
	mama/c_cpp/src/c/mama/integration/publisher.h
	mama/c_cpp/src/c/bridge/qpid/endpointpool.h
	mama/c_cpp/src/c/mama/integration/stat.h
	mama/c_cpp/src/c/bridge/qpid/publisher.c
	mama/dotnet/src/cs/mamadotnet.csproj
	mama/c_cpp/src/c/queueimpl.h
	mama/c_cpp/src/c/mama/integration/msgfield.h
	mama/c_cpp/src/c/mamainternal.h
	mama/c_cpp/src/c/statscollectorinternal.h
	mama/c_cpp/src/gunittest/SConscript
	mamda/dotnet/src/cs/mamdadotnet.csproj
	mama/c_cpp/src/c/bridge/qpid/SConscript
	mama/c_cpp/src/c/conflation/manager_int.h
	mama/c_cpp/src/c/statinternal.h
	mama/c_cpp/src/cpp/SConscript.win
	mama/c_cpp/src/c/bridge/qpid/qpiddefs.h
	mama/c_cpp/src/c/mama/integration/endpointpool.h
	mama/c_cpp/src/c/transportimpl.h
	mama/c_cpp/src/c/mama/integration/msgutils.h
	mama/dotnet/src/testtools/load/MamaChurn/MamaChurnCS.csproj
	mama/c_cpp/src/cpp/SConscript
	mama/c_cpp/src/c/bridge/qpid/subscription.c
	mama/c_cpp/src/c/bridge/qpid/SConscript.win
	mama/c_cpp/src/c/SConscript.win
	mama/c_cpp/src/c/mama/integration/statsgenerator.h
	mama/c_cpp/src/c/msgutils.h
	mama/c_cpp/src/c/publisherimpl.h
	mama/c_cpp/src/c/payloadbridge.h
	mama/c_cpp/src/c/mama/integration/queue.h
	mama/c_cpp/src/c/mamac.vcxproj
	mama/c_cpp/src/c/endpointpool.c
	mama/c_cpp/src/c/mama/integration/transport.h
	mama/c_cpp/src/c/statsgeneratorinternal.h
	mama/c_cpp/src/c/mama/integration/msg.h
	mama/c_cpp/src/c/inboximpl.h
	mama/jni/src/c/mamajni.c
	mama/c_cpp/src/c/mama/integration/bridge.h
	mama/c_cpp/src/c/imagerequest.h
	mama/c_cpp/src/c/mama/integration/types.h
	mama/c_cpp/src/c/mama/integration/subscription.h
	mama/c_cpp/src/c/dqstrategy.h
	mama/c_cpp/src/c/mama/integration/mama.h
	mama/c_cpp/src/c/subscriptionimpl.h
	mama/c_cpp/src/c/mama/integration/inbox.h
	mama/c_cpp/src/c/msgfieldimpl.h
	mama/c_cpp/src/c/bridge.h
	mama/c_cpp/src/c/bridge/qpid/qpid.vcxproj
	mama/c_cpp/src/c/mama/integration/statscollector.h
	mama/c_cpp/src/c/msgimpl.h
	mama/c_cpp/src/c/mama.c
	mama/c_cpp/src/c/throttle.h
	mama/c_cpp/src/c/SConscript
	common/c_cpp/src/c/SConscript.win
	mama/c_cpp/src/c/bridge/qpid/endpointpool.c
	mama/c_cpp/src/c/bridge/qpid/transport.c
	OpenMama.sln

Results for OpenMAMA_Snapshot_Linux CI run with latest changes:

  • CI Project Name: OpenMAMA_Snapshot_Linux
  • Build Number: #197
  • Build Status: Successful
  • Build Warnings: 0
  • Total Amount of Tests: 1829
  • Passed: 1829
  • Failed: 0
  • Skipped / Disabled: 0

You may also check CI console output to view the full results.

Re: Finalizers are dangerous

Frank Quinn
 

Hi Bill,

Sure sounds good, though these are MAMA bridge level configurations so let's make it:

mama.middleware.<id>.unload_on_close=true|false

and

mama.payload.<id>.unload_on_close=true|false


The destructor / finalizer approach will fix the GC problem just fine for C# / Java. What is being described there is effectively a bug in those methods. What it won't solve is applications deliberately accessing MAMA payload and middleware methods after close and expecting it to actually function with new messages, iterators etc. However it would certainly stop GC after close from crashing the jvm which sounds like it is Yury's main issue.

As much as I would love to just mandate that all Java and C# developers call destroy on all of the objects (it would make my life a lot easier), a lot of developers we have worked with in the past simply don't accept that as a solution for a GC based runtime which is why we need all this finalizer fun to play nicely.

Cheers,
Frank

On Thu, Dec 28, 2017 at 7:17 PM, Bill Torpey <wallstprog@...> wrote:
Hi Frank:

Why don’t we start over here and see if we can make some progress?

If you’re OK with a solution based on a mama.properties setting, I can live with that.  


For the transport it seems to me that a property setting like the following could work:

mama.<middleware>.transport.<name>.unload_on_close=0|1


And for the payload library:

mama.payload.<id>.unload_on_close=0|1


If that works for you, I’ll work up a PR and maybe we can put this bad boy to bed ;-)

Or feel free to suggest something different.  (With the caveat that the dtor approach is not something I’m open to — nor does it solve the problem for our friends in Java and .Net land).

Regards,

Bill

P.S.  Note also that short-circuiting the dlclose plays much more nicely with tools like valgrind, which discards symbols when a shared library is closed.


On Dec 28, 2017, at 1:27 PM, Frank Quinn <frank@...> wrote:

I have been quite receptive to your concerns - just not your proposed solution which I think is too coarse.

Checking if something exists before trying to access it within a framework is far from a hack - it's simply defensive code. mamaInternal_findPayload is already used in MAMA C++ - this is a solvable problem.

I've clearly acknowledged that it's a problem. I'm not sure what makes you think that I think that it's not. The ticket is still open and i'm suggesting solutions including one which will do exactly what you want based on a configuration option rather than forcing it to be the only option when C developers (for example) would have no need for it whatsoever.

The other is an attempt to solve the problem in a defensive way which means that application developers don't have to give special consideration to this use case when writing their applications.

Cheers,
Frank



On Thu, Dec 28, 2017 at 5:58 PM, Bill Torpey <wallstprog@...> wrote:
Hi Frank:

Obviously I would prefer to remain as close as possible to upstream code, so forking is a last resort.  That being said, you’ve been so far quite unreceptive to my concerns about crashing as a result of unloading the payload (and transport, for that matter) library code.

The approach of checking if the payload library exists is a bit of a hack, and is not possible currently, since the mamaInternal_findPayload function is not exposed as part of the API.  Are you planning to expose those functions?

A better solution I believe would be separating out the unloading of the library code from the other activities needed to do a clean shutdown.  I’ve created a fugly hack for that in the forked OpenMAMA code (see attached), but would much prefer something a bit more “elegant”, which would likely require changing the API, and I don’t want to do that without agreement from you.  But so far you haven’t even agreed that this is a problem.

I’m open to ideas, but I think we can do better than what you suggest.

Regards,

Bill





On Dec 28, 2017, at 12:21 PM, Frank Quinn <frank@...> wrote:

On the contrary I welcome OpenMAMA forks If you want to fork and maintain all fixes etc from the upstream that's entirely your decision and part of the beauty of Open Source software. More power to you.

I simply don't agree that always leaking is the right solution when it's avoidable. It's as simple as that.

After another look I think the solution should live in the C++ destructor method where it can:

1. Cache the payload type in the C++ layer as soon as it is known.
2. On destructor, find out if the bridge referred to in #1 is still active using mamaInternal_findPayload from mamaMsg_destroy. Therefore the destroy calls can intercept bridge specific calls before they are made which would otherwise cause a crash.

The mama internal lock may also need to be opened up to avoid race conditions.

You can do something similar in Java finalizer methods via a JNI method.

Alternatively you could have a mama property which will simply prevent the payload bridges from being deallocated and will instead only destroy the middleware bridges. This way it will do what you want (i.e. always leak memory), but not be turned on for everyone unless they want it.

Cheers,
Frank

On Thu, Dec 28, 2017 at 4:25 PM, Bill Torpey <wallstprog@...> wrote:
See comments inline …

On Dec 28, 2017, at 11:07 AM, Frank Quinn <frank@...> wrote:

Hi Bill,

We close the bridges because we leak memory if we dont.

No, we shut down the bridges to prevent events from firing.  In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which is a Good Thing.


Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

It’s not up to you.  As I said before, it’s my application, and I get to decide what leaks are worth worrying about.  One-time leaks that don’t grow over time don’t concern me, and the cost of eliminating them is not worth it in almost all cases.  (Again, that’s my choice — “Perfect is the enemy of good enough”).


If you really want control and are happy to leak memory, just don't call mama_close(),

As you are well aware, that is not a solution — it doesn’t stop events from firing, which is the real reason for shutting down the transport.

or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

What configuration option is that?  How would it work?  


In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

I would be happy to submit a PR, but it doesn’t sound like it would be accepted.  If we can agree on an approach I’ll see what I can come up with.

In the meantime I gave up and forked the code.  As project maintainer I don’t imagine that’s what you want, but you’re not giving me a choice.


Cheers,
Frank


On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:
See comments inline …

On Dec 28, 2017, at 11:07 AM, Frank Quinn <frank@...> wrote:

Hi Bill,

We close the bridges because we leak memory if we dont.

No, we shut down the bridges to prevent events from firing.  In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which is a Good Thing.


Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

It’s not up to you.  As I said before, it’s my application, and I get to decide what leaks are worth worrying about.  One-time leaks that don’t grow over time don’t concern me, and the cost of eliminating them is not worth it in almost all cases.  (Again, that’s my choice — “Perfect is the enemy of good enough”).


If you really want control and are happy to leak memory, just don't call mama_close(),

As you are well aware, that is not a solution — it doesn’t stop events from firing, which is the real reason for shutting down the transport.

or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

What configuration option is that?  How would it work?  


In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

I would be happy to submit a PR, but it doesn’t sound like it would be accepted.  If we can agree on an approach I’ll see what I can come up with.

In the meantime I gave up and forked the code.  As project maintainer I don’t imagine that’s what you want, but you’re not giving me a choice.


Cheers,
Frank


On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:
HI Frank:

And Happy Holidays to you too!

A couple of points:

  • I’m not aware of any changes to OpenMAMA that affect the issue, so if there are some please point me in the proper direction.  The last reply from you was back in May.
  • As the application developer I get to decide which leaks are acceptable to me, and which are not.  Taking that choice away from me is not OK.
  • You’re confusing and/or conflating the shutdown of the bridge libraries with the unloading of those libraries from memory.  
    • It is not necessary to unload the libraries in order to shut them down:
      • The transport library can be shut down without being unloaded from memory.
      • The payload library doesn’t need to be shut down at all, since it never fires any events.
    • The only reason I can think of for dynamically unloading the libraries is to support some kind of dynamic switching of transports and/or payloads.  I suspect that this feature is an example of YAGNI, but even there is a reasonable use for this feature, forcing the vast majority of applications that don’t need it to pay the price for it is a bad design decision.

Short version, it’s my application, and I get to decide how I want it to behave. 

Best Regards,

Bill 

On Dec 28, 2017, at 10:33 AM, Frank Quinn <frank@...> wrote:

Happy holidays folks!

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

Cheers,
Frank


On Thu, Dec 28, 2017 at 3:17 PM, Sanjeev Wahi <sawahi@...> wrote:

I can suggest a possible fix (by adding extra weak_ptr check) while calling Mama.close()  that can avoid this problem in C11/C11++ when using shared_ptr.
*(assumption is Mama.close() is not called by many threads same time, in that case also use C11 atomic integer counter with this code)

*( I do not know much Java but something similar would work).



1st Approach:
Gat a new shared_ptr, but test for whether it is empty or pointing to something by testing
it for true/false, analogous to what we would do with a built-in pointer that might be zero:

void do_it(weak_ptr<Thing> wp){
        shared_ptr<Thing> sp = wp.lock(); // get shared_ptr from weak_ptr
        if(sp)
                sp->defrangulate(); // tell the Thing to do something
        else
                cout << "The Thing is gone!" << endl;
}



2nd Approach:
We can ask the weak_ptr if it has "expired":

bool is_it_there(weak_ptr<Thing> wp) {
        if(wp.expired()) {
                cout << "The Thing is gone!" << endl;
                return false;
        }
return true;
}





-Sanjeev Wahi



-----Original Message-----
From: openmama-dev-bounces@...nmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Bill Torpey
Sent: Thursday, December 28, 2017 9:39 AM
To: Yury Batrakov <yury.batrakov@...>
Cc: openmama-dev <openmama-dev@...rg>
Subject: Re: [Openmama-dev] Finalizers are dangerous

Unfortunately, that is not a bug, but a “feature”.

The problem is that mama_close unloads both the transport and payload libraries (via dlclose on Linux).  So, any access to any objects related to either library following mama_close is guaranteed to crash.

This makes OpenMAMA completely unusable for GC languages like Java, and presumably .Net, as well as for reference-counted implementations in other languages (e.g., shared_ptr in C++).

I’ve argued this point with Frank, but so far to no avail:  https://github.com/OpenMAMA/OpenMAMA/issues/264

Perhaps if enough people chime in, we can change Frank’s mind.  Until that time, the only solution I can think of is to fork OpenMAMA and remove or replace the offending code.  That is not a great solution, but as I mention in the bug report, this behavior is a total non-starter for me (and presumably for others as well).


> On Dec 28, 2017, at 6:08 AM, Yury Batrakov <yury.batrakov@...> wrote:
>
> Classification: Public
> Hi team,
>
> Sorry for telling bad news in holidays but I have found a major issue with Java API - JVM may crash if GC comes after Mama.close() method. Here's code sample to reproduce it:
>
> import com.wombat.mama.Mama;
> import com.wombat.mama.MamaMsg;
>
> public class Test {
>    private static MamaMsg getMessage() {
>        return new MamaMsg();
>    }
>
>    public static void main(String[] args) {
>        Mama.loadBridge("...");
>        Mama.open();
>
>        getMessage(); // Creating MamaMsg object without reference
>
>        Mama.close(); // Payload bridge is destroyed here
>        System.gc();
>        System.runFinalization(); // Calling MamaMsg.destroy() which delegates the destruction to deleted payload bridge
>    }
> }
>
> Stack trace:
> #12 0x00007fc494a095f0 in ?? ()
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> #14 0x00007fc496d70b7f in Java_com_wombat_mama_MamaMsg__1destroy (env=0x7fc4b00039f8, this=0x7fc49779d710) at mama/jni/src/c/mamamsgjni.c:3882
> #15 0x00007fc4bae7e494 in ?? ()
>
> Problematic frame:
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> 127             if (MAMA_STATUS_OK != impl->mPayloadBridge->msgPayloadDestroy (impl->mPayload))
>
> impl->mPayloadBridge is destroyed here.
>
> Similar crash occurs when finalizing subscriptions - they also need entitlements bridge to be available but Mama.close() deletes it too.
>
> The workaround is to call destroy() method for each message/subscription created but this actually nullifies the need for finalize() methods. I would delete all them from MAMA code.
>
>
> ---
> 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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
> _______________________________________________
> Openmama-dev mailing list
> Openmama-dev@...g
> https://lists.openmama.org/mailman/listinfo/openmama-dev

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

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...g
https://lists.openmama.org/mailman/listinfo/openmama-dev
Re: Finalizers are dangerous

Bill Torpey
 

Hi Frank:

Why don’t we start over here and see if we can make some progress?

If you’re OK with a solution based on a mama.properties setting, I can live with that.  


For the transport it seems to me that a property setting like the following could work:

mama.<middleware>.transport.<name>.unload_on_close=0|1


And for the payload library:

mama.payload.<id>.unload_on_close=0|1


If that works for you, I’ll work up a PR and maybe we can put this bad boy to bed ;-)

Or feel free to suggest something different.  (With the caveat that the dtor approach is not something I’m open to — nor does it solve the problem for our friends in Java and .Net land).

Regards,

Bill

P.S.  Note also that short-circuiting the dlclose plays much more nicely with tools like valgrind, which discards symbols when a shared library is closed.


On Dec 28, 2017, at 1:27 PM, Frank Quinn <frank@...> wrote:

I have been quite receptive to your concerns - just not your proposed solution which I think is too coarse.

Checking if something exists before trying to access it within a framework is far from a hack - it's simply defensive code. mamaInternal_findPayload is already used in MAMA C++ - this is a solvable problem.

I've clearly acknowledged that it's a problem. I'm not sure what makes you think that I think that it's not. The ticket is still open and i'm suggesting solutions including one which will do exactly what you want based on a configuration option rather than forcing it to be the only option when C developers (for example) would have no need for it whatsoever.

The other is an attempt to solve the problem in a defensive way which means that application developers don't have to give special consideration to this use case when writing their applications.

Cheers,
Frank



On Thu, Dec 28, 2017 at 5:58 PM, Bill Torpey <wallstprog@...> wrote:
Hi Frank:

Obviously I would prefer to remain as close as possible to upstream code, so forking is a last resort.  That being said, you’ve been so far quite unreceptive to my concerns about crashing as a result of unloading the payload (and transport, for that matter) library code.

The approach of checking if the payload library exists is a bit of a hack, and is not possible currently, since the mamaInternal_findPayload function is not exposed as part of the API.  Are you planning to expose those functions?

A better solution I believe would be separating out the unloading of the library code from the other activities needed to do a clean shutdown.  I’ve created a fugly hack for that in the forked OpenMAMA code (see attached), but would much prefer something a bit more “elegant”, which would likely require changing the API, and I don’t want to do that without agreement from you.  But so far you haven’t even agreed that this is a problem.

I’m open to ideas, but I think we can do better than what you suggest.

Regards,

Bill





On Dec 28, 2017, at 12:21 PM, Frank Quinn <frank@...> wrote:

On the contrary I welcome OpenMAMA forks If you want to fork and maintain all fixes etc from the upstream that's entirely your decision and part of the beauty of Open Source software. More power to you.

I simply don't agree that always leaking is the right solution when it's avoidable. It's as simple as that.

After another look I think the solution should live in the C++ destructor method where it can:

1. Cache the payload type in the C++ layer as soon as it is known.
2. On destructor, find out if the bridge referred to in #1 is still active using mamaInternal_findPayload from mamaMsg_destroy. Therefore the destroy calls can intercept bridge specific calls before they are made which would otherwise cause a crash.

The mama internal lock may also need to be opened up to avoid race conditions.

You can do something similar in Java finalizer methods via a JNI method.

Alternatively you could have a mama property which will simply prevent the payload bridges from being deallocated and will instead only destroy the middleware bridges. This way it will do what you want (i.e. always leak memory), but not be turned on for everyone unless they want it.

Cheers,
Frank

On Thu, Dec 28, 2017 at 4:25 PM, Bill Torpey <wallstprog@...> wrote:
See comments inline …

On Dec 28, 2017, at 11:07 AM, Frank Quinn <frank@...> wrote:

Hi Bill,

We close the bridges because we leak memory if we dont.

No, we shut down the bridges to prevent events from firing.  In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which is a Good Thing.


Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

It’s not up to you.  As I said before, it’s my application, and I get to decide what leaks are worth worrying about.  One-time leaks that don’t grow over time don’t concern me, and the cost of eliminating them is not worth it in almost all cases.  (Again, that’s my choice — “Perfect is the enemy of good enough”).


If you really want control and are happy to leak memory, just don't call mama_close(),

As you are well aware, that is not a solution — it doesn’t stop events from firing, which is the real reason for shutting down the transport.

or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

What configuration option is that?  How would it work?  


In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

I would be happy to submit a PR, but it doesn’t sound like it would be accepted.  If we can agree on an approach I’ll see what I can come up with.

In the meantime I gave up and forked the code.  As project maintainer I don’t imagine that’s what you want, but you’re not giving me a choice.


Cheers,
Frank


On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:
See comments inline …

On Dec 28, 2017, at 11:07 AM, Frank Quinn <frank@...> wrote:

Hi Bill,

We close the bridges because we leak memory if we dont.

No, we shut down the bridges to prevent events from firing.  In some cases (and certainly *not* all) that also releases resources acquired when the bridges were opened, which is a Good Thing.


Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it.

It’s not up to you.  As I said before, it’s my application, and I get to decide what leaks are worth worrying about.  One-time leaks that don’t grow over time don’t concern me, and the cost of eliminating them is not worth it in almost all cases.  (Again, that’s my choice — “Perfect is the enemy of good enough”).


If you really want control and are happy to leak memory, just don't call mama_close(),

As you are well aware, that is not a solution — it doesn’t stop events from firing, which is the real reason for shutting down the transport.

or we can look at that configuration option I suggested (though it will need to avoid freeing the bridges too - not just avoid dlclosing).

What configuration option is that?  How would it work?  


In terms of the actual fix, as I said, I haven't gotten around to it yet. I know how to fix it, I just haven't had the chance, nor have any volunteers come forward to pick it up.

I would be happy to submit a PR, but it doesn’t sound like it would be accepted.  If we can agree on an approach I’ll see what I can come up with.

In the meantime I gave up and forked the code.  As project maintainer I don’t imagine that’s what you want, but you’re not giving me a choice.


Cheers,
Frank


On 28 Dec 2017 15:49, "Bill Torpey" <wallstprog@...> wrote:
HI Frank:

And Happy Holidays to you too!

A couple of points:

  • I’m not aware of any changes to OpenMAMA that affect the issue, so if there are some please point me in the proper direction.  The last reply from you was back in May.
  • As the application developer I get to decide which leaks are acceptable to me, and which are not.  Taking that choice away from me is not OK.
  • You’re confusing and/or conflating the shutdown of the bridge libraries with the unloading of those libraries from memory.  
    • It is not necessary to unload the libraries in order to shut them down:
      • The transport library can be shut down without being unloaded from memory.
      • The payload library doesn’t need to be shut down at all, since it never fires any events.
    • The only reason I can think of for dynamically unloading the libraries is to support some kind of dynamic switching of transports and/or payloads.  I suspect that this feature is an example of YAGNI, but even there is a reasonable use for this feature, forcing the vast majority of applications that don’t need it to pay the price for it is a bad design decision.

Short version, it’s my application, and I get to decide how I want it to behave. 

Best Regards,

Bill 

On Dec 28, 2017, at 10:33 AM, Frank Quinn <frank@...> wrote:

Happy holidays folks!

First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet.

My suggestions were far from "don't solve it" and was instead was more like "let's not annoy every developer of OpenMAMA by leaking memory every single time they close their application" which is what was suggested. My opinion was that if there was an alternative, we should do that. If there was no alternative, we can reassess. Fortunately in this case there is an alternative since it's possible (thanks to last year's bridge changes) to programatically check if a specific bridge is still open in the finalizer / destructor and therefore not attempt to access the bridge if it has been unloaded. This is clean, unobtrusive and lightweight.

I also suggested a configuration option to optionally leave the payload bridge open (though as mentioned in the ticket if its memory is tied to the middleware bridge, it could crash anyway).

I would suggest a similar approach in Java - let the language specific layer deal with the language specific nuances. We can avoid crashes with code changes in OpenMAMA here fairly easily.

Cheers,
Frank


On Thu, Dec 28, 2017 at 3:17 PM, Sanjeev Wahi <sawahi@...> wrote:

I can suggest a possible fix (by adding extra weak_ptr check) while calling Mama.close()  that can avoid this problem in C11/C11++ when using shared_ptr.
*(assumption is Mama.close() is not called by many threads same time, in that case also use C11 atomic integer counter with this code)

*( I do not know much Java but something similar would work).



1st Approach:
Gat a new shared_ptr, but test for whether it is empty or pointing to something by testing
it for true/false, analogous to what we would do with a built-in pointer that might be zero:

void do_it(weak_ptr<Thing> wp){
        shared_ptr<Thing> sp = wp.lock(); // get shared_ptr from weak_ptr
        if(sp)
                sp->defrangulate(); // tell the Thing to do something
        else
                cout << "The Thing is gone!" << endl;
}



2nd Approach:
We can ask the weak_ptr if it has "expired":

bool is_it_there(weak_ptr<Thing> wp) {
        if(wp.expired()) {
                cout << "The Thing is gone!" << endl;
                return false;
        }
return true;
}





-Sanjeev Wahi



-----Original Message-----
From: openmama-dev-bounces@...nmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Bill Torpey
Sent: Thursday, December 28, 2017 9:39 AM
To: Yury Batrakov <yury.batrakov@...>
Cc: openmama-dev <openmama-dev@...rg>
Subject: Re: [Openmama-dev] Finalizers are dangerous

Unfortunately, that is not a bug, but a “feature”.

The problem is that mama_close unloads both the transport and payload libraries (via dlclose on Linux).  So, any access to any objects related to either library following mama_close is guaranteed to crash.

This makes OpenMAMA completely unusable for GC languages like Java, and presumably .Net, as well as for reference-counted implementations in other languages (e.g., shared_ptr in C++).

I’ve argued this point with Frank, but so far to no avail:  https://github.com/OpenMAMA/OpenMAMA/issues/264

Perhaps if enough people chime in, we can change Frank’s mind.  Until that time, the only solution I can think of is to fork OpenMAMA and remove or replace the offending code.  That is not a great solution, but as I mention in the bug report, this behavior is a total non-starter for me (and presumably for others as well).


> On Dec 28, 2017, at 6:08 AM, Yury Batrakov <yury.batrakov@...> wrote:
>
> Classification: Public
> Hi team,
>
> Sorry for telling bad news in holidays but I have found a major issue with Java API - JVM may crash if GC comes after Mama.close() method. Here's code sample to reproduce it:
>
> import com.wombat.mama.Mama;
> import com.wombat.mama.MamaMsg;
>
> public class Test {
>    private static MamaMsg getMessage() {
>        return new MamaMsg();
>    }
>
>    public static void main(String[] args) {
>        Mama.loadBridge("...");
>        Mama.open();
>
>        getMessage(); // Creating MamaMsg object without reference
>
>        Mama.close(); // Payload bridge is destroyed here
>        System.gc();
>        System.runFinalization(); // Calling MamaMsg.destroy() which delegates the destruction to deleted payload bridge
>    }
> }
>
> Stack trace:
> #12 0x00007fc494a095f0 in ?? ()
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> #14 0x00007fc496d70b7f in Java_com_wombat_mama_MamaMsg__1destroy (env=0x7fc4b00039f8, this=0x7fc49779d710) at mama/jni/src/c/mamamsgjni.c:3882
> #15 0x00007fc4bae7e494 in ?? ()
>
> Problematic frame:
> #13 0x00007fc496ac1cf4 in mamaMsg_destroy (msg=0x7fc4900c90a0) at mama/c_cpp/src/c/msg.c:127
> 127             if (MAMA_STATUS_OK != impl->mPayloadBridge->msgPayloadDestroy (impl->mPayload))
>
> impl->mPayloadBridge is destroyed here.
>
> Similar crash occurs when finalizing subscriptions - they also need entitlements bridge to be available but Mama.close() deletes it too.
>
> The workaround is to call destroy() method for each message/subscription created but this actually nullifies the need for finalize() methods. I would delete all them from MAMA code.
>
>
> ---
> 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 https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
> _______________________________________________
> Openmama-dev mailing list
> Openmama-dev@...g
> https://lists.openmama.org/mailman/listinfo/openmama-dev

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

_______________________________________________
Openmama-dev mailing list
Openmama-dev@...g
https://lists.openmama.org/mailman/listinfo/openmama-dev
161 - 180 of 2319