Java publishing is broken in 6.2.1
Yury Batrakov
Classification: Public
Hi team, We found that Java publishing was broken when onSuccess event was introduced. The problem is here - mamapublisherjni.c, function Java_com_wombat_mama_MamaPublisher_initIDs: publisherCallbackMethoOnSuccess_g = (*env)->GetMethodID(env, publisherCallbackClass, "onSuccess", "(Lcom/wombat/mama/MamaPublisher;SLjava/lang/String;)V"); But com.wombat.mama. MamaPublisherCallback doesn't have this method and we get exception when trying to create MamaPublisher object (reproduced with MamaPublisherJava example): Exception in thread "main" java.lang.NoSuchMethodError: onSuccess at com.wombat.mama.MamaPublisher.initIDs(Native Method) at com.wombat.mama.MamaPublisher.<clinit>(MamaPublisher.java:31) at com.wombat.mama.examples.MamaPublisherJava.createPublisher(MamaPublisherJava.java:103) at com.wombat.mama.examples.MamaPublisherJava.run(MamaPublisherJava.java:313) at com.wombat.mama.examples.MamaPublisherJava.main(MamaPublisherJava.java:301) Obvious fix is to add new method to MamaPublisherCallback but it will break the code for those clients who were using publisher events before. What do you think should be the fix for this? --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
|
||||
|
||||
Operation Windows Love Concludes
Frank Quinn <fquinn.ni@...>
Hi Folks, As part of the last round of integration testing prior to the last release, we noticed that Java and C# builds were actually broken and had to be fixed fairly last-minute. To prevent this going forward, I have just merged some changes which: - Removes broken unit tests - Fixes working unit tests (including an actual bugfix spotted by some tests) - Adds running unit tests to ci script This is for both Java and C# builds. Travis builds have also been updated so they will automatically be tested now on each PR raised. This concludes "Operation Windows Love" which has been trickling in changes for over a year now to: - Improve the build experience on windows - Get unit tests running on windows - Get nunit tests running on windows - Get junit tests running on windows - Remove compiler warnings on windows - Modify CI to take advantage of the above Don't get me wrong - there are still a *lot* of things we could still improve upon, but at least we have a decent minimum set to work from now. Cheers, Frank
|
||||
|
||||
Code change(s) just landed on origin/next (Successful)
jenkins@...
Some changes have just been added to the origin/next branch!
[Frank Quinn] Set build product to mamdaall release_scripts/ci-run.py [Frank Quinn] Fixed bug in java deserialization methods mama/jni/src/junittests/MamaTimerCallbacks.java mama/jni/src/junittests/MamaMsgAddArrayMsgWithLength.java mama/jni/src/junittests/MamaMsgGetStringAsCharBuffer.java mama/jni/src/junittests/MamaMsgVectorFields.java mama/jni/src/junittests/MamaPublisherTest.java mama/jni/src/c/mamamsgjni.c mama/jni/src/junittests/MamaMsgTryMethods.java mama/jni/src/junittests/MamaInboxCallbacks.java mama/jni/src/junittests/Main.java [Frank Quinn] Fixed a few jni compiler warnings mama/jni/src/c/mamaconnectionjni.c mama/jni/src/c/mamabasicsubscriptionjni.c mama/jni/src/c/mamajni.vcxproj [Frank Quinn] Added junit unit tests to ci run release_scripts/ci-run.py [Frank Quinn] Set nunit to x86 directory by default site_scons/community/windows.py [Frank Quinn] Added setting of PATH for unit test run release_scripts/ci-run.py [Frank Quinn] Fixes for c# unit tests mama/c_cpp/src/c/mama/log.h mama/dotnet/src/nunittest/MamaSetLogSizeTest.cs mama/dotnet/src/nunittest/MamaPublisherTest.cs mama/dotnet/src/cs/MamaVersion.cs mama/dotnet/src/nunittest/MamaLogMessageTest.cs mama/dotnet/src/nunittest/MamaMsgVectorStringTest.cs release_scripts/ci-run.py mama/dotnet/src/nunittest/NUnitTest.csproj mama/dotnet/src/cs/MAMA.cs mama/dotnet/src/nunittest/SConscript.win mamda/dotnet/SConscript.win mama/dotnet/src/nunittest/MamaSetLogFilePolicyTest.cs mama/dotnet/SConscript.win mama/dotnet/src/cs/AssemblyInfo.cs mama/dotnet/src/nunittest/MamaMsgVectorPriceTest.cs mama/dotnet/src/nunittest/MamaLogTest.cs mama/dotnet/src/nunittest/MamaLogToFileTest.cs [Frank Quinn] Added nunit path for unit test runner release_scripts/ci-run.py [Frank Quinn] Escaped clashes in nunit release_scripts/ci-run.py [Frank Quinn] Fixed jni warnings on win and enabled for linux mama/jni/src/c/mamasubscriptionjni.c mama/jni/src/c/mamajni.c mama/jni/src/c/mamamsgjni.c release_scripts/ci-run.py mama/jni/src/c/mamapublisherjni.c [Frank Quinn] Added setting of JAVA_HOME for travis .travis.yml [Frank Quinn] Added consideration of JAVA_HOME to ci script release_scripts/ci-run.py [Frank Quinn] Updated JAVA_HOME path for travis .travis.yml [Frank Quinn] Fixed some compiler warnings for jni and removed dead code mama/jni/src/com/wombat/mama/Mama.java mama/jni/src/c/SConscript mama/jni/src/c/mamadqpublisherjni.c mama/jni/src/c/mamajni.c mamda/java/com/wombat/mamda/options/MamdaOptionChainListener.java mama/jni/src/c/mamadqpublishermanagerjni.c mama/c_cpp/src/testtools/load/cpp/mamachurncpp.cpp mama/jni/src/c/mamapricejni.c mamda/java/com/wombat/mamda/MamdaSecurityStatusListener.java mama/jni/src/com/wombat/mama/MamaTransport.java mamda/java/com/wombat/mamda/examples/MamdaOptionChainExample.java mama/jni/src/c/mamapublisherjni.c mama/jni/src/c/mamasourcejni.c mama/jni/src/c/mamaconnectionjni.c mamda/java/com/wombat/mamda/examples/MamdaOptionChainViewExample.java mama/jni/src/junittests/MamaMsgTryMethods.java mama/jni/src/c/mamasubscriptionjni.c mama/jni/src/c/mamamsgjni.c
Results for OpenMAMA_Snapshot_Linux 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] Fixed memory leak in MamaMsgField (#331) mama/c_cpp/src/cpp/mama/MamaMsgField.h mama/c_cpp/src/cpp/MamaMsgField.cpp
Results for OpenMAMA_Snapshot_Linux CI run with latest changes:
You may also check CI console output to view the full results.
|
||||
|
||||
Re: [PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField
Frank Quinn <fquinn.ni@...>
Hi Victor, Apologies - yes the website is out of date - I'll update it. We now follow: https://openmama.github.io/openmama_submission_process.html I did raise the PR on your request though: And just merged into next so it will be included in the next release. Cheers, Frank
On Wed, Nov 8, 2017 at 1:39 PM, Victor Maleyev <imnotmindlin@...> wrote: Hey Damian,
|
||||
|
||||
Re: [PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField
Victor Maleyev
Hey Damian,
toggle quoted messageShow quoted text
Could you apply the patch? I thought it's official way to contribute changes - it is documented on openmama.org -> Contribute. 08.11.2017, 14:51, "Damian Maguire" <dmaguire@...>:
|
||||
|
||||
Re: [PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField
Damian Maguire <dmaguire@...>
Hey Victor,
In Github projects, forking is generally the best way to work with the project, and is the recommended approach for raising patches for OpenMAMA - you can actually see the forks used by the likes of myself, Frank and other contributors if you go looking.
Regarding some documentation, you can find a bunch in the 'Contributor Guides' section of the OpenMAMA GitHub page, with the 'Submission Process' page probably the most interesting for you: https://openmama.github.io/openmama_submission_process.html
If you still aren't comfortable with the approach once you've given it a try, or if you hit some difficulties, we can apply the patch for you, but I'd recommend you give it a go - it's a much nicer way of working with the project than sending patches around,
and should let you use a bunch of GitHub's other functionality as well.
Any questions feel free to reach out to me.
Thanks,
Damian
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: Victor Maleyev <imnotmindlin@...>
Sent: 08 November 2017 11:01 To: Frank Quinn Cc: openmama-dev; Damian Maguire; frank@... Subject: Re: [Openmama-dev] [PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField Hi Frank,
I don't know how to make pull requests without forking the project, that's why I sent the patch. Is it possible for you to apply it? Or is it any instruction on how to do pull requests?
08.11.2017, 02:41, "Frank Quinn" <fquinn.ni@...>:
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: [PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField
Victor Maleyev
Hi Frank,
toggle quoted messageShow quoted text
I don't know how to make pull requests without forking the project, that's why I sent the patch. Is it possible for you to apply it? Or is it any instruction on how to do pull requests? 08.11.2017, 02:41, "Frank Quinn" <fquinn.ni@...>:
|
||||
|
||||
Re: [PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField
Frank Quinn <fquinn.ni@...>
Thanks Victor, Yes I can see how that wouldn't have behaved as expected and fix looks sound. Are you going to raise a pull request against the "next" branch for this or do you want me to take it from here? Cheers,
On Mon, 6 Nov 2017, 09:55 Victor Maleyev, <imnotmindlin@...> wrote: Not sure if my previous mail reached the maillist. Adding list admins, sorry if this is inapropriate.
|
||||
|
||||
[PATCH 6.2.1] MAMA C++: Fixed memory leak in MamaMsgField
Victor Maleyev
Not sure if my previous mail reached the maillist. Adding list admins, sorry if this is inapropriate.
--- It is possible to reproduce memory leak using the following: MamaMsgIterator i; for(MamaMsgField field = msg.begin(i); ...; field = *++i) { field.getVectorMsg(...); } Note that field is not reference but object. When calling getVectorMsg() the array of pointers (mLastVectorMsg) is allocated by malloc but when we assign a new value to the field (field = *++i) the allocated array becomes unreachable and can't be deleted. Overloaded assignment operator calling clear before assignment can solve this. Signed-off-by: Victor Maleyev <imnotmindlin@...> From c036b0726464916b2e49d6b1297a2a82404c0359 Mon Sep 17 00:00:00 2001 From: Victor Maleyev <imnotmindlin@...> Date: Fri, 3 Nov 2017 00:14:05 +0300 Subject: [PATCH] Fixed memory leak in MamaMsgField Signed-off-by: Victor Maleyev <imnotmindlin@...> --- mama/c_cpp/src/cpp/MamaMsgField.cpp | 15 +++++++++++++++ mama/c_cpp/src/cpp/mama/MamaMsgField.h | 6 ++++++ 2 files changed, 21 insertions(+) diff --git a/mama/c_cpp/src/cpp/MamaMsgField.cpp b/mama/c_cpp/src/cpp/MamaMsgField.cpp index f2f287c..2cf1270 100644 --- a/mama/c_cpp/src/cpp/MamaMsgField.cpp +++ b/mama/c_cpp/src/cpp/MamaMsgField.cpp @@ -47,6 +47,21 @@ namespace Wombat { } + MamaMsgField::MamaMsgField (const MamaMsgField& field) + : mField (field.mField) + , mFieldDesc (NULL) + , mLastVectorMsg (NULL) + , mLastVectorMsgLen (0) + { + } + + MamaMsgField& MamaMsgField::operator= (const MamaMsgField& field) + { + clear(); + mField = field.mField; + return *this; + } + void MamaMsgField::clear () { if (mFieldDesc) diff --git a/mama/c_cpp/src/cpp/mama/MamaMsgField.h b/mama/c_cpp/src/cpp/mama/MamaMsgField.h index b9b9e73..d8f45b1 100644 --- a/mama/c_cpp/src/cpp/mama/MamaMsgField.h +++ b/mama/c_cpp/src/cpp/mama/MamaMsgField.h @@ -50,6 +50,12 @@ namespace Wombat MamaMsgField ( mamaMsgField field); + MamaMsgField ( + const MamaMsgField& field); + + MamaMsgField& operator= ( + const MamaMsgField& field); + /** * Clear the field. */ -- 2.13.3 -------- Конец пересылаемого сообщения --------
|
||||
|
||||
Re: Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]
Yury Batrakov
Classification: Public Thanks for the details guys!
From: Frank Quinn [mailto:fquinn.ni@...]
Sent: Tuesday, October 03, 2017 8:53 PM To: Yury Batrakov <yury.batrakov@...> Cc: Damian Maguire <dmaguire@...>; openmama-users <openmama-users@...>; openmama-dev <openmama-dev@...> Subject: Re: [Openmama-dev] Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]
Hi Yury,
Yes that method is deprecated because OpenMAMA prefers dynamic loading methods now (so that payloads don't need to be registered in OpenMAMA's core code to load or depend on magic characters).
Have you looked at mamaMsg_createForPayloadBridge? It should do the same thing, but accepts a payload bridge rather than a char identifier and is not deprecated.
Damian also provided some helper functions included 6.2.1 to help look up bridges by name which might be helpful for lookup and cache, including mama_getPayloadBridge.
Cheers, Frank
On Tue, Oct 3, 2017 at 10:07 AM, Yury Batrakov <yury.batrakov@...> wrote:
--- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
|
||||
|
||||
Re: Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]
Frank Quinn <fquinn.ni@...>
Hi Yury, Yes that method is deprecated because OpenMAMA prefers dynamic loading methods now (so that payloads don't need to be registered in OpenMAMA's core code to load or depend on magic characters). Have you looked at mamaMsg_createForPayloadBridge? It should do the same thing, but accepts a payload bridge rather than a char identifier and is not deprecated. Damian also provided some helper functions included 6.2.1 to help look up bridges by name which might be helpful for lookup and cache, including mama_getPayloadBridge. Cheers, Frank
On Tue, Oct 3, 2017 at 10:07 AM, Yury Batrakov <yury.batrakov@...> wrote:
|
||||
|
||||
Re: Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]
Damian Maguire <dmaguire@...>
No problem Yury,
Yes, if I remember correctly the problem here was with some compilers which warned about the declaration of a deprecated method, which meant we wanted to both mark it as deprecated and also silence the deprecation warning at the same time. Not the most straight
forward of things to manage in a portable cross platform fashion unfortunately.
Regarding the deprecated method, the 'mamaMsg_createForPayloadBridge ()' method was specifically created to handle this case - using the payload bridge itself to generate the message, rather than a simple identifier. There's an
accessor for the payload bridges as well - 'mama_getPayloadBridge ()' (declared in mama.h) which you can use to search for an already loaded payload bridge. (it returns NULL in the case of a bridge not being found). Alternatively, 'mama_loadPayloadBridge ()'
will either load the bridge or return an already loaded bridge if it exists.
Thanks,
Damian
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: Yury Batrakov <yury.batrakov@...>
Sent: 03 October 2017 10:07 To: Damian Maguire; openmama-users; openmama-dev Subject: RE: Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I] Classification: For internal use only Hey Damian,
OK, thank you for clarification. The reason why I thought that deprecation warnings should be deleted automatically (after defining MAMA_DLL and BRIDGE preprocessor variables) is the following declaration of mamaMsg_createForPayload MAMAIgnoreDeprecatedOpen MAMAExpDeprecatedDLL( "mamaMsg_createForPayload has been deprecated, use dynamic loading instead!") extern mama_status mamaMsg_createForPayload (mamaMsg* msg, const char id); MAMAIgnoreDeprecatedClose
The background of this question is: I’m writing a middleware bridge which always has to create messages for specific payload - it’s a problem because mamaMsg_createForPayload is deprecated and mamaMsg_create creates messages for “default” payload - the payload initialized by a first bridge created by OpenMAMA. This will be a problem when two or more bridges are loaded to a process.
From: Damian Maguire [mailto:dmaguire@...]
Hey Yury,
I'm not sure the behaviour you're describing is an issue - the purpose of the pragma's is to allow you to use 'deprecated' features of the API without generating warnings, rather than disable the deprecation completely. For example, when we implemented dynamic loading, we deprecated the 'mamaPayloadType' here. However, in order to support legacy clients, we continue to use the type within the MAMA codebase. We generally aim to be 'warning free' in the code, and understand the risks associated with using the type, so where we make use of mamaPayloadType we mark them with MamaIgnoreDeprecatedOpen and MamaIgnoreDeprecatedClose pragma's. This disables the deprecation specific warnings at those sites - for example, here.
Using your code, the equivalent would be:
Which shouldn't warn about the use of b();.
Let me know if that makes sense, or if you have further questions around this.
Thanks,
Damian
DAMIAN MAGUIRE Senior Sales Engineer
O. +44 289 568 0298 M. +44 783 584 4770
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 Yury Batrakov <yury.batrakov@...>
Classification: Public Hi team,
Is MAMAIgnoreDeprecatedOpen supposed to work for Linux with gcc > 4.6? See the following example:
// Next 3 lines were copied from wombat/…/linux/port.h _Pragma ("GCC diagnostic push") _Pragma ("GCC diagnostic ignored \"-Wdeprecated\"") _Pragma ("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
int __attribute__((deprecated)) b() { return 0; }
_Pragma ("GCC diagnostic pop")
int main() { printf("GCC %d %d\n" , __GNUC__, __GNUC_MINOR__); b(); return 0; }
When compiling with 4.8 it shows the following warnings anyway: /opt/gcc/gcc-4.8.1/bin/g++ -Wall -Wextra 123.c 123.c: In function ‘int main()’: 123.c:15:9: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations] b(); ^ 123.c:15:11: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations] b(); ^
But if we place those pragmas around invocation of b() (not around the definition) all warnings go away
--- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy. 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: Did MAMAIgnoreDeprecatedOpen ever work on Linux? [I]
Yury Batrakov
Classification: For internal use only Hey Damian,
OK, thank you for clarification. The reason why I thought that deprecation warnings should be deleted automatically (after defining MAMA_DLL and BRIDGE preprocessor variables) is the following declaration of mamaMsg_createForPayload MAMAIgnoreDeprecatedOpen MAMAExpDeprecatedDLL( "mamaMsg_createForPayload has been deprecated, use dynamic loading instead!") extern mama_status mamaMsg_createForPayload (mamaMsg* msg, const char id); MAMAIgnoreDeprecatedClose
The background of this question is: I’m writing a middleware bridge which always has to create messages for specific payload - it’s a problem because mamaMsg_createForPayload is deprecated and mamaMsg_create creates messages for “default” payload - the payload initialized by a first bridge created by OpenMAMA. This will be a problem when two or more bridges are loaded to a process.
From: Damian Maguire [mailto:dmaguire@...]
Sent: Tuesday, October 03, 2017 10:27 AM To: Yury Batrakov <yury.batrakov@...>; openmama-users <openmama-users@...>; openmama-dev <openmama-dev@...> Subject: Re: Did MAMAIgnoreDeprecatedOpen ever work on Linux?
Hey Yury,
I'm not sure the behaviour you're describing is an issue - the purpose of the pragma's is to allow you to use 'deprecated' features of the API without generating warnings, rather than disable the deprecation completely. For example, when we implemented dynamic loading, we deprecated the 'mamaPayloadType' here. However, in order to support legacy clients, we continue to use the type within the MAMA codebase. We generally aim to be 'warning free' in the code, and understand the risks associated with using the type, so where we make use of mamaPayloadType we mark them with MamaIgnoreDeprecatedOpen and MamaIgnoreDeprecatedClose pragma's. This disables the deprecation specific warnings at those sites - for example, here.
Using your code, the equivalent would be:
Which shouldn't warn about the use of b();.
Let me know if that makes sense, or if you have further questions around this.
Thanks,
Damian
DAMIAN MAGUIRE Senior Sales Engineer
O. +44 289 568 0298 M. +44 783 584 4770
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 Yury Batrakov <yury.batrakov@...>
Classification: Public Hi team,
Is MAMAIgnoreDeprecatedOpen supposed to work for Linux with gcc > 4.6? See the following example:
// Next 3 lines were copied from wombat/…/linux/port.h _Pragma ("GCC diagnostic push") _Pragma ("GCC diagnostic ignored \"-Wdeprecated\"") _Pragma ("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
int __attribute__((deprecated)) b() { return 0; }
_Pragma ("GCC diagnostic pop")
int main() { printf("GCC %d %d\n" , __GNUC__, __GNUC_MINOR__); b(); return 0; }
When compiling with 4.8 it shows the following warnings anyway: /opt/gcc/gcc-4.8.1/bin/g++ -Wall -Wextra 123.c 123.c: In function ‘int main()’: 123.c:15:9: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations] b(); ^ 123.c:15:11: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations] b(); ^
But if we place those pragmas around invocation of b() (not around the definition) all warnings go away
--- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
|
||||
|
||||
Re: Did MAMAIgnoreDeprecatedOpen ever work on Linux?
Damian Maguire <dmaguire@...>
Hey Yury,
I'm not sure the behaviour you're describing is an issue - the purpose of the pragma's is to allow you to use 'deprecated' features of the API without generating warnings, rather than disable the deprecation completely. For example, when we implemented dynamic
loading, we deprecated the 'mamaPayloadType'
here. However, in order to support legacy clients, we continue to use the type within the MAMA codebase. We generally aim to be 'warning free' in the code, and understand the risks associated with using the type, so where we make use of mamaPayloadType
we mark them with MamaIgnoreDeprecatedOpen and MamaIgnoreDeprecatedClose pragma's. This disables the deprecation specific warnings at those sites - for example,
here.
Using your code, the equivalent would be:
Which shouldn't warn about the use of b();.
Let me know if that makes sense, or if you have further questions around this.
Thanks,
Damian
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 Yury Batrakov <yury.batrakov@...>
Sent: 02 October 2017 17:16 To: openmama-users; openmama-dev Subject: [Openmama-dev] Did MAMAIgnoreDeprecatedOpen ever work on Linux? Classification: Public Hi team,
Is MAMAIgnoreDeprecatedOpen supposed to work for Linux with gcc > 4.6? See the following example:
// Next 3 lines were copied from wombat/…/linux/port.h _Pragma ("GCC diagnostic push") _Pragma ("GCC diagnostic ignored \"-Wdeprecated\"") _Pragma ("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
int __attribute__((deprecated)) b() { return 0; }
_Pragma ("GCC diagnostic pop")
int main() { printf("GCC %d %d\n" , __GNUC__, __GNUC_MINOR__); b(); return 0; }
When compiling with 4.8 it shows the following warnings anyway: /opt/gcc/gcc-4.8.1/bin/g++ -Wall -Wextra 123.c 123.c: In function ‘int main()’: 123.c:15:9: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations] b(); ^ 123.c:15:11: warning: ‘int b()’ is deprecated (declared at 123.c:7) [-Wdeprecated-declarations] b(); ^
But if we place those pragmas around invocation of b() (not around the definition) all warnings go away --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy. 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
|
||||
|
||||
Did MAMAIgnoreDeprecatedOpen ever work on Linux?
Yury Batrakov
Classification: Public
Hi team, Is MAMAIgnoreDeprecatedOpen supposed to work for Linux with gcc > 4.6? See the following example: // Next 3 lines were copied from wombat/.../linux/port.h _Pragma ("GCC diagnostic push") _Pragma ("GCC diagnostic ignored \"-Wdeprecated\"") _Pragma ("GCC diagnostic ignored \"-Wdeprecated-declarations\"") int __attribute__((deprecated)) b() { return 0; } _Pragma ("GCC diagnostic pop") int main() { printf("GCC %d %d\n" , __GNUC__, __GNUC_MINOR__); b(); return 0; } When compiling with 4.8 it shows the following warnings anyway: /opt/gcc/gcc-4.8.1/bin/g++ -Wall -Wextra 123.c 123.c: In function 'int main()': 123.c:15:9: warning: 'int b()' is deprecated (declared at 123.c:7) [-Wdeprecated-declarations] b(); ^ 123.c:15:11: warning: 'int b()' is deprecated (declared at 123.c:7) [-Wdeprecated-declarations] b(); ^ But if we place those pragmas around invocation of b() (not around the definition) all warnings go away --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
|
||||
|
||||
Re: OpenMAMA static analysis
Bill Torpey
Hi All:
toggle quoted messageShow quoted text
I’ve completed a draft version of my latest article on static analysis, using clang and cppcheck on the OpenMAMA code. It can be found at: http://btorpey.github.io/lots-o-static/ I’m very interested in any comments, suggestions, etc. that the members of the community may have! Regards, Bill Torpey
|
||||
|
||||
Re: RFC for Source Discovery
Keith Rudd
Classification: Public My feedback:
Why was extending the existing MamaTransport Callback interface not considered as an approach?
All sources are available only in the context of a Mama Transport. Middleware bridges already can use the Transport Callback interface to inform when the transport is connected, disconnected, has a data quality change etc. It seems a fairly logical extension to me for basically the same mechanism (with an extra callback or two) to be used to relay other information about this connection (transport), including what sources are available on it, changes to the status of those, if that info becomes available.
I agree with the requirement to provide info on source names as strings, ids as integers. For capabilities, using strings is perhaps best in practice to cope with the fact that the list of possible capabilities could change and may not be completely definable up front. We need some standardization around this though (defined set of strings?) since I can see people wanting to process this capability info automatically and it is reasonable to expect that exactly equivalent capabilities could be provided by different middlewares – need to ensure they name them the same way in that case.
Regards, Keith
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Tom Doust
Sent: 20 September 2017 12:21 To: fquinn.ni@...; openmama-dev <openmama-dev@...> Subject: Re: [Openmama-dev] RFC for Source Discovery
I have some feedback about the RFC for OpenMAMA Source Discovery page: https://openmama.github.io/openmama_rfc_source_discovery.html# I’m pretty much in agreement with delivering the source descriptions and notification encoded in MAMA messages, it significantly reduces the work required to deliver an implementation and also simplifies things for application writers. However, I’d like to suggest that rather than build a new API around a notional “source discovery object” as the RFC suggests, we simply make requests on the existing market data subscription API and differentiate by specifying
a “special” source name (similar to how dictionary subscriptions are made ) This will work for both initial “discovered source” messages and updates to source status. This approach works well enough in the Tick42 TREP bridge. The main benefit of this approach
is that in its simplest form it requires NO code to be written in the mama infrastructure and avoids having to replicate the API across each of the language bindings. I think that defining the fields as properties as indicated is necessary as it effectively defines the message schema but there are a couple of potential issues that are not covered by the RFC
Is it possible to attribute a source with a data dictionary? I suspect that currently the assumptions made about field names in some of the MAMDA code effectively limit to a single data dictionary. This is an area that needs to be carefully explored and potentially tidied up. Best regards
Tom Doust
From:
openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Frank Quinn
Hi Folks,
We have a new RFC contributed by Arcontech to cover the upcoming Source Discovery functionality. Thanks very much to the Arcontech folks for taking the time to put this together.
You can find it listed here:
As a reminder of the RFC process and how to get involved, I'll refer you all to:
Pay particular attention to the most constructive ways to provide feedback: https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback
As per our process, we will leave this RFC open for a period of 2 weeks, after which point if there are no major concerns, the RFC design will be considered approved and work can begin.
Cheers, Frank --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
|
||||
|
||||
Code change(s) just landed on origin/next (Successful)
jenkins@...
Some changes have just been added to the origin/next branch!
[Frank Quinn] Added C# generated files to gitignore .gitignore [Frank Quinn] Fixed build for C# unit tests mama/dotnet/src/nunittest/NUnitTest.csproj mama/dotnet/src/nunittest/MamaPublisherTest.cs mama/jni/src/junittests/MamaPublisherTest.java
Results for OpenMAMA_Snapshot_Linux CI run with latest changes:
You may also check CI console output to view the full results.
|
||||
|
||||
Re: RFC for Source Discovery
Tom Doust
I have some feedback about the RFC for OpenMAMA Source Discovery page: https://openmama.github.io/openmama_rfc_source_discovery.html# I’m pretty much in agreement with delivering the source descriptions and notification encoded in MAMA messages, it significantly reduces the work required to deliver an implementation and also simplifies things for application writers. However, I’d like to suggest that rather than build a new API around a notional “source discovery object” as the RFC suggests, we simply make requests on the existing market data subscription API and differentiate by specifying
a “special” source name (similar to how dictionary subscriptions are made ) This will work for both initial “discovered source” messages and updates to source status. This approach works well enough in the Tick42 TREP bridge. The main benefit of this approach
is that in its simplest form it requires NO code to be written in the mama infrastructure and avoids having to replicate the API across each of the language bindings. I think that defining the fields as properties as indicated is necessary as it effectively defines the message schema but there are a couple of potential issues that are not covered by the RFC
Is it possible to attribute a source with a data dictionary? I suspect that currently the assumptions made about field names in some of the MAMDA code effectively limit to a single data dictionary. This is an area that needs to be carefully explored and potentially tidied up. Best regards
Tom Doust
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Frank Quinn
Sent: 13 September 2017 11:53 To: openmama-dev <openmama-dev@...> Subject: [Openmama-dev] RFC for Source Discovery
Hi Folks,
We have a new RFC contributed by Arcontech to cover the upcoming Source Discovery functionality. Thanks very much to the Arcontech folks for taking the time to put this together.
You can find it listed here:
As a reminder of the RFC process and how to get involved, I'll refer you all to:
Pay particular attention to the most constructive ways to provide feedback: https://openmama.github.io/openmama_rfc_process.html#how-to-provide-rfc-feedback
As per our process, we will leave this RFC open for a period of 2 weeks, after which point if there are no major concerns, the RFC design will be considered approved and work can begin.
Cheers, Frank
|
||||
|