Date   

Re: Handling REFRESH messages in DQ publisher manager

Ian Bell
 

Hi Yury

The MAMA level refreshes are generally separate from the middleware heartbeat functionality. Specially they operate at a higher level although they can be similar in nature.

Normal operation would be to have the transport clean up the client context information as the clients went away using its own heartbeat functionality and let MAMA inform the client application of subscribers using its own refresh messages. The refresh timeout is an hour so this is generally a lot higher than a transport heartbeat timeout.

The dqpublisher specifically does a send rather than a sendReply to reduce the heartbeat traffic as well as to allow for transports which don't maintain subscriber lists.

I.e. If you have 4 clients on 1 symbol each will send a refresh message once an hour less a random period of time, however the client refresh timeout is reset on receiving a refresh response from a publisher, so what actually happens is that the first client to timeout sends a refresh and then the rest of the clients reset their timeouts on the refresh response from the publisher. So the publisher only processes a single refresh message per topic as opposed to 1 for every client on every topic.

Thanks,
Ian Bell

Hapsoft Consulting Ltd
138 Belmont Road, Belfast, BT4 2AQ
Office: +447481866051
Web: www.hapsoftconsulting.co.uk

-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Yury Batrakov
Sent: 14 April 2015 13:43
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] Handling REFRESH messages in DQ publisher manager

Classification: Public

Hi team,

I'm implementing new OpenMAMA transport bridge and have a question about Advanced publishing. In my middleware a publisher keeps track of all subscribers connected to it. A publisher and subscribers exchange with heartbeat messages posted to a single topic providing a string with session id in heartbeats' payload. When a publisher receives a heartbeat it sends a reply with the same session ID. Once heartbeat is not received by publisher it stops sending data and cleans up the resources allocated for a subscriber.
I tried implementing heartbeats with MAMA_SUBSC_REFRESH messages but the following problem occurs: in dqpublishermanager.c there is a handler for REFRESHES

switch (msgType)
{
case MAMA_SUBSC_REFRESH:
if (!impl->mRefreshResponseMsg)
{
*Here MAMA creates empty reply message*
mamaMsg_create(&impl->mRefreshResponseMsg);
mamaMsg_addU8(impl->mRefreshResponseMsg, NULL,
MamaFieldMsgStatus.mFid, MAMA_MSG_STATUS_MISC);
mamaMsg_addU8(impl->mRefreshResponseMsg, NULL,
MamaFieldMsgType.mFid, MAMA_MSG_TYPE_REFRESH);

}
*And sends it via the bridge*
mamaDQPublisher_send(info->pub, impl->mRefreshResponseMsg);
impl->mUserCallbacks.onRefresh((mamaDQPublisherManager)impl,
info, subType, msgType, msg );


The problem is that in the bridge we cannot restore the context of communication i.e. session id as mRefreshResponseMsg doesn't have any fields set. Thus we force users to implement a part of underlying protocol by handling refreshes themselves.

I'd propose the following change to fix that:

- mamaDQPublisher_send(info->pub, impl->mRefreshResponseMsg);
+ mamaDQPublisher_sendReply(info->pub, msg, impl->mRefreshResponseMsg);

Or could you advise how to workaround it?

Thanks,
Yury.


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

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@lists.openmama.org
https://lists.openmama.org/mailman/listinfo/openmama-dev


Handling REFRESH messages in DQ publisher manager

Yury Batrakov
 

Classification: Public

Hi team,

I'm implementing new OpenMAMA transport bridge and have a question about Advanced publishing. In my middleware a publisher keeps track of all subscribers connected to it. A publisher and subscribers exchange with heartbeat messages posted to a single topic providing a string with session id in heartbeats' payload. When a publisher receives a heartbeat it sends a reply with the same session ID. Once heartbeat is not received by publisher it stops sending data and cleans up the resources allocated for a subscriber.
I tried implementing heartbeats with MAMA_SUBSC_REFRESH messages but the following problem occurs: in dqpublishermanager.c there is a handler for REFRESHES

switch (msgType)
{
case MAMA_SUBSC_REFRESH:
if (!impl->mRefreshResponseMsg)
{
*Here MAMA creates empty reply message*
mamaMsg_create(&impl->mRefreshResponseMsg);
mamaMsg_addU8(impl->mRefreshResponseMsg, NULL,
MamaFieldMsgStatus.mFid, MAMA_MSG_STATUS_MISC);
mamaMsg_addU8(impl->mRefreshResponseMsg, NULL,
MamaFieldMsgType.mFid, MAMA_MSG_TYPE_REFRESH);

}
*And sends it via the bridge*
mamaDQPublisher_send(info->pub, impl->mRefreshResponseMsg);
impl->mUserCallbacks.onRefresh((mamaDQPublisherManager)impl,
info, subType, msgType, msg );


The problem is that in the bridge we cannot restore the context of communication i.e. session id as mRefreshResponseMsg doesn't have any fields set. Thus we force users to implement a part of underlying protocol by handling refreshes themselves.

I'd propose the following change to fix that:

- mamaDQPublisher_send(info->pub, impl->mRefreshResponseMsg);
+ mamaDQPublisher_sendReply(info->pub, msg, impl->mRefreshResponseMsg);

Or could you advise how to workaround it?

Thanks,
Yury.


---
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: C# DQPublisher Manager

Ian Bell
 

Hi

Just wondering if you go this sorted?
The first request should route through to the OnNewRequst callback. As a guess I suspect that the topic is 100% correct, or possibly the callback delegates are not hooked up completely.
Can you supply the code and some logs and I may be able to spot the issue.

Thanks,
Ian Bell

Hapsoft Consulting Ltd
138 Belmont Road, Belfast, BT4 2AQ
Office: +447481866051
Web: www.hapsoftconsulting.co.uk

-----Original Message-----
From: Mathias Kim [mailto:Mathias.Kim@crossflow.de]
Sent: 25 March 2015 16:40
Subject: [Openmama-dev] C# DQPublisher Manager

Hi guys,

we continued wrapping the dqpublishermanager class in C# but got stuck again. We can create a dqpublishermanager and I also get the onCreate callback. Now, we try to notify the dqpm that there is interest in a certain symbol.
We try to connect to the dqpm via a qpid bridge. Unfortunately, the request never arrives at the dqpm so the OnNewRequest callback never gets called. However, the transport class recognizes the request and notifies us on the console. It even remembers that we previously shows interest in the same symbol. Therefore we like to know whether our implementation is faulty or whether we need to route the request from the transport to the dqpm ourselves.
How does this generally work?

Hope you can help us.
Best regards

Mathias Kim

ETF Analyst

Phone +49 89 442327-191
Mobile +49 171 4152665
mathias.kim at crossflow.de<mailto:mathias.kim at crossflow.de> www.crossflow.de<https://exchange.assenagon.com/owa/redir.aspx?C=tVJgRBMA7UG6CkQ3TBnr2S2utVWiDdIIBlqZxpqCNcW6tUTfy7PQJ8R4pX_VH_LEFJ8GJHinPD8.&URL=http%3a%2f%2fwww.crossflow.de>

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



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmama.org/pipermail/openmama-dev/attachments/20150325/6a1d3525/attachment.html>


Re: [PATCH 2.3.1 1/1] Include stdout for build commands using site scons logger

Gary Molloy <g.molloy@...>
 

Hi Alireza,

Thanks for your patch. I have had a look at it and it looks good.

I have logged it in Bugzilla for you as http://bugs.openmama.org/show_bug.cgi?id=187

Thanks,
Gary


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

-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Alireza Assadzadeh
Sent: 06 April 2015 20:11
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] [PATCH 2.3.1 1/1] Include stdout for build commands using site scons logger


Update OpenMAMA site_scons logger to include stdout for build commands as well as stderr. Hence, Windows builds details of the compile/link error (if any) from MSVS CL command-line.

Signed-off-by: Alireza Assadzadeh <Alireza.Assadzadeh@solacesystems.com>
---

The patch is based on 'next' branch.
This was tested and used with scons builds on Windows with MSVS 2010 and Linux with GCC.

site_scons/logger.py | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/site_scons/logger.py b/site_scons/logger.py index acb5123..59e857f 100644
--- a/site_scons/logger.py
+++ b/site_scons/logger.py
@@ -36,6 +36,13 @@ class Logger:
if self.opts['verbose'] == True:
sys.stderr.write('WARNING:: %s' % (stderr))
self.fd.write('%s\n' % (stderr))
+ # Include stdout logs if there are any. This is especially
+ # helpful in Windows builds where MSVS CL command-line sends
+ # useful errors/warnings to stdout instead of stderr.
+ if len(stdout) > 0:
+ if self.opts['verbose'] == True:
+ sys.stdout.write('WARNING::stdout: %s' % (stdout))
+ self.fd.write('stdout: %s\n' % (stdout))
return p.returncode

def log_command(self, s, target, src, env):
--
1.9.3


Re: Missing transport status in C++ code

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

I also think the MAMA_TRANSPORT_CONNECT_FAILED language binding is applicable and missing in C++ and it should be supported for consistency with C API.

 

For the user not valid (not in DACS) case, the Solace middleware bridge returns an error mama_status code from bridge mama transport create. Additionally, it invokes the transport callback with MAMA_TRANSPORT_CONNECT_FAILED mama transport event.

 

There are perhaps some of these mama transport events that are deprecated, should not be used or should only be used in special situations. It would be worthwhile to document these in the code.

 

--Alireza

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Tom Doust
Sent: Tuesday, March 31, 2015 7:51 AM
To: Alpert, Reed; Adrienne Ambrose; openmama-dev@...
Subject: Re: [Openmama-dev] Missing transport status in C++ code

 

If the status codes are defined in the fundamental C API then the language bindings that build on that layer must support them. This is supposed to be middleware agnostic – you can’t make assumptions about whether connection failures are going to be synchronous  or not. Some platforms they might be, others they are not.

 

Tom

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed
Sent: 30 March 2015 18:01
To: Adrienne Ambrose; openmama-dev@...
Subject: Re: [Openmama-dev] Missing transport status in C++ code

 

Hi,

 

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

 

Thanks,

 

Reed.

 


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

 

Hi Reed,

 

On second thoughts, the callbacks are the internal MamaQueue.  

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

 

Thanks,

Adrienne

 

 

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

 

Hi Reed,

 

Thanks for your email.

 

In regards to the status codes

- MAMA_TRANSPORT_CONNECT_FAILED

- MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK

- MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK

 

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

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

 

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

 

Thanks,

Adrienne

 

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

 

Hi,

 

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

 

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

 

Thanks,

 

Reed.

 


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

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

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any 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.

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


[PATCH 2.3.1 1/1] Include stdout for build commands using site scons logger

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Update OpenMAMA site_scons logger to include stdout for build
commands as well as stderr. Hence, Windows builds details of the
compile/link error (if any) from MSVS CL command-line.

Signed-off-by: Alireza Assadzadeh <Alireza.Assadzadeh@solacesystems.com>
---

The patch is based on 'next' branch.
This was tested and used with scons builds on Windows with MSVS 2010 and
Linux with GCC.

site_scons/logger.py | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/site_scons/logger.py b/site_scons/logger.py
index acb5123..59e857f 100644
--- a/site_scons/logger.py
+++ b/site_scons/logger.py
@@ -36,6 +36,13 @@ class Logger:
if self.opts['verbose'] == True:
sys.stderr.write('WARNING:: %s' % (stderr))
self.fd.write('%s\n' % (stderr))
+ # Include stdout logs if there are any. This is especially
+ # helpful in Windows builds where MSVS CL command-line sends
+ # useful errors/warnings to stdout instead of stderr.
+ if len(stdout) > 0:
+ if self.opts['verbose'] == True:
+ sys.stdout.write('WARNING::stdout: %s' % (stdout))
+ self.fd.write('stdout: %s\n' % (stdout))
return p.returncode

def log_command(self, s, target, src, env):
--
1.9.3


Re: Missing transport status in C++ code

Tom Doust
 

If the status codes are defined in the fundamental C API then the language bindings that build on that layer must support them. This is supposed to be middleware agnostic – you can’t make assumptions about whether connection failures are going to be synchronous  or not. Some platforms they might be, others they are not.

 

Tom

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed
Sent: 30 March 2015 18:01
To: Adrienne Ambrose; openmama-dev@...
Subject: Re: [Openmama-dev] Missing transport status in C++ code

 

Hi,

 

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

 

Thanks,

 

Reed.

 


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

 

Hi Reed,

 

On second thoughts, the callbacks are the internal MamaQueue.  

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

 

Thanks,

Adrienne

 

 

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

 

Hi Reed,

 

Thanks for your email.

 

In regards to the status codes

- MAMA_TRANSPORT_CONNECT_FAILED

- MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK

- MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK

 

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

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

 

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

 

Thanks,

Adrienne

 

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

 

Hi,

 

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

 

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

 

Thanks,

 

Reed.

 


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

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

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any 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.

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


Re: Question about queue's reusable message

Sam Wilson <Sam.Wilson@...>
 

Hey Gary,

Thanks for getting back to me! I've opened Bug 186 (http://bugs.openmama.org/show_bug.cgi?id=186) about this issue. I think I recreated the same leak in the qpid bridge by detaching messages.

Thanks for your help,
Sam
________________________________________
From: Gary Molloy [g.molloy@srtechlabs.com]
Sent: Monday, March 30, 2015 12:58 PM
To: Sam Wilson; openmama-dev@lists.openmama.org
Subject: RE: Question about queue's reusable message

Hi Sam,

Thanks for your email.

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

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

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

Thanks,
Gary



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

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

Hey all,

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

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

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


Re: Missing transport status in C++ code

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

Hi,

 

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

 

Thanks,

 

Reed.

 


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

 

Hi Reed,

 

On second thoughts, the callbacks are the internal MamaQueue.  

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

 

Thanks,

Adrienne

 

 

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

 

Hi Reed,

 

Thanks for your email.

 

In regards to the status codes

- MAMA_TRANSPORT_CONNECT_FAILED

- MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK

- MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK

 

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

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

 

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

 

Thanks,

Adrienne

 

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

 

Hi,

 

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

 

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

 

Thanks,

 

Reed.

 


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

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

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any 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.

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


Re: Question about queue's reusable message

Gary Molloy <g.molloy@...>
 

Hi Sam,

Thanks for your email.

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

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

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

Thanks,
Gary



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

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

Hey all,

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

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

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


Re: Missing transport status in C++ code

Adrienne Ambrose <a.ambrose@...>
 

Hi Reed,

 

On second thoughts, the callbacks are the internal MamaQueue.  

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

 

Thanks,

Adrienne

 

 

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

 

Hi Reed,

 

Thanks for your email.

 

In regards to the status codes

- MAMA_TRANSPORT_CONNECT_FAILED

- MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK

- MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK

 

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

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

 

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

 

Thanks,

Adrienne

 

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

 

Hi,

 

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

 

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

 

Thanks,

 

Reed.

 


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

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

 

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


Re: Missing transport status in C++ code

Adrienne Ambrose <a.ambrose@...>
 

Hi Reed,

 

Thanks for your email.

 

In regards to the status codes

- MAMA_TRANSPORT_CONNECT_FAILED

- MAMA_TRANSPORT_WRITE_QUEUE_LOW_WATER_MARK

- MAMA_TRANSPORT_WRITE_QUEUE_HIGH_WATER_MARK

 

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

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

 

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

 

Thanks,

Adrienne

 

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

 

Hi,

 

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

 

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

 

Thanks,

 

Reed.

 


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

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

 

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


Missing transport status in C++ code

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

Hi,

 

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

 

Is this for a specific reason or just missing?

If missing I can submit a patch with new callbacks.

 

Thanks,

 

Reed.

 


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

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

 

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


[Patch 2.3.2] Scons: fixes for Windows and Linux

Reed Alpert <reed.alpert@...>
 

Hi,

These are against the next branch.

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

Thanks,

Reed.


diff --git a/mama/c_cpp/SConscript.win b/mama/c_cpp/SConscript.win
index 77e3157..ece0710 100644
--- a/mama/c_cpp/SConscript.win
+++ b/mama/c_cpp/SConscript.win
@@ -121,14 +121,13 @@ if env['with_testtools'] == True and 'dynamic' in env['build']:
 if (    not Media.has_key('mama/c_cpp/docs')
         and env['build'] == 'dynamic'
         and not env.GetOption('clean')
+        and env['product'] == 'mama'
         and env['with_docs'] == True ):
 
     cdoc = env.Doxygen('doxyconfig-c.in')
     cppdoc = env.Doxygen('doxyconfig-cpp.in')
 
-    env.Command( '$prefix/doc/mama/images', cdoc, 'mkdir $TARGET && cp -rf %s\mama\c_cpp\doc\images\* $TARGET' % ( env['TOPLEVEL'] ) )
-    env.Command( '$prefix/doc/mama/c/html', cdoc, 'mkdir $TARGET && cp -rf %s\mama\c_cpp\doc\c\html\* $TARGET' % ( env['TOPLEVEL'] ) )
-    env.Command( '$prefix/doc/mama/cpp/html', cppdoc, 'mkdir $TARGET && cp -rf %s\mama\c_cpp\doc\cpp\html\* $TARGET' % ( env['TOPLEVEL'] ) )
+    env.Command( '$prefix/doc/mama', '', 'mkdir $TARGET && xcopy /q /s /e /y %s\mama\c_cpp\doc\* $TARGET' % ( env['TOPLEVEL'] ) )
 
     env.Clean( cdoc, '%s/mama/c_cpp/doc/c' % (env['TOPLEVEL']) )
     env.Clean( cppdoc, '%s/mama/c_cpp/doc/cpp' % (env['TOPLEVEL']) )
diff --git a/mama/c_cpp/doxyconfig-c.in b/mama/c_cpp/doxyconfig-c.in
index 9e03518..b92b005 100644
--- a/mama/c_cpp/doxyconfig-c.in
+++ b/mama/c_cpp/doxyconfig-c.in
@@ -754,7 +754,7 @@ WARN_LOGFILE           =
 # spaces.
 # Note: If this tag is empty the current directory is searched.
 
-INPUT                  = ./src/c/mama ./src/enterprise/c/mama
+INPUT                  = ./src/c/mama ./src/c/mama
 
 # This tag can be used to specify the character encoding of the source files
 # that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
diff --git a/mama/jni/SConscript b/mama/jni/SConscript
index 6d4173d..61a3570 100644
--- a/mama/jni/SConscript
+++ b/mama/jni/SConscript
@@ -20,6 +20,9 @@ testtools_source = Split("""
 
 testtools = []
 
+unittest_source = Glob('src/junittests')
+unittest = []
+
 jExamples = Glob('src/com/wombat/mama/examples/*java')
 
 version = env['versions']['mama']['releaseString']
@@ -43,14 +46,20 @@ if env['with_testtools'] == True:
     for t in testtools_source:
         testtools.append( env.Java( 'classes', t ) )
 
+if env['with_unittest'] == True:
+    for t in unittest_source:
+        unittest.append( env.Java( 'classes', t ) )
+        env.Append(JAVACLASSPATH = ('$junit_home/junit.jar'))
+
 env.Depends( mama_classes, common_classes )
 env.Depends( testtools, mama_classes )
+env.Depends( unittest, mama_classes )
 
 # Builds all of the header files which is unnecessary but no reason not to
 # do this
 headers = env.JavaH(target=Dir('src/c/mamajni').abspath,source= [ mama_classes, common_classes ])
 
-env.Depends( headers, [ mama_classes, common_classes, testtools ] )
+env.Depends( headers, [ mama_classes, common_classes, testtools, unittest ] )
 
 jar = env.Jar(target='mamajni.jar', source='classes', JARCHDIR = Dir('classes').abspath  )
 
diff --git a/mamda/c_cpp/SConscript.win b/mamda/c_cpp/SConscript.win
index 4c63b51..0a67d48 100644
--- a/mamda/c_cpp/SConscript.win
+++ b/mamda/c_cpp/SConscript.win
@@ -113,7 +113,7 @@ if env['with_unittest'] == True:
 if ( env['with_docs'] == True and not Media.has_key('mamda/c_cpp/docs') and env['build'] == 'dynamic' and not env.GetOption('clean') ):
    cppdoc = env.Doxygen('doxyconfig-cpp.in')
 
-   env.Command( '$prefix/doc/mamda/cpp/html', cppdoc, 'mkdir $TARGET && cp -rf %s\mamda\c_cpp\doc\cpp\html\* $TARGET' % ( env['TOPLEVEL'] ) )
+   env.Command( '$prefix/doc/mamda', cppdoc, 'mkdir $TARGET && xcopy /q /s /e /y  %s\mamda\c_cpp\doc\* $TARGET' % ( env['TOPLEVEL'] ) )
 
    env.Clean( cppdoc, '%s/mamda/c_cpp/doc/cpp' % (env['TOPLEVEL']) )
 
diff --git a/site_scons/community/command_line.py b/site_scons/community/command_line.py
index e1791e2..4bbacc5 100644
--- a/site_scons/community/command_line.py
+++ b/site_scons/community/command_line.py
@@ -26,6 +26,7 @@ def get_command_line_opts( host, products, VERSIONS ):
        BoolVariable('with_examples','Build with test tools',True),
        BoolVariable('entitled','Whether the build is entitled or unentitled',False),
        PathVariable('gtest_home','Path to Google Test home',None, PathVariable.PathIsDir),
+       PathVariable('junit_home','Path to Junit home',None, PathVariable.PathIsDir),
        ListVariable('middleware','Middleware(s) to be compiled in', 'avis', names = ['avis', 'qpid'] ),
        ('jobs', 'Number of scons threads to spawn, if n is passed the number of availabe cores is calculated and used', '1'),
 
@@ -39,7 +40,7 @@ def get_command_line_opts( host, products, VERSIONS ):
             PathVariable('qpid_home', 'Path to QPID Proton Libraries',
                           'c:\\proton', PathVariable.PathAccept),
             EnumVariable('vsver','Visual Studio Version to use', '10.0',
-                allowed_values=('8.0','9.0','10.0')),
+                allowed_values=('8.0','9.0','10.0','11.0','12.0')),
             EnumVariable('product', 'Product to be built', 'mamda',
                      allowed_values=( products )),
             EnumVariable('dotnet_version', 'Dotnet Version used to determine framework directory', '2.0',
@@ -63,6 +64,8 @@ def get_command_line_opts( host, products, VERSIONS ):
             EnumVariable('product', 'Product to be built', 'mamda',
                          #mamda all is a windows only build
                          allowed_values=( [ x for x in products if x != "mamdaall" ] )),
+            EnumVariable('target_arch', 'Specifies if the build should target 32 or 64 bit architectures.',
+                          host['arch'], allowed_values=['x86', 'x86_64']),
             EnumVariable( 'compiler', 'Compiler to use for building OpenMAMA',
                          'default', allowed_values=('default', 'gcc', 'clang', 'clang-analyzer')),
         )
diff --git a/site_scons/community/windows.py b/site_scons/community/windows.py
index 362f697..80c241d 100644
--- a/site_scons/community/windows.py
+++ b/site_scons/community/windows.py
@@ -64,8 +64,10 @@ class Windows:
             env = Environment(ENV={
                 'JAVA_HOME': '%s' % (optsEnv['java_home']),
                 'PATH': '%s:%s\\bin' % (os.environ['PATH'], optsEnv['java_home']),
-                'MSVC_VERSION' : '%s' %(optsEnv['vsver'])},
+                },
                 tools = tools,
+                MSVC_VERSION = optsEnv['vsver'],
+                MSVS_VERSION = optsEnv['vsver'],
                 TARGET_ARCH = optsEnv['target_arch'])
 
             #ConfigureJNI searches os.env for java_home not env['ENV']['JAVA_HOME'] 
@@ -78,7 +80,7 @@ class Windows:
             env['JAVAH'] = 'javah'
 
         else:
-            env = Environment(ENV={'PATH': '%s' % (os.environ['PATH'])}, MSVC_VERSION = optsEnv['vsver'], tools = tools, TARGET_ARCH = optsEnv['target_arch'])
+            env = Environment(ENV={'PATH': '%s' % (os.environ['PATH'])}, MSVC_VERSION = optsEnv['vsver'], MSVS_VERSION = optsEnv['vsver'], tools = tools, TARGET_ARCH = optsEnv['target_arch'])
 
         env['SPAWN'] = logger.log_output
         env['PRINT_CMD_LINE_FUNC'] = logger.log_command
@@ -196,7 +198,7 @@ class Windows:
     # Configures all of the appropriate environment variables for windows.
     def configure(self, env ):
         env.Append( CPPDEFINES = ['WIN32'] )
-        env.Append( CCFLAGS = ['-EHsc','/GR','/FIwombat\\targetsxs.h'] )
+        env.Append( CCFLAGS = ['/EHsc','/GR','/FIwombat\\targetsxs.h'] )
         env.Append( LINKFLAGS =['/MANIFEST'] )
         env.Append( CCPDBFLAGS = '/Fd${TARGET}.pdb' )
         env.Append( PDB = '${TARGET.base}.pdb')


Question about queue's reusable message

Sam Wilson <Sam.Wilson@...>
 

Hey all,

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

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

Thanks,
Sam


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

Adrienne Ambrose <a.ambrose@...>
 

Good Afternoon,

 

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

 

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

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

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

 

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

 

Thanks,

Adrienne

 

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

 

Hi there,

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

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

Again, thanks for your comments and answers!

 


Re: onError from image request inbox lost

Ian Bell <i.bell@...>
 

Hi

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

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

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

Ian

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

Hi Sam

Interesting question.

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

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

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

Best regards

Tom

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

Hey,

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

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

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

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


C# DQPublisher Manager

Mathias Kim
 

Hi guys,

 

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

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

How does this generally work?

 

Hope you can help us.

Best regards

 

Mathias Kim

 

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

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

 

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

 


Re: onError from image request inbox lost

Tom Doust
 

Hi Sam

Interesting question.

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

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

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

Best regards

Tom

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

Hey,

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

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

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

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


onError from image request inbox lost

Sam Wilson <Sam.Wilson@...>
 

Hey,

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

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

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

Thanks,
Sam

841 - 860 of 2306