Date   

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

jenkins@...
 

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

[fquinn.ni] BUILD: Fix for RPM build failure
	release_scripts/openmama-rpm.sh


Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #121
  • Build Status: Successful
  • Build Warnings: 157
  • 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!

[fquinn.ni] BUILD: Fix for RPM build failure
	release_scripts/openmama-rpm.sh


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

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

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


OpenMAMA_RPM - Build # 517 - Still Failing!

jenkins@...
 

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

[fquinn.ni] PLAT-773: Extend time range for mamaDateTime structures. C/CPP Changes
	mama/c_cpp/src/c/datetime.c
	mama/c_cpp/src/c/datetimeimpl.h
	mama/c_cpp/src/cpp/datetime.cpp
	mama/c_cpp/src/cpp/mama/MamaDateTime.h
	mama/c_cpp/src/c/mama/datetime.h
	mama/c_cpp/src/c/mama/types.h

[fquinn.ni] PLAT-773: Extend time range for mamaDateTime structures. JAVA/JNI
	mama/jni/src/com/wombat/mama/MamaDateTime.java
	mama/jni/src/c/mamadatetimejni.c

[fquinn.ni] PLAT-773: Extend time range for mamaDateTime structures - Unittests.
	mama/c_cpp/src/gunittest/c/mamadatetime/datetimetest.cpp
	mama/c_cpp/src/gunittest/cpp/MamaDateTimeTest.cpp

[fquinn.ni] PLAT-971: Extend time range for mamaDateTime structures for C#
	mama/c_cpp/src/c/mama/msg.h
	mama/dotnet/src/cs/MamaMsg.cs
	mama/c_cpp/src/c/msg.c

[fquinn.ni] PLAT-971: Junittests for PLAT-773
	mama/jni/src/junittests/MamaDateTimeSetTimeZone.java

[fquinn.ni] OpenMAMA pull request #245 changes
	mama/c_cpp/src/c/datetime.c
	mama/c_cpp/src/cpp/mama/MamaDateTime.h
	mama/c_cpp/src/c/datetimeimpl.h
	mama/jni/src/c/mamadatetimejni.c

[fquinn.ni] Added timespec based implementation for datetimei and updated C# and
	mama/jni/SConscript.win
	mama/jni/src/c/mamadatetimejni.c
	mama/c_cpp/src/c/datetimeimpl.h
	common/c_cpp/src/c/windows/wombat/port.h
	mama/c_cpp/src/c/mama/datetime.h
	mama/c_cpp/src/gunittest/c/mamadatetime/datetimetest.cpp
	mama/jni/src/com/wombat/mama/MamaDateTime.java
	mama/c_cpp/src/c/msg.c
	mama/c_cpp/src/c/datetime.c


Results for OpenMAMA_RPM CI run with latest changes:

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

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


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

jenkins@...
 

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

[fquinn.ni] PLAT-773: Extend time range for mamaDateTime structures. C/CPP Changes
	mama/c_cpp/src/c/mama/datetime.h
	mama/c_cpp/src/cpp/mama/MamaDateTime.h
	mama/c_cpp/src/c/datetime.c
	mama/c_cpp/src/c/mama/types.h
	mama/c_cpp/src/c/datetimeimpl.h
	mama/c_cpp/src/cpp/datetime.cpp

[fquinn.ni] PLAT-773: Extend time range for mamaDateTime structures. JAVA/JNI
	mama/jni/src/com/wombat/mama/MamaDateTime.java
	mama/jni/src/c/mamadatetimejni.c

[fquinn.ni] PLAT-773: Extend time range for mamaDateTime structures - Unittests.
	mama/c_cpp/src/gunittest/c/mamadatetime/datetimetest.cpp
	mama/c_cpp/src/gunittest/cpp/MamaDateTimeTest.cpp

[fquinn.ni] PLAT-971: Extend time range for mamaDateTime structures for C#
	mama/c_cpp/src/c/msg.c
	mama/c_cpp/src/c/mama/msg.h
	mama/dotnet/src/cs/MamaMsg.cs

[fquinn.ni] PLAT-971: Junittests for PLAT-773
	mama/jni/src/junittests/MamaDateTimeSetTimeZone.java

[fquinn.ni] OpenMAMA pull request #245 changes
	mama/c_cpp/src/cpp/mama/MamaDateTime.h
	mama/c_cpp/src/c/datetime.c
	mama/jni/src/c/mamadatetimejni.c
	mama/c_cpp/src/c/datetimeimpl.h

[fquinn.ni] Added timespec based implementation for datetimei and updated C# and JNI
	mama/jni/src/c/mamadatetimejni.c
	mama/c_cpp/src/c/datetime.c
	mama/c_cpp/src/c/datetimeimpl.h
	mama/c_cpp/src/gunittest/c/mamadatetime/datetimetest.cpp
	mama/c_cpp/src/c/mama/datetime.h
	mama/c_cpp/src/c/msg.c
	common/c_cpp/src/c/windows/wombat/port.h
	mama/jni/SConscript.win
	mama/jni/src/com/wombat/mama/MamaDateTime.java


Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #120
  • Build Status: Successful
  • Build Warnings: 157
  • 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!

[fquinn.ni] PLAT-773: Extend time range for mamaDateTime structures. C/CPP Changes
	mama/c_cpp/src/c/datetime.c
	mama/c_cpp/src/cpp/mama/MamaDateTime.h
	mama/c_cpp/src/c/mama/datetime.h
	mama/c_cpp/src/c/mama/types.h
	mama/c_cpp/src/cpp/datetime.cpp
	mama/c_cpp/src/c/datetimeimpl.h

[fquinn.ni] PLAT-773: Extend time range for mamaDateTime structures. JAVA/JNI
	mama/jni/src/c/mamadatetimejni.c
	mama/jni/src/com/wombat/mama/MamaDateTime.java

[fquinn.ni] PLAT-773: Extend time range for mamaDateTime structures - Unittests.
	mama/c_cpp/src/gunittest/c/mamadatetime/datetimetest.cpp
	mama/c_cpp/src/gunittest/cpp/MamaDateTimeTest.cpp

[fquinn.ni] PLAT-971: Extend time range for mamaDateTime structures for C#
	mama/c_cpp/src/c/mama/msg.h
	mama/dotnet/src/cs/MamaMsg.cs
	mama/c_cpp/src/c/msg.c

[fquinn.ni] PLAT-971: Junittests for PLAT-773
	mama/jni/src/junittests/MamaDateTimeSetTimeZone.java

[fquinn.ni] OpenMAMA pull request #245 changes
	mama/jni/src/c/mamadatetimejni.c
	mama/c_cpp/src/cpp/mama/MamaDateTime.h
	mama/c_cpp/src/c/datetimeimpl.h
	mama/c_cpp/src/c/datetime.c

[fquinn.ni] Added timespec based implementation for datetimei and updated C# and
	mama/c_cpp/src/gunittest/c/mamadatetime/datetimetest.cpp
	mama/c_cpp/src/c/datetime.c
	mama/jni/SConscript.win
	mama/c_cpp/src/c/msg.c
	mama/jni/src/c/mamadatetimejni.c
	mama/c_cpp/src/c/datetimeimpl.h
	common/c_cpp/src/c/windows/wombat/port.h
	mama/c_cpp/src/c/mama/datetime.h
	mama/jni/src/com/wombat/mama/MamaDateTime.java


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

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

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


Re: Extended MAMA DateTime Further Modifications

Frank Quinn <fquinn.ni@...>
 

Hi Nigel,

Yes I just completed editing the RFC details with the updated prototypes and updated status: https://openmama.github.io/openmama_rfc_closed.html

Vela also submitted a fresh PR with requested changes implemented which has just been approved so the code has now landed in the next branch.

Cheers,
Frank

On Thu, Feb 16, 2017 at 10:28 AM, Phelan, Nigel via Openmama-dev <openmama-dev@...> wrote:

Looks like the right thing to do, Frank.  Do you intend to revise the RFC in some way to take account of this (in case the previously mentioned payload bridge developers refer to that for a reference with regard to the preferred getter / setter methods)?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Frank Quinn
Sent: Wednesday, February 15, 2017 7:54 PM
To: openmama-dev
Subject: [Openmama-dev] Extended MAMA DateTime Further Modifications

 

Hi Folks,

I tried running the recent extended MAMA Date Time unit tests on windows after some of my suggested changes were made (https://github.com/OpenMAMA/OpenMAMA/pull/245) and got some suspicious errors.

On closer inspection it looks like there is an issue with our original assessment specifically on windows. The RFC revolved around the assumption that windows uses the posix definition of timeval where tv_sec was a time_t and tv_usec was a long, but it turns out that windows has a subtly different definition of timeval where both struct members are in fact long ints... which on windows (both 32 and 64 bit) is in fact 4 bytes. Linux is fine though as are the internal data structures so it's mostly OK but it means the existing timeval based functions will be insufficient for extended ranges on windows.

With that in mind I am going to suggest that a new interface is made available in addition to those in the existing implementation

mama_status
mamaDateTime_setFromStructTimeSpec(const mamaDateTime dateTime,
                                   struct timespec*   inputTimeVal);
 
mama_status
mamaDateTime_getStructTimeSpec(const mamaDateTime dateTime,
                               struct timespec*   result);

They're pretty much identical to the existing timeval based functions but with timespec instead and their implementation should very very straightforward based on what's already there so in terms of code it's a small change.


An explicit definition of timespec can then be defined in port.h for versions of MSVC which don't define it. It'll also mean that we effectively add support in the interface for nanosecond support in case anyone wants to support that too.


Raising it with the list to make everyone aware because these new functions should be the preferred methods for payload bridge developers to use if they want to support extended ranges properly on both windows and linux.

Cheers,

Frank

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email


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



Re: Extended MAMA DateTime Further Modifications

Phelan, Nigel
 

Looks like the right thing to do, Frank.  Do you intend to revise the RFC in some way to take account of this (in case the previously mentioned payload bridge developers refer to that for a reference with regard to the preferred getter / setter methods)?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Frank Quinn
Sent: Wednesday, February 15, 2017 7:54 PM
To: openmama-dev
Subject: [Openmama-dev] Extended MAMA DateTime Further Modifications

 

Hi Folks,

I tried running the recent extended MAMA Date Time unit tests on windows after some of my suggested changes were made (https://github.com/OpenMAMA/OpenMAMA/pull/245) and got some suspicious errors.

On closer inspection it looks like there is an issue with our original assessment specifically on windows. The RFC revolved around the assumption that windows uses the posix definition of timeval where tv_sec was a time_t and tv_usec was a long, but it turns out that windows has a subtly different definition of timeval where both struct members are in fact long ints... which on windows (both 32 and 64 bit) is in fact 4 bytes. Linux is fine though as are the internal data structures so it's mostly OK but it means the existing timeval based functions will be insufficient for extended ranges on windows.

With that in mind I am going to suggest that a new interface is made available in addition to those in the existing implementation

mama_status
mamaDateTime_setFromStructTimeSpec(const mamaDateTime dateTime,
                                   struct timespec*   inputTimeVal);
 
mama_status
mamaDateTime_getStructTimeSpec(const mamaDateTime dateTime,
                               struct timespec*   result);

They're pretty much identical to the existing timeval based functions but with timespec instead and their implementation should very very straightforward based on what's already there so in terms of code it's a small change.


An explicit definition of timespec can then be defined in port.h for versions of MSVC which don't define it. It'll also mean that we effectively add support in the interface for nanosecond support in case anyone wants to support that too.


Raising it with the list to make everyone aware because these new functions should be the preferred methods for payload bridge developers to use if they want to support extended ranges properly on both windows and linux.

Cheers,

Frank

This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email


Extended MAMA DateTime Further Modifications

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

I tried running the recent extended MAMA Date Time unit tests on windows after some of my suggested changes were made (https://github.com/OpenMAMA/OpenMAMA/pull/245) and got some suspicious errors.

On closer inspection it looks like there is an issue with our original assessment specifically on windows. The RFC revolved around the assumption that windows uses the posix definition of timeval where tv_sec was a time_t and tv_usec was a long, but it turns out that windows has a subtly different definition of timeval where both struct members are in fact long ints... which on windows (both 32 and 64 bit) is in fact 4 bytes. Linux is fine though as are the internal data structures so it's mostly OK but it means the existing timeval based functions will be insufficient for extended ranges on windows.

With that in mind I am going to suggest that a new interface is made available in addition to those in the existing implementation
mama_status
mamaDateTime_setFromStructTimeSpec(const mamaDateTime dateTime,
                                   struct timespec*   inputTimeVal);

mama_status
mamaDateTime_getStructTimeSpec(const mamaDateTime dateTime,
                               struct timespec*   result);
They're pretty much identical to the existing timeval based functions but with timespec instead and their implementation should very very straightforward based on what's already there so in terms of code it's a small change.

An explicit definition of timespec can then be defined in port.h for versions of MSVC which don't define it. It'll also mean that we effectively add support in the interface for nanosecond support in case anyone wants to support that too.

Raising it with the list to make everyone aware because these new functions should be the preferred methods for payload bridge developers to use if they want to support extended ranges properly on both windows and linux.

Cheers,
Frank


OpenMAMA_RPM - Build # 516 - Still Failing!

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_RPM CI run with latest changes:

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

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


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

jenkins@...
 

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

[noreply] 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_VS_2015 CI run with latest changes:

  • CI Project Name: OpenMAMA_Next_Branch_VS_2015
  • Build Number: #119
  • 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] 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.