Date   

Re: RC3 and GA

Frank Quinn <fquinn.ni@...>
 

Hi Dmitri,

It's looking like a third (and hopefully final) release candidate towards the end of this week and we're aiming to have the GA release out before the end of the month.

Cheers,
Frank

On Tue, Mar 15, 2016 at 6:17 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hello dear all,

Would you be able to share ETA for RC3 and GA, please?

Thank you.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

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



RC3 and GA

Dmitri Fedorov <dfedorov.solace@...>
 

Hello dear all,

Would you be able to share ETA for RC3 and GA, please?

Thank you.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


Help creating generic plugin

Keith Rudd
 

Classification: Public

Is there any documentation or example code I can refer to for creating a plugin that will get called during initialization?

 

I’m referring to this call in mama.c, mama_openWithPropertiesCount()

 

                mama_initPlugins();

 

Might be useful to have an example plugin included with the source code in the same way example bridges are included.

 

Kind regards,
Keith Rudd

____________________________________________________



Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
6/8 Bishopsgate, EC2N 4DA London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


 



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

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


Re: Openmama Documentation for subscription onDestroy

Dmitri Fedorov <dfedorov.solace@...>
 

Hi Frank,

I'm going to echo Duane: this is a very straightforward and low risk fix, and it addresses a severe issue.

We'll make sure we follow a proper process from now on, but for this one time could you please pick it up from the patch file attached to the issue (114)?

Thank you
Dmitri


Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 9 March 2016 at 16:31, Frank Quinn <fquinn.ni@...> wrote:

Hi Dmitri,


It’s not tagged for the 2.4.0 milestone as of today... why? Is it a showstopper for you guys? If so we can see if we can get it in.


To provide some context, when preparing release cuts, we look for any showstopper bugs and pull requests as well as any major features that are part of a release. Because this issue was a patch masquerading as an "issue" rather than a "pull request", it didn't make the cut at the time.


Cheers,

Frank


On Wed, Mar 9, 2016 at 4:38 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Gents, are you taking this path for 2.4?

Thank you
Dmitri Fedorov


Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On Mon, Feb 1, 2016 at 3:18 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

I’ve raised an issue to cover this on github.

 

Here is a link to the issue:

https://github.com/OpenMAMA/OpenMAMA/issues/114

 

Chris Morgan

 

 

From: Alpert, Reed [mailto:reed.alpert@...]
Sent: February-01-16 10:48 AM
To: Duane Pauls <Duane.Pauls@...>; Christopher Morgan <Christopher.Morgan@...>; openmama-dev@...
Subject: RE: Openmama Documentation for subscription onDestroy

 

I think the app needs to call sub->destroy(), then wait for the onDestroy(), and then ‘delete sub’.

 

onDestroy() is a completion event – once you get it you won’t hear from that subscription again (no callbacks of any kind).

 

In order for an app to call C++ or Java ‘delete sub’ w/o sub->destroy the destructor needs to completely disconnect the app from the impl (which as Duane & Chris point out it does not).

In that case the inline onDestroy() does have value in that the app knows it can safely destroy any of its data structures.

 

Thanks,

 

Reed.

 


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

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

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Duane Pauls
Sent: Thursday, January 28, 2016 1:39 PM
To: Christopher Morgan; openmama-dev@...
Subject: Re: [Openmama-dev] Openmama Documentation for subscription onDestroy

 

I’ll add a bit of clarification to the problem with the CPP interface if the middleware bridge queues an event to call the onDestroy callback.

 

When an application destructs a MamaSubscription object, the application onDestroy is called inline, and the MamaSubscription object is freed, but the corresponding MamaSubscriptionImpl object is not freed.  So far so good – it is the MamaSubscriptionImpl object pointer that is the closure to the C-layer and this is still valid, unfreed memory.  However, at this point the MamaSubscriptionImpl object’s mCallback pointer still points to the application’s MamaSubscriptionCallback object.  The application may have freed this memory since MamaSubscriptionCallback::onDestroy() has been called.

 

If we look at MamdaSubscription as an example, it in fact does not implement MamaSubscriptionCallback::onDestroy at all.  It will always destroy the callback (MamdaSubscription::mImpl) immediately after destroying the underlying MamaSubscription.  This happens to occur after onDestroy is called since it is called inline with MamaSubscription::~MamaSubscription.  But nevertheless, it is freed immediately after onDestroy is called inline with the call to MamaSubscription::~MamaSubscription().

 

Now, sometime later, the C-layer onDestroy is called.  This calls the static MamaSubscription::onSubscriptionDestroy which calls MamaSubscriptionImpl::InvokeDestroy().  This checks if MamaSubscriptionImpl::mCallback is NULL (it is not – in the case of a MamdaSubscription it is still pointing to a freed MamdaSubscriptionImpl object) and tries to invoke the onDestroy() method.  If the vtable pointer is no longer valid, a core here is quite likely.

 

Even if a core does not occur, the application would see onDestroy() twice – once inline with when the destroy was started and a second time when the lower layer destroy was completed.  It seems the design intent here is to decouple the MamaSubscriptionImpl from everything above it when the MamaSubscription is destroyed.  To do this, it seems the right thing to do in the C++ layer would be to set MamaSubscriptionImpl::mCallback to NULL when setting MamaSubscriptionImpl::mFreed to true (or alternatively include mFreed in the tests that check mCallback == NULL).

 

Should a bug be raised for this issue?  Or should a middleware bridge in fact NOT enqueue the onDestroy callback as stated in the OpenMAMA Bridge Documentation Wiki and instead invoke onDestroy inline?  If the intent is to always invoke the callback inline, it seems the benefit of having a callback in the first place is diminished.

 

Cheers,

Duane

 

From: Christopher Morgan
Sent: Thursday, January 28, 2016 10:30 AM
To:
openmama-dev@...
Subject: Openmama Documentation for subscription onDestroy

 

Hi,

 

I’m with solace dev for the openmama middle bridge and I have question about mamaSubscription onDestroy with the CPP openmama. On the openmama Developer Wiki under Bridge Documentation for myMiddlewareBridgeMamaSubscription_destroy () it states “…the destroy method adds an event to the queue to invokes the destroy callback, which notifies the client application of the successful destroy of the subscription.” Our Bridge currently does this but in the CPP API for openmama the MamaSubscription seems to do an inline onDestroy as a part of the destructor. This does not work well with the enqueuerd onDestroy callback (potential for causing segmentation faults). I’ve also compared to the Qpid bridge which seems to do an inline onDestroy callback as a part their MiddlewareBridgeMamaSubscription_destroy(). Should the onDestroy callback be inline the MiddlewareBridgeMamaSubscription_destroy() like the Qpid to work with the CPP API? Or Is there a problem with the CPP API?

 

Chris Morgan

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


_______________________________________________
Openmama-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




Re: Openmama Documentation for subscription onDestroy

Duane Pauls <Duane.Pauls@...>
 

We're not direct users of OpenMAMA, but as someone who provides a bridge for OpenMAMA, it seems like this is a very severe problem. To run the risk of a crash when a subscription is destroyed sounds like something users of OpenMAMA wouldn't appreciate.

The fix seems relatively low risk -- we're just checking to see if the object is still valid before calling a callback on it.

So my opinion is that it would be a very good idea to try to include this in the next release.

Cheers,
Duane


Subject: Re: [Openmama-dev] Openmama Documentation for subscription
onDestroy
Message-ID:
<CAL75PSfGCH0vbd_wBpjtjx5oXotiuyKAB6tdGR8GbEMJPfHRhg@...>
Content-Type: text/plain; charset="utf-8"

Hi Dmitri,


It?s not tagged for the 2.4.0 milestone as of today... why? Is it a
showstopper for you guys? If so we can see if we can get it in.


To provide some context, when preparing release cuts, we look for any
showstopper bugs and pull requests as well as any major features that are
part of a release. Because this issue was a patch masquerading as an
"issue" rather than a "pull request", it didn't make the cut at the time.


Cheers,

Frank

On Wed, Mar 9, 2016 at 4:38 PM, Dmitri Fedorov <dfedorov.solace@...>
wrote:

Gents, are you taking this path for 2.4?

Thank you
Dmitri Fedorov


Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for
the consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing. Any
views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Solace Systems.

On Mon, Feb 1, 2016 at 3:18 PM, Christopher Morgan <
Christopher.Morgan@...> wrote:

I?ve raised an issue to cover this on github.



Here is a link to the issue:

https://github.com/OpenMAMA/OpenMAMA/issues/114



Chris Morgan





*From:* Alpert, Reed [mailto:reed.alpert@...]
*Sent:* February-01-16 10:48 AM
*To:* Duane Pauls <Duane.Pauls@...>; Christopher Morgan <
Christopher.Morgan@...>; openmama-dev@...
*Subject:* RE: Openmama Documentation for subscription onDestroy



I think the app needs to call sub->destroy(), then wait for the
onDestroy(), and then ?delete sub?.



onDestroy() is a completion event ? once you get it you won?t hear from
that subscription again (no callbacks of any kind).



In order for an app to call C++ or Java ?delete sub? w/o sub->destroy the
destructor needs to completely disconnect the app from the impl (which as
Duane & Chris point out it does not).

In that case the inline onDestroy() does have value in that the app knows
it can safely destroy any of its data structures.



Thanks,



Reed.


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

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

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





*From:* openmama-dev-bounces@... [
mailto:openmama-dev-bounces@...
<openmama-dev-bounces@...>] *On Behalf Of *Duane Pauls
*Sent:* Thursday, January 28, 2016 1:39 PM
*To:* Christopher Morgan; openmama-dev@...
*Subject:* Re: [Openmama-dev] Openmama Documentation for subscription
onDestroy



I?ll add a bit of clarification to the problem with the CPP interface if
the middleware bridge queues an event to call the onDestroy callback.



When an application destructs a MamaSubscription object, the application
onDestroy is called inline, and the MamaSubscription object is freed, but
the corresponding MamaSubscriptionImpl object is not freed. So far so good
? it is the MamaSubscriptionImpl object pointer that is the closure to the
C-layer and this is still valid, unfreed memory. However, at this point
the MamaSubscriptionImpl object?s mCallback pointer still points to the
application?s MamaSubscriptionCallback object. The application may have
freed this memory since MamaSubscriptionCallback::onDestroy() has been
called.



If we look at MamdaSubscription as an example, it in fact does not
implement MamaSubscriptionCallback::onDestroy at all. It will always
destroy the callback (MamdaSubscription::mImpl) immediately after
destroying the underlying MamaSubscription. This happens to occur after
onDestroy is called since it is called inline with
MamaSubscription::~MamaSubscription. But nevertheless, it is freed
immediately after onDestroy is called inline with the call to
MamaSubscription::~MamaSubscription().



Now, sometime later, the C-layer onDestroy is called. This calls the
static MamaSubscription::onSubscriptionDestroy which calls
MamaSubscriptionImpl::InvokeDestroy(). This checks if
MamaSubscriptionImpl::mCallback is NULL (it is not ? in the case of a
MamdaSubscription it is still pointing to a freed MamdaSubscriptionImpl
object) and tries to invoke the onDestroy() method. If the vtable pointer
is no longer valid, a core here is quite likely.



Even if a core does not occur, the application would see onDestroy()
twice ? once inline with when the destroy was started and a second time
when the lower layer destroy was completed. It seems the design intent
here is to decouple the MamaSubscriptionImpl from everything above it when
the MamaSubscription is destroyed. To do this, it seems the right thing to
do in the C++ layer would be to set MamaSubscriptionImpl::mCallback to NULL
when setting MamaSubscriptionImpl::mFreed to true (or alternatively include
mFreed in the tests that check mCallback == NULL).



Should a bug be raised for this issue? Or should a middleware bridge in
fact NOT enqueue the onDestroy callback as stated in the OpenMAMA Bridge
Documentation Wiki
<http://wiki.openmama.org/index.php/OpenMAMA_Bridge_Documentation#Destroy_methods>
and instead invoke onDestroy inline? If the intent is to always invoke the
callback inline, it seems the benefit of having a callback in the first
place is diminished.



Cheers,

Duane



*From:* Christopher Morgan
*Sent:* Thursday, January 28, 2016 10:30 AM
*To:* openmama-dev@...
*Subject:* Openmama Documentation for subscription onDestroy



Hi,



I?m with solace dev for the openmama middle bridge and I have question
about mamaSubscription onDestroy with the CPP openmama. On the openmama
Developer Wiki under Bridge Documentation for
*myMiddlewareBridgeMamaSubscription_destroy* () it states ??the destroy
method adds an event to the queue to invokes the destroy callback, which
notifies the client application of the successful destroy of the
subscription.? Our Bridge currently does this but in the CPP API for
openmama the MamaSubscription seems to do an inline onDestroy as a part of
the destructor. This does not work well with the enqueuerd onDestroy
callback (potential for causing segmentation faults). I?ve also compared to
the Qpid bridge which seems to do an inline onDestroy callback as a part
their MiddlewareBridgeMamaSubscription_destroy(). Should the onDestroy
callback be inline the MiddlewareBridgeMamaSubscription_destroy() like the
Qpid to work with the CPP API? Or Is there a problem with the CPP API?



Chris Morgan

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

_______________________________________________
Openmama-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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmama.org/pipermail/openmama-dev/attachments/20160309/7af2260d/attachment-0001.html>

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

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


End of Openmama-dev Digest, Vol 53, Issue 5
*******************************************


Re: Openmama Documentation for subscription onDestroy

Frank Quinn <fquinn.ni@...>
 

Hi Dmitri,


It’s not tagged for the 2.4.0 milestone as of today... why? Is it a showstopper for you guys? If so we can see if we can get it in.


To provide some context, when preparing release cuts, we look for any showstopper bugs and pull requests as well as any major features that are part of a release. Because this issue was a patch masquerading as an "issue" rather than a "pull request", it didn't make the cut at the time.


Cheers,

Frank


On Wed, Mar 9, 2016 at 4:38 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Gents, are you taking this path for 2.4?

Thank you
Dmitri Fedorov


Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On Mon, Feb 1, 2016 at 3:18 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

I’ve raised an issue to cover this on github.

 

Here is a link to the issue:

https://github.com/OpenMAMA/OpenMAMA/issues/114

 

Chris Morgan

 

 

From: Alpert, Reed [mailto:reed.alpert@...]
Sent: February-01-16 10:48 AM
To: Duane Pauls <Duane.Pauls@...>; Christopher Morgan <Christopher.Morgan@...>; openmama-dev@...
Subject: RE: Openmama Documentation for subscription onDestroy

 

I think the app needs to call sub->destroy(), then wait for the onDestroy(), and then ‘delete sub’.

 

onDestroy() is a completion event – once you get it you won’t hear from that subscription again (no callbacks of any kind).

 

In order for an app to call C++ or Java ‘delete sub’ w/o sub->destroy the destructor needs to completely disconnect the app from the impl (which as Duane & Chris point out it does not).

In that case the inline onDestroy() does have value in that the app knows it can safely destroy any of its data structures.

 

Thanks,

 

Reed.

 


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

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

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Duane Pauls
Sent: Thursday, January 28, 2016 1:39 PM
To: Christopher Morgan; openmama-dev@...
Subject: Re: [Openmama-dev] Openmama Documentation for subscription onDestroy

 

I’ll add a bit of clarification to the problem with the CPP interface if the middleware bridge queues an event to call the onDestroy callback.

 

When an application destructs a MamaSubscription object, the application onDestroy is called inline, and the MamaSubscription object is freed, but the corresponding MamaSubscriptionImpl object is not freed.  So far so good – it is the MamaSubscriptionImpl object pointer that is the closure to the C-layer and this is still valid, unfreed memory.  However, at this point the MamaSubscriptionImpl object’s mCallback pointer still points to the application’s MamaSubscriptionCallback object.  The application may have freed this memory since MamaSubscriptionCallback::onDestroy() has been called.

 

If we look at MamdaSubscription as an example, it in fact does not implement MamaSubscriptionCallback::onDestroy at all.  It will always destroy the callback (MamdaSubscription::mImpl) immediately after destroying the underlying MamaSubscription.  This happens to occur after onDestroy is called since it is called inline with MamaSubscription::~MamaSubscription.  But nevertheless, it is freed immediately after onDestroy is called inline with the call to MamaSubscription::~MamaSubscription().

 

Now, sometime later, the C-layer onDestroy is called.  This calls the static MamaSubscription::onSubscriptionDestroy which calls MamaSubscriptionImpl::InvokeDestroy().  This checks if MamaSubscriptionImpl::mCallback is NULL (it is not – in the case of a MamdaSubscription it is still pointing to a freed MamdaSubscriptionImpl object) and tries to invoke the onDestroy() method.  If the vtable pointer is no longer valid, a core here is quite likely.

 

Even if a core does not occur, the application would see onDestroy() twice – once inline with when the destroy was started and a second time when the lower layer destroy was completed.  It seems the design intent here is to decouple the MamaSubscriptionImpl from everything above it when the MamaSubscription is destroyed.  To do this, it seems the right thing to do in the C++ layer would be to set MamaSubscriptionImpl::mCallback to NULL when setting MamaSubscriptionImpl::mFreed to true (or alternatively include mFreed in the tests that check mCallback == NULL).

 

Should a bug be raised for this issue?  Or should a middleware bridge in fact NOT enqueue the onDestroy callback as stated in the OpenMAMA Bridge Documentation Wiki and instead invoke onDestroy inline?  If the intent is to always invoke the callback inline, it seems the benefit of having a callback in the first place is diminished.

 

Cheers,

Duane

 

From: Christopher Morgan
Sent: Thursday, January 28, 2016 10:30 AM
To:
openmama-dev@...
Subject: Openmama Documentation for subscription onDestroy

 

Hi,

 

I’m with solace dev for the openmama middle bridge and I have question about mamaSubscription onDestroy with the CPP openmama. On the openmama Developer Wiki under Bridge Documentation for myMiddlewareBridgeMamaSubscription_destroy () it states “…the destroy method adds an event to the queue to invokes the destroy callback, which notifies the client application of the successful destroy of the subscription.” Our Bridge currently does this but in the CPP API for openmama the MamaSubscription seems to do an inline onDestroy as a part of the destructor. This does not work well with the enqueuerd onDestroy callback (potential for causing segmentation faults). I’ve also compared to the Qpid bridge which seems to do an inline onDestroy callback as a part their MiddlewareBridgeMamaSubscription_destroy(). Should the onDestroy callback be inline the MiddlewareBridgeMamaSubscription_destroy() like the Qpid to work with the CPP API? Or Is there a problem with the CPP API?

 

Chris Morgan

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


_______________________________________________
Openmama-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



Re: Openmama Documentation for subscription onDestroy

Dmitri Fedorov <dfedorov.solace@...>
 

Gents, are you taking this path for 2.4?

Thank you
Dmitri Fedorov


Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On Mon, Feb 1, 2016 at 3:18 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

I’ve raised an issue to cover this on github.

 

Here is a link to the issue:

https://github.com/OpenMAMA/OpenMAMA/issues/114

 

Chris Morgan

 

 

From: Alpert, Reed [mailto:reed.alpert@...]
Sent: February-01-16 10:48 AM
To: Duane Pauls <Duane.Pauls@...>; Christopher Morgan <Christopher.Morgan@...>; openmama-dev@...
Subject: RE: Openmama Documentation for subscription onDestroy

 

I think the app needs to call sub->destroy(), then wait for the onDestroy(), and then ‘delete sub’.

 

onDestroy() is a completion event – once you get it you won’t hear from that subscription again (no callbacks of any kind).

 

In order for an app to call C++ or Java ‘delete sub’ w/o sub->destroy the destructor needs to completely disconnect the app from the impl (which as Duane & Chris point out it does not).

In that case the inline onDestroy() does have value in that the app knows it can safely destroy any of its data structures.

 

Thanks,

 

Reed.

 


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

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

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Duane Pauls
Sent: Thursday, January 28, 2016 1:39 PM
To: Christopher Morgan; openmama-dev@...
Subject: Re: [Openmama-dev] Openmama Documentation for subscription onDestroy

 

I’ll add a bit of clarification to the problem with the CPP interface if the middleware bridge queues an event to call the onDestroy callback.

 

When an application destructs a MamaSubscription object, the application onDestroy is called inline, and the MamaSubscription object is freed, but the corresponding MamaSubscriptionImpl object is not freed.  So far so good – it is the MamaSubscriptionImpl object pointer that is the closure to the C-layer and this is still valid, unfreed memory.  However, at this point the MamaSubscriptionImpl object’s mCallback pointer still points to the application’s MamaSubscriptionCallback object.  The application may have freed this memory since MamaSubscriptionCallback::onDestroy() has been called.

 

If we look at MamdaSubscription as an example, it in fact does not implement MamaSubscriptionCallback::onDestroy at all.  It will always destroy the callback (MamdaSubscription::mImpl) immediately after destroying the underlying MamaSubscription.  This happens to occur after onDestroy is called since it is called inline with MamaSubscription::~MamaSubscription.  But nevertheless, it is freed immediately after onDestroy is called inline with the call to MamaSubscription::~MamaSubscription().

 

Now, sometime later, the C-layer onDestroy is called.  This calls the static MamaSubscription::onSubscriptionDestroy which calls MamaSubscriptionImpl::InvokeDestroy().  This checks if MamaSubscriptionImpl::mCallback is NULL (it is not – in the case of a MamdaSubscription it is still pointing to a freed MamdaSubscriptionImpl object) and tries to invoke the onDestroy() method.  If the vtable pointer is no longer valid, a core here is quite likely.

 

Even if a core does not occur, the application would see onDestroy() twice – once inline with when the destroy was started and a second time when the lower layer destroy was completed.  It seems the design intent here is to decouple the MamaSubscriptionImpl from everything above it when the MamaSubscription is destroyed.  To do this, it seems the right thing to do in the C++ layer would be to set MamaSubscriptionImpl::mCallback to NULL when setting MamaSubscriptionImpl::mFreed to true (or alternatively include mFreed in the tests that check mCallback == NULL).

 

Should a bug be raised for this issue?  Or should a middleware bridge in fact NOT enqueue the onDestroy callback as stated in the OpenMAMA Bridge Documentation Wiki and instead invoke onDestroy inline?  If the intent is to always invoke the callback inline, it seems the benefit of having a callback in the first place is diminished.

 

Cheers,

Duane

 

From: Christopher Morgan
Sent: Thursday, January 28, 2016 10:30 AM
To:
openmama-dev@...
Subject: Openmama Documentation for subscription onDestroy

 

Hi,

 

I’m with solace dev for the openmama middle bridge and I have question about mamaSubscription onDestroy with the CPP openmama. On the openmama Developer Wiki under Bridge Documentation for myMiddlewareBridgeMamaSubscription_destroy () it states “…the destroy method adds an event to the queue to invokes the destroy callback, which notifies the client application of the successful destroy of the subscription.” Our Bridge currently does this but in the CPP API for openmama the MamaSubscription seems to do an inline onDestroy as a part of the destructor. This does not work well with the enqueuerd onDestroy callback (potential for causing segmentation faults). I’ve also compared to the Qpid bridge which seems to do an inline onDestroy callback as a part their MiddlewareBridgeMamaSubscription_destroy(). Should the onDestroy callback be inline the MiddlewareBridgeMamaSubscription_destroy() like the Qpid to work with the CPP API? Or Is there a problem with the CPP API?

 

Chris Morgan

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


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



OpenMAMA-2.4.0-rc2 Now Available

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

The second release candidate for OpenMAMA 2.4.0 has just been cut and contains a few fixes put in since RC1 - see https://github.com/OpenMAMA/OpenMAMA/releases for details.

Once again, we appreciate the continued assistance from the community. Assuming no major issues are found, we'll look to pin down a hard date for the 2.4.0 release towards the end of next week.

Cheers,
Frank


Re: can't compile 2.4.0 branch

Damian Maguire <damian.j.maguire@...>
 

Sorry Dmitri, that's what happens when I try and answer emails at 6 in the morning. ;-)

D.


On Thu, 3 Mar 2016 at 15:10, Dmitri Fedorov <dfedorov.solace@...> wrote:
Thank you, yes, "libevent-devel" was missing.

Damian, who is "Dimitry" :-)?

Regards,
Dmitri Fedorov
Software Architect
​grep -i wiki ​
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On Thu, Mar 3, 2016 at 4:45 AM, Frank Quinn <fquinn.ni@...> wrote:

Yeah you can find details on https://github.com/OpenMAMA/OpenMAMA/wiki/Building-on-Linux, but you’re missing libevent-devel.

 

Cheers,

Frank


On Thu, 3 Mar 2016 06:07 Damian Maguire, <damian.j.maguire@...> wrote:
Hey Dimitry, 

At a glance I'd say it's failing to find libevent and its headers. Can you check you have the correct libraries installed and located in a standard location? There should be some info on those on the wiki on GitHub. Were you able to build master previously, or is this a completely fresh checkout?

Thanks,

Damian

On Thu, 3 Mar 2016 01:03 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.
_______________________________________________
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


Re: can't compile 2.4.0 branch

Dmitri Fedorov <dfedorov.solace@...>
 

Thank you, yes, "libevent-devel" was missing.

Damian, who is "Dimitry" :-)?

Regards,
Dmitri Fedorov
Software Architect
​grep -i wiki ​
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On Thu, Mar 3, 2016 at 4:45 AM, Frank Quinn <fquinn.ni@...> wrote:

Yeah you can find details on https://github.com/OpenMAMA/OpenMAMA/wiki/Building-on-Linux, but you’re missing libevent-devel.

 

Cheers,

Frank


On Thu, 3 Mar 2016 06:07 Damian Maguire, <damian.j.maguire@...> wrote:
Hey Dimitry, 

At a glance I'd say it's failing to find libevent and its headers. Can you check you have the correct libraries installed and located in a standard location? There should be some info on those on the wiki on GitHub. Were you able to build master previously, or is this a completely fresh checkout?

Thanks,

Damian

On Thu, 3 Mar 2016 01:03 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.
_______________________________________________
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


Re: can't compile 2.4.0 branch

Frank Quinn <fquinn.ni@...>
 

Yeah you can find details on https://github.com/OpenMAMA/OpenMAMA/wiki/Building-on-Linux, but you’re missing libevent-devel.

 

Cheers,

Frank


On Thu, 3 Mar 2016 06:07 Damian Maguire, <damian.j.maguire@...> wrote:
Hey Dimitry, 

At a glance I'd say it's failing to find libevent and its headers. Can you check you have the correct libraries installed and located in a standard location? There should be some info on those on the wiki on GitHub. Were you able to build master previously, or is this a completely fresh checkout?

Thanks,

Damian

On Thu, 3 Mar 2016 01:03 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.
_______________________________________________
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


Re: can't compile 2.4.0 branch

Damian Maguire <damian.j.maguire@...>
 

Hey Dimitry, 

At a glance I'd say it's failing to find libevent and its headers. Can you check you have the correct libraries installed and located in a standard location? There should be some info on those on the wiki on GitHub. Were you able to build master previously, or is this a completely fresh checkout?

Thanks,

Damian

On Thu, 3 Mar 2016 01:03 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


can't compile 2.4.0 branch

Dmitri Fedorov <dfedorov.solace@...>
 

Hello,

On CentOS 7, this is the build command:
[dfedorov@localhost OpenMAMA]$ scons middleware=avis avis_home=/opt/avis with_testtools=True with_unittest=True gtest_home=/usr

<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/avis/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/opt/avis/include -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/avis/io.c
WARNING:: mama/c_cpp/src/c/bridge/avis/io.c:32:19: fatal error: event.h: No such file or directory
 #include <event.h>
                   ^
compilation terminated.

The only "event.h" I found is the one that that is a part of qpid-proton-c-devel package:

Alright, I thought, let's build with qpid instead:

[dfedorov@localhost OpenMAMA]$ scons middleware=qpid qpid_home=/usr/include/proton
<...>
gcc -o objdir/mama/c_cpp/src/c/bridge/qpid/io.o -c -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Werror -g -O2 -D_GNU_SOURCE -Imama/c_cpp/src/c -Iopenmama_install_2.4.0/include -Icommon/c_cpp/src/c -I/usr/include/proton -Imama/c_cpp/src/c mama/c_cpp/src/c/bridge/qpid/io.c
WARNING:: mama/c_cpp/src/c/bridge/qpid/io.c:54:25: error: field 'mEvent' has incomplete type
     struct event        mEvent;
                         ^
mama/c_cpp/src/c/bridge/qpid/io.c: In function 'qpidBridgeMamaIo_create':
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: error: 'EV_READ' undeclared (first use in this function)
         evtType = EV_READ;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:103:19: note: each undeclared identifier is reported only once for each function it appears in
mama/c_cpp/src/c/bridge/qpid/io.c:106:19: error: 'EV_WRITE' undeclared (first use in this function)
         evtType = EV_WRITE;
                   ^
mama/c_cpp/src/c/bridge/qpid/io.c:132:5: error: implicit declaration of function 'event_set' [-Werror=implicit-function-declaration]
     event_set (&impl->mEvent,
<...>
mama/c_cpp/src/c/bridge/qpid/io.c:270:9: error: 'EV_TIMEOUT' undeclared (first use in this function)
     if (EV_TIMEOUT == type)
         ^
cc1: all warnings being treated as errors
scons: *** [objdir/mama/c_cpp/src/c/bridge/qpid/io.o] Error 1
scons: building terminated because of errors.


I could dig dipper, but I'm sure you guys know what I'm doing wrong here, please advise.

Thank you in advance!

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


Last Call for Bug Fixes to Include in OpenMAMA 2.4.0 RC2

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

There were a few bugs reported which fixes have been put in for since OpenMAMA 2.4.0 RC1 which have now been merged (thanks to all contributors) so we’re on schedule to cut another release candidate this Thursday / Friday. If there are any new bugs to report, please raise them on github as soon as possible.

 

N.B. As this is a release candidate, only bug fixes will be considered.

 

Cheers,

Frank


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


OpenMAMA Data Quality as pluggable libs

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

Hi,

 

I've been looking at the data quality (dq) code and have some ideas on how to support multiple dq strategies.

 

Generally mama has a dq strategy built into dqstrategy.c, subscription.c, and transport.c that supports:

·         SeqNums being present from the publisher to detect gaps and request recaps.

·         SenderIds being present from the publisher and used for FT takeover.

·         Initial/Recap pre-cache to correctly order an initial/recap and updates.

·         Various config parameters for how the app should handle dq issues:

o   Transport bounces and setting subs stale.

o   Duplicate msgs.

o   When to apply pre-cache.

o   Handle initials (requiresInitial).

o   Turn on/off dq (recoverGaps).

 

In order to provide additional dq strategies it is proposed:

·         Move any code that references dq variables into dqstrategy.c. This is largely done, but there is some code in subscription.c that can be moved.

·         Make all dq structures opaque so they are only visible via methods.

·         Turn dqstrategy.c into a pluggable dq bridge, using entitlements as a model.

At this point current impl will be the default pluggable dq bridge, so the same behavior as now will be observed, and additional pluggable dq libs can be developed.

 

There is also the code in transport.c that handles transport bounces. This needs to be defined as to what service it provides for the bridges.

·         When a transport disconnects it can notify the app via a transport callback, and also each sub on the transport via stale/maybeStale.

·         When a transport reconnects it can notify the app via a transport callback, and also each sub via quality=OK, and requesting a recap.

It may be helpful to create an mDQTransport struct to hold transport-specific dq vars.

 

Attached is the beginnings of a state diagram for dq - it is a bit busy, but I think will be helpful in determining what does happen. Note that this does have paths for the code we added to send stale to subs even if dq is turned off. The red text/lines are for the 99.9% use case.

 

Any comments or ways forward please contribute.

 

Thanks,

 

Reed.

 

 


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

Alternate Contact:  CIB Market Data Services Engineers | CIB_Market_Data_Services_Engineers@...

 

 

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


Re: Publisher Events Feature Documentation

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

Hi Chris,

 

I owe that, I’ll send an updated PDF to the list today/tmrw.

 

OpenMAMA group: is there a place on the wiki to store the PDF?

 

Thanks,

 

Reed.

 


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

Alternate Contact:  CIB Market Data Services Engineers | CIB_Market_Data_Services_Engineers@...

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Christopher Morgan
Sent: Monday, February 22, 2016 2:55 PM
To: openmama-dev@...
Subject: [Openmama-dev] Publisher Events Feature Documentation

 

Hello,

 

I was wondering where I can find up-to-date documentation for Publisher Events with transport callbacks (like a wiki page)? The current wiki page (https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading) only refers to the publisher callbacks.

 

I have mainly been referring to the document http://lists.openmama.org/pipermail/openmama-dev/attachments/20151009/0737e7e2/attachment-0001.pdf and I was looking over the openmama 2.4.0 rc1 source code at publisher events with transport callbacks and noticed that the additions to mamaTransportTopicEvent do not have enums for MAMA_TRANSPORT_TOPIC_PUBLISH_CREATE, MAMA_TRANSPORT_TOPIC_PUBLISH_DESTROY, and MAMA_TRANSPORT_TOPIC_PUBLISH_SUCCESS. I was wondering what kind of support does publisher events have for transport callbacks?

 

Chris Morgan

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


Publisher Events Feature Documentation

cmorgan
 

Hello,

 

I was wondering where I can find up-to-date documentation for Publisher Events with transport callbacks (like a wiki page)? The current wiki page (https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading) only refers to the publisher callbacks.

 

I have mainly been referring to the document http://lists.openmama.org/pipermail/openmama-dev/attachments/20151009/0737e7e2/attachment-0001.pdf and I was looking over the openmama 2.4.0 rc1 source code at publisher events with transport callbacks and noticed that the additions to mamaTransportTopicEvent do not have enums for MAMA_TRANSPORT_TOPIC_PUBLISH_CREATE, MAMA_TRANSPORT_TOPIC_PUBLISH_DESTROY, and MAMA_TRANSPORT_TOPIC_PUBLISH_SUCCESS. I was wondering what kind of support does publisher events have for transport callbacks?

 

Chris Morgan


Re: OpenMAMA-2.4.0-rc1 Now Available

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

Hi,

 

Submitted one pull request for Sconscript.win to create entitlementlibraries.c.

 

With that the build works fine via scons on Windows 7 32b/64b, RHEL5 32b/64b, RHEL6 32b/64b.

 

Thanks,

 

Reed.

 


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

Alternate Contact:  CIB Market Data Services Engineers | CIB_Market_Data_Services_Engineers@...

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: Thursday, February 18, 2016 6:37 AM
To: openmama-dev
Subject: [Openmama-dev] OpenMAMA-2.4.0-rc1 Now Available

 

Hi Folks,

 

We are pleased to announce the first release candidate for OpenMAMA 2.4.0 is now available:

 

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-2.4.0-rc1

 

As many of you will be aware, we have been working on closing off the work required for a new OpenMAMA release for several weeks now and it is one of the biggest we have ever assembled - both in terms of features assembled and sheer quantity of new and modified lines of code.

 

With that in mind, I would appreciate everyone’s help in trying out the latest release candidate and helping weed out any bugs or unexpected behavior which may have crept in, or may be specific to your environment / bridges. At a high level, the main new functionality is in the following areas:

 

·         Qpid proton broker support

·         Several qpid proton bridge bug fixes including fixing support for using the qpid payload on non-qpid transports and vice versa

·         CentOS / RHEL 7 support

·         Timer fixes

·         Several changes to work with recent OSX

·         Publisher Events

·         Dynamic Entitlements (phase 1 - mainly focused on defining existing interface points)

·         Dynamic Bridge loading (the ability to load any middleware bridge, even if there is no reference to it in OpenMAMA code, and adding flexibility to the bride interface).

·         Ability to specify a default payload via configuration

 

With that in mind, we recommend that any testing you plan on doing pays particular attention to those areas.

 

NB for bridge developers, see updated wiki page detailing the changes required in the bridge which have changed slightly since our last notification: https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading

 

As well as new functionality, we have also been undergoing several major operational changes since the last OpenMAMA Release:

 

·         Migrated Wiki, Issue tracking and code review all in Github out in the open (see http://github.com/OpenMAMA/OpenMAMA)

·         Continuous integration now includes Microsoft Windows builds (see http://ci.openmama.org)

·         All compiler warnings have been removed from our CentOS 6.x builds

·         All supported unit tests should now pass on Avis

 

Another focal point of this release is a general bug scrub of all outstanding issues, leading to over 100 issues of various sizes being resolved since we moved to Github less than 6 months ago.

 

Thank you all in advance for your help in testing - if you spot any issues, please follow our guidelines for raising an issue, or even better, follow our guidelines for raising a patch. Good hunting.

 

Cheers,

Frank

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


OpenMAMA-2.4.0-rc1 Now Available

Frank Quinn <fquinn.ni@...>
 

Hi Folks,


We are pleased to announce the first release candidate for OpenMAMA 2.4.0 is now available:


https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-2.4.0-rc1


As many of you will be aware, we have been working on closing off the work required for a new OpenMAMA release for several weeks now and it is one of the biggest we have ever assembled - both in terms of features assembled and sheer quantity of new and modified lines of code.


With that in mind, I would appreciate everyone’s help in trying out the latest release candidate and helping weed out any bugs or unexpected behavior which may have crept in, or may be specific to your environment / bridges. At a high level, the main new functionality is in the following areas:


  • Qpid proton broker support

  • Several qpid proton bridge bug fixes including fixing support for using the qpid payload on non-qpid transports and vice versa

  • CentOS / RHEL 7 support

  • Timer fixes

  • Several changes to work with recent OSX

  • Publisher Events

  • Dynamic Entitlements (phase 1 - mainly focused on defining existing interface points)

  • Dynamic Bridge loading (the ability to load any middleware bridge, even if there is no reference to it in OpenMAMA code, and adding flexibility to the bride interface).

  • Ability to specify a default payload via configuration


With that in mind, we recommend that any testing you plan on doing pays particular attention to those areas.


NB for bridge developers, see updated wiki page detailing the changes required in the bridge which have changed slightly since our last notification: https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading


As well as new functionality, we have also been undergoing several major operational changes since the last OpenMAMA Release:


  • Migrated Wiki, Issue tracking and code review all in Github out in the open (see http://github.com/OpenMAMA/OpenMAMA)

  • Continuous integration now includes Microsoft Windows builds (see http://ci.openmama.org)

  • All compiler warnings have been removed from our CentOS 6.x builds

  • All supported unit tests should now pass on Avis


Another focal point of this release is a general bug scrub of all outstanding issues, leading to over 100 issues of various sizes being resolved since we moved to Github less than 6 months ago.


Thank you all in advance for your help in testing - if you spot any issues, please follow our guidelines for raising an issue, or even better, follow our guidelines for raising a patch. Good hunting.


Cheers,

Frank


Re: OpenMAMA 2.4.0

Dmitri Fedorov <dfedorov.solace@...>
 

Great, thank you very much Frank, we're looking forward to it.

Regards
Dmitri

On Mon, Feb 8, 2016 at 11:08 AM, Frank Quinn <f.quinn@...> wrote:

Hi Dmitri,

 

Yeah most of the work is done at this point so with any luck we’ll be taking the RC cut at the end of this week or the beginning of next week.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 08 February 2016 16:04
To: openmama-dev@...
Subject: Re: [Openmama-dev] OpenMAMA 2.4.0

 

Thank you Frank,

 

No, there is nothing, I'm just trying to understand when we are here at Solace Systems should expect this release.

 

I suppose it will take a few days to complete the remaining issues, not as few weeks, right?

 

Regards

Dmitri Fedorov

 

On Mon, Feb 8, 2016 at 10:59 AM, Frank Quinn <f.quinn@...> wrote:

Hi Dmitri,

 

Yeah that’s all that is to be completed before we take the 2.4.0 cut, why is there something that you need squeezed in?

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 08 February 2016 15:23
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA 2.4.0

 

Hi all,

 

I'm with Solace R&D for OpenMAMA.

 

Am I right to assume that this list of open issues https://github.com/OpenMAMA/OpenMAMA/milestones/OpenMAMA-2.4.0 is all what is remained before 2.4.0 is declared, please?

 

Thank you

Dmitri Fedorov

 


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

 


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

641 - 660 of 2311