Hey @fquinner I'm trying to address the issue described in #297 in the bridge I'm working on and I found that the openmama Payload tests for update sub msg segfault as they still pass a msgPayload not a mamaMsg. I really think the bridge function definition should be updated and the co-responding tests should be updated before 6.3.0 is made to officially release. What you think?
Yeah latest is a copy of whatever was in next at the time I was testing I'll do new release once 6.3.0 is released
Or do you mean something unrelated to #297?
and yes I think mamaMsg is better leaves opportunity open for transcoding
(and thanks :))
Created pull request #397. It does not include changes for mamaMsg_applyMsg @fquinner if you think its worth it to make similar changes let me know.
Nope my testing scripts try to skip certain tests that's probably why
Hey @fquinner I'm having some trouble building my bridges on windows without scons. I've changed how my bridges build to no longer use scons. However my bridge depends on the port.h header which seems to include a <windows/lock.h> which is not a part of the install directory from build openmama with cmake. Should the port.h on windows be including the <windows/lock.h>?
It sounds like the path of least resistance is simply to include those files on windows cmake install
Qpid does it because mama it may not be building against an "installed" openmama codebase so it has to use code relative the source tree
Thanks @fquinner so far so good, I noticed openmama-6.3.0rc2.win.x64.zip link seems to be missing from https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc2, release page though. Win64 seems to build fine for me when I try from source.
Actually just did it from my phone there good hunting :)
https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc2 and https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.0-rc1 are both missing their linux tar archive, see 6.2.3, https://github.com/OpenMAMA/OpenMAMA/releases/download/OpenMAMA-6.2.3-release/openmama-6.2.3.linux.x86_64.tar.gz. @fquinner Was this archive missed like windows?
Love the ASCIICinema work. Magic.
NYFIX, a division of Itiviti AB, has recently released an open-source transport for OpenMAMA based on ZeroMQ which we are calling OZ. We're hopeful that the OpenMAMA community will find OZ helpful, and we look forward to working with everyone in the community to make OZ, and OpenMAMA itself, even better. We encourage everyone to check out OZ at https://github.com/nyfix/OZ.
@fquinner Hopefully a quick question can mamaSubscription_deallocate from a subcsription onDestroy callback? I know before issues did not arise from calling deallocate from onDestroy but with 6.3.1 and the post destroy callback interaction on the subscription object this is likely not the case anymore. Was this ever intended? Would this be supported going forward? (Honestly deallocating an object in an object's callback sounds dubious to me but this was not an issue pre 6.3.1)
Hmm it feels like an antipattern to have to do that but we do usually try and be backwards compatible with this sort of thing so initial reaction (before I have dug any deeper into this) is that post subscription destroy callback should be configurable but would need to look a little deeper
"is that post subscription destroy callback" Yes the subscription destroy callback now holds a lock for the application callback. If the subscription destroy callback deallocates the subscription and the wlock_unlock statement operation on an invalid pointer causing stack corruption.
Easiest solution may well be simply nerf deallocate inside that callback depending on the subscription state but there be dragons everywhere in that stuff and we'd need to make sure that memory would still get cleaned up in all scenarios, languages etc
You may want to take a look at the "MME" (MAMA Managed Environment) code we open-sourced a while back: https://github.com/nyfix/MME. We've been using MME for over ten years to successfully deal with just these kinds of problems. Also see the mailing list message that talks about this in more detail: https://lists.openmama.org/g/Openmama-dev/topic/a_new_mamaresourcepool_api/81909897.