Date   

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

jenkins@...
 

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

[noreply] COMMON: Made version string parsing more robust (#247)
	common/c_cpp/src/c/strutils.c
	common/c_cpp/src/gunittest/c/utiltest.cpp


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #126
  • Build Status: Successful
  • Build Warnings: 2
  • Total Amount of Tests: 1775
  • Passed: 1775
  • Failed: 0
  • Skipped / Disabled: 0

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


OpenMAMA_RPM - Build # 515 - Failure!

jenkins@...
 

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

[noreply] Removed gCachedMsg from mamaproducerc_v2
	mama/c_cpp/src/testtools/performance/c/mamaproducerc_v2.c


Results for OpenMAMA_RPM CI run with latest changes:

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

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


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

jenkins@...
 

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

[noreply] Removed gCachedMsg from mamaproducerc_v2
	mama/c_cpp/src/testtools/performance/c/mamaproducerc_v2.c


Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #118
  • Build Status: Successful
  • Build Warnings: 158
  • Total Amount of Tests:
  • Passed:
  • Failed:
  • Skipped / Disabled:

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


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

jenkins@...
 

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

[noreply] Removed gCachedMsg from mamaproducerc_v2
	mama/c_cpp/src/testtools/performance/c/mamaproducerc_v2.c


Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:

  • CI Project Name: OpenMAMA Next Branch with Qpid Proton
  • Build Number: #125
  • Build Status: Successful
  • Build Warnings: 2
  • Total Amount of Tests: 1769
  • Passed: 1769
  • Failed: 0
  • Skipped / Disabled: 0

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


Re: order book price level number of entries

Frank Quinn <fquinn@...>
 

Thanks Dmitri – we’ll await your test case.

 

FRANK QUINN

Principal Engineer - EMEA

Vela Trading Technologies

 

O. +44 289 568 0209 ext. 3592

fquinn@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 27 January 2017 20:49
To: Damian Maguire <damian.j.maguire@...>
Cc: openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] order book price level number of entries

 

Thank you Damian,

I don't want to bring it up just based on the code analysis.

Let's see if I'd be able to come up with a test case that demonstrates different behaviour that is triggered by this logic .

Cheers

Dmitri

 

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

 

On Fri, Jan 27, 2017 at 2:59 AM, Damian Maguire <damian.j.maguire@...> wrote:

Hey Dmitri, 

 

There's probably someone who can clarify better, but I believe the difference is the 'mNumEntries' is the total number of entries which the data feed has reported is part of the book, but which may not necessarily be accessible within the MAMDA Price Level structure (for example, if the feed doesn't supply entry level information for the book we might still report the number of entries, but have nothing we can look at). The 'mNumEntriesTotal' is then the total number of entries which are actually iterable within the same structure. 

 

Looking at the logic in that snippit, I'm not convinced there's not a small issue there (I don't know that we should be setting mNumEntriesTotal as part of this logic) - it might be worth raising a bug in GitHub and someone more familiar with that code might be able to comment. 

 

Cheers, 

 

D

 

On Thu, Jan 26, 2017 at 8:23 PM Dmitri Fedorov <dfedorov.solace@...> wrote:

Hi,

I'm working on a performance issue with the Solace proprietary OpenMAMA bridge processing MAMDA messages and I've come across this:


void MamdaOrderBookPriceLevel::setNumEntries (mama_u32_t  numEntries)
    {
        mImpl.mNumEntries      = numEntries;
        mImpl.mNumEntriesTotal = (mImpl.mEntries ?  mImpl.mEntries->size() : 
                                                        numEntries);
    }

Could someone explain to me please, what's the difference between the "number of entries" and the "total number of entries" in the order book price level, and whe the "total" number of sets it with this condition?

Thank you in advance.

 

Regards,

Dmitri Fedorov

Software Architect

Solace

Ottawa, ON Canada

 

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

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

 


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


Re: is this a valid MAMDA delete message

Frank Quinn <fquinn@...>
 

You trying to delete an order book entry I assume? What sort of undesired MAMDA behaviour? You have a backtrace if a crash results? I can’t see the rest of your book to assess if PL_SIZE=3112200 is valid or not. It may well be OK.

 

Cheers,

Frank

 

FRANK QUINN

Principal Engineer - EMEA

Vela Trading Technologies

 

O. +44 289 568 0209 ext. 3592

fquinn@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 27 January 2017 20:44
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] is this a valid MAMDA delete message

 

Hi all,

Is this a valid MAMDA delete message, please (non-relevant fields removed)?

[PL_ACTION]=MAMDA_BOOK_ACTION_UPDATE

[PL_PRICE]=10.04

[PL_SIZE]=3112200

[PL_NUM_ENTRIES]=5650
[ENTRY_SIDE]=ask
[ENTRY_SIZE]=100
[ENTRY_ACTION]=MAMDA_BOOK_ACTION_DELETE

 

This message gives us an undesired MAMDA  behaviour, what do you think is wrong with it? [PL_SIZE]=3112200?

This message corresponds to the client code as:
           book->deleteEntry(entry, bookTime, NULL);

 

Thank you in advance.

 

Regards,

Dmitri Fedorov

Software Architect

Solace

Ottawa, ON Canada

 

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


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


Re: is this a valid MAMDA update message

Frank Quinn <fquinn@...>
 

Hi Dmitri,

 

Looks like an illegal message to me – it’s trying to add an entry to a price level with zero size.

 

Cheers,

Frank

 

FRANK QUINN

Principal Engineer - EMEA

Vela Trading Technologies

 

O. +44 289 568 0209 ext. 3592

fquinn@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 27 January 2017 20:38
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] is this a valid MAMDA update message

 

Hi all,

Is this a valid MAMDA update message, please (non-relevant fields removed)?

PL_ACTION]=MAMDA_BOOK_ACTION_UPDATE
[PL_PRICE]=10.04

[PL_SIZE]=500

[PL_NUM_ENTRIES]=2
[ENTRY_SIDE]=ask
[ENTRY_SIZE]=0
[ENTRY_ACTION]=MAMDA_BOOK_ACTION_ADD

 

This field value gives us an undesired MAMDA  behaviour:
[ENTRY_SIZE]=0

 

When I assign to non-zero (e.g.  [ENTRY_SIZE]=100) the undesired MAMDA  behaviour disappears.

 

Thank you in advance.


Regards,

Dmitri Fedorov

Software Architect

Solace

Ottawa, ON Canada

 

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


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


Re: discarded data dictionary request

Dmitri Fedorov <dfedorov.solace@...>
 

Thanks Damian,

Yes, referring to the data dictionary file made them working, my bad, I naively trusted to the "bookticker --help" output :-/.
My focus is recap messages and how different order book updates affect it, so I don't want to use capturereplay, the bookpublisher seems to better suited for my case.

Cheers
Dmitri

P.S. For future references, this is the pair that works, it uses non-altered configuration from the OpenMAMA 6.1.0 distribution and a locally run Apache Qpid server:

> bookpublisher -v -SP WOMBAT -m qpid -tport pub -use_dict_file data/data.dict -s book.1 -threads 5
> bookticker -v -m qpid -S WOMBAT -use_dict_file data/data.dict -tport sub -s book.1

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

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

On Tue, Jan 31, 2017 at 1:57 PM, Damian Maguire <dmaguire@...> wrote:

From a really (really) quick glance at the source, I don’t think the BookPublisher code is handling dictionary requests itself. You can probably get ‘bookticker’ to work by using the same ‘-use_dict_file’ command line argument you have used for the publisher. If you’re interested in how to actually handle dictionary requests, the capturereplay example code should demonstrate that pretty well.

 

Cheers,

 

Damian

 

From: <openmama-dev-bounces@lists.openmama.org> on behalf of Dmitri Fedorov <dfedorov.solace@...>
Date: Tuesday, 31 January 2017 at 19:32
To: openmama-dev <openmama-dev@....org>
Subject: [Openmama-dev] discarded data dictionary request

 

Hi all,

I'm testing the QPID bridge with bookpublisher and bookticker, but it seems that the dialog between them is stuck at the data dictionary request.

 

This is the command lines:
> bookpublisher -v -SP WOMBAT -m qpid -tport pub -DT pub -use_dict_file data/data.dict -s book.1 -threads 5
> bookticker -v -m qpid -S WOMBAT -DP sub -tport sub -s book.1

This is what I see at the bookpublisher side:

2017-01-31 13:11:31: (60fb7700) : qpidBridgeMamaTransportImpl_dispatchThread(): discarding uninteresting message for symbol _MDDD.WOMBAT.DATA_DICT

And nothing happens after that.

 

What am I doing wrong, please?

Regards,

Dmitri Fedorov

Software Architect

Solace

Ottawa, ON Canada

 

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


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


Re: discarded data dictionary request

Damian Maguire <dmaguire@...>
 

From a really (really) quick glance at the source, I don’t think the BookPublisher code is handling dictionary requests itself. You can probably get ‘bookticker’ to work by using the same ‘-use_dict_file’ command line argument you have used for the publisher. If you’re interested in how to actually handle dictionary requests, the capturereplay example code should demonstrate that pretty well.

 

Cheers,

 

Damian

 

From: <openmama-dev-bounces@...> on behalf of Dmitri Fedorov <dfedorov.solace@...>
Date: Tuesday, 31 January 2017 at 19:32
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] discarded data dictionary request

 

Hi all,

I'm testing the QPID bridge with bookpublisher and bookticker, but it seems that the dialog between them is stuck at the data dictionary request.

 

This is the command lines:
> bookpublisher -v -SP WOMBAT -m qpid -tport pub -DT pub -use_dict_file data/data.dict -s book.1 -threads 5
> bookticker -v -m qpid -S WOMBAT -DP sub -tport sub -s book.1

This is what I see at the bookpublisher side:

2017-01-31 13:11:31: (60fb7700) : qpidBridgeMamaTransportImpl_dispatchThread(): discarding uninteresting message for symbol _MDDD.WOMBAT.DATA_DICT

And nothing happens after that.

 

What am I doing wrong, please?

Regards,

Dmitri Fedorov

Software Architect

Solace

Ottawa, ON Canada

 

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


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


discarded data dictionary request

Dmitri Fedorov <dfedorov.solace@...>
 

Hi all,

I'm testing the QPID bridge with bookpublisher and bookticker, but it seems that the dialog between them is stuck at the data dictionary request.

This is the command lines:
> bookpublisher -v -SP WOMBAT -m qpid -tport pub -DT pub -use_dict_file data/data.dict -s book.1 -threads 5
> bookticker -v -m qpid -S WOMBAT -DP sub -tport sub -s book.1

This is what I see at the bookpublisher side:

2017-01-31 13:11:31: (60fb7700) : qpidBridgeMamaTransportImpl_dispatchThread(): discarding uninteresting message for symbol _MDDD.WOMBAT.DATA_DICT

And nothing happens after that.

What am I doing wrong, please?

Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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


Re: order book price level number of entries

Dmitri Fedorov <dfedorov.solace@...>
 

Thank you Damian,

I don't want to bring it up just based on the code analysis.

Let's see if I'd be able to come up with a test case that demonstrates different behaviour that is triggered by this logic .

Cheers
Dmitri

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

On Fri, Jan 27, 2017 at 2:59 AM, Damian Maguire <damian.j.maguire@...> wrote:
Hey Dmitri, 

There's probably someone who can clarify better, but I believe the difference is the 'mNumEntries' is the total number of entries which the data feed has reported is part of the book, but which may not necessarily be accessible within the MAMDA Price Level structure (for example, if the feed doesn't supply entry level information for the book we might still report the number of entries, but have nothing we can look at). The 'mNumEntriesTotal' is then the total number of entries which are actually iterable within the same structure. 

Looking at the logic in that snippit, I'm not convinced there's not a small issue there (I don't know that we should be setting mNumEntriesTotal as part of this logic) - it might be worth raising a bug in GitHub and someone more familiar with that code might be able to comment. 

Cheers, 

D

On Thu, Jan 26, 2017 at 8:23 PM Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi,

I'm working on a performance issue with the Solace proprietary OpenMAMA bridge processing MAMDA messages and I've come across this:

void MamdaOrderBookPriceLevel::setNumEntries (mama_u32_t  numEntries)
    {
        mImpl.mNumEntries      = numEntries;
        mImpl.mNumEntriesTotal = (mImpl.mEntries ?  mImpl.mEntries->size() : 
                                                        numEntries);
    }
Could someone explain to me please, what's the difference between the "number of entries" and the "total number of entries" in the order book price level, and whe the "total" number of sets it with this condition?

Thank you in advance.

Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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


is this a valid MAMDA delete message

Dmitri Fedorov <dfedorov.solace@...>
 

Hi all,

Is this a valid MAMDA delete message, please (non-relevant fields removed)?

[PL_ACTION]=MAMDA_BOOK_ACTION_UPDATE

[PL_PRICE]=10.04

[PL_SIZE]=3112200

[PL_NUM_ENTRIES]=5650
[ENTRY_SIDE]=ask
[ENTRY_SIZE]=100
[ENTRY_ACTION]=MAMDA_BOOK_ACTION_DELETE


This message gives us an undesired MAMDA  behaviour, what do you think is wrong with it? [PL_SIZE]=3112200?

This message corresponds to the client code as:
           book->deleteEntry(entry, bookTime, NULL);

Thank you in advance.

Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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


is this a valid MAMDA update message

Dmitri Fedorov <dfedorov.solace@...>
 

Hi all,

Is this a valid MAMDA update message, please (non-relevant fields removed)?

PL_ACTION]=MAMDA_BOOK_ACTION_UPDATE
[PL_PRICE]=10.04

[PL_SIZE]=500

[PL_NUM_ENTRIES]=2
[ENTRY_SIDE]=ask
[ENTRY_SIZE]=0
[ENTRY_ACTION]=MAMDA_BOOK_ACTION_ADD


This field value gives us an undesired MAMDA  behaviour:
[ENTRY_SIZE]=0

When I assign to non-zero (e.g.  [ENTRY_SIZE]=100) the undesired MAMDA  behaviour disappears.

Thank you in advance.

Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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


Re: order book price level number of entries

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

Hey Dmitri, 

There's probably someone who can clarify better, but I believe the difference is the 'mNumEntries' is the total number of entries which the data feed has reported is part of the book, but which may not necessarily be accessible within the MAMDA Price Level structure (for example, if the feed doesn't supply entry level information for the book we might still report the number of entries, but have nothing we can look at). The 'mNumEntriesTotal' is then the total number of entries which are actually iterable within the same structure. 

Looking at the logic in that snippit, I'm not convinced there's not a small issue there (I don't know that we should be setting mNumEntriesTotal as part of this logic) - it might be worth raising a bug in GitHub and someone more familiar with that code might be able to comment. 

Cheers, 

D


On Thu, Jan 26, 2017 at 8:23 PM Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi,

I'm working on a performance issue with the Solace proprietary OpenMAMA bridge processing MAMDA messages and I've come across this:

void MamdaOrderBookPriceLevel::setNumEntries (mama_u32_t  numEntries)
    {
        mImpl.mNumEntries      = numEntries;
        mImpl.mNumEntriesTotal = (mImpl.mEntries ?  mImpl.mEntries->size() : 
                                                        numEntries);
    }
Could someone explain to me please, what's the difference between the "number of entries" and the "total number of entries" in the order book price level, and whe the "total" number of sets it with this condition?

Thank you in advance.

Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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


order book price level number of entries

Dmitri Fedorov <dfedorov.solace@...>
 

Hi,

I'm working on a performance issue with the Solace proprietary OpenMAMA bridge processing MAMDA messages and I've come across this:

void MamdaOrderBookPriceLevel::setNumEntries (mama_u32_t  numEntries)
    {
        mImpl.mNumEntries      = numEntries;
        mImpl.mNumEntriesTotal = (mImpl.mEntries ?  mImpl.mEntries->size() : 
                                                        numEntries);
    }
Could someone explain to me please, what's the difference between the "number of entries" and the "total number of entries" in the order book price level, and whe the "total" number of sets it with this condition?

Thank you in advance.

Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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


Re: RFC for Extended MAMA Date Time

Dmitri Fedorov <dfedorov.solace@...>
 

Look good for Solace.

Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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

On Tue, Dec 13, 2016 at 6:20 AM, Frank Quinn <fquinn@...> wrote:

Hi Folks,

 

I have just opened up a new RFC to cover the upcoming Extended MAMA Date Time functionality. You can find it listed here:

 

https://openmama.github.io/openmama_rfc_open.html

 

Also note that in the interest of making this process completely transparent, I have also created a process document outlining how we review RFCs and guidelines on how to create them going forward:

 

https://openmama.github.io/openmama_rfc_process.html

 

Pay particular attention to the most constructive ways to provide feedback: https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback

 

As per our process, we will leave this RFC open for a period of 2 weeks, after which point if there are no major concerns, the RFC design will be considered approved and work can begin.

 

Cheers,

Frank

 

FRANK QUINN

Principal Engineer, Europe

 

O. +44 289 568 0209 x3592

fquinn@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 


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

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



Re: RFC for Extended MAMA Date Time

Frank Quinn <fquinn.ni@...>
 

Hi Dmitri.

Honestly you should have reviewed it by now. The RFC review period is supposed to be 2 weeks and it has been almost a month now so it remains closed.

In saying that if you want to suggest changes, you're free to follow https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback and it'll be considered on a best-effort basis, but you'll need to be quick as Vela (who are completing this work) may well have started work already according to the current form of the RFC.

Cheers,
Frank


On Mon, 9 Jan 2017, 15:55 Dmitri Fedorov, <dfedorov.solace@...> wrote:
Hi Frank, can I have one more week for that please?


Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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

On Sat, Jan 7, 2017 at 7:51 AM, Frank Quinn <fquinn.ni@...> wrote:
Hi Folks,

As there have been no changes requested for this RFC, I will now consider it closed and approved. Thank you all for your attention in reviewing this.

Cheers,
Frank

On Wed, Dec 14, 2016 at 9:33 AM, Tom Doust <tom.doust@...> wrote:

Returning an error sounds fine to me.

 

 

From: Frank Quinn [mailto:fquinn@...]
Sent: 14 December 2016 09:24
To: Tom Doust <tom.doust@...>; Alpert, Reed <reed.alpert@...>; 'Openmama-dev@...' <Openmama-dev@...>


Subject: RE: RFC for Extended MAMA Date Time

 

Good question… the approach we had planned on taking was to allow accessors to be called and return an error if an extended value was requested via a function which doesn’t support extended values.

 

An argument could certainly be made to implement what you’re talking about and in terms of code, it would be the easiest thing in the world to add, but I think (after some deliberation) we should avoid it because:

 

1.       It makes the application aware of the concept of “Extended” values, which I expect the application developer won’t want to have to consider independently

2.       Whether it’s extended or not is usually irrelevant until you try to read or write to it using certain accessors in which case we have a mechanism already in there in returning an error code (which applications should already be checking)

3.       It would mean introducing a method which would immediately get deprecated in MAMA 7 (as we will revisit the interface at that point to make all interfaces support extended data types)

 

I also have one eye on trying to steer anyone who is depending on extended data types to actually move exclusively towards methods which support extended values and use POSIX mechanisms rather than have conditional statements where they need to maintain two blocks of code – one for extended and one for the old non-extended.

 

Cheers,

Frank

 

From: Tom Doust [mailto:tom.doust@...]
Sent: 14 December 2016 08:56
To: Alpert, Reed <reed.alpert@...>; Frank Quinn <fquinn@...>; 'Openmama-dev@...' <Openmama-dev@...>
Subject: RE: RFC for Extended MAMA Date Time

 

One question, (and I haven’t fully thought this through), is there any need to be able to determine at runtime, given a mamaDateTime object, whether it contains an extended value?

 

Tom

 

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Alpert, Reed via Openmama-dev
Sent: 13 December 2016 22:12
To: Frank Quinn <fquinn@...>; openmama-dev <openmama-dev@...>
Subject: Re: [Openmama-dev] RFC for Extended MAMA Date Time

 

Hi,

 

This looks good for JPMChase, we will be able to support our securities before 1970 and far into the future.

 

Thanks,

 

Reed.

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: Tuesday, December 13, 2016 6:21 AM
To: openmama-dev
Subject: [Openmama-dev] RFC for Extended MAMA Date Time

 

Hi Folks,

 

I have just opened up a new RFC to cover the upcoming Extended MAMA Date Time functionality. You can find it listed here:

 

https://openmama.github.io/openmama_rfc_open.html

 

Also note that in the interest of making this process completely transparent, I have also created a process document outlining how we review RFCs and guidelines on how to create them going forward:

 

https://openmama.github.io/openmama_rfc_process.html

 

Pay particular attention to the most constructive ways to provide feedback: https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback

 

As per our process, we will leave this RFC open for a period of 2 weeks, after which point if there are no major concerns, the RFC design will be considered approved and work can begin.

 

Cheers,

Frank

 

FRANK QUINN

Principal Engineer, Europe

 

O. +44 289 568 0209 x3592

fquinn@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

 


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

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


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


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



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



Re: MAMDA recap message format

Dmitri Fedorov <dfedorov.solace@...>
 

T
​hanks Frank,

The two different recap messages are from the same subscription at different points in time.

I've looked at updates coming it, they don't look like the recap messages at all. None of them has the counter field ​wPlNumEntries ​657 and each always has the ​
​​
wEntryId field 681 as "ask" or "bid" (one of the recap messages has this field removed).

I see wPlNumEntries added and modified in MamdaOrderBookWriter, and ​
​​
wEntryId is used do drive logic in MamdaBookAtomicListener, do we have somewhere an explanation of how these two fields are used in MAMDA?

I'll try to figure out why and how the ​
​​
wEntryId field disappears from the recap message, I suspect this is not right, would you agree?

Cheers
Dmitri


On Sat, Jan 7, 2017 at 7:49 AM, Frank Quinn <fquinn.ni@...> wrote:
Hi Dmitri,

Best place to start would be for the updates coming in. Odds are you'll find these fields are getting populated from the data source containing each delta rather than from within MAMDA itself, or that data types are different in multiple sources causing mixed results or something like that.

Were the two different recap messages you specified from two different subscription or
​​
at different points in time from the same subscription?

Cheers,
Frank

On Thu, Jan 5, 2017 at 7:52 PM, Dmitri Fedorov <dfedorov.solace@...> wrote:
Hi all,

I'm investigating an issue in a Solace proprietary product that uses an instance of MamdaOrderBookListener to keep track of orders and to populate recap messages.

During the investigation I've come across two different formats for recap messages coming from the MamdaOrderBook->populateRecap(MamaMsg& recapMsg) call: one has ask/bid strings and the other does not.

Where should I dig to find out why and how this happens?

In my test case the publisher generates eight price levels (four asks and for bids), and after a few tens of thousand messages, the first recap message format I see is:

[653]=PRICE:10.01
[654]=INT8:65
[655]=UINT32:1014500
[656]=UINT32:0
[657]=UINT16:2257
[658]=DATETIME:2017-01-04 22:55:57.428543
​​
[681]=STRING:ask
[682]=UINT32:500
[683]=INT8:65
}, {

the second:

}, {
[653]=PRICE:10.01
[655]=UINT32:1006400
[656]=UINT32:0
​​
[657]=UINT16:2221
[658]=DATETIME:2017-01-04 22:55:57.440543
[659]=INT16:0
}, {

[657] is the entry count
​​
wPlNumEntries, [681], [682] and [683] are
​​
​​
wEntryId, wEntrySize and wEntryAction, and [659] (that is missing from the first recap message format) is wPlNumAttach.

T
​hank you in advance.​


Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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

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




Re: RFC for Extended MAMA Date Time

Dmitri Fedorov <dfedorov.solace@...>
 

Hi Frank, can I have one more week for that please?


Regards,
Dmitri Fedorov
Software Architect
Solace
Ottawa, ON Canada

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

On Sat, Jan 7, 2017 at 7:51 AM, Frank Quinn <fquinn.ni@...> wrote:
Hi Folks,

As there have been no changes requested for this RFC, I will now consider it closed and approved. Thank you all for your attention in reviewing this.

Cheers,
Frank

On Wed, Dec 14, 2016 at 9:33 AM, Tom Doust <tom.doust@...> wrote:

Returning an error sounds fine to me.

 

 

From: Frank Quinn [mailto:fquinn@...]
Sent: 14 December 2016 09:24
To: Tom Doust <tom.doust@...>; Alpert, Reed <reed.alpert@...>; 'Openmama-dev@...rg' <Openmama-dev@...rg>


Subject: RE: RFC for Extended MAMA Date Time

 

Good question… the approach we had planned on taking was to allow accessors to be called and return an error if an extended value was requested via a function which doesn’t support extended values.

 

An argument could certainly be made to implement what you’re talking about and in terms of code, it would be the easiest thing in the world to add, but I think (after some deliberation) we should avoid it because:

 

1.       It makes the application aware of the concept of “Extended” values, which I expect the application developer won’t want to have to consider independently

2.       Whether it’s extended or not is usually irrelevant until you try to read or write to it using certain accessors in which case we have a mechanism already in there in returning an error code (which applications should already be checking)

3.       It would mean introducing a method which would immediately get deprecated in MAMA 7 (as we will revisit the interface at that point to make all interfaces support extended data types)

 

I also have one eye on trying to steer anyone who is depending on extended data types to actually move exclusively towards methods which support extended values and use POSIX mechanisms rather than have conditional statements where they need to maintain two blocks of code – one for extended and one for the old non-extended.

 

Cheers,

Frank

 

From: Tom Doust [mailto:tom.doust@...]
Sent: 14 December 2016 08:56
To: Alpert, Reed <reed.alpert@...>; Frank Quinn <fquinn@...>; 'Openmama-dev@...rg' <Openmama-dev@...rg>
Subject: RE: RFC for Extended MAMA Date Time

 

One question, (and I haven’t fully thought this through), is there any need to be able to determine at runtime, given a mamaDateTime object, whether it contains an extended value?

 

Tom

 

 

From: openmama-dev-bounces@...nmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Alpert, Reed via Openmama-dev
Sent: 13 December 2016 22:12
To: Frank Quinn <fquinn@...>; openmama-dev <openmama-dev@...rg>
Subject: Re: [Openmama-dev] RFC for Extended MAMA Date Time

 

Hi,

 

This looks good for JPMChase, we will be able to support our securities before 1970 and far into the future.

 

Thanks,

 

Reed.

 

From: openmama-dev-bounces@...nmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Frank Quinn
Sent: Tuesday, December 13, 2016 6:21 AM
To: openmama-dev
Subject: [Openmama-dev] RFC for Extended MAMA Date Time

 

Hi Folks,

 

I have just opened up a new RFC to cover the upcoming Extended MAMA Date Time functionality. You can find it listed here:

 

https://openmama.github.io/openmama_rfc_open.html

 

Also note that in the interest of making this process completely transparent, I have also created a process document outlining how we review RFCs and guidelines on how to create them going forward:

 

https://openmama.github.io/openmama_rfc_process.html

 

Pay particular attention to the most constructive ways to provide feedback: https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback

 

As per our process, we will leave this RFC open for a period of 2 weeks, after which point if there are no major concerns, the RFC design will be considered approved and work can begin.

 

Cheers,

Frank

 

FRANK QUINN

Principal Engineer, Europe

 

O. +44 289 568 0209 x3592

fquinn@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

 


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

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


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


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



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



Re: RFC for Extended MAMA Date Time

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

As there have been no changes requested for this RFC, I will now consider it closed and approved. Thank you all for your attention in reviewing this.

Cheers,
Frank

On Wed, Dec 14, 2016 at 9:33 AM, Tom Doust <tom.doust@...> wrote:

Returning an error sounds fine to me.

 

 

From: Frank Quinn [mailto:fquinn@...]
Sent: 14 December 2016 09:24
To: Tom Doust <tom.doust@...>; Alpert, Reed <reed.alpert@...>; 'Openmama-dev@....org' <Openmama-dev@....org>


Subject: RE: RFC for Extended MAMA Date Time

 

Good question… the approach we had planned on taking was to allow accessors to be called and return an error if an extended value was requested via a function which doesn’t support extended values.

 

An argument could certainly be made to implement what you’re talking about and in terms of code, it would be the easiest thing in the world to add, but I think (after some deliberation) we should avoid it because:

 

1.       It makes the application aware of the concept of “Extended” values, which I expect the application developer won’t want to have to consider independently

2.       Whether it’s extended or not is usually irrelevant until you try to read or write to it using certain accessors in which case we have a mechanism already in there in returning an error code (which applications should already be checking)

3.       It would mean introducing a method which would immediately get deprecated in MAMA 7 (as we will revisit the interface at that point to make all interfaces support extended data types)

 

I also have one eye on trying to steer anyone who is depending on extended data types to actually move exclusively towards methods which support extended values and use POSIX mechanisms rather than have conditional statements where they need to maintain two blocks of code – one for extended and one for the old non-extended.

 

Cheers,

Frank

 

From: Tom Doust [mailto:tom.doust@...]
Sent: 14 December 2016 08:56
To: Alpert, Reed <reed.alpert@...>; Frank Quinn <fquinn@...>; 'Openmama-dev@....org' <Openmama-dev@....org>
Subject: RE: RFC for Extended MAMA Date Time

 

One question, (and I haven’t fully thought this through), is there any need to be able to determine at runtime, given a mamaDateTime object, whether it contains an extended value?

 

Tom

 

 

From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Alpert, Reed via Openmama-dev
Sent: 13 December 2016 22:12
To: Frank Quinn <fquinn@...>; openmama-dev <openmama-dev@....org>
Subject: Re: [Openmama-dev] RFC for Extended MAMA Date Time

 

Hi,

 

This looks good for JPMChase, we will be able to support our securities before 1970 and far into the future.

 

Thanks,

 

Reed.

 

From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Frank Quinn
Sent: Tuesday, December 13, 2016 6:21 AM
To: openmama-dev
Subject: [Openmama-dev] RFC for Extended MAMA Date Time

 

Hi Folks,

 

I have just opened up a new RFC to cover the upcoming Extended MAMA Date Time functionality. You can find it listed here:

 

https://openmama.github.io/openmama_rfc_open.html

 

Also note that in the interest of making this process completely transparent, I have also created a process document outlining how we review RFCs and guidelines on how to create them going forward:

 

https://openmama.github.io/openmama_rfc_process.html

 

Pay particular attention to the most constructive ways to provide feedback: https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback

 

As per our process, we will leave this RFC open for a period of 2 weeks, after which point if there are no major concerns, the RFC design will be considered approved and work can begin.

 

Cheers,

Frank

 

FRANK QUINN

Principal Engineer, Europe

 

O. +44 289 568 0209 x3592

fquinn@...

 

Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD

velatradingtech.com | @vela_tt

 

 

 


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

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


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


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


341 - 360 of 2305