Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 19 13:44

    fquinner on next

    Disable cloudsmith for centos s… Updated centos stream with ga l… (compare)

  • May 19 13:44
    fquinner closed #457
  • May 19 13:37
    fquinner opened #457
  • May 18 21:36
    fquinner closed #450
  • May 18 21:36
    fquinner commented #450
  • May 18 21:35
    fquinner closed #449
  • May 18 21:35
    fquinner commented #449
  • May 18 21:35
    fquinner closed #456
  • May 18 21:35
    fquinner commented #456
  • May 18 21:34

    fquinner on next

    Dropped fedora builds in favour… Fixed gradle builds for Gradle … (compare)

  • May 18 21:34
    fquinner closed #455
  • May 18 21:07
    fquinner synchronize #455
  • May 18 18:51
    fquinner commented #456
  • May 18 18:42
    fquinner commented #456
  • May 18 18:39
    fquinner opened #456
  • May 18 18:32
    fquinner opened #455
  • May 18 16:00
    fquinner closed #451
  • May 18 16:00
    fquinner commented #451
  • May 11 16:09
    fquinner closed #448
  • May 11 16:09
    fquinner commented #448
fquinner
@fquinner
OK awesome cheers will keep an eye out!
Windows looks better now anyway!
fquinner
@fquinner
That's it merged now thanks!
Chris Morgan
@cjwmorgan-sol
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?
Chris Morgan
@cjwmorgan-sol
Also I checked out the OpenMAMA docker image looks like the "latest" tag points to 6.2.2? Will there be a 6.3.0 docker image? Also will there be docker images for release candidates? (I am interested in how and what to expect for docker image release for openmama.)
fquinner
@fquinner
Yeah I'm OK for changing to be honest I don't think many people make use of submsg anyway, and updating to support would be an easy fix
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
Chris Morgan
@cjwmorgan-sol
@fquinner when do think you get commit the bridge interface updates?
fquinner
@fquinner
I thought you were working on those?
Or do you mean something unrelated to #297?
Chris Morgan
@cjwmorgan-sol
Nope, I can update the bridge interface if you need me to. I only got a build environment for c and cpp but I think the bridge interface is only accessed through c so all the other bindings would be fine, correct?
Chris Morgan
@cjwmorgan-sol
Also @fquinner do you think that making the bridge interface consistent would be a good idea? For example mamaMsg_updateSubMsg should now pass a mamaMsg to the payload when the mamaMsg_addMsg passes a msgPayload? Should updated as well to make the api consistent?
fquinner
@fquinner
yes for the bridge, C is all you need to worry about
and yes I think mamaMsg is better leaves opportunity open for transcoding
(and thanks :))
Chris Morgan
@cjwmorgan-sol
Hey @fquinner do you think mamaMsg_applyMsg is also a candidate for transcoding message from the payload bridge?
Chris Morgan
@cjwmorgan-sol
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.
fquinner
@fquinner
It probably is worth it yeah but would need to run that one by the mailing list I know its much more commonly used so community may be more opposed to breaking changes in that area
Chris Morgan
@cjwmorgan-sol
Hmm looks like some tests that were disabled (which I accidently enabled) failed. Interestingly enough they passed when I ran them. I guess the qpid bridge has some issue with those tests?
Nope my testing scripts try to skip certain tests that's probably why
Chris Morgan
@cjwmorgan-sol
Looks like the only test failures are the ones a accidentally enabled. I'll disable them again to hopefully get a clean merge.
fquinner
@fquinner
Awesome sounds good thanks!
Chris Morgan
@cjwmorgan-sol
Looks like I got a clean build for #397.
fquinner
@fquinner
Yeah I saw that thanks will get a proper review shortly, need to send note out to mailing list too
Chris Morgan
@cjwmorgan-sol
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>?
Chris Morgan
@cjwmorgan-sol
I noticed that the sample qpid bridge includes internal wombat common source directories in it's cmake lists. Are bridges required to have the openmama source in order to build? I was under the impression that bridges no longer needed openmama source to build.
fquinner
@fquinner
Bridges definitely shouldn't need openmama source to build that's what the integration headers are supposed to be for (if required)
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
fquinner
@fquinner
If it was an external bridge it wouldn't do that
Chris Morgan
@cjwmorgan-sol
Ok sounds reasonable to me, thanks. After #397 gets merged and a fix for #398 is done do you think it would be a good point to get a 6.3.0-rc2?
fquinner
@fquinner
Yeah I have been on holidays most of August (and still am) hence the tardiness :)
fquinner
@fquinner
New OpenMAMA builds cooking...
fquinner
@fquinner
New builds ready folks
Chris Morgan
@cjwmorgan-sol
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.
fquinner
@fquinner
Erm must have just missed one will check tomorrow - builds were all a clean slate but you have to download the artifacts individually from appveyor so super easy to miss one
Actually just did it from my phone there good hunting :)
Chris Morgan
@cjwmorgan-sol
Other then the missing build artifacts for Linux. OpenMAMA 6.3.0-rc2 passes my tests on linux and windows. Looks good to me for release.
fquinner
@fquinner
Thanks Chris I had actually forgotten to add that to autobuilds since moving to docker but its in again now ready for release
fquinner
@fquinner
New website staging environment is now live: https://openmama.github.io :)
Damian Maguire
@dmagOM
Nice work @fquinner , looks awesome.
Love the ASCIICinema work. Magic.
Bill Torpey
@bill-torpey
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.
Chris Morgan
@cjwmorgan-sol
@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)
fquinner
@fquinner
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
Chris Morgan
@cjwmorgan-sol
"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
Bill Torpey
@bill-torpey
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.