Date   

Re: OpenMAMA End of Support for Avis

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

Last call on this - if I hear no word back, it's getting taken out on Monday.

Cheers,
Frank

On Sat, Jul 16, 2016 at 7:18 PM, Frank Quinn <fquinn.ni@...> wrote:
Hi Folks,

I'd like too propose that we stop maintaining the avis bridge for OpenMAMA and that the release which just went out (2.4.1) is the last to support avis, which may then be removed from the code base.

This has already been agreed by the Steering Committee, but I want to put it out there to the users and dev mailing lists to see if there are any further objections, or if anyone would like to step up and take ownership of the bridge (e.g. split out an external OpenMAMA-avis project).

There are several reasons for wanting to retire support for avis:

1. To the best of my knowledge, nobody is using it (we never hear of it on the mailing list any more).
2. Avis itself hasn't been updated in 7 years
3. It's a resource drain on any new functionality we may add for zero return.
4. Even today, doesn't pass all unit tests because the payload doesn't support all OpenMAMA functionality.

It's all about focus - I want to make sure that we spend time focusing on what people are actively using.

If anyone has any sentimental attachment to the avis bridge, please speak up now.

We are currently scheduling the removal of avis from the codebase on 25th July.

Cheers,
Frank


OpenMAMA End of Support for Avis

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

I'd like too propose that we stop maintaining the avis bridge for OpenMAMA and that the release which just went out (2.4.1) is the last to support avis, which may then be removed from the code base.

This has already been agreed by the Steering Committee, but I want to put it out there to the users and dev mailing lists to see if there are any further objections, or if anyone would like to step up and take ownership of the bridge (e.g. split out an external OpenMAMA-avis project).

There are several reasons for wanting to retire support for avis:

1. To the best of my knowledge, nobody is using it (we never hear of it on the mailing list any more).
2. Avis itself hasn't been updated in 7 years
3. It's a resource drain on any new functionality we may add for zero return.
4. Even today, doesn't pass all unit tests because the payload doesn't support all OpenMAMA functionality.

It's all about focus - I want to make sure that we spend time focusing on what people are actively using.

If anyone has any sentimental attachment to the avis bridge, please speak up now.

We are currently scheduling the removal of avis from the codebase on 25th July.

Cheers,
Frank


Re: [Openmama-dev] Gitter vs IRC

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

All links on the openmama website have now been updated to point to Gitter rather than IRC (and a few pages have been cleaned up during the review). If anyone spots any stale references to IRC, please let me know.

 

I am pleased to say it really has grown to be quite lively - we already have more active participants than we ever had on IRC so I think it was the right move.

 

We also just updated wiki.openmama.org to point to the github wiki rather than the old mediawiki installation to avoid duplication and forking of our development documentation.

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: Monday, June 13, 2016 9:26 AM
To: openmama-dev <openmama-dev@...>; openmama-users@...
Subject: Re: [Openmama-dev] Gitter vs IRC

 

Hi folks,

As we have heard no objections, we'll be going ahead with the move to gitter. It is ready to go right now and you'll find the usual IRC folks in Gitter. Meanwhile we'll work on updating all documentation etc to point to gitter rather than freenode.

Cheers,

Frank

 

On Tue, May 31, 2016 at 9:05 PM, Frank Quinn <fquinn.ni@...> wrote:

Hi folks,

We're currently looking at gitter as a potential IRC compatible replacement and my personal opinion is that we should go with it.

 

You can already mess about in the proposed channel; you can read anonymously, or use a github or twitter account to contribute: 

 

https://gitter.im/OpenMAMA/OpenMAMA

It has several great features:

1. Instant messages are persisted to the room, so you will see history when you log in
2. Sensible concurrent login access with no username1 nonsense
3. Web front end comes for free
4. Provided by github so integrates very nicely into the project wiki etc
5. Native client provided for Mac, windows, Linux, iPhone and android
6. Also compatible with standard IRC clients

Downsides:

1. It increases the github lock-in
2. You'll need a github or twitter account to contribute

If anyone has any feedback about making the move, please speak up now. I'm sending this to both users and developers because it will impact both and I'll welcome and consider all responses. I'd hope that we can agree a decision one way or another by 7th June, then (if necessary) take the plunge.

Cheers,
Frank

 


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


Re: OpenMAMA-2.4.1 (hotfix release for deferred entitlements)

Frank Quinn <f.quinn@...>
 

Hi Folks,


I can confirm that 2.4.1 is now available – see:

 

https://github.com/OpenMAMA/OpenMAMA/releases

 

Cheers,

Frank

 

From: Frank Quinn
Sent: Monday, June 13, 2016 1:23 PM
To: openmama-dev <openmama-dev@...>; 'openmama-users@...' <openmama-users@...>
Subject: OpenMAMA-2.4.1 (hotfix release for deferred entitlements)

 

Hi Folks,

 

We will be cutting a release shortly which is a hot fix release to include following change:

 

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

 

Note that if you have fallen victim to this issue, you will not be able to subscribe to anything, so if you can subscribe to data sources and receive data today, you don’t need to upgrade.

 

Only users of middleware bridges which use deferred entitlements will require this change (i.e. Qpid, Avis, ZeroMQ and SR Labs bridges are unaffected).

 

I am aiming to get binaries available within the next day or two. Alternatively if you build your own, you can go ahead and build off the OpenMAMA-2.4.1 release branch.

 

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-2.4.1 (hotfix release for deferred entitlements)

Frank Quinn <f.quinn@...>
 

Hi Folks,

 

We will be cutting a release shortly which is a hot fix release to include following change:

 

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

 

Note that if you have fallen victim to this issue, you will not be able to subscribe to anything, so if you can subscribe to data sources and receive data today, you don’t need to upgrade.

 

Only users of middleware bridges which use deferred entitlements will require this change (i.e. Qpid, Avis, ZeroMQ and SR Labs bridges are unaffected).

 

I am aiming to get binaries available within the next day or two. Alternatively if you build your own, you can go ahead and build off the OpenMAMA-2.4.1 release branch.

 

Cheers,

Frank


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


Re: Gitter vs IRC

Frank Quinn <fquinn.ni@...>
 

Hi folks,

As we have heard no objections, we'll be going ahead with the move to gitter. It is ready to go right now and you'll find the usual IRC folks in Gitter. Meanwhile we'll work on updating all documentation etc to point to gitter rather than freenode.

Cheers,
Frank

On Tue, May 31, 2016 at 9:05 PM, Frank Quinn <fquinn.ni@...> wrote:
Hi folks,

We're currently looking at gitter as a potential IRC compatible replacement and my personal opinion is that we should go with it.

You can already mess about in the proposed channel; you can read anonymously, or use a github or twitter account to contribute: 

https://gitter.im/OpenMAMA/OpenMAMA

It has several great features:

1. Instant messages are persisted to the room, so you will see history when you log in
2. Sensible concurrent login access with no username1 nonsense
3. Web front end comes for free
4. Provided by github so integrates very nicely into the project wiki etc
5. Native client provided for Mac, windows, Linux, iPhone and android
6. Also compatible with standard IRC clients

Downsides:

1. It increases the github lock-in
2. You'll need a github or twitter account to contribute

If anyone has any feedback about making the move, please speak up now. I'm sending this to both users and developers because it will impact both and I'll welcome and consider all responses. I'd hope that we can agree a decision one way or another by 7th June, then (if necessary) take the plunge.

Cheers,
Frank


Re: [Openmama-dev] Gitter vs IRC

Damian Maguire <d.maguire@...>
 

Having toyed with it a bit, as well as many of the alternatives, I think Gitter is a really good option – public, easy to use for new users (beats IRC on that front), enough platform support for regular users to work with, preserves history (again beats IRC default), much more open than Slack etc. Integrations might need some work (CI notifications in the IRC channel are nice for example), but I think we can work around that.

 

So yeah, my vote is go for it (with some sort of plan for deprecating Freenode of course).

 

Cheers,

 

D

 

Damian Maguire

Senior Sales Engineer

Desk (Direct): +4428 9568 0298

 

From: <openmama-dev-bounces@...> on behalf of Frank Quinn <fquinn.ni@...>
Date: Tuesday, May 31, 2016 at 9:05 PM
To: openmama-dev <openmama-dev@...>, "openmama-users@..." <openmama-users@...>
Subject: [Openmama-dev] Gitter vs IRC

 

Hi folks,

We're currently looking at gitter as a potential IRC compatible replacement and my personal opinion is that we should go with it.

 

You can already mess about in the proposed channel; you can read anonymously, or use a github or twitter account to contribute: 

 

https://gitter.im/OpenMAMA/OpenMAMA

It has several great features:

1. Instant messages are persisted to the room, so you will see history when you log in
2. Sensible concurrent login access with no username1 nonsense
3. Web front end comes for free
4. Provided by github so integrates very nicely into the project wiki etc
5. Native client provided for Mac, windows, Linux, iPhone and android
6. Also compatible with standard IRC clients

Downsides:

1. It increases the github lock-in
2. You'll need a github or twitter account to contribute

If anyone has any feedback about making the move, please speak up now. I'm sending this to both users and developers because it will impact both and I'll welcome and consider all responses. I'd hope that we can agree a decision one way or another by 7th June, then (if necessary) take the plunge.

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


Gitter vs IRC

Frank Quinn <fquinn.ni@...>
 

Hi folks,

We're currently looking at gitter as a potential IRC compatible replacement and my personal opinion is that we should go with it.

You can already mess about in the proposed channel; you can read anonymously, or use a github or twitter account to contribute: 

https://gitter.im/OpenMAMA/OpenMAMA

It has several great features:

1. Instant messages are persisted to the room, so you will see history when you log in
2. Sensible concurrent login access with no username1 nonsense
3. Web front end comes for free
4. Provided by github so integrates very nicely into the project wiki etc
5. Native client provided for Mac, windows, Linux, iPhone and android
6. Also compatible with standard IRC clients

Downsides:

1. It increases the github lock-in
2. You'll need a github or twitter account to contribute

If anyone has any feedback about making the move, please speak up now. I'm sending this to both users and developers because it will impact both and I'll welcome and consider all responses. I'd hope that we can agree a decision one way or another by 7th June, then (if necessary) take the plunge.

Cheers,
Frank


Re: [Openmama-dev] Using Qpid Broker

Frank Quinn <fquinn.ni@...>
 

Thanks for the update, Nestor, glad to see you got to the bottom of it!

Cheers,
Frank

On Thu, Apr 21, 2016 at 5:45 PM, Macrux <kmacrux@...> wrote:
Hi, its me again, I have resolved this just creating a new topic exchange called "MAMA". That's all. Thanks anyway.

Kind regards,

Nestor.


On 21 April 2016 at 11:21, Macrux <kmacrux@...> wrote:
Hi there,

I'm trying to use the Java Qpid Broker implementation with OpenMAMA 2.4.0. On the web management console of the broker I have created a queue called "test" and I've bound it to the "amqp.topic" exchange (that is there by default). As a binding key I'm using "MAMA.*". When I run the mamapublisherc with:

mamapublisherc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/8c60fd18-07db-11e6-b2bd-d8fc939b9a65 : (null)

And it seems to connect correctly, but when I subscribe a client with:

mamasubscriberc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/b45ca894-07db-11e6-8de4-d8fc939b9a65 : (null)

And although it seems to connect correctly to the broker, it doesn't receive anything.

I haven't modified anything in the mama.properties file, so I have an error in the configuration of the broker, I suppose.

Could anyone please give me a hand with this? Thanks in advance.

Nestor.



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



Re: Using Qpid Broker

macrux
 

Hi, its me again, I have resolved this just creating a new topic exchange called "MAMA". That's all. Thanks anyway.

Kind regards,

Nestor.

On 21 April 2016 at 11:21, Macrux <kmacrux@...> wrote:
Hi there,

I'm trying to use the Java Qpid Broker implementation with OpenMAMA 2.4.0. On the web management console of the broker I have created a queue called "test" and I've bound it to the "amqp.topic" exchange (that is there by default). As a binding key I'm using "MAMA.*". When I run the mamapublisherc with:

mamapublisherc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/8c60fd18-07db-11e6-b2bd-d8fc939b9a65 : (null)

And it seems to connect correctly, but when I subscribe a client with:

mamasubscriberc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/b45ca894-07db-11e6-8de4-d8fc939b9a65 : (null)

And although it seems to connect correctly to the broker, it doesn't receive anything.

I haven't modified anything in the mama.properties file, so I have an error in the configuration of the broker, I suppose.

Could anyone please give me a hand with this? Thanks in advance.

Nestor.



Using Qpid Broker

macrux
 

Hi there,

I'm trying to use the Java Qpid Broker implementation with OpenMAMA 2.4.0. On the web management console of the broker I have created a queue called "test" and I've bound it to the "amqp.topic" exchange (that is there by default). As a binding key I'm using "MAMA.*". When I run the mamapublisherc with:

mamapublisherc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/8c60fd18-07db-11e6-b2bd-d8fc939b9a65 : (null)

And it seems to connect correctly, but when I subscribe a client with:

mamasubscriberc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/b45ca894-07db-11e6-8de4-d8fc939b9a65 : (null)

And although it seems to connect correctly to the broker, it doesn't receive anything.

I haven't modified anything in the mama.properties file, so I have an error in the configuration of the broker, I suppose.

Could anyone please give me a hand with this? Thanks in advance.

Nestor.


Re: Deal with multiple clients and only one transport in tick42blp bridge

Tom Doust
 

Hi Nestor

 

I think there is nothing inherent in OpenMAMA that prevents you from creating and running multiple instances of the same transport. I have demonstrated this with the Tick42 TREP bridge.

 

Your second solution is not ideal because the single static transport is only going to maintain a single connection (and thread) to Bloomberg.

 

Using your first solution (which I believe is the correct way to go) , where did it fail ?

 

Best regards

 

Tom

 

From: openmama-users-bounces@... [mailto:openmama-users-bounces@...] On Behalf Of Macrux
Sent: 29 March 2016 15:52
To: openmama-dev@...; openmama-users@...
Subject: [Openmama-users] Deal with multiple clients and only one transport in tick42blp bridge

 

Hi there,

I'm working with Bloomberg and the tick42blp bridge, and I have an application which starts multiple clients, each one in a different thread, and each one can be subscribed to different subjects. I had a problem, when the second client started, it failed because the transport with that name (blp_tport) had been already created when the first client started. Then I decided to make the transport static so all clients can use the same instance, but I am not able to destroy the transport until the last client is closed, otherwise, clients that are using the transport will fail.

My question is if this is the correct approach to deal with this situation, or there is a better one?

 

Thanks in advance for any help you could give me.

Kind regards,

Nestor.


Deal with multiple clients and only one transport in tick42blp bridge

macrux
 

Hi there,

I'm working with Bloomberg and the tick42blp bridge, and I have an application which starts multiple clients, each one in a different thread, and each one can be subscribed to different subjects. I had a problem, when the second client started, it failed because the transport with that name (blp_tport) had been already created when the first client started. Then I decided to make the transport static so all clients can use the same instance, but I am not able to destroy the transport until the last client is closed, otherwise, clients that are using the transport will fail.

My question is if this is the correct approach to deal with this situation, or there is a better one?

Thanks in advance for any help you could give me.

Kind regards,

Nestor.


OpenMAMA 2.4.0 Released

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

We are pleased to announce the final release of OpenMAMA 2.4.0 is now available:

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

As many of you will be aware, we have been working on this OpenMAMA release for months 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.

At a high level, the main new functionality is in the following areas:
  • Qpid proton broker support
  • It is now possible to use the qpid payload on non-qpid transports and vice versa
  • Support for Microsoft Visual Studio 2015
  • CentOS / RHEL 7 support
  • Fedora 23 support
  • A default payload type may now be enabled via configuration
  • Several changes made to work with recent OSX
  • Publisher Events now in place to allow asyncronous publish time failures to be handled
  • Dynamic entitlements now defines an entitlement interface which doesn't depend on OEA
  • Dynamic Bridge loading now allows middleware and payload bridges to work without needing to register an enum with OpenMAMA
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. If you have not made these changes since the first release candidate was cut in February, we recommend you do so ASAP to remain current with the project.


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.

A special thanks to all developers, contributors and testers who helped is getting this out door.

Cheers,
Frank


Re: Problem bringing fields from bloomberg professional terminal

Tom Doust
 

Hi Nestor

 

Do you have mappings for these fields in the field map file?

 

Feel free to mail me a copy of the file directly and I will take a look

 

 

Best regards

 

Tom

 

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

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

 

 

From: openmama-users-bounces@... [mailto:openmama-users-bounces@...] On Behalf Of Macrux
Sent: 26 October 2015 15:26
To: openmama-dev@...; openmama-users@...
Subject: [Openmama-users] Problem bringing fields from bloomberg professional terminal

 

Hi there,

I have a problem bringing some fields with the tick42blp bridge, I'm trying to get the data for the price levels (wBestBidPrice1, wBestBidPrice2,..., wBestBidPrice10) as well as the sizes for those levels and also for the ask side, but when the mamalisten example receives the MamaMsg, it doesn't has those fields, even if they are specified as the documentation shows:

mamalistenc -m tick42blp -tport blp_tport -S BlpMktData -s "AAPL US Equity,[BEST_BID1, BEST_BID2,BEST_BID3,BEST_ASK1,BEST_ASK2,BEST_ASK3]"

And so on...

I have the fieldmap.csv file in WOMBAT_PATH, and I'm using Blomberg's professional terminal, in fact, I can bring these fields using the example included in Blomberg Open API, but not through the bridge which brings other fields like wBidPrice, wAskPrice, wBidSize, wAskSize, wEventTime, among others, but not information about levels.

Has anyone had this  issue?

Thanks in advance,

Nestor.


Problem bringing fields from bloomberg professional terminal

macrux
 

Hi there,

I have a problem bringing some fields with the tick42blp bridge, I'm trying to get the data for the price levels (wBestBidPrice1, wBestBidPrice2,..., wBestBidPrice10) as well as the sizes for those levels and also for the ask side, but when the mamalisten example receives the MamaMsg, it doesn't has those fields, even if they are specified as the documentation shows:

mamalistenc -m tick42blp -tport blp_tport -S BlpMktData -s "AAPL US Equity,[BEST_BID1, BEST_BID2,BEST_BID3,BEST_ASK1,BEST_ASK2,BEST_ASK3]"

And so on...

I have the fieldmap.csv file in WOMBAT_PATH, and I'm using Blomberg's professional terminal, in fact, I can bring these fields using the example included in Blomberg Open API, but not through the bridge which brings other fields like wBidPrice, wAskPrice, wBidSize, wAskSize, wEventTime, among others, but not information about levels.

Has anyone had this  issue?

Thanks in advance,

Nestor.


Re: Capturec and tick42blp bridge

macrux
 

Hi,

I recorded just a few seconds of the AAPL US Equity from Bloomberg yesterday (I sent a bigger capture in my first message). The playback is attached in the file 1325551007.playback. The log of the capturerec is attached in the file capturerec-aapl.log, and for the capturereplayc two logs are attached: one in the file capturereplayc-aapl-ubuntu.log and the other in the file capturereplayc-aapl-windows.log. It was done using the openmama 2.3.1 release in windows using the bridge tick42blp to connect to the bloomberg terminal. I used the same parameters mentioned before:

capturec -m tick42blp -MS BlpMktData:blp_tport:symbols.sym

Where symbols.sym is a file containing only one symbol: "AAPL US Equity"

It starts to recording a file. After a while I stop the process with CTLR+C. Then I try to use the capturereplayc to play the file:

capturereplayc -S TEST -m qpid -tport pub -dictionary data/dictionaries/data.dict -f 1325551007.playback

The fact is that capturereplayc cannot even start when I try to reproduce the file in ubuntu (in this machine I have the openmama 2.3.3 release), it happens a "segmentation fault" as you can see in the ubuntu log. If I try to reproduce it in a windows machine (with windows 10 and openmama 2.3.1), then the capturereplayc starts listening and when I start a mamalistenc, it stops abruptly, but the verbose log of capturereplayc doesn't say anything. The same happens if I do it in the machine where I have the bloomberg terminal (with windows 7 machine and openmama 2.3.1), so I'm stuck in this problem.


Thanks in advance,

Nestor.


On 2 October 2015 at 02:45, Damian Maguire <d.maguire@...> wrote:
Hey Nestor, 

Do you have a verbose log file from capturereplay up to the point at which it stops? And does the process simply hang, or is it crashing? I’ve never tried capturereplay with the Bloomberg bridge, though Tom and co will likely have a better idea of the issues there, but if it’s a bug in capturereplay we should be able to get a better idea of where from the logs.

Cheers, 

D

Damian Maguire
Senior Sales Engineer

SR.LABS Proven High Speed Electronic Trading Solutions

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

d.maguire@...  

+44 7835 844770



From: <openmama-users-bounces@...> on behalf of Macrux
Date: Thursday, October 1, 2015 at 10:23 PM
To: "openmama-dev@...", "openmama-users@..."
Subject: [Openmama-users] Capturec and tick42blp bridge

Hi folks,

As part of the work I'm doing with bloomberg and openmama, I'm trying to record the data coming from bloomberg through the bridge, I'm using this instruction:

capturec -m tick42blp -MS BlpMktData:blp_tport:symbols.sym


Where symbols.sym is a file containing only one symbol: "AAPL US Equity"

It starts to recording a file. After a while I stop the process with CTLR+C. Then I try to use the capturereplayc to play the file:

capturereplayc -S TEST -m qpid -tport pub -dictionary bbdict.txt -f 1221191001.playback

But the capturereplayc stops abruptly. The same happens if I try to use the dictionary provided in the openmama release.

So my question is, how could I record the data coming from bloomberg and then play them with the capturereplayc tool.

Thanks for your help. I appreciate your patience, I'm really new with openama.

Best regards,



PD: I attached the playback file recorded today just in case someone wants to test it.




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


Re: Capturec and tick42blp bridge

Damian Maguire <d.maguire@...>
 

Hey Nestor, 

Do you have a verbose log file from capturereplay up to the point at which it stops? And does the process simply hang, or is it crashing? I’ve never tried capturereplay with the Bloomberg bridge, though Tom and co will likely have a better idea of the issues there, but if it’s a bug in capturereplay we should be able to get a better idea of where from the logs.

Cheers, 

D

Damian Maguire
Senior Sales Engineer

SR.LABS Proven High Speed Electronic Trading Solutions

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

d.maguire@...  

+44 7835 844770



From: <openmama-users-bounces@...> on behalf of Macrux
Date: Thursday, October 1, 2015 at 10:23 PM
To: "openmama-dev@...", "openmama-users@..."
Subject: [Openmama-users] Capturec and tick42blp bridge

Hi folks,

As part of the work I'm doing with bloomberg and openmama, I'm trying to record the data coming from bloomberg through the bridge, I'm using this instruction:

capturec -m tick42blp -MS BlpMktData:blp_tport:symbols.sym


Where symbols.sym is a file containing only one symbol: "AAPL US Equity"

It starts to recording a file. After a while I stop the process with CTLR+C. Then I try to use the capturereplayc to play the file:

capturereplayc -S TEST -m qpid -tport pub -dictionary bbdict.txt -f 1221191001.playback

But the capturereplayc stops abruptly. The same happens if I try to use the dictionary provided in the openmama release.

So my question is, how could I record the data coming from bloomberg and then play them with the capturereplayc tool.

Thanks for your help. I appreciate your patience, I'm really new with openama.

Best regards,



PD: I attached the playback file recorded today just in case someone wants to test it.




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


Capturec and tick42blp bridge

macrux
 

Hi folks,

As part of the work I'm doing with bloomberg and openmama, I'm trying to record the data coming from bloomberg through the bridge, I'm using this instruction:

capturec -m tick42blp -MS BlpMktData:blp_tport:symbols.sym


Where symbols.sym is a file containing only one symbol: "AAPL US Equity"

It starts to recording a file. After a while I stop the process with CTLR+C. Then I try to use the capturereplayc to play the file:

capturereplayc -S TEST -m qpid -tport pub -dictionary bbdict.txt -f 1221191001.playback

But the capturereplayc stops abruptly. The same happens if I try to use the dictionary provided in the openmama release.

So my question is, how could I record the data coming from bloomberg and then play them with the capturereplayc tool.

Thanks for your help. I appreciate your patience, I'm really new with openama.

Best regards,



PD: I attached the playback file recorded today just in case someone wants to test it.




Re: Build Mamda Book from Mama Subscription

Tom Doust
 

Hi Nestor, Glenn

 

Order book handling is outside the scope of the current version of our BLP bridge.

 

In our TREP bridge we take OMM MarketByPrice and MarketByOrder messages and build mamda book messages from them. Conceptually, it’s quite simple because the OMM and the Mamda models are almost identical. In practice, it’s a bit messy because in order to key the price levels correctly you have to maintain some state between updates.

 

I think generating the messages in the bridge is the right way to go.

 

From what I recall of the Open Bloomberg  API there are several, source dependent representations, some of which are similar to the TR OMM model.

 

The TREP bridge code described above is in our  open source release in git hub if you want to take a look. A lot of the code we used to build the mama book messages is based on code doing the same thing in the mamda book publisher example that ships with OpenMAMA.


Apologies that this doesn’t really give any easy answers but hopefully will point you in the right direction.

 

Best regards

 

Tom

 

From: openmama-users-bounces@... [mailto:openmama-users-bounces@...] On Behalf Of Glenn McClements
Sent: 01 October 2015 08:23
To: Macrux <kmacrux@...>; openmama-dev@...; openmama-users@...
Subject: Re: [Openmama-users] Build Mamda Book from Mama Subscription

 

Hi Nestor,

Perhaps one of the tick42blp bridge developers could help out, but one thing that may help is a orderbook message spec for OpenMAMDA. This isn't currently published on the OpenMAMA website but I see when we can get it out.

 

Regards,

Glenn 

 

Glenn McClements, SVP Engineering 

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

www.srtechlabs.com

 

SR.LABS Proven High Speed Electronic Trading Solutions

 


From: openmama-users-bounces@... <openmama-users-bounces@...> on behalf of Macrux <kmacrux@...>
Sent: 30 September 2015 22:39
To: openmama-dev@...; openmama-users@...
Subject: [Openmama-users] Build Mamda Book from Mama Subscription

 

Hi there,

I'm wondering if there is any example in which data received through OpenMAMA is transformed into a Mamda Order book. For example, I have a subcription to Bloomberg through the tick42blp bridge but I need to transform the data received into a Mamda Order Book because I have a client (other program) which works with OpenMamda order books, that's the point.


Thanks in advance for any help you could give about that case.

Regards,

Nestor.


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