|
Code change(s) just landed on origin/next (Successful)
jenkins@...
Some changes have just been added to the origin/next branch!
[noreply] Added Inno Setup installer script and LICENSE file (#231) release_scripts/setup.iss LICENSE.md release_scripts/setup_info_before.txt release_scripts/openmama.ico release_scripts/setup_info_after.txt
Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:
You may also check CI console output to view the full results.
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Re: Should we make the jump to cmake?
Damian Maguire <dmaguire@...>
- Somehow I managed to drop the mailing list responding to this earlier. Sorry about that.
In an effort to avoid bike-shedding this one, I'll
say nothing more than I think using CMake is a great idea.
(Side Note: Reed, you're correct that OpenMAMA currently
supports OSX as well. CMake integration should make this simpler as well, eliminating the need for the 'Darwin' specific Scons files.)
Cheers,
D
DAMIAN MAGUIRE Senior Sales Engineer
O. +44 289 568 0298 M. +44 783 584 4770 dmaguire@...
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
From: openmama-dev-bounces@... <openmama-dev-bounces@...> on behalf of Alpert, Reed via Openmama-dev <openmama-dev@...>
Sent: 17 October 2016 22:44:47 To: Glenn McClements; Dmitri Fedorov Cc: openmama-dev@... Subject: Re: [Openmama-dev] Should we make the jump to cmake? Hi,
CMake is fine for us, Tick42 uses it now so we have it integrated into our build systems. Most important is making it easy to change a build feature and do it on one place.
Are there other O/S for OpenMAMA – Apple?
Thanks,
Reed.
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Dmitri Fedorov
Hi Glenn
I don't see any advantage of using cmake over autotools and I don't understand why need a cross-platform builds when there are only two of them - Linux and Windows.
Regards, Dmitri Fedorov Software Architect Solace
Solace accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.
On Mon, Oct 17, 2016 at 11:14 AM, Glenn McClements <gmcclements@...> wrote: Sending on behalf of Frank (mail issues):
Hi Folks,
I have been giving quite a bit of consideration recently to making life easier for setting up new development environments for 3 developer types across all languages (particularly targeting windows as a development platform):
· Users of OpenMAMA · Developers of OpenMAMA bridges · OpenMAMA contributors
I found myself getting repeatedly frustrated with the build system. It’s inflexibility makes many things awkward, and I found my options limited because of having to support all of the build systems we have available (particularly handling build directory structures of third party libraries on windows). Today we have scons for linux, scons for windows (yes – they are fairly separate for some reason), and Visual Studio project files for Windows IDE developers so any time you make a change, you really need to consider all 3.
Today in our build infrastructure, we use Scons which is grand, but we already have a lot of things that you have to hack together for scons, but which you actually get out of the box with Cmake like toolchain discovery.
I have started playing with it on a small scale and I think it is a really good fit for OpenMAMA because it:
· Generates project files for you so you don’t need to check them into source control – they’ll all get generated from the same definition files · They have some library discovery mechanisms built in · They have install rules that make sense on both linux and windows · It can be used to generate .msi installer executables in conjunction with Wix (!) · Allows easy integration with external project types (I’m thinking specifically for C# for this one – mono and visual studio both use msbuild) · Takes care of DESTDIR and SONAME functionality which has been requested by package-creators in the past (i.e. for rpm / dpkg) · Single build system would simplify CI by not requiring changes in both scons and visual studio on windows · It has native IDE integration with many platforms and looks like it might even be on its way for Visual Studio
Interestingly, both libevent and qpid proton use cmake, as does almost every other cross-platform C/C++ project that I have stumbled across in the last number of months. With that in mind, I propose that we move our build system to Cmake and end this fun of having to update 3 different built system files every time a new source code file is added.
Any opinions either pro or against are welcome. Also if anyone is key to pitch in with the implementation, please chime in!
Cheers, Frank
GLENN MCCLEMENTS SVP Engineering, Europe
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
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
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Re: Should we make the jump to cmake?
Alpert, Reed <reed.alpert@...>
Hi,
CMake is fine for us, Tick42 uses it now so we have it integrated into our build systems. Most important is making it easy to change a build feature and do it on one place.
Are there other O/S for OpenMAMA – Apple?
Thanks,
Reed.
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Dmitri Fedorov
Sent: Monday, October 17, 2016 12:00 PM To: Glenn McClements Cc: openmama-dev@... Subject: Re: [Openmama-dev] Should we make the jump to cmake?
Hi Glenn
I don't see any advantage of using cmake over autotools and I don't understand why need a cross-platform builds when there are only two of them - Linux and Windows.
Regards, Dmitri Fedorov Software Architect Solace
Solace accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.
On Mon, Oct 17, 2016 at 11:14 AM, Glenn McClements <gmcclements@...> wrote: Sending on behalf of Frank (mail issues):
Hi Folks,
I have been giving quite a bit of consideration recently to making life easier for setting up new development environments for 3 developer types across all languages (particularly targeting windows as a development platform):
· Users of OpenMAMA · Developers of OpenMAMA bridges · OpenMAMA contributors
I found myself getting repeatedly frustrated with the build system. It’s inflexibility makes many things awkward, and I found my options limited because of having to support all of the build systems we have available (particularly handling build directory structures of third party libraries on windows). Today we have scons for linux, scons for windows (yes – they are fairly separate for some reason), and Visual Studio project files for Windows IDE developers so any time you make a change, you really need to consider all 3.
Today in our build infrastructure, we use Scons which is grand, but we already have a lot of things that you have to hack together for scons, but which you actually get out of the box with Cmake like toolchain discovery.
I have started playing with it on a small scale and I think it is a really good fit for OpenMAMA because it:
· Generates project files for you so you don’t need to check them into source control – they’ll all get generated from the same definition files · They have some library discovery mechanisms built in · They have install rules that make sense on both linux and windows · It can be used to generate .msi installer executables in conjunction with Wix (!) · Allows easy integration with external project types (I’m thinking specifically for C# for this one – mono and visual studio both use msbuild) · Takes care of DESTDIR and SONAME functionality which has been requested by package-creators in the past (i.e. for rpm / dpkg) · Single build system would simplify CI by not requiring changes in both scons and visual studio on windows · It has native IDE integration with many platforms and looks like it might even be on its way for Visual Studio
Interestingly, both libevent and qpid proton use cmake, as does almost every other cross-platform C/C++ project that I have stumbled across in the last number of months. With that in mind, I propose that we move our build system to Cmake and end this fun of having to update 3 different built system files every time a new source code file is added.
Any opinions either pro or against are welcome. Also if anyone is key to pitch in with the implementation, please chime in!
Cheers, Frank
GLENN MCCLEMENTS SVP Engineering, Europe
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates (collectively, "JPMC"). This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMC for any loss or damage arising in any way from its use. Please note that any electronic communication that is conducted within or through JPMC's systems is subject to interception, monitoring, review, retention and external production in accordance with JPMC's policy and local laws, rules and regulations; may be stored or otherwise processed in countries other than the country in which you are located; and will be treated in accordance with JPMC policies and applicable laws and regulations. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Re: Should we make the jump to cmake?
Dmitri Fedorov <dfedorov.solace@...>
Hi Glenn My choice is autotools for Linux and MSBuild (VS-project files) on Windows. I don't see any advantage of using cmake over autotools and I don't understand why need a cross-platform builds when there are only two of them - Linux and Windows. Regards, Dmitri Fedorov Software Architect Solace Ottawa, ON Canada Solace accepts no liability for the content of this
email, or for the consequences of any actions taken on the basis of the
information provided, unless that information is subsequently confirmed in
writing. Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Solace Systems.
On Mon, Oct 17, 2016 at 11:14 AM, Glenn McClements <gmcclements@...> wrote:
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Re: Should we make the jump to cmake?
Frank Quinn <fquinn@...>
Apologies that was supposed to have been sent last Friday (and hopefully you can all see this now).
From: Glenn McClements
Sent: 17 October 2016 16:14 To: openmama-dev@... Cc: Frank Quinn <fquinn@...> Subject: Should we make the jump to cmake?
Sending on behalf of Frank (mail issues):
Hi Folks,
I have been giving quite a bit of consideration recently to making life easier for setting up new development environments for 3 developer types across all languages (particularly targeting windows as a development platform):
· Users of OpenMAMA · Developers of OpenMAMA bridges · OpenMAMA contributors
I found myself getting repeatedly frustrated with the build system. It’s inflexibility makes many things awkward, and I found my options limited because of having to support all of the build systems we have available (particularly handling build directory structures of third party libraries on windows). Today we have scons for linux, scons for windows (yes – they are fairly separate for some reason), and Visual Studio project files for Windows IDE developers so any time you make a change, you really need to consider all 3.
Today in our build infrastructure, we use Scons which is grand, but we already have a lot of things that you have to hack together for scons, but which you actually get out of the box with Cmake like toolchain discovery.
I have started playing with it on a small scale and I think it is a really good fit for OpenMAMA because it:
· Generates project files for you so you don’t need to check them into source control – they’ll all get generated from the same definition files · They have some library discovery mechanisms built in · They have install rules that make sense on both linux and windows · It can be used to generate .msi installer executables in conjunction with Wix (!) · Allows easy integration with external project types (I’m thinking specifically for C# for this one – mono and visual studio both use msbuild) · Takes care of DESTDIR and SONAME functionality which has been requested by package-creators in the past (i.e. for rpm / dpkg) · Single build system would simplify CI by not requiring changes in both scons and visual studio on windows · It has native IDE integration with many platforms and looks like it might even be on its way for Visual Studio
Interestingly, both libevent and qpid proton use cmake, as does almost every other cross-platform C/C++ project that I have stumbled across in the last number of months. With that in mind, I propose that we move our build system to Cmake and end this fun of having to update 3 different built system files every time a new source code file is added.
Any opinions either pro or against are welcome. Also if anyone is key to pitch in with the implementation, please chime in!
Cheers, Frank
GLENN MCCLEMENTS SVP Engineering, Europe
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
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Should we make the jump to cmake?
Glenn McClements <gmcclements@...>
Sending on behalf of Frank (mail issues):
Hi Folks,
I have been giving quite a bit of consideration recently to making life easier for setting up new development environments for 3 developer types across all languages (particularly targeting windows as a development platform):
· Users of OpenMAMA · Developers of OpenMAMA bridges · OpenMAMA contributors
I found myself getting repeatedly frustrated with the build system. It’s inflexibility makes many things awkward, and I found my options limited because of having to support all of the build systems we have available (particularly handling build directory structures of third party libraries on windows). Today we have scons for linux, scons for windows (yes – they are fairly separate for some reason), and Visual Studio project files for Windows IDE developers so any time you make a change, you really need to consider all 3.
Today in our build infrastructure, we use Scons which is grand, but we already have a lot of things that you have to hack together for scons, but which you actually get out of the box with Cmake like toolchain discovery.
I have started playing with it on a small scale and I think it is a really good fit for OpenMAMA because it:
· Generates project files for you so you don’t need to check them into source control – they’ll all get generated from the same definition files · They have some library discovery mechanisms built in · They have install rules that make sense on both linux and windows · It can be used to generate .msi installer executables in conjunction with Wix (!) · Allows easy integration with external project types (I’m thinking specifically for C# for this one – mono and visual studio both use msbuild) · Takes care of DESTDIR and SONAME functionality which has been requested by package-creators in the past (i.e. for rpm / dpkg) · Single build system would simplify CI by not requiring changes in both scons and visual studio on windows · It has native IDE integration with many platforms and looks like it might even be on its way for Visual Studio
Interestingly, both libevent and qpid proton use cmake, as does almost every other cross-platform C/C++ project that I have stumbled across in the last number of months. With that in mind, I propose that we move our build system to Cmake and end this fun of having to update 3 different built system files every time a new source code file is added.
Any opinions either pro or against are welcome. Also if anyone is key to pitch in with the implementation, please chime in!
Cheers, Frank
GLENN MCCLEMENTS SVP Engineering, Europe gmcclements@...
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
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Code change(s) just landed on origin/next (Successful)
jenkins@...
Some changes have just been added to the origin/next branch!
[noreply] COMMON: Removed wtimegm implementation for Windows (#224) common/c_cpp/src/gunittest/c/UnitTestCommonC.vcxproj mama/c_cpp/src/gunittest/c/UnitTestMamaC.vcxproj mama/c_cpp/src/gunittest/cpp/UnitTestMamaCPP.vcxproj common/c_cpp/src/c/windows/port.c common/c_cpp/src/c/windows/wombat/port.h mama/c_cpp/src/c/entitlement/noop/noop.vcxproj
Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:
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: Removed wtimegm implementation for Windows (#224) common/c_cpp/src/c/windows/wombat/port.h common/c_cpp/src/gunittest/c/UnitTestCommonC.vcxproj mama/c_cpp/src/c/entitlement/noop/noop.vcxproj mama/c_cpp/src/gunittest/c/UnitTestMamaC.vcxproj common/c_cpp/src/c/windows/port.c mama/c_cpp/src/gunittest/cpp/UnitTestMamaCPP.vcxproj
Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:
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!
[Frank Quinn] Whitespace tidy up across large numbers of files mamda/dotnet/src/cs/MamdaSecurityStatusListener.cs mama/jni/src/junittests/MamaSetLogCallback.java mama/c_cpp/src/cpp/mama/MamaFt.h mamda/dotnet/src/examples/MamdaMultiSecurityTicker/MamdaMultiSecurityTicker.cs mama/dotnet/src/testtools/load/MamaChurn/Properties/Resources.Designer.cs mama/c_cpp/src/cpp/fieldcache/MamaFieldCacheFieldTypes.cpp mama/dotnet/src/cs/MamaSourceState.cs mamda/dotnet/src/examples/MamdaBookChurn/MamdaBookChurn.cs mama/dotnet/SConscript mamda/c_cpp/src/testtools/quoteselftest.cpp mama/dotnet/src/cs/MamaCallbackWrapper.cs mamda/dotnet/src/cs/MamdaTradeFields.cs mama/jni/src/junittests/MamaMsgGetStringAsCharBuffer.java mama/c_cpp/src/cpp/mamacpp.cpp mamda/dotnet/src/cs/Options/MamdaOptionChainListener.cs mamda/dotnet/src/cs/Options/MamdaOptionExpirationDateSet.cs mama/c_cpp/src/c/publisher.c mamda/c_cpp/src/cpp/MamdaSubscription.cpp mamda/dotnet/src/cs/MamdaConcreteTradeRecap.cs mama/c_cpp/src/cpp/MamaDQPublisherManager.cpp mama/c_cpp/src/cpp/mama/MamaSourceManager.h mama/dotnet/src/cs/MAMA.cs mama/c_cpp/src/c/playback/playbackpublisher.c mama/c_cpp/src/examples/cpp/mamaiocpp.cpp mama/jni/src/c/mamasubscriptionjni.c mama/jni/src/com/wombat/mama/MamaQueue.java mamda/c_cpp/src/testtools/bookselftest.cpp mama/c_cpp/src/examples/c/mamaftmemberc.c mama/dotnet/src/examples/MamaFtMember/MamaFtMemberCS.cs mama/c_cpp/src/examples/cpp/mamainboxcpp.cpp mamda/dotnet/src/cs/OrderBook/MamdaOrderBookEntry.cs mama/c_cpp/src/c/msg.c mama/c_cpp/src/c/mama/fieldcache/fieldcache.h mamda/dotnet/src/cs/MamdaConcreteOrderImbalanceRecap.cs mama/dotnet/src/cs/NullableTypes/NullableLong.cs mamda/dotnet/src/cs/MamdaSecurityStatusUpdate.cs mama/c_cpp/src/cpp/mama/mamacpp.h mamda/c_cpp/src/examples/SConscript.win mamda/dotnet/src/cs/OrderBook/MamdaOrderBookCheckerHandler.cs mama/jni/src/junittests/MamaMsgTryMethods.java mamda/dotnet/src/examples/MamdaBookTicker/MamdaBookTicker.cs mama/dotnet/src/cs/MamaLogFileCallback2.cs mamda/dotnet/src/cs/MamdaConcreteQuoteRecap.cs mamda/dotnet/src/cs/MamdaDataException.cs mama/c_cpp/src/c/bridge.h mamda/dotnet/src/cs/MamdaConcreteSecurityStatusRecap.cs mama/c_cpp/src/cpp/MamaBasicSubscription.cpp mama/c_cpp/src/cpp/MamaStatsCollector.cpp mama/dotnet/src/cs/MamaSource.cs mama/dotnet/SConscript.win mamda/dotnet/src/cs/MamdaQuoteRecap.cs mama/c_cpp/src/cpp/mama/MamaLogFile.h mama/dotnet/src/cs/MamaSourceGroupManager.cs mamda/dotnet/src/examples/MamdaMultiPartTicker/MamdaMultiPartTicker.cs mamda/dotnet/src/examples/MamdaListen/MamdaListen.cs mama/c_cpp/src/examples/c/mamasubscriberc.c mamda/c_cpp/src/cpp/mamda/MamdaAuctionHandler.h mama/dotnet/src/examples/MamaIo/MamaIoCS.cs mama/dotnet/src/cs/MamaDictionary.cs mama/c_cpp/src/c/transportimpl.h mama/c_cpp/src/cpp/MamaFt.cpp mama/jni/src/junittests/MamaTimerCallbacks.java mamda/c_cpp/src/cpp/MamdaTradeExecVenue.cpp mamda/c_cpp/src/cpp/MamdaAuctionListener.cpp mama/dotnet/src/cs/MamaQueueMonitorCallback.cs mamda/c_cpp/src/cpp/SConscript mama/dotnet/src/cs/MamaSymbolMapCallback.cs mama/c_cpp/src/cpp/mama/MamaStatsCollector.h mamda/dotnet/src/cs/MamdaOrderImbalanceRecap.cs mamda/dotnet/src/examples/MamdaExamplesCommon/ComboTicker.cs mama/dotnet/src/cs/MamaWrapper.cs mama/jni/src/c/mamaqueuejni.c mamda/dotnet/src/cs/MamdaQuoteUpdate.cs mama/c_cpp/src/c/msgimpl.h mama/dotnet/src/cs/MamaTransport.cs mamda/c_cpp/src/gunittest/SConscript mama/dotnet/src/cs/MamaMsg.cs mama/dotnet/src/cs/MamaFieldDescriptor.cs mamda/dotnet/src/cs/Options/MamdaOptionChain.cs mama/c_cpp/src/c/transport.c mama/dotnet/src/cs/MamaReservedFields.cs mamda/dotnet/src/cs/MamdaBasicEvent.cs mamda/dotnet/src/cs/Containers/RedBlackTree.cs mama/c_cpp/src/cpp/mama/fieldcache/MamaFieldCacheField.h mama/dotnet/src/cs/MamaException.cs mama/dotnet/src/nunittest/MamaMsgVectorMsgTest.cs mamda/c_cpp/src/examples/quoteticker.cpp mama/c_cpp/src/c/mama/publisher.h mama/c_cpp/src/testtools/performance/c/mamaproducerc_v2.c mamda/dotnet/src/cs/MamdaQuoteListener.cs mamda/dotnet/src/cs/MamdaTradeGap.cs mamda/dotnet/src/cs/MamdaMultiParticipantHandler.cs mamda/dotnet/src/examples/MamdaOptionChainExample/MamdaOptionChainExample.cs mamda/dotnet/src/examples/MamdaExamplesCommon/CommandLineProcessor.cs mama/jni/src/com/wombat/mama/MamaMsg.java mamda/c_cpp/src/cpp/mamda/MamdaSecStatusRecap.h mama/dotnet/src/cs/MamaQueueEventCallback.cs mama/jni/src/c/mamapublisherjni.c mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookListener.cpp mama/dotnet/src/cs/MamaTimer.cs mamda/c_cpp/src/cpp/MamdaOrderImbalanceType.cpp mama/c_cpp/src/cpp/mama/MamaTransport.h mama/dotnet/src/examples/MamaInbox/MamaInboxCS.cs mama/dotnet/src/cs/MamaBasicSubscriptionCallback.cs mama/c_cpp/src/c/mama/fieldcache/fieldcacheiterator.h mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceUpdate.h mama/dotnet/src/cs/MamaPayloadBridge.cs mama/dotnet/src/examples/MamaMultiSubscriber/MamaMultiSubscriberCS.cs mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceListener.h mama/c_cpp/src/cpp/mama/fieldcache/MamaFieldCacheRecord.h mama/dotnet/src/cs/MamaSourceGroup.cs mamda/dotnet/src/cs/MamdaTradeClosing.cs mama/c_cpp/src/examples/cpp/mamaftmembercpp.cpp mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBook.cpp mama/c_cpp/src/c/entitlement/noop/noop.c mamda/dotnet/src/cs/Containers/TreeMap.cs mama/jni/src/junittests/MamaMsgGetByteBuffer.java mamda/dotnet/src/cs/MamdaMultiSecurityManager.cs mama/jni/src/c/mamadqpublishermanagerjni.c mama/c_cpp/src/cpp/fieldcache/MamaFieldCacheField.cpp mamda/dotnet/src/cs/MamdaAuctionRecap.cs common/c_cpp/src/c/wombat/strutils.h mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookPriceLevel.cpp mama/jni/src/com/wombat/mama/MamaDQPublisherManager.java mama/dotnet/src/cs/MamaBasicSubscription.cs mamda/c_cpp/src/cpp/MamdaUtils.cpp mamda/c_cpp/src/cpp/news/SConscript mamda/dotnet/src/cs/MamdaOrderImbalanceHandler.cs mamda/dotnet/src/cs/Containers/TreeSet.cs mamda/c_cpp/src/cpp/MamdaFundamentalListener.cpp mamda/c_cpp/src/cpp/MamdaOrderImbalanceFields.cpp mama/dotnet/src/cs/MamaIo.cs mama/c_cpp/src/c/playback/playbackpublisher.h mama/c_cpp/src/examples/c/plugin/SConscript mamda/dotnet/src/cs/OrderBook/MamdaOrderBookChecker.cs mama/c_cpp/src/regression/c_cpp/tools/Makefile.sample mama/c_cpp/src/cpp/mama/MamaSourceGroupManager.h mama/c_cpp/src/cpp/MamaTransport.cpp mama/dotnet/src/cs/MamaSymbolMapFile.cs mama/jni/src/com/wombat/mama/examples/MamaSubscriberJava.java mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceRecap.h mama/c_cpp/src/examples/cpp/mamasymbollistsubscribercpp.cpp mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceSide.h mama/dotnet/src/cs/MamaTimerCallback.cs mamda/c_cpp/src/cpp/options/MamdaOptionChain.cpp mama/jni/src/c/mamadqpublisherjni.c mamda/dotnet/src/cs/MamdaFields.cs mama/c_cpp/src/c/mama/stat.h mama/c_cpp/src/examples/cpp/mamalistencpp.cpp mamda/dotnet/src/examples/MamdaComboTicker/MamdaComboTicker.cs mama/c_cpp/src/testtools/capturereplay/c/capturec.c mama/c_cpp/src/c/mama/msgtype.h mama/c_cpp/src/c/mama/datetime.h mamda/c_cpp/src/examples/parsecmd.h mama/c_cpp/src/c/dictionary.c mama/dotnet/src/cs/MamaTransportCallback.cs mamda/dotnet/src/cs/MamdaOrderImbalanceType.cs mama/dotnet/src/cs/MamaBridge.cs mama/c_cpp/src/c/middleware.c mamda/c_cpp/src/gunittest/orderbooks/Makefile.am mama/c_cpp/src/c/playback/playbackFileParser.c mama/c_cpp/src/cpp/SConscript mama/c_cpp/src/cpp/mama/fieldcache/MamaFieldCache.h mamda/dotnet/src/cs/Options/MamdaOptionChainView.cs mama/c_cpp/src/c/queueimpl.h mamda/c_cpp/src/gunittest/trades/Makefile.am mama/jni/src/c/mamabasicsubscriptionjni.c mama/c_cpp/src/c/mama/fieldcache/fieldcachefield.h mamda/c_cpp/src/cpp/MamdaOrderImbalanceListener.cpp mamda/c_cpp/src/cpp/mamda/MamdaAuctionListener.h mama/dotnet/src/cs/MamaQueueGroup.cs mama/jni/src/junittests/Main.java mamda/dotnet/src/cs/MamdaOrderImbalanceListener.cs mamda/c_cpp/src/cpp/mamda/MamdaFieldState.h mama/c_cpp/src/c/mama/msg.h mama/c_cpp/src/c/statsloggerfields.c mama/jni/src/com/wombat/mama/examples/MamaPublisherJava.java mamda/dotnet/src/cs/MamdaQuoteFields.cs mama/jni/src/c/subscriptioncommon.c mama/jni/src/com/wombat/mama/MamaMdDataType.java mamda/dotnet/src/cs/Containers/Iterable.cs mama/dotnet/src/cs/NullableTypes/NullableBool.cs mama/c_cpp/src/c/msgtype.c mamda/dotnet/src/cs/MamdaFundamentalFields.cs mamda/dotnet/src/cs/MamdaSecurityStatusFields.cs mama/jni/src/junittests/MamaInboxCallbacks.java mamda/dotnet/src/cs/OrderBook/MamdaOrderBook.cs mamda/dotnet/src/cs/MamdaSecurityStatusRecap.cs mamda/java/com/wombat/mamda/MamdaSecurityStatusQual.java mama/c_cpp/src/c/mama/transport.h mama/c_cpp/src/c/mama/dictionary.h mama/jni/src/com/wombat/mama/examples/MamaListen.java mamda/dotnet/src/cs/MamdaTradeCancelOrError.cs mama/dotnet/src/examples/MamaListen/MamaListenCS.cs mama/jni/src/c/mamajni.c mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceFields.h mama/c_cpp/src/c/statsgenerator.c mama/c_cpp/src/cpp/fieldcache/MamaFieldCacheRecord.cpp mamda/dotnet/src/cs/MamdaTradeSide.cs mamda/dotnet/src/cs/OrderBook/MamdaOrderBookPriceLevel.cs mama/c_cpp/src/c/fieldcache/fieldcachefield.c mamda/dotnet/src/cs/MamdaQuoteGap.cs mamda/c_cpp/src/cpp/options/MamdaOptionContract.cpp mama/jni/src/com/wombat/mama/MamaDateTime.java mama/c_cpp/src/cpp/MamaSymbolList.cpp mamda/c_cpp/src/cpp/orderbooks/MamdaQuoteToBookListener.cpp mamda/c_cpp/src/cpp/MamdaMultiParticipantManager.cpp mama/c_cpp/src/examples/cpp/mamamsgpublishercpp.cpp mama/c_cpp/src/c/mama/mama.h mama/c_cpp/src/testtools/performance/c/mamaconsumerc_v2.c mama/dotnet/src/cs/MamaSubscriptionCallback.cs mama/dotnet/src/cs/MamaFtMember.cs mama/c_cpp/src/cpp/mama/MamaPublisher.h mama/c_cpp/src/c/mama/io.h mamda/c_cpp/src/testtools/tradeselftest.cpp mamda/dotnet/src/cs/MamdaTradeCorrection.cs mama/dotnet/src/cs/MamaSourceStateChangeCallback.cs mamda/dotnet/src/cs/MamdaCommonFields.cs mama/jni/src/c/mamamsgjni.c mama/jni/src/junittests/MamaDateTimeSetTimeZone.java mama/c_cpp/src/cpp/mama/MamaMsg.h mamda/dotnet/src/cs/MamdaQuoteHandler.cs mama/jni/src/com/wombat/mama/MamaDQPublisher.java mama/c_cpp/src/c/mama/ft.h mama/dotnet/src/cs/NullableTypes/NullableInt.cs mamda/c_cpp/src/cpp/mamda/MamdaUncrossPriceInd.h mama/c_cpp/src/c/mama/status.h mamda/dotnet/src/cs/MamdaFundamentals.cs mamda/dotnet/src/cs/Options/MamdaOptionUnderlying.cs mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookWriter.h mama/jni/src/junittests/MamaMsgAddArrayMsgWithLength.java mamda/dotnet/src/cs/Containers/HashMap.cs mama/jni/src/com/wombat/mama/MamaBasicWildCardSubscriptionCallback.java mama/dotnet/src/cs/MamaQueue.cs mamda/c_cpp/src/cpp/mamda/MamdaAuctionRecap.h mamda/c_cpp/src/gunittest/quotes/Makefile.am mama/c_cpp/src/cpp/MamaPublisher.cpp mama/c_cpp/src/cpp/fieldcache/MamaFieldCache.cpp mama/c_cpp/src/testtools/load/cpp/mamachurn.h mama/jni/src/junittests/MamaPriceGetRoundedPrice.java mama/c_cpp/src/c/dqpublisher.c mama/jni/src/c/mamaftmemberjni.c mama/jni/src/c/mamajniutils.c mama/jni/src/com/wombat/mama/MamaSource.java mamda/dotnet/src/cs/MamdaOrderImbalanceSide.cs mamda/dotnet/src/cs/Options/MamdaOptionContractSet.cs mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp mama/c_cpp/src/testtools/load/cpp/SConscript.win mama/c_cpp/src/testtools/performance/cpp/mamapingpong_replycpp.cpp mama/jni/src/c/mamajniutils.h mama/c_cpp/src/cpp/version.rc mama/jni/src/com/wombat/mama/MamaPublisher.java mama/dotnet/src/cs/MamaCallbackStore.cs mamda/c_cpp/src/cpp/MamdaSecStatusListener.cpp mama/c_cpp/src/c/mama/statsloggerfields.h mama/c_cpp/src/cpp/mama/MamaBridgeCallback.h mama/jni/src/com/wombat/mama/MamaSubscription.java mama/jni/src/com/wombat/mama/MamaTransport.java mamda/c_cpp/src/cpp/mamda/MamdaSecurityStatusQual.h mama/c_cpp/src/cpp/mama/fieldcache/MamaFieldCacheFieldTypes.h mama/dotnet/src/cs/MamaInboxCallback.cs mama/jni/src/c/mamainboxjni.c mama/c_cpp/src/c/mama/dqpublisher.h mamda/c_cpp/src/cpp/orderbooks/MamdaBookAtomicListener.cpp mama/c_cpp/src/testtools/performance/cpp/Makefile.am mama/dotnet/src/cs/MamaFtMemberCallback.cs mamda/dotnet/src/cs/MamdaTradeListener.cs mama/c_cpp/src/c/status.c mamda/c_cpp/src/cpp/options/SConscript mama/dotnet/src/examples/MamaSubscriber/MamaSubscriberCS.cs mamda/c_cpp/src/cpp/MamdaLock.cpp mama/dotnet/src/cs/MamaStatus.cs mamda/dotnet/src/cs/MamdaOrderImbalanceFields.cs mama/c_cpp/src/examples/cpp/mamaproxycpp.cpp mamda/dotnet/src/cs/MamdaBasicRecap.cs mamda/dotnet/src/cs/MamdaAuctionUpdate.cs mama/c_cpp/src/c/reservedfields.c mama/dotnet/src/cs/MamaSendCompleteCallback.cs mamda/c_cpp/src/cpp/MamdaErrorCode.h mama/jni/src/junittests/MamaOpenClose.java mamda/c_cpp/src/cpp/mamda/MamdaAuctionUpdate.h mama/dotnet/src/cs/MamaIoType.cs mama/jni/src/c/mamadatetimejni.c mamda/c_cpp/src/cpp/orderbooks/mamda/MamdaOrderBookDepthFilter.h mamda/dotnet/src/cs/Options/MamdaOptionContract.cs mamda/c_cpp/src/examples/tradeticker.cpp mama/c_cpp/src/examples/cpp/mamasubscribercpp.cpp mama/c_cpp/src/testtools/load/c/Makefile.am mamda/dotnet/src/cs/OrderBook/MamdaOrderBookFields.cs mama/c_cpp/src/examples/cpp/SConscript.win mama/c_cpp/src/c/msgfield.c mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceHandler.h mamda/dotnet/src/cs/MamdaFundamentalHandler.cs mama/jni/src/c/SConscript mamda/dotnet/src/cs/MamdaQuoteClosing.cs mama/jni/src/c/mamatransportjni.c mamda/dotnet/src/examples/MamdaOptionChainViewExample/MamdaOptionChainViewExample.cs mama/jni/src/c/mamapayloadbridgejni.c mamda/dotnet/src/cs/Options/MamdaOptionChainHandler.cs mama/dotnet/src/cs/MamaInbox.cs mamda/c_cpp/src/examples/Makefile.sample mamda/c_cpp/src/gunittest/secstatus/Makefile.am mamda/dotnet/src/examples/MamdaExamplesCommon/UnderlyingTicker.cs mamda/dotnet/src/cs/MamdaFundamentalListener.cs mamda/c_cpp/src/cpp/MamdaUncrossPriceInd.cpp mamda/c_cpp/doxyconfig-cpp.in mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookBasicDeltaList.cpp mamda/c_cpp/src/gunittest/orderImbalances/Makefile.am mama/c_cpp/src/c/dqpublishermanager.c mama/c_cpp/src/cpp/MamaPublisherImpl.h mamda/c_cpp/src/examples/parsecmd.cpp mamda/dotnet/src/cs/MamdaSecurityStatusQual.cs mama/jni/src/com/wombat/mama/MamaBasicSubscription.java mamda/c_cpp/src/cpp/MamdaTradeSide.cpp mamda/c_cpp/src/cpp/mamda/MamdaFundamentals.h mamda/dotnet/src/cs/MamdaTradeRecap.cs mama/c_cpp/src/c/mama/timezone.h mama/c_cpp/src/testtools/load/cpp/Makefile.am mama/dotnet/src/nunittest/MamaEnqueueEventTest.cs mamda/c_cpp/src/cpp/MamdaQuery.cpp mama/c_cpp/src/cpp/MamaSubscription.cpp mama/dotnet/src/cs/MamaSubscription.cs mama/c_cpp/src/examples/cpp/mamalistencachedcpp.cpp mamda/c_cpp/src/testtools/Makefile.am mamda/dotnet/src/cs/MamdaTradeReport.cs mama/jni/src/com/wombat/mama/MamaPayloadType.java mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c mamda/dotnet/src/cs/OrderBook/MamdaOrderBookListener.cs mama/c_cpp/src/examples/c/mamalistencachedc.c mama/c_cpp/src/gunittest/c/middleware/middlewareQueueTests.cpp mama/jni/src/com/wombat/mama/MamaQueueGroup.java mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceType.h mama/c_cpp/src/c/mamac.vcxproj mama/c_cpp/src/c/symbollist.c mama/c_cpp/src/cpp/MamaQueue.cpp mama/c_cpp/src/cpp/mama/MamaBasicSubscription.h mama/c_cpp/src/examples/c/SConscript.win mamda/dotnet/src/cs/Containers/Helpers.cs mama/c_cpp/src/c/datetime.c mama/jni/src/junittests/MamaPublisherTest.java mama/dotnet/src/cs/MamaMsgField.cs mamda/dotnet/src/cs/MamdaTradeHandler.cs mama/c_cpp/src/c/mama/price.h mama/dotnet/src/testtools/load/MamaChurn/MamaChurnCS.cs mama/c_cpp/src/c/mama/fielddesc.h mama/c_cpp/src/cpp/mama/MamaSourceGroup.h mama/c_cpp/src/testtools/capturereplay/c/captureconvert.c mamda/dotnet/src/cs/MamdaMultiParticipantManager.cs mama/dotnet/src/cs/MamaPublisher.cs mama/jni/src/junittests/MamaMsgVectorFields.java mama/c_cpp/src/c/mama/subscription.h mama/c_cpp/src/testtools/load/cpp/mamachurncpp.cpp mamda/c_cpp/src/cpp/mamda/MamdaTradeExecVenue.h mamda/dotnet/src/cs/MamdaSubscription.cs mama/jni/src/c/mamapricejni.c mama/dotnet/src/cs/MamaQueueEnqueueCallback.cs mama/c_cpp/src/c/dqstrategy.c [Frank Quinn] Removed legacy autotools framework entirely common/c_cpp/Makefile.am common/c_cpp/configure.ac mamda/c_cpp/src/gunittest/Makefile.am mama/c_cpp/src/gunittest/c/middleware/Makefile.am mamda/c_cpp/src/gunittest/trades/Makefile.am mama/c_cpp/src/testtools/capturereplay/Makefile.am common/c_cpp/src/c/Makefile.am common/c_cpp/src/gunittest/Makefile.am mama/c_cpp/src/c/payload/qpidmsg/Makefile.am mama/c_cpp/src/c/payload/Makefile.am mama/c_cpp/Makefile.am mama/c_cpp/src/gunittest/c/mamaprice/Makefile.am mama/c_cpp/src/examples/c/Makefile.am mama/c_cpp/src/testtools/performance/cpp/Makefile.am mama/c_cpp/src/examples/cpp/Makefile.am mama/c_cpp/src/testtools/performance/Makefile.am mamda/c_cpp/src/cpp/orderbooks/Makefile.am mama/c_cpp/src/examples/Makefile.am mama/c_cpp/configure.ac mamda/c_cpp/src/examples/news/Makefile.am mamda/c_cpp/src/gunittest/orderbooks/Makefile.am mama/c_cpp/src/c/bridge/qpid/Makefile.am mamda/c_cpp/src/examples/orderbooks/test/Makefile.am mamda/c_cpp/src/examples/orderbooks/Makefile.am common/c_cpp/src/gunittest/c/Makefile.am mama/c_cpp/src/gunittest/c/Makefile.am mama/c_cpp/src/gunittest/c/mamamsg/Makefile.am common/c_cpp/src/Makefile.am mamda/c_cpp/src/Makefile.am mama/c_cpp/src/testtools/load/cpp/Makefile.am mama/c_cpp/src/gunittest/cpp/Makefile.am mama/c_cpp/src/gunittest/cpp/fieldcache/Makefile.am mama/jni/src/Makefile.am mama/c_cpp/src/c/Makefile.am mama/c_cpp/src/testtools/Makefile.am mama/c_cpp/src/c/bridge/Makefile.am mama/c_cpp/src/gunittest/c/fieldcache/Makefile.am mama/jni/Makefile.am mama/c_cpp/src/Makefile.am mamda/c_cpp/configure.ac mamda/c_cpp/src/cpp/options/Makefile.am mamda/c_cpp/src/gunittest/quotes/Makefile.am mamda/c_cpp/src/cpp/news/Makefile.am mama/c_cpp/src/gunittest/Makefile.am mamda/c_cpp/src/examples/Makefile.am mamda/c_cpp/src/gunittest/secstatus/Makefile.am mama/c_cpp/src/cpp/Makefile.am mamda/c_cpp/src/testtools/Makefile.am common/c_cpp/src/cpp/Makefile.am mama/c_cpp/src/gunittest/c/mamadatetime/Makefile.am mama/jni/src/c/Makefile.am mama/c_cpp/src/testtools/capturereplay/c/Makefile.am mama/c_cpp/src/gunittest/c/payload/Makefile.am mama/c_cpp/src/testtools/performance/c/Makefile.am mama/jni/configure.ac mama/c_cpp/src/testtools/load/c/Makefile.am mama/c_cpp/src/testtools/load/Makefile.am mamda/c_cpp/src/gunittest/orderImbalances/Makefile.am mamda/c_cpp/Makefile.am mamda/c_cpp/src/cpp/Makefile.am [Frank Quinn] PLAT-294: Named threads support (updated) common/c_cpp/src/c/thread.c common/c_cpp/src/c/windows/wombat/port.h common/c_cpp/src/c/windows/port.c common/c_cpp/src/c/wombat/thread.h mama/c_cpp/src/c/mama.c common/c_cpp/src/c/linux/port.h mama/c_cpp/src/c/queue.c [Frank Quinn] PLAT-719: Changed error handling when trying to apply thread mama/c_cpp/src/c/mama.c mama/c_cpp/src/c/queue.c [Frank Quinn] MAMA: Enable unified logging in external components. mama/c_cpp/src/c/log.c mama/c_cpp/src/c/mama/log.h [Frank Quinn] Issue: Mama-5329 Submitted by: Adrienne Ambrose Reviewed by: Ian common/c_cpp/src/gunittest/c/queuetest.cpp [Frank Quinn] Allow point to point message to be intercepted based on DQ mama/c_cpp/src/c/listenermsgcallback.c [Frank Quinn] Modifications to correct vela build system failures mama/c_cpp/src/c/SConscript.win mama/c_cpp/src/c/entitlement/oea/oea.h mama/c_cpp/src/c/entitlement/oea/oea.c mama/c_cpp/src/c/SConscript mama/dotnet/src/cs/mamadotnet.csproj mama/c_cpp/src/c/mama.c mama/c_cpp/src/c/generateMamaSourceFiles.bat mama/c_cpp/src/c/mamainternal.h common/c_cpp/src/c/windows/wombat/wConfig.h [Frank Quinn] MAMA-5420: Cleared up all possible warnings from Products.mamac mama/c_cpp/src/c/subscriptionimpl.h [Frank Quinn] Issue: Mamda-1944 Submitted by: Adrienne Ambrose Reviewed by: Ian mamda/c_cpp/src/examples/auctionticker.cpp mamda/c_cpp/src/examples/orderbooks/test/bookselftest.cpp mamda/c_cpp/src/examples/orderbooks/atomicbookbuilder.cpp mamda/c_cpp/src/examples/orderbooks/test/bookiters.cpp mamda/c_cpp/src/examples/multisecurityticker.cpp mamda/c_cpp/src/examples/comboticker.cpp mamda/c_cpp/src/examples/orderbooks/bookpublisher.cpp mamda/c_cpp/src/examples/orderbooks/atomicbookticker.cpp mamda/c_cpp/src/examples/currencyticker.cpp mamda/c_cpp/src/examples/mamdapublisher.cpp mamda/c_cpp/src/examples/orderbooks/bookviewer.cpp mamda/c_cpp/src/examples/orderbooks/listenerBookPublisher.cpp mamda/c_cpp/src/examples/orderimbalanceticker.cpp mamda/c_cpp/src/examples/orderbooks/bookticker.cpp mamda/c_cpp/src/examples/fundamentallisten.cpp mamda/c_cpp/src/examples/optionview.cpp mamda/c_cpp/src/examples/optionchainer.cpp mamda/c_cpp/src/examples/orderbooks/bookchurn.cpp mamda/c_cpp/src/examples/mamdalisten.cpp mamda/c_cpp/src/examples/news/newsticker.cpp mamda/c_cpp/src/examples/orderbooks/test/randomaccess.cpp mamda/c_cpp/src/examples/multipartticker.cpp mamda/c_cpp/src/examples/secstatuslisten.cpp [Frank Quinn] PLAT-526: Added Lock C++ header for lockable types common/c_cpp/src/cpp/wombat/Lock.h [Frank Quinn] Reverted duplicate loading of entitlement bridge mama/c_cpp/src/c/mama.c [Frank Quinn] Merge fix from api_rel_6_0_1 to api_rel_6_0_0 mama/c_cpp/src/c/listenermsgcallback.c [Frank Quinn] [PLAT-383] - Additional NULL check before string.h function calls mama/c_cpp/src/c/subscription.c [Frank Quinn] Fixing build error caused by RC versions. mama/c_cpp/src/c/mamainternal.h mama/c_cpp/SConscript [Frank Quinn] MAMA-5842 Corrected initialisation of ttl and service FT parameters mama/c_cpp/src/c/ft.c [Frank Quinn] Correcting Windows build issues. mama/c_cpp/src/c/subscription.c [Frank Quinn] PLAT-620: Loading all default payloads for each middleware in mama/c_cpp/src/c/mama.c [Frank Quinn] Cleaned up trailing whitespace across source code files mama/dotnet/src/examples/MamaSubscriber/MamaSubscriberCS.csproj mama/c_cpp/src/examples/cpp/mamaproxycpp.cpp mamda/java/com/wombat/mamda/MamdaSecurityStatusListener.java mama/c_cpp/src/c/msgfield.c mamda/c_cpp/src/examples/multipartticker.cpp mamda/dotnet/src/examples/MamdaAuctionTicker/MamdaAuctionTickerCS.csproj mamda/c_cpp/src/cpp/generateMamdaVersion.bat mama/c_cpp/src/cpp/MamaMsg.cpp mamda/dotnet/src/examples/MamdaBookTicker/MamdaBookTickerCS.csproj common/c_cpp/src/c/commonc.vcxproj mama/dotnet/src/examples/MamaInbox/MamaInboxCS.csproj mama/dotnet/src/examples/MamaMultiSubscriber/MamaMultiSubscriberCS.csproj mama/dotnet/src/cs/mamadotnet.csproj mamda/c_cpp/src/examples/mamdapublisher.cpp mamda/dotnet/src/examples/MamdaBookChurn/MamdaBookChurnCS.csproj mamda/c_cpp/src/examples/orderbooks/bookviewer.cpp mama/c_cpp/src/examples/c/Makefile.sample mamda/c_cpp/src/cpp/MamdaTradeListener.cpp mamda/c_cpp/src/examples/auctionticker.cpp mamda/java/com/wombat/mamda/MamdaAuctionRecap.java mamda/dotnet/src/examples/MamdaListen/MamdaListenCS.csproj mamda/c_cpp/src/examples/currencyticker.cpp mamda/c_cpp/src/examples/orderbooks/test/bookiters.cpp mamda/dotnet/src/examples/MamdaTradeTicker/MamdaTradeTickerCS.csproj mamda/java/com/wombat/mamda/MamdaQuoteListener.java mama/dotnet/src/examples/MamaIo/MamaIoCS.csproj mamda/dotnet/src/examples/MamdaMultiSecurityTicker/MamdaMultiSecurityTickerCS.csproj mama/c_cpp/src/c/subscriptionimpl.h mama/c_cpp/src/examples/cpp/Makefile.sample mamda/c_cpp/src/examples/optionview.cpp mamda/dotnet/src/examples/MamdaOptionChainExample/MamdaOptionChainExampleCS.csproj mamda/dotnet/src/examples/MamdaSecStatusTicker/MamdaSecStatusTickerCS.csproj mamda/c_cpp/src/examples/multisecurityticker.cpp mama/c_cpp/src/c/fieldcache/fieldcache.c mama/dotnet/src/nunittest/NUnitTest.csproj mamda/c_cpp/src/examples/comboticker.cpp mama/dotnet/src/examples/MamaListen/MamaListenCS.csproj mamda/c_cpp/src/examples/orderbooks/atomicbookticker.cpp mama/c_cpp/src/c/entitlement/noop/noop.c mama/dotnet/src/examples/MamaSymbolListSubscriber/MamaSymbolListSubscriberCS.csproj mamda/c_cpp/src/examples/fundamentallisten.cpp mamda/c_cpp/src/examples/orderbooks/test/randomaccess.cpp common/c_cpp/src/c/windows/wombat/port.h mamda/java/com/wombat/mamda/MamdaSecurityStatusQual.java mamda/dotnet/SConscript.win mamda/c_cpp/src/examples/orderbooks/bookpublisher.cpp mamda/dotnet/src/examples/MamdaAtomicBookTicker/MamdaAtomicBookTickerCS.csproj mama/dotnet/src/examples/MamaPublisher/MamaPublisherCS.csproj mama/c_cpp/src/cpp/MamaQueue.cpp mamda/c_cpp/src/cpp/MamdaSecurityStatusQual.cpp mama/c_cpp/src/c/mama/log.h mamda/c_cpp/src/examples/orderbooks/Makefile.sample mama/dotnet/src/examples/MamaFtMember/MamaFtMemberCS.csproj mama/dotnet/src/testtools/load/MamaChurn/MamaChurnCS.csproj mamda/c_cpp/src/examples/orderbooks/test/bookselftest.cpp mamda/dotnet/src/examples/MamdaMultiPartTicker/MamdaMultiPartTickerCS.csproj mamda/dotnet/src/examples/MamdaQuoteTicker/MamdaQuoteTickerCS.csproj mama/c_cpp/src/cpp/mama/MamaSubscription.h mamda/c_cpp/src/examples/optionchainer.cpp mamda/dotnet/src/cs/mamdadotnet.csproj mamda/dotnet/src/examples/MamdaOptionChainViewExample/MamdaOptionChainViewExampleCS.csproj mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookWriter.cpp mama/c_cpp/src/c/mama.c site_scons/community/windows.py mamda/c_cpp/src/examples/orderbooks/bookticker.cpp mamda/c_cpp/src/examples/mamdalisten.cpp site_scons/jni_tools.py mamda/c_cpp/src/examples/news/newsticker.cpp mamda/java/com/wombat/mamda/MamdaSecurityStatus.java mamda/c_cpp/src/examples/orderimbalanceticker.cpp mama/c_cpp/src/c/queue.c mamda/dotnet/src/examples/MamdaComboTicker/MamdaComboTickerCS.csproj mamda/dotnet/src/examples/MamdaFundamentalTicker/MamdaFundamentalTickerCS.csproj site_scons/logger.py common/c_cpp/src/c/linux/wConfig.h mama/c_cpp/src/c/subscription.c mamda/c_cpp/src/examples/orderbooks/listenerBookPublisher.cpp mamda/dotnet/src/NUnittest/NUnitTest.csproj mamda/c_cpp/src/examples/orderbooks/bookchurn.cpp mamda/c_cpp/src/examples/orderbooks/atomicbookbuilder.cpp mamda/c_cpp/src/examples/secstatuslisten.cpp mama/c_cpp/src/c/ft.c site_scons/community/linux.py [Frank Quinn] Reverted spurious change that sneaked in with whitespace mama/c_cpp/src/c/queue.c [Frank Quinn] Added thread C file to common visual studio project common/c_cpp/src/c/commonc.vcxproj [Frank Quinn] Fixed build warning in MamdaOrderBookWriter mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookWriter.cpp [Frank Quinn] Fixed build failure in C# after recent changes mama/dotnet/src/cs/mamadotnet.csproj [Frank Quinn] Fixed build failure in C# after recent changes #2 mama/dotnet/src/cs/mamadotnet.csproj
Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:
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!
[Frank Quinn] Whitespace tidy up across large numbers of files mama/c_cpp/src/cpp/mama/MamaFt.h mama/c_cpp/src/testtools/capturereplay/c/capturec.c mama/jni/src/c/SConscript mama/dotnet/src/cs/MamaSourceState.cs mama/c_cpp/src/c/msgtype.c mama/c_cpp/src/testtools/load/cpp/Makefile.am mama/dotnet/src/cs/MamaSourceStateChangeCallback.cs mama/dotnet/src/cs/MamaCallbackStore.cs mama/jni/src/c/mamajniutils.c mamda/dotnet/src/cs/MamdaQuoteGap.cs mama/c_cpp/src/cpp/fieldcache/MamaFieldCacheRecord.cpp mamda/c_cpp/src/gunittest/orderImbalances/Makefile.am mamda/dotnet/src/cs/OrderBook/MamdaOrderBookListener.cs mama/dotnet/src/cs/MamaFtMember.cs mama/jni/src/junittests/MamaOpenClose.java mama/c_cpp/src/c/mama/dictionary.h mama/c_cpp/src/examples/c/mamalistencachedc.c mamda/dotnet/src/cs/OrderBook/MamdaOrderBookFields.cs mamda/c_cpp/src/gunittest/SConscript mama/c_cpp/src/c/dictionary.c mama/c_cpp/src/examples/cpp/mamasubscribercpp.cpp mama/dotnet/src/cs/MamaSendCompleteCallback.cs mamda/c_cpp/src/cpp/MamdaErrorCode.h mama/c_cpp/src/c/datetime.c mama/dotnet/src/cs/MamaException.cs mamda/c_cpp/src/cpp/SConscript mama/c_cpp/src/cpp/mama/MamaTransport.h mama/c_cpp/src/c/status.c mama/c_cpp/src/testtools/performance/cpp/Makefile.am mamda/dotnet/src/cs/MamdaTradeReport.cs mama/jni/src/com/wombat/mama/examples/MamaPublisherJava.java mamda/dotnet/src/cs/MamdaTradeCancelOrError.cs mama/dotnet/src/cs/MamaInboxCallback.cs mama/c_cpp/src/c/transportimpl.h mama/c_cpp/src/c/mama/io.h mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceSide.h mama/c_cpp/src/c/symbollist.c mama/jni/src/junittests/MamaPriceGetRoundedPrice.java mama/dotnet/src/examples/MamaFtMember/MamaFtMemberCS.cs mama/dotnet/src/nunittest/MamaMsgVectorMsgTest.cs mama/dotnet/src/examples/MamaInbox/MamaInboxCS.cs mama/dotnet/src/testtools/load/MamaChurn/MamaChurnCS.cs mama/jni/src/junittests/MamaMsgVectorFields.java mamda/dotnet/src/cs/Options/MamdaOptionChain.cs mamda/dotnet/src/cs/MamdaTradeSide.cs mama/dotnet/src/nunittest/MamaEnqueueEventTest.cs mamda/c_cpp/src/gunittest/orderbooks/Makefile.am mama/c_cpp/src/cpp/mama/MamaBridgeCallback.h mama/dotnet/src/cs/MamaQueueGroup.cs mamda/c_cpp/src/cpp/options/MamdaOptionChain.cpp mama/c_cpp/src/examples/c/mamasubscriberc.c mama/dotnet/src/cs/MamaSubscriptionCallback.cs mamda/dotnet/src/cs/MamdaFundamentalListener.cs mamda/dotnet/src/cs/MamdaConcreteSecurityStatusRecap.cs mama/jni/src/junittests/MamaMsgGetStringAsCharBuffer.java mama/c_cpp/src/c/msgfield.c mama/jni/src/c/mamamsgjni.c mamda/c_cpp/src/cpp/MamdaLock.cpp mama/jni/src/com/wombat/mama/MamaQueueGroup.java mama/jni/src/com/wombat/mama/MamaTransport.java mama/dotnet/src/cs/NullableTypes/NullableLong.cs mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookListener.cpp mamda/dotnet/src/cs/MamdaFundamentals.cs mama/c_cpp/src/cpp/MamaPublisherImpl.h mama/dotnet/src/cs/MamaSource.cs mama/jni/src/com/wombat/mama/MamaMdDataType.java mamda/c_cpp/src/cpp/mamda/MamdaFieldState.h mamda/c_cpp/src/cpp/mamda/MamdaAuctionHandler.h mamda/dotnet/src/cs/MamdaSecurityStatusFields.cs mama/c_cpp/src/cpp/mama/MamaSourceGroupManager.h mama/jni/src/com/wombat/mama/MamaSource.java mama/c_cpp/src/c/dqpublishermanager.c common/c_cpp/src/c/wombat/strutils.h mamda/dotnet/src/examples/MamdaBookChurn/MamdaBookChurn.cs mama/dotnet/src/cs/MamaMsgField.cs mamda/c_cpp/src/cpp/MamdaOrderImbalanceFields.cpp mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceFields.h mama/c_cpp/src/examples/c/plugin/SConscript mamda/dotnet/src/cs/Containers/Helpers.cs mama/c_cpp/src/c/queueimpl.h mama/jni/src/junittests/MamaInboxCallbacks.java mamda/dotnet/src/examples/MamdaOptionChainViewExample/MamdaOptionChainViewExample.cs mama/dotnet/src/examples/MamaMultiSubscriber/MamaMultiSubscriberCS.cs mama/jni/src/c/mamapayloadbridgejni.c mama/c_cpp/src/c/publisher.c mamda/dotnet/src/cs/MamdaQuoteRecap.cs mama/c_cpp/src/c/middleware.c mamda/c_cpp/src/examples/tradeticker.cpp mama/c_cpp/src/c/mama/datetime.h mamda/dotnet/src/cs/MamdaFundamentalFields.cs mama/dotnet/src/cs/MAMA.cs mama/dotnet/src/cs/MamaPayloadBridge.cs mamda/c_cpp/src/examples/quoteticker.cpp mamda/dotnet/src/cs/Options/MamdaOptionExpirationDateSet.cs mama/c_cpp/src/testtools/performance/c/mamaproducerc_v2.c mama/dotnet/src/cs/MamaPublisher.cs mamda/dotnet/src/cs/MamdaFields.cs mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceListener.h mamda/dotnet/src/examples/MamdaBookTicker/MamdaBookTicker.cs mama/c_cpp/src/cpp/MamaFt.cpp mama/jni/src/junittests/MamaSetLogCallback.java mamda/c_cpp/src/cpp/orderbooks/MamdaQuoteToBookListener.cpp mama/dotnet/src/cs/MamaQueueMonitorCallback.cs mama/c_cpp/src/cpp/mama/MamaSourceGroup.h mama/dotnet/src/cs/MamaFtMemberCallback.cs mama/c_cpp/src/cpp/mama/MamaBasicSubscription.h mamda/c_cpp/src/cpp/mamda/MamdaSecStatusRecap.h mamda/dotnet/src/cs/MamdaBasicRecap.cs mama/c_cpp/src/c/mama/stat.h mama/c_cpp/src/cpp/mama/fieldcache/MamaFieldCacheField.h mama/jni/src/com/wombat/mama/MamaBasicSubscription.java mamda/dotnet/src/cs/MamdaDataException.cs mama/c_cpp/src/testtools/load/cpp/mamachurncpp.cpp mamda/dotnet/src/examples/MamdaOptionChainExample/MamdaOptionChainExample.cs mama/c_cpp/src/cpp/MamaQueue.cpp mamda/c_cpp/src/cpp/MamdaUtils.cpp mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceType.h mamda/c_cpp/src/gunittest/quotes/Makefile.am mama/dotnet/src/cs/MamaLogFileCallback2.cs mamda/c_cpp/src/cpp/news/SConscript mama/c_cpp/src/c/mama/transport.h mamda/c_cpp/src/testtools/Makefile.am mama/dotnet/src/cs/MamaSymbolMapCallback.cs mamda/c_cpp/src/cpp/options/SConscript mamda/c_cpp/src/gunittest/trades/Makefile.am mama/c_cpp/src/examples/cpp/mamalistencachedcpp.cpp mama/jni/src/com/wombat/mama/MamaDQPublisherManager.java mamda/dotnet/src/cs/MamdaTradeClosing.cs mama/dotnet/src/examples/MamaIo/MamaIoCS.cs mamda/dotnet/src/cs/MamdaOrderImbalanceSide.cs mamda/dotnet/src/examples/MamdaExamplesCommon/CommandLineProcessor.cs mama/jni/src/c/mamasubscriptionjni.c mama/jni/src/c/mamatransportjni.c mamda/c_cpp/src/cpp/MamdaMultiParticipantManager.cpp mama/c_cpp/src/c/statsgenerator.c mamda/c_cpp/src/testtools/quoteselftest.cpp mamda/dotnet/src/cs/MamdaSecurityStatusUpdate.cs mama/c_cpp/src/c/mama/fieldcache/fieldcachefield.h mama/jni/src/c/mamainboxjni.c mamda/dotnet/src/cs/MamdaOrderImbalanceListener.cs mama/c_cpp/src/cpp/fieldcache/MamaFieldCacheField.cpp mamda/dotnet/src/cs/Containers/Iterable.cs mama/c_cpp/src/c/playback/playbackpublisher.c mamda/c_cpp/src/cpp/mamda/MamdaAuctionUpdate.h mamda/c_cpp/src/cpp/mamda/MamdaSecurityStatusQual.h mama/dotnet/src/cs/NullableTypes/NullableBool.cs mama/c_cpp/src/testtools/load/c/Makefile.am mamda/dotnet/src/cs/MamdaConcreteQuoteRecap.cs mamda/dotnet/src/cs/Options/MamdaOptionContractSet.cs mama/dotnet/src/testtools/load/MamaChurn/Properties/Resources.Designer.cs mama/c_cpp/src/cpp/mama/fieldcache/MamaFieldCache.h mama/c_cpp/src/c/mama/publisher.h mama/c_cpp/src/testtools/performance/c/mamaconsumerc_v2.c mama/dotnet/src/cs/MamaWrapper.cs mama/c_cpp/src/examples/cpp/mamasymbollistsubscribercpp.cpp mama/dotnet/src/cs/MamaReservedFields.cs mama/jni/src/com/wombat/mama/examples/MamaSubscriberJava.java mama/c_cpp/src/cpp/mamacpp.cpp mamda/c_cpp/src/cpp/MamdaQuery.cpp mama/c_cpp/src/c/mama/msg.h mama/c_cpp/src/examples/cpp/mamalistencpp.cpp mama/dotnet/src/cs/MamaDictionary.cs mama/jni/src/com/wombat/mama/MamaSubscription.java mamda/dotnet/src/cs/Options/MamdaOptionChainHandler.cs mamda/dotnet/src/cs/MamdaOrderImbalanceFields.cs mamda/dotnet/src/cs/MamdaQuoteFields.cs mamda/dotnet/src/cs/Containers/HashMap.cs mama/c_cpp/src/c/mama/fieldcache/fieldcache.h mama/c_cpp/src/examples/c/mamaftmemberc.c mama/c_cpp/src/examples/cpp/mamainboxcpp.cpp mama/c_cpp/src/cpp/fieldcache/MamaFieldCache.cpp mama/jni/src/c/mamapublisherjni.c mamda/dotnet/src/examples/MamdaExamplesCommon/ComboTicker.cs mama/dotnet/src/cs/MamaQueueEnqueueCallback.cs mamda/dotnet/src/cs/MamdaOrderImbalanceHandler.cs mamda/dotnet/src/examples/MamdaComboTicker/MamdaComboTicker.cs mama/c_cpp/src/cpp/fieldcache/MamaFieldCacheFieldTypes.cpp mama/c_cpp/src/testtools/performance/cpp/mamapingpong_replycpp.cpp mama/dotnet/src/examples/MamaListen/MamaListenCS.cs mama/jni/src/com/wombat/mama/examples/MamaListen.java mamda/c_cpp/src/gunittest/secstatus/Makefile.am mama/c_cpp/src/c/bridge.h mama/dotnet/src/cs/MamaBasicSubscription.cs mama/dotnet/src/cs/MamaSourceGroupManager.cs mama/c_cpp/src/cpp/MamaSubscription.cpp mama/jni/src/junittests/MamaMsgGetByteBuffer.java mama/jni/src/c/mamadatetimejni.c mamda/dotnet/src/cs/MamdaCommonFields.cs mamda/c_cpp/src/cpp/MamdaOrderImbalanceType.cpp mama/c_cpp/src/c/playback/playbackpublisher.h mama/c_cpp/src/cpp/mama/MamaSourceManager.h mama/dotnet/src/cs/MamaQueueEventCallback.cs mama/jni/src/junittests/MamaMsgAddArrayMsgWithLength.java mama/c_cpp/src/testtools/load/cpp/mamachurn.h mama/jni/src/c/mamabasicsubscriptionjni.c mama/jni/src/com/wombat/mama/MamaPayloadType.java mamda/dotnet/src/cs/OrderBook/MamdaOrderBookCheckerHandler.cs mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceRecap.h mama/c_cpp/src/regression/c_cpp/tools/Makefile.sample mamda/c_cpp/src/cpp/MamdaAuctionListener.cpp mamda/c_cpp/src/cpp/orderbooks/MamdaBookAtomicListener.cpp mama/c_cpp/src/c/mama/statsloggerfields.h mama/dotnet/src/cs/MamaTimer.cs mamda/dotnet/src/cs/MamdaTradeGap.cs mamda/c_cpp/src/cpp/mamda/MamdaAuctionRecap.h mama/jni/src/com/wombat/mama/MamaDQPublisher.java mama/jni/src/c/subscriptioncommon.c mamda/c_cpp/src/cpp/MamdaUncrossPriceInd.cpp mama/dotnet/src/cs/MamaQueue.cs mamda/dotnet/src/cs/MamdaSecurityStatusListener.cs mamda/dotnet/src/cs/OrderBook/MamdaOrderBookPriceLevel.cs mamda/dotnet/src/examples/MamdaMultiSecurityTicker/MamdaMultiSecurityTicker.cs mama/c_cpp/src/cpp/MamaSymbolList.cpp mama/c_cpp/src/c/fieldcache/fieldcachefield.c mama/c_cpp/src/examples/cpp/mamaftmembercpp.cpp mama/jni/src/com/wombat/mama/MamaBasicWildCardSubscriptionCallback.java mamda/dotnet/src/cs/MamdaTradeHandler.cs mama/c_cpp/src/c/mama/subscription.h mama/c_cpp/src/testtools/capturereplay/c/captureconvert.c mama/jni/src/c/mamadqpublisherjni.c mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceUpdate.h mamda/dotnet/src/cs/MamdaBasicEvent.cs mama/dotnet/src/cs/MamaIo.cs mama/c_cpp/src/examples/cpp/mamaproxycpp.cpp mama/dotnet/src/cs/MamaSymbolMapFile.cs mamda/dotnet/src/cs/Options/MamdaOptionUnderlying.cs mamda/c_cpp/src/cpp/mamda/MamdaOrderImbalanceHandler.h mama/c_cpp/src/c/mama/fieldcache/fieldcacheiterator.h mama/jni/src/c/mamajniutils.h mamda/dotnet/src/cs/MamdaMultiParticipantManager.cs mama/c_cpp/src/cpp/mama/MamaMsg.h mamda/c_cpp/src/examples/SConscript.win mamda/c_cpp/src/cpp/mamda/MamdaAuctionListener.h mama/jni/src/com/wombat/mama/MamaPublisher.java mamda/c_cpp/src/cpp/mamda/MamdaTradeExecVenue.h mama/jni/src/com/wombat/mama/MamaMsg.java mamda/dotnet/src/cs/MamdaTradeRecap.cs mamda/c_cpp/src/cpp/mamda/MamdaUncrossPriceInd.h mama/dotnet/src/cs/MamaTimerCallback.cs mama/jni/src/com/wombat/mama/MamaQueue.java mama/jni/src/c/mamaqueuejni.c mamda/dotnet/src/cs/MamdaTradeListener.cs mama/jni/src/c/mamaftmemberjni.c mamda/dotnet/src/cs/MamdaOrderImbalanceRecap.cs mamda/dotnet/src/cs/MamdaTradeFields.cs mamda/c_cpp/doxyconfig-cpp.in mama/c_cpp/src/c/mama/fielddesc.h mamda/dotnet/src/cs/MamdaSecurityStatusQual.cs mama/dotnet/src/cs/MamaSourceGroup.cs mamda/dotnet/src/cs/OrderBook/MamdaOrderBookEntry.cs mama/c_cpp/src/cpp/mama/fieldcache/MamaFieldCacheFieldTypes.h mamda/dotnet/src/cs/MamdaQuoteHandler.cs mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookWriter.h mama/dotnet/src/examples/MamaSubscriber/MamaSubscriberCS.cs mamda/dotnet/src/cs/Containers/RedBlackTree.cs mamda/dotnet/src/examples/MamdaListen/MamdaListen.cs mama/c_cpp/src/c/mamac.vcxproj mama/c_cpp/src/c/transport.c mama/dotnet/src/cs/MamaMsg.cs mama/jni/src/com/wombat/mama/MamaDateTime.java mamda/dotnet/src/cs/MamdaMultiSecurityManager.cs mama/c_cpp/src/examples/c/SConscript.win mama/c_cpp/src/cpp/mama/MamaStatsCollector.h mama/dotnet/src/cs/MamaTransportCallback.cs mama/c_cpp/src/c/mama/status.h mama/c_cpp/src/cpp/mama/MamaLogFile.h mama/dotnet/SConscript.win mama/jni/src/junittests/MamaDateTimeSetTimeZone.java mama/jni/src/junittests/MamaTimerCallbacks.java mamda/c_cpp/src/cpp/mamda/MamdaFundamentals.h mama/jni/src/c/mamapricejni.c mamda/dotnet/src/cs/MamdaAuctionRecap.cs mama/c_cpp/src/c/mama/mama.h mama/jni/src/c/mamadqpublishermanagerjni.c mama/c_cpp/src/cpp/mama/fieldcache/MamaFieldCacheRecord.h mamda/dotnet/src/cs/MamdaTradeCorrection.cs mamda/c_cpp/src/cpp/MamdaOrderImbalanceListener.cpp mama/dotnet/src/cs/MamaFieldDescriptor.cs mama/c_cpp/src/cpp/version.rc mamda/dotnet/src/cs/Options/MamdaOptionChainListener.cs mamda/dotnet/src/cs/MamdaConcreteOrderImbalanceRecap.cs mama/c_cpp/src/c/statsloggerfields.c mamda/c_cpp/src/cpp/MamdaSubscription.cpp mamda/dotnet/src/cs/Containers/TreeSet.cs mama/c_cpp/src/cpp/SConscript mama/dotnet/src/cs/MamaSubscription.cs mamda/dotnet/src/cs/Options/MamdaOptionChainView.cs mamda/dotnet/src/cs/Options/MamdaOptionContract.cs mama/c_cpp/src/cpp/MamaStatsCollector.cpp mamda/dotnet/src/cs/MamdaQuoteListener.cs mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBook.cpp mamda/dotnet/src/examples/MamdaMultiPartTicker/MamdaMultiPartTicker.cs mama/jni/src/junittests/MamaMsgTryMethods.java mamda/c_cpp/src/testtools/tradeselftest.cpp mama/dotnet/src/cs/NullableTypes/NullableInt.cs mama/c_cpp/src/examples/cpp/mamamsgpublishercpp.cpp mama/c_cpp/src/cpp/mama/mamacpp.h mama/c_cpp/src/cpp/mama/MamaPublisher.h mamda/dotnet/src/cs/MamdaAuctionUpdate.cs mamda/dotnet/src/cs/OrderBook/MamdaOrderBook.cs mama/jni/src/junittests/Main.java mamda/dotnet/src/cs/MamdaOrderImbalanceType.cs mamda/c_cpp/src/cpp/MamdaSecStatusListener.cpp mama/c_cpp/src/testtools/capturereplay/c/capturereplayc.c mama/c_cpp/src/c/dqstrategy.c mama/dotnet/src/cs/MamaTransport.cs mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookBasicDeltaList.cpp mamda/dotnet/src/cs/MamdaFundamentalHandler.cs mamda/dotnet/src/cs/OrderBook/MamdaOrderBookChecker.cs mamda/dotnet/src/cs/MamdaSubscription.cs mamda/c_cpp/src/testtools/bookselftest.cpp mamda/c_cpp/src/examples/parsecmd.cpp mama/c_cpp/src/c/dqpublisher.c mama/c_cpp/src/gunittest/c/middleware/middlewareQueueTests.cpp mamda/dotnet/src/cs/MamdaMultiParticipantHandler.cs mama/c_cpp/src/c/reservedfields.c mama/jni/src/c/mamajni.c mamda/dotnet/src/cs/MamdaQuoteUpdate.cs mama/c_cpp/src/c/mama/price.h mamda/c_cpp/src/cpp/options/MamdaOptionContract.cpp mamda/java/com/wombat/mamda/MamdaSecurityStatusQual.java mamda/dotnet/src/cs/MamdaConcreteTradeRecap.cs mamda/c_cpp/src/examples/Makefile.sample mama/c_cpp/src/c/entitlement/noop/noop.c mamda/dotnet/src/cs/MamdaQuoteClosing.cs mama/c_cpp/src/cpp/MamaDQPublisherManager.cpp mama/c_cpp/src/c/mama/ft.h mamda/c_cpp/src/examples/parsecmd.h mamda/c_cpp/src/cpp/orderbooks/mamda/MamdaOrderBookDepthFilter.h mama/dotnet/src/cs/MamaBridge.cs mamda/c_cpp/src/cpp/MamdaFundamentalListener.cpp mamda/dotnet/src/cs/MamdaSecurityStatusRecap.cs mama/c_cpp/src/c/mama/dqpublisher.h mama/c_cpp/src/gunittest/cpp/MamaMsgTest.cpp mama/c_cpp/src/cpp/MamaPublisher.cpp mama/c_cpp/src/c/playback/playbackFileParser.c mama/dotnet/src/cs/MamaIoType.cs mama/dotnet/src/cs/MamaStatus.cs mama/c_cpp/src/c/msgimpl.h mamda/c_cpp/src/cpp/MamdaTradeSide.cpp mama/c_cpp/src/c/mama/msgtype.h mama/c_cpp/src/cpp/MamaBasicSubscription.cpp mama/c_cpp/src/examples/cpp/mamaiocpp.cpp mama/c_cpp/src/examples/cpp/SConscript.win mama/dotnet/SConscript mama/dotnet/src/cs/MamaCallbackWrapper.cs mamda/dotnet/src/cs/Containers/TreeMap.cs mama/c_cpp/src/testtools/load/cpp/SConscript.win mama/c_cpp/src/cpp/MamaTransport.cpp mama/c_cpp/src/c/mama/timezone.h mamda/dotnet/src/examples/MamdaExamplesCommon/UnderlyingTicker.cs mama/c_cpp/src/c/msg.c mama/dotnet/src/cs/MamaInbox.cs mama/jni/src/junittests/MamaPublisherTest.java mama/dotnet/src/cs/MamaBasicSubscriptionCallback.cs mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookPriceLevel.cpp mamda/c_cpp/src/cpp/MamdaTradeExecVenue.cpp [Frank Quinn] Removed legacy autotools framework entirely mama/c_cpp/src/gunittest/c/mamaprice/Makefile.am common/c_cpp/src/cpp/Makefile.am mama/c_cpp/src/gunittest/c/middleware/Makefile.am mamda/c_cpp/src/gunittest/orderbooks/Makefile.am mama/c_cpp/src/c/bridge/qpid/Makefile.am mamda/c_cpp/src/gunittest/trades/Makefile.am mama/c_cpp/Makefile.am mama/c_cpp/src/Makefile.am mama/c_cpp/src/gunittest/Makefile.am mamda/c_cpp/src/examples/orderbooks/Makefile.am mamda/c_cpp/src/cpp/news/Makefile.am mamda/c_cpp/Makefile.am mamda/c_cpp/src/examples/orderbooks/test/Makefile.am mama/c_cpp/src/gunittest/c/fieldcache/Makefile.am mama/c_cpp/src/testtools/capturereplay/Makefile.am common/c_cpp/src/Makefile.am mamda/c_cpp/src/Makefile.am mamda/c_cpp/src/cpp/options/Makefile.am mama/c_cpp/src/testtools/Makefile.am mama/c_cpp/src/testtools/performance/c/Makefile.am common/c_cpp/src/gunittest/c/Makefile.am mama/c_cpp/src/c/payload/Makefile.am mama/c_cpp/src/c/Makefile.am mama/c_cpp/src/testtools/load/cpp/Makefile.am mamda/c_cpp/src/cpp/Makefile.am mama/c_cpp/src/c/bridge/Makefile.am mama/c_cpp/src/gunittest/c/payload/Makefile.am mamda/c_cpp/src/examples/Makefile.am mama/c_cpp/src/gunittest/cpp/Makefile.am mamda/c_cpp/src/gunittest/secstatus/Makefile.am common/c_cpp/src/c/Makefile.am mama/c_cpp/configure.ac mama/c_cpp/src/gunittest/c/mamadatetime/Makefile.am mama/c_cpp/src/testtools/performance/Makefile.am mama/c_cpp/src/testtools/performance/cpp/Makefile.am common/c_cpp/Makefile.am mama/c_cpp/src/gunittest/c/mamamsg/Makefile.am mama/c_cpp/src/examples/Makefile.am common/c_cpp/configure.ac mama/jni/src/c/Makefile.am mamda/c_cpp/src/gunittest/Makefile.am mamda/c_cpp/src/gunittest/quotes/Makefile.am mama/c_cpp/src/cpp/Makefile.am mama/c_cpp/src/gunittest/cpp/fieldcache/Makefile.am mama/c_cpp/src/testtools/load/c/Makefile.am mama/jni/Makefile.am mamda/c_cpp/src/cpp/orderbooks/Makefile.am common/c_cpp/src/gunittest/Makefile.am mama/c_cpp/src/testtools/capturereplay/c/Makefile.am mama/c_cpp/src/c/payload/qpidmsg/Makefile.am mama/c_cpp/src/examples/cpp/Makefile.am mama/c_cpp/src/testtools/load/Makefile.am mamda/c_cpp/configure.ac mamda/c_cpp/src/gunittest/orderImbalances/Makefile.am mama/c_cpp/src/gunittest/c/Makefile.am mamda/c_cpp/src/testtools/Makefile.am mama/jni/src/Makefile.am mamda/c_cpp/src/examples/news/Makefile.am mama/c_cpp/src/examples/c/Makefile.am mama/jni/configure.ac [Frank Quinn] PLAT-294: Named threads support (updated) common/c_cpp/src/c/thread.c common/c_cpp/src/c/wombat/thread.h mama/c_cpp/src/c/mama.c common/c_cpp/src/c/windows/port.c mama/c_cpp/src/c/queue.c common/c_cpp/src/c/linux/port.h common/c_cpp/src/c/windows/wombat/port.h [Frank Quinn] PLAT-719: Changed error handling when trying to apply thread affinities. mama/c_cpp/src/c/mama.c mama/c_cpp/src/c/queue.c [Frank Quinn] MAMA: Enable unified logging in external components. mama/c_cpp/src/c/log.c mama/c_cpp/src/c/mama/log.h [Frank Quinn] Issue: Mama-5329 Submitted by: Adrienne Ambrose Reviewed by: Ian common/c_cpp/src/gunittest/c/queuetest.cpp [Frank Quinn] Allow point to point message to be intercepted based on DQ mama/c_cpp/src/c/listenermsgcallback.c [Frank Quinn] Modifications to correct vela build system failures mama/c_cpp/src/c/entitlement/oea/oea.h mama/c_cpp/src/c/mamainternal.h common/c_cpp/src/c/windows/wombat/wConfig.h mama/c_cpp/src/c/entitlement/oea/oea.c mama/dotnet/src/cs/mamadotnet.csproj mama/c_cpp/src/c/SConscript mama/c_cpp/src/c/mama.c mama/c_cpp/src/c/SConscript.win mama/c_cpp/src/c/generateMamaSourceFiles.bat [Frank Quinn] MAMA-5420: Cleared up all possible warnings from Products.mamac mama/c_cpp/src/c/subscriptionimpl.h [Frank Quinn] Issue: Mamda-1944 Submitted by: Adrienne Ambrose Reviewed by: Ian mamda/c_cpp/src/examples/orderbooks/bookchurn.cpp mamda/c_cpp/src/examples/secstatuslisten.cpp mamda/c_cpp/src/examples/news/newsticker.cpp mamda/c_cpp/src/examples/multipartticker.cpp mamda/c_cpp/src/examples/orderbooks/test/bookiters.cpp mamda/c_cpp/src/examples/orderimbalanceticker.cpp mamda/c_cpp/src/examples/orderbooks/bookviewer.cpp mamda/c_cpp/src/examples/orderbooks/test/bookselftest.cpp mamda/c_cpp/src/examples/mamdalisten.cpp mamda/c_cpp/src/examples/orderbooks/bookticker.cpp mamda/c_cpp/src/examples/auctionticker.cpp mamda/c_cpp/src/examples/orderbooks/test/randomaccess.cpp mamda/c_cpp/src/examples/currencyticker.cpp mamda/c_cpp/src/examples/optionview.cpp mamda/c_cpp/src/examples/optionchainer.cpp mamda/c_cpp/src/examples/orderbooks/listenerBookPublisher.cpp mamda/c_cpp/src/examples/mamdapublisher.cpp mamda/c_cpp/src/examples/orderbooks/atomicbookbuilder.cpp mamda/c_cpp/src/examples/orderbooks/bookpublisher.cpp mamda/c_cpp/src/examples/multisecurityticker.cpp mamda/c_cpp/src/examples/comboticker.cpp mamda/c_cpp/src/examples/fundamentallisten.cpp mamda/c_cpp/src/examples/orderbooks/atomicbookticker.cpp [Frank Quinn] PLAT-526: Added Lock C++ header for lockable types common/c_cpp/src/cpp/wombat/Lock.h [Frank Quinn] Reverted duplicate loading of entitlement bridge mama/c_cpp/src/c/mama.c [Frank Quinn] Merge fix from api_rel_6_0_1 to api_rel_6_0_0 mama/c_cpp/src/c/listenermsgcallback.c [Frank Quinn] [PLAT-383] - Additional NULL check before string.h function calls added. mama/c_cpp/src/c/subscription.c [Frank Quinn] Fixing build error caused by RC versions. mama/c_cpp/SConscript mama/c_cpp/src/c/mamainternal.h [Frank Quinn] MAMA-5842 Corrected initialisation of ttl and service FT parameters mama/c_cpp/src/c/ft.c [Frank Quinn] Correcting Windows build issues. mama/c_cpp/src/c/subscription.c [Frank Quinn] PLAT-620: Loading all default payloads for each middleware in mama/c_cpp/src/c/mama.c [Frank Quinn] Cleaned up trailing whitespace across source code files mama/c_cpp/src/c/mama/log.h common/c_cpp/src/c/linux/wConfig.h mama/dotnet/src/cs/mamadotnet.csproj mamda/c_cpp/src/examples/news/newsticker.cpp mama/dotnet/src/examples/MamaMultiSubscriber/MamaMultiSubscriberCS.csproj mamda/c_cpp/src/examples/orderbooks/listenerBookPublisher.cpp mamda/c_cpp/src/examples/orderbooks/bookchurn.cpp mamda/c_cpp/src/examples/secstatuslisten.cpp mamda/c_cpp/src/examples/auctionticker.cpp mamda/dotnet/src/examples/MamdaQuoteTicker/MamdaQuoteTickerCS.csproj mama/c_cpp/src/cpp/MamaQueue.cpp mamda/c_cpp/src/examples/orderbooks/Makefile.sample mamda/java/com/wombat/mamda/MamdaAuctionRecap.java mamda/c_cpp/src/cpp/MamdaTradeListener.cpp mamda/dotnet/src/NUnittest/NUnitTest.csproj mama/c_cpp/src/examples/cpp/mamaproxycpp.cpp mamda/dotnet/src/cs/mamdadotnet.csproj mamda/dotnet/src/examples/MamdaMultiSecurityTicker/MamdaMultiSecurityTickerCS.csproj mamda/c_cpp/src/examples/orderbooks/bookticker.cpp mamda/dotnet/src/examples/MamdaTradeTicker/MamdaTradeTickerCS.csproj mamda/c_cpp/src/examples/fundamentallisten.cpp mama/dotnet/src/examples/MamaFtMember/MamaFtMemberCS.csproj site_scons/community/windows.py mama/c_cpp/src/c/entitlement/noop/noop.c mamda/dotnet/src/examples/MamdaComboTicker/MamdaComboTickerCS.csproj mamda/c_cpp/src/examples/orderbooks/test/bookselftest.cpp mama/dotnet/src/nunittest/NUnitTest.csproj mamda/dotnet/src/examples/MamdaAtomicBookTicker/MamdaAtomicBookTickerCS.csproj mama/c_cpp/src/cpp/MamaMsg.cpp mamda/c_cpp/src/examples/orderbooks/atomicbookticker.cpp mama/c_cpp/src/c/fieldcache/fieldcache.c mama/dotnet/src/examples/MamaInbox/MamaInboxCS.csproj mamda/c_cpp/src/examples/optionchainer.cpp mamda/dotnet/src/examples/MamdaListen/MamdaListenCS.csproj mamda/c_cpp/src/examples/orderbooks/test/randomaccess.cpp site_scons/jni_tools.py mamda/dotnet/src/examples/MamdaMultiPartTicker/MamdaMultiPartTickerCS.csproj mamda/dotnet/src/examples/MamdaBookTicker/MamdaBookTickerCS.csproj mamda/java/com/wombat/mamda/MamdaQuoteListener.java mamda/dotnet/src/examples/MamdaFundamentalTicker/MamdaFundamentalTickerCS.csproj mama/c_cpp/src/c/queue.c mamda/c_cpp/src/cpp/MamdaSecurityStatusQual.cpp mama/c_cpp/src/examples/c/Makefile.sample mama/c_cpp/src/c/subscription.c mama/dotnet/src/testtools/load/MamaChurn/MamaChurnCS.csproj mama/c_cpp/src/cpp/mama/MamaSubscription.h mamda/c_cpp/src/examples/multisecurityticker.cpp mamda/dotnet/src/examples/MamdaAuctionTicker/MamdaAuctionTickerCS.csproj mama/dotnet/src/examples/MamaListen/MamaListenCS.csproj mama/dotnet/src/examples/MamaSymbolListSubscriber/MamaSymbolListSubscriberCS.csproj mamda/c_cpp/src/examples/orderbooks/test/bookiters.cpp common/c_cpp/src/c/commonc.vcxproj site_scons/logger.py mamda/c_cpp/src/examples/mamdalisten.cpp mamda/dotnet/src/examples/MamdaBookChurn/MamdaBookChurnCS.csproj mama/dotnet/src/examples/MamaIo/MamaIoCS.csproj mamda/c_cpp/src/cpp/generateMamdaVersion.bat mamda/dotnet/src/examples/MamdaOptionChainViewExample/MamdaOptionChainViewExampleCS.csproj mama/c_cpp/src/c/ft.c site_scons/community/linux.py mama/c_cpp/src/c/subscriptionimpl.h mamda/c_cpp/src/examples/orderbooks/bookviewer.cpp mamda/java/com/wombat/mamda/MamdaSecurityStatusListener.java mamda/dotnet/SConscript.win mamda/dotnet/src/examples/MamdaOptionChainExample/MamdaOptionChainExampleCS.csproj mamda/java/com/wombat/mamda/MamdaSecurityStatus.java mamda/c_cpp/src/examples/orderbooks/atomicbookbuilder.cpp mamda/dotnet/src/examples/MamdaSecStatusTicker/MamdaSecStatusTickerCS.csproj mamda/c_cpp/src/examples/multipartticker.cpp mamda/c_cpp/src/examples/comboticker.cpp mamda/c_cpp/src/examples/mamdapublisher.cpp common/c_cpp/src/c/windows/wombat/port.h mama/c_cpp/src/examples/cpp/Makefile.sample mamda/c_cpp/src/examples/orderbooks/bookpublisher.cpp mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookWriter.cpp mama/c_cpp/src/c/mama.c mamda/c_cpp/src/examples/currencyticker.cpp mamda/java/com/wombat/mamda/MamdaSecurityStatusQual.java mama/dotnet/src/examples/MamaSubscriber/MamaSubscriberCS.csproj mamda/c_cpp/src/examples/optionview.cpp mamda/c_cpp/src/examples/orderimbalanceticker.cpp mama/dotnet/src/examples/MamaPublisher/MamaPublisherCS.csproj mama/c_cpp/src/c/msgfield.c [Frank Quinn] Reverted spurious change that sneaked in with whitespace mama/c_cpp/src/c/queue.c [Frank Quinn] Added thread C file to common visual studio project common/c_cpp/src/c/commonc.vcxproj [Frank Quinn] Fixed build warning in MamdaOrderBookWriter mamda/c_cpp/src/cpp/orderbooks/MamdaOrderBookWriter.cpp [Frank Quinn] Fixed build failure in C# after recent changes mama/dotnet/src/cs/mamadotnet.csproj [Frank Quinn] Fixed build failure in C# after recent changes #2 mama/dotnet/src/cs/mamadotnet.csproj
Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:
You may also check CI console output to view the full results.
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Re: New feature: Extending timestamp format
Tom Doust
In the TREP bridge we have a wrapper around the mamaDateTime type and only use the accessor functions. There is a certain amount of messing around converting between mamaDateTime and rssl date and time representations, but so long as the set of accessor functions doesn’t change it should “just work”
One to bear in mind with “breaking changes” like this is that you may also introduce a dependency between the bridge version and the mama runtime version. This was (is) an issue with the change to bridge loading. If I simply install a bridge built with OpenMAMA > 2.4 into a deployment that includes components built with OpenMama <2.4
But, in principle, I agree with Frank’s #1
Tom
From: <openmama-dev-bounces@...> on behalf of Glenn McClements <gmcclements@...>
For Vela we have a couple of payloads: - V5/Wirecache has its own internal format and calls mamaDateTime setters, so this is fine. - WombatMsg actually uses the same encoding as OpenMAMA does internally, so this will need to be changed but I’m fine with this as it was somewhat breaking encapsulation. The wire format will remain the same, we’ll just need to call a setting rather than doing a direct assignment.
Also, from another offline thread, we should take time to consider if the new implementation will be flexible/extendable. Time zone hint and nanosecond support are two feature that spring to mind that we may like to add later.
These are outside of scope for the current piece of work but they have been asked about before and we’d want to make sure that any implementation could be extended to support these if needed.
GLENN MCCLEMENTS SVP Engineering, Europe
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
From: <openmama-dev-bounces@...> on behalf of "Phelan, Nigel via Openmama-dev" <openmama-dev@...>
I think that, at the moment, the most important payload bridges come from Vela, Solace and Tick 42. Would anyone from Solace and Tick 42 care to comment on the behaviour of their payload bridges and whether they took this shortcut in the implementation (I’m assuming Frank can speak authoritatively for Vela)? Also good to know the QPID open source reference implementation gets this right. Out of curiosity, Frank, does your ZeroMQ bridge handle this, or does it just re-use the proton payload (which would presumably automatically make it compatible)?
Thanks
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From: Frank Quinn [mailto:fquinn@...]
Sent: Tuesday, October 04, 2016 9:13 AM To: Stuart Beattie; Phelan, Nigel; openmama-dev@... Subject: RE: New feature: Extending timestamp format
Hi Folks,
The biggest concern here is around interface compatibility with the mamaDateTime type. In our types.h it’s defined as a u64* rather than a void*. Unfortunately, I expect this has given payload bridges a mechanism too tempting to ignore when it comes to simply using the underlying U64 for serialization and deserialization.
If payload bridge developers have treated the mamaDateTime as an encapsulated object, changing mamaDateTime to an opaque struct would be reasonably safe. Qpid proton, for example, would be unaffected by the struct change as it uses mamaDateTime_get/set.
However, any payload bridges which access the native U64 would need to change. Options would be either:
1. Just break the bridge and move on to 6.2 2. Make the first member of the struct the “legacy” U64 member and have a payload bridge flag to enable “backwards compatible” mode and speckle a bunch of backwards compatible code throughout the MAMA Date Time code 3. Assume that no bridges actually use this U64 directly and risk breaking the bridge
Personally my vote would be for #1 - this sort of thing is the reason why we put that version handshaking code in.
Note I just looked through the OpenMAMA wiki for a link explaining the versioning and didn’t find one, so I just created https://github.com/OpenMAMA/OpenMAMA/wiki/OpenMAMA-Versioning for reference.
Cheers, Frank
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Stuart Beattie
Hi Nigel,
Apologies, yes I meant to mention timezones in the original email as something to consider
- Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
“addition of a timestamp” was meant to be “timezone”, my mistake.
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
From: Phelan, Nigel [mailto:nigel.phelan@...]
If contemplating a new type, is it worth considering the question of time zones? The current model doesn’t really address this, although the java constructors have some implicit assumptions that DateTime objects are stored in UTC
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Stuart Beattie
Hi everyone,
We are currently investigating an approach to improve and extend the handling of date/times in OpenMAMA.
The current mamaDateTime type, essentially being a 64-bit bitmask, is inflexible and has some built in limitations – such as the 4-byte second field limiting the maximum stored date to the year 2106, as well as being limited to time since the epoch. The current datetime format is this:
So while there are currently some bytes available to extend this somewhat, if these are used there will be no more room for expansion or new features in the existing format so we are thinking of a more long-term solution.
Instead we are proposing to introduce a new datetime format using a new type which is an actual struct with separate fields for the different elements (seconds, date, time etc.) While this may be larger (in terms of storage size – eg some bits may go unused), it would have the advantages of: a) Being more extensible – fields could be added or changed as necessary without being bound by the current 64 bits b) Being more intuitive to work with
Format could be something like:
This is in the early stages so we are asking for input as well as having a few specific questions for developers – with backwards compatibility being a major concern: - It is currently possible to serialise a mamaDateTime by using the native bitmask format directly – is anyone out there currently doing this and relying on this being possible? - For bridge developers, how do you currently encode timestamps? - Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
Thanks Stuart
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
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
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
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Code change(s) just landed on origin/next (Successful)
jenkins@...
Some changes have just been added to the origin/next branch!
[noreply] EXAMPLE: Added -rewind option to mamaproducerc_v2 (#220) mama/c_cpp/src/testtools/performance/c/mamaproducerc_v2.c
Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:
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] EXAMPLE: Added -rewind option to mamaproducerc_v2 (#220) mama/c_cpp/src/testtools/performance/c/mamaproducerc_v2.c
Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:
You may also check CI console output to view the full results.
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Re: New feature: Extending timestamp format
Glenn McClements <gmcclements@...>
For Vela we have a couple of payloads: - V5/Wirecache has its own internal format and calls mamaDateTime setters, so this is fine. - WombatMsg actually uses the same encoding as OpenMAMA does internally, so this will need to be changed but I’m fine with this as it was somewhat breaking encapsulation. The wire format will remain the same, we’ll just need to call a setting rather than doing a direct assignment.
Also, from another offline thread, we should take time to consider if the new implementation will be flexible/extendable. Time zone hint and nanosecond support are two feature that spring to mind that we may like to add later.
These are outside of scope for the current piece of work but they have been asked about before and we’d want to make sure that any implementation could be extended to support these if needed.
GLENN MCCLEMENTS SVP Engineering, Europe
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
From: <openmama-dev-bounces@...> on behalf of "Phelan, Nigel via Openmama-dev" <openmama-dev@...>
I think that, at the moment, the most important payload bridges come from Vela, Solace and Tick 42. Would anyone from Solace and Tick 42 care to comment on the behaviour of their payload bridges and whether they took this shortcut in the implementation (I’m assuming Frank can speak authoritatively for Vela)? Also good to know the QPID open source reference implementation gets this right. Out of curiosity, Frank, does your ZeroMQ bridge handle this, or does it just re-use the proton payload (which would presumably automatically make it compatible)?
Thanks
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From: Frank Quinn [mailto:fquinn@...]
Sent: Tuesday, October 04, 2016 9:13 AM To: Stuart Beattie; Phelan, Nigel; openmama-dev@... Subject: RE: New feature: Extending timestamp format
Hi Folks,
The biggest concern here is around interface compatibility with the mamaDateTime type. In our types.h it’s defined as a u64* rather than a void*. Unfortunately, I expect this has given payload bridges a mechanism too tempting to ignore when it comes to simply using the underlying U64 for serialization and deserialization.
If payload bridge developers have treated the mamaDateTime as an encapsulated object, changing mamaDateTime to an opaque struct would be reasonably safe. Qpid proton, for example, would be unaffected by the struct change as it uses mamaDateTime_get/set.
However, any payload bridges which access the native U64 would need to change. Options would be either:
1. Just break the bridge and move on to 6.2 2. Make the first member of the struct the “legacy” U64 member and have a payload bridge flag to enable “backwards compatible” mode and speckle a bunch of backwards compatible code throughout the MAMA Date Time code 3. Assume that no bridges actually use this U64 directly and risk breaking the bridge
Personally my vote would be for #1 - this sort of thing is the reason why we put that version handshaking code in.
Note I just looked through the OpenMAMA wiki for a link explaining the versioning and didn’t find one, so I just created https://github.com/OpenMAMA/OpenMAMA/wiki/OpenMAMA-Versioning for reference.
Cheers, Frank
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Stuart Beattie
Hi Nigel,
Apologies, yes I meant to mention timezones in the original email as something to consider
- Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
“addition of a timestamp” was meant to be “timezone”, my mistake.
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
From: Phelan, Nigel [mailto:nigel.phelan@...]
If contemplating a new type, is it worth considering the question of time zones? The current model doesn’t really address this, although the java constructors have some implicit assumptions that DateTime objects are stored in UTC
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Stuart Beattie
Hi everyone,
We are currently investigating an approach to improve and extend the handling of date/times in OpenMAMA.
The current mamaDateTime type, essentially being a 64-bit bitmask, is inflexible and has some built in limitations – such as the 4-byte second field limiting the maximum stored date to the year 2106, as well as being limited to time since the epoch. The current datetime format is this:
So while there are currently some bytes available to extend this somewhat, if these are used there will be no more room for expansion or new features in the existing format so we are thinking of a more long-term solution.
Instead we are proposing to introduce a new datetime format using a new type which is an actual struct with separate fields for the different elements (seconds, date, time etc.) While this may be larger (in terms of storage size – eg some bits may go unused), it would have the advantages of: a) Being more extensible – fields could be added or changed as necessary without being bound by the current 64 bits b) Being more intuitive to work with
Format could be something like:
This is in the early stages so we are asking for input as well as having a few specific questions for developers – with backwards compatibility being a major concern: - It is currently possible to serialise a mamaDateTime by using the native bitmask format directly – is anyone out there currently doing this and relying on this being possible? - For bridge developers, how do you currently encode timestamps? - Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
Thanks Stuart
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
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
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 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: New feature: Extending timestamp format
Phelan, Nigel
I think that, at the moment, the most important payload bridges come from Vela, Solace and Tick 42. Would anyone from Solace and Tick 42 care to comment on the behaviour of their payload bridges and whether they took this shortcut in the implementation (I’m assuming Frank can speak authoritatively for Vela)? Also good to know the QPID open source reference implementation gets this right. Out of curiosity, Frank, does your ZeroMQ bridge handle this, or does it just re-use the proton payload (which would presumably automatically make it compatible)?
Thanks
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From: Frank Quinn [mailto:fquinn@...]
Sent: Tuesday, October 04, 2016 9:13 AM To: Stuart Beattie; Phelan, Nigel; openmama-dev@... Subject: RE: New feature: Extending timestamp format
Hi Folks,
The biggest concern here is around interface compatibility with the mamaDateTime type. In our types.h it’s defined as a u64* rather than a void*. Unfortunately, I expect this has given payload bridges a mechanism too tempting to ignore when it comes to simply using the underlying U64 for serialization and deserialization.
If payload bridge developers have treated the mamaDateTime as an encapsulated object, changing mamaDateTime to an opaque struct would be reasonably safe. Qpid proton, for example, would be unaffected by the struct change as it uses mamaDateTime_get/set.
However, any payload bridges which access the native U64 would need to change. Options would be either:
1. Just break the bridge and move on to 6.2 2. Make the first member of the struct the “legacy” U64 member and have a payload bridge flag to enable “backwards compatible” mode and speckle a bunch of backwards compatible code throughout the MAMA Date Time code 3. Assume that no bridges actually use this U64 directly and risk breaking the bridge
Personally my vote would be for #1 - this sort of thing is the reason why we put that version handshaking code in.
Note I just looked through the OpenMAMA wiki for a link explaining the versioning and didn’t find one, so I just created https://github.com/OpenMAMA/OpenMAMA/wiki/OpenMAMA-Versioning for reference.
Cheers, Frank
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Stuart Beattie
Hi Nigel,
Apologies, yes I meant to mention timezones in the original email as something to consider
- Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
“addition of a timestamp” was meant to be “timezone”, my mistake.
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
From: Phelan, Nigel [mailto:nigel.phelan@...]
If contemplating a new type, is it worth considering the question of time zones? The current model doesn’t really address this, although the java constructors have some implicit assumptions that DateTime objects are stored in UTC
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Stuart Beattie
Hi everyone,
We are currently investigating an approach to improve and extend the handling of date/times in OpenMAMA.
The current mamaDateTime type, essentially being a 64-bit bitmask, is inflexible and has some built in limitations – such as the 4-byte second field limiting the maximum stored date to the year 2106, as well as being limited to time since the epoch. The current datetime format is this:
So while there are currently some bytes available to extend this somewhat, if these are used there will be no more room for expansion or new features in the existing format so we are thinking of a more long-term solution.
Instead we are proposing to introduce a new datetime format using a new type which is an actual struct with separate fields for the different elements (seconds, date, time etc.) While this may be larger (in terms of storage size – eg some bits may go unused), it would have the advantages of: a) Being more extensible – fields could be added or changed as necessary without being bound by the current 64 bits b) Being more intuitive to work with
Format could be something like:
This is in the early stages so we are asking for input as well as having a few specific questions for developers – with backwards compatibility being a major concern: - It is currently possible to serialise a mamaDateTime by using the native bitmask format directly – is anyone out there currently doing this and relying on this being possible? - For bridge developers, how do you currently encode timestamps? - Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
Thanks Stuart
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
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
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
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Code change(s) just landed on origin/next (Successful)
jenkins@...
Some changes have just been added to the origin/next branch!
[fquinn.ni] Fixed Vector DateTime Unit Tests (#221) .gitignore mama/c_cpp/src/gunittest/c/payload/payloadvectortests.cpp
Results for OpenMAMA Next Branch with Qpid Proton CI run with latest changes:
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!
[Frank Quinn] VERSION: Updating version files to 2.4.1 mamda/c_cpp/configure.ac mama/c_cpp/src/c/generateMamaSourceFiles.bat mama/c_cpp/configure.ac mamda/VERSION.scons mamda/java/build.xml mama/VERSION.scons mama/jni/build.xml mamda/c_cpp/src/cpp/generateMamdaVersion.bat [Frank Quinn] Added FC24 to RPM generation script release_scripts/openmama-rpm.sh [Frank Quinn] COMMON Failed build and unit test on Mac (#212) common/c_cpp/src/c/darwin/wSemaphore.c common/c_cpp/src/c/wtable.c common/c_cpp/src/c/darwin/port.h site_scons/community/command_line.py [Frank Quinn] PLAT-529: Fixed a bug where mamapublishercpp was adding an extra . to mama/c_cpp/src/examples/cpp/mamapublishercpp.cpp [Frank Quinn] MAMA: Removed mixed declaration in ent-noop (#214) mama/c_cpp/src/c/entitlement/noop/noop.c [Frank Quinn] PLAT-747: Mamalistenc cores on start up when entitlements are not mama/c_cpp/src/c/entitlement/oea/oea.c [Frank Quinn] MAMA: Fixed race condition deadlock in mamaDispatcher_destroy mama/c_cpp/src/c/queue.c mama/c_cpp/src/gunittest/c/queuetest.cpp [Frank Quinn] PLAT-737: Core within mamaSubscription_processWildCardMsg (#218) mama/c_cpp/src/c/subscription.c [fquinn.ni] Fixed Vector DateTime Unit Tests (#221) mama/c_cpp/src/gunittest/c/payload/payloadvectortests.cpp .gitignore
Results for OpenMAMA_Next_Branch_VS_2015 CI run with latest changes:
You may also check CI console output to view the full results.
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Re: New feature: Extending timestamp format
Phelan, Nigel
It’s definitely a good thing to have, Glenn, but it does add some complexity, particularly when you consider future and past dates, daylight savings transitions and the desire to compare timestamps for latency measurement purposes. I think we should try to keep the scope manageable, but we are finding the date ranges restrictive with real world use cases like mortgage backed securities and long dated bonds
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From: Glenn McClements [mailto:gmcclements@...]
Sent: Thursday, September 29, 2016 4:38 AM To: Stuart Beattie; Phelan, Nigel; openmama-dev@... Subject: Re: New feature: Extending timestamp format
>If contemplating a new type, is it worth considering the question of time zones?
The current OpenMAMA implementation assumes all timestamps are UTC, and as much as I like the simplicity of this, even in small deployments it can prove difficult to guarantee even in small deployments. So I do think some timezone capabilities are needed in the longer term, and it's actually something which sprang to mind as well when were were considering these changes.
A question would be where OpenMAMA picks up the timezone from. It could be defined in a MamaSource metadata, reference (initial) data for the symbol, some other out of band mechanism or encoded in the field, but I think this a separate problem from supporting it in the MamaDateTime type.
Glenn
GLENN MCCLEMENTS SVP Engineering, Europe
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
From:
openmama-dev-bounces@... <openmama-dev-bounces@...> on behalf of Stuart Beattie <sbeattie@...>
Hi Nigel,
Apologies, yes I meant to mention timezones in the original email as something to consider
- Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
“addition of a timestamp” was meant to be “timezone”, my mistake.
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
From: Phelan, Nigel [mailto:nigel.phelan@...]
If contemplating a new type, is it worth considering the question of time zones? The current model doesn’t really address this, although the java constructors have some implicit assumptions that DateTime objects are stored in UTC
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Stuart Beattie
Hi everyone,
We are currently investigating an approach to improve and extend the handling of date/times in OpenMAMA.
The current mamaDateTime type, essentially being a 64-bit bitmask, is inflexible and has some built in limitations – such as the 4-byte second field limiting the maximum stored date to the year 2106, as well as being limited to time since the epoch. The current datetime format is this:
So while there are currently some bytes available to extend this somewhat, if these are used there will be no more room for expansion or new features in the existing format so we are thinking of a more long-term solution.
Instead we are proposing to introduce a new datetime format using a new type which is an actual struct with separate fields for the different elements (seconds, date, time etc.) While this may be larger (in terms of storage size – eg some bits may go unused), it would have the advantages of: a) Being more extensible – fields could be added or changed as necessary without being bound by the current 64 bits b) Being more intuitive to work with
Format could be something like:
This is in the early stages so we are asking for input as well as having a few specific questions for developers – with backwards compatibility being a major concern: - It is currently possible to serialise a mamaDateTime by using the native bitmask format directly – is anyone out there currently doing this and relying on this being possible? - For bridge developers, how do you currently encode timestamps? - Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
Thanks Stuart
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
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
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
|
|||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||
|
Re: New feature: Extending timestamp format
Stuart Beattie
Hi Nigel,
Apologies, yes I meant to mention timezones in the original email as something to consider
- Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
“addition of a timestamp” was meant to be “timezone”, my mistake.
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 28 September 2016 17:36 To: Stuart Beattie <sbeattie@...>; openmama-dev@... Subject: RE: New feature: Extending timestamp format
If contemplating a new type, is it worth considering the question of time zones? The current model doesn’t really address this, although the java constructors have some implicit assumptions that DateTime objects are stored in UTC
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Stuart Beattie
Hi everyone,
We are currently investigating an approach to improve and extend the handling of date/times in OpenMAMA.
The current mamaDateTime type, essentially being a 64-bit bitmask, is inflexible and has some built in limitations – such as the 4-byte second field limiting the maximum stored date to the year 2106, as well as being limited to time since the epoch. The current datetime format is this:
So while there are currently some bytes available to extend this somewhat, if these are used there will be no more room for expansion or new features in the existing format so we are thinking of a more long-term solution.
Instead we are proposing to introduce a new datetime format using a new type which is an actual struct with separate fields for the different elements (seconds, date, time etc.) While this may be larger (in terms of storage size – eg some bits may go unused), it would have the advantages of: a) Being more extensible – fields could be added or changed as necessary without being bound by the current 64 bits b) Being more intuitive to work with
Format could be something like:
This is in the early stages so we are asking for input as well as having a few specific questions for developers – with backwards compatibility being a major concern: - It is currently possible to serialise a mamaDateTime by using the native bitmask format directly – is anyone out there currently doing this and relying on this being possible? - For bridge developers, how do you currently encode timestamps? - Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
Thanks Stuart
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
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 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: New feature: Extending timestamp format
Phelan, Nigel
If contemplating a new type, is it worth considering the question of time zones? The current model doesn’t really address this, although the java constructors have some implicit assumptions that DateTime objects are stored in UTC
Nigel
Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan
From: openmama-dev-bounces@...
[mailto:openmama-dev-bounces@...] On Behalf Of Stuart Beattie
Sent: Wednesday, September 28, 2016 5:23 PM To: openmama-dev@... Subject: [Openmama-dev] New feature: Extending timestamp format
Hi everyone,
We are currently investigating an approach to improve and extend the handling of date/times in OpenMAMA.
The current mamaDateTime type, essentially being a 64-bit bitmask, is inflexible and has some built in limitations – such as the 4-byte second field limiting the maximum stored date to the year 2106, as well as being limited to time since the epoch. The current datetime format is this:
So while there are currently some bytes available to extend this somewhat, if these are used there will be no more room for expansion or new features in the existing format so we are thinking of a more long-term solution.
Instead we are proposing to introduce a new datetime format using a new type which is an actual struct with separate fields for the different elements (seconds, date, time etc.) While this may be larger (in terms of storage size – eg some bits may go unused), it would have the advantages of: a) Being more extensible – fields could be added or changed as necessary without being bound by the current 64 bits b) Being more intuitive to work with
Format could be something like:
This is in the early stages so we are asking for input as well as having a few specific questions for developers – with backwards compatibility being a major concern: - It is currently possible to serialise a mamaDateTime by using the native bitmask format directly – is anyone out there currently doing this and relying on this being possible? - For bridge developers, how do you currently encode timestamps? - Does anyone have any other suggestions for the new format? For example, nanosecond precision, addition of a timestamp, or any other useful features?
Thanks Stuart
STUART BEATTIE Senior Software Engineer
O. +44 28909 93365 M.
Adelaide Exchange Building, 2nd Floor, 24-26 Adelaide Street, Belfast, BT2 8GD velatradingtech.com | @vela_tt
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
|
|||||||||||||||||||||||||||||||||
|
|
