GearmanBundle
GearmanBundle copied to clipboard
mmoreram
[Call For Help] - New maintainers for that Package
Hi guys :)
Well, this Issue is not an issue at all, but a call for help. Some years ago I started this bundle, when Symfony 2.0 was a new project, very very new, and I think that has helped a lot of people.
GearmanBundle has more than 50K downloads on Packagist.
It's been a long time since these days, and sadly, I'm not using Gearman anymore. I made it as good as I could, but my work here has ended, I cannot be helpful anymore in this repository and this is something I would really love to avoid. This scenario is affecting on the quality of the repo management (quality of the code, BC Break policy...), and I want it to change.
So, I need some help here. Is anyone interested on being, with @daum, maintainer of this package? I really need to feel that this package is safe and as good maintainer as it deserves :)
Thanks :)
Hi Marc!
Is there any change on this? Any other maintainer? I have to configure a job scheduler in my company's server, and Gearman is one of my main options at this moment. If I finally configure it, I will use this bundle. My symfony skills are medium / low, so I don't know how much help I could give, but I could try to do something :)
We are using this bundle for API access between our site and NetSuite because of the API limit. You can only make one API request at a time so gearman helps us make sure two API requests do no execute at the same time.
I am in the middle of a big project at work but I could see myself helping maintain this project and get it ready for the newer versions of Symfony.
@mmoreram - Maybe interested... If I can convince my current company to switch from beanstalk to gearman (or use them both).
What are you using these days?
I don't have enough time to be the only maintainer on this platform. @bmeynell do you think you could go part time on it too?
One thing I do want to get going is we have a few PR's that I believe should be merged soon. There is one feature which I made the PR and it has been open for a while, then the other is the Symfony 3.0 version which I think we'll want to tag the repo at that point before we bump up the requirements to Symfony 3.0. We could also leave a 2.X branch, right now there is a "2" and "3" branch, but I'm not sure if they were originally meant for Symfony 2.X vs Symfony 3.X. @mmoreram do you have any input on that?
If we don't get merging on at least the 3.0 bump I think this repo is going to end up with tons of forks and not a single main repo.
@mihaileu definitely appreciate all the help you've been doing on your PR for the refactor/Symfony 5/6 support. @mmoreram I don't have access to be able to grant others maintainer status, would you consider doing this and/or updating my permissions?
would it be considerable to migrate to a symfony messenger transport for gearman: https://symfony.com/doc/current/messenger.html#transport-configuration
see also https://packagist.org/packages/slickdeals/gearman-messenger
@daum Oh, I completely miss that. I'm looking for how to add you as administrator of the repository.
@ro0NL you could migrate, however if you are using gearman for two way communication, for example where you send a task to the workers and await the results, then the Symfony messenger as you can't get the result from it back where you dispatched it, unless I missed something on it.
Wouldn't that only work for synchronous messages? I think we'd need to finagling around the dispatch of the message and the handling to make it work. For example, if you have a 5 task that you are trying to do in parallel right now you'd do something like addTask, then runTask, and get the results via the callback. Those 5 would then go to however many gearman workers you have running and be processed and results returned.
With the messenger, I think we'd need to basically make it so that a single message would consist of all 5 tasks, which then would send the message out, get the results and then put it into the handled stamp/results. Very likely there is a better solution for that, but just was my initial thoughts. The current implementation of the slickdeals messenger, dispatches all via background jobs only: https://github.com/Slickdeals/gearman-messenger/blob/f007579f0c141c63eea857332ae7a140e22d5895/src/Transport/Connection.php#L111
maybe i'm oversimplifying it :sweat_smile: im not that much into infrastructural concerns.
as a simple minded developer i only know dispatching command messages for async handlig, and dispatching query messages for sync results