-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature] Queue jobs from a project to workers on another project #107
Comments
HI there! Thanks for your comment. Is very useful for me to see that this Bundle is being used by other companies :) Nowadays, Jobs are configured by annotations. When I developed the first version, I figured it was a great idea, but right now, I think it's not. Maybe the best approach for your problem ( and for sure, most people problem ) is to allow workers definition by yml / xml / php as well. With this new feature, you could define more workers with a simple format, allowing to create workers from other servers. Is this a good workaround for U? Maybe we could create a new Milestone to work on it :) Looking forward for your feedback :) Thanks. |
If so workers configuration will not be related anymore to worker code ? For example :
In this case worker configuration is in "Awesome backend" project, and I don't see a good reason for "Awesome frontend" to be aware of this configuration. So being able to chose annotation, xml, yml or php to configure workers could be nice, but I'm not sure that really solve our problem. |
When you talk about projects, maybe could be more useful to talk about Bundles. If you have many projects using same queues, maybe you should focus on "How to share your code". If you Isolate your workers in a simple Bundle, you can require this Bundle in as many projects as you need, and as far as workers configuration are defined in the worker itself, this should work. A worker is just a class that takes data from a "queue" from a server, so I think isolating the workers should be the best solution. Am I right? |
Well for sure it could be a possibility. But we don't want to overload our projects with useless stuff. If I a take back my example, my "Awesome frontend" do not need to be aware of email logic. He just need to be able to ask for a "AwesomeBackendBundle~sendEmail" to be executed . If we were using a shared bundle for each or various workers, it will mean to add theirs dependencies in each project also, so in this case to add Email logic in our "Awesome frontend" who doesn't need them. At small scale it's probably a solution but I think it quickly will have performance and maintainability issues. |
up |
hmmm, I understand... let me think about this. If you have any idea, please let me know. |
Thinking more about that, I've found an even better example. So I bring back my suggestions :
Then we should be able to call |
up ? |
I did not see your answer. Sorry, no time enough :( One of new features for new version is to define new queues using configuration ( yml, php, xml ), so this could fix your problem. We could define new local workers, checking their integrity ( valid classes, etc ) and new foreign workers, just defining queue name. Agree? Your format sounds good to me :) |
Look nice, is this feature logged somewhere ? |
Once the code is done, we could all implement/document it and maybe write GearmanBundle's first cookbook :) How it sounds? ^^ Anyone wants to help? :) Thanks for your feedback ! |
Wait. Can you just use the same name in different projects? Instead of |
yes, you can name a job with specific name, so if you define it, you can name it with same string :) |
Hello !
We use your awesome bundle in many of our projects to handle gearman tasks an jobs and really appreciate it.
Lately we needed to queue a job from a symfony project and have the work done by a worker located on another symfony project.
We discovered that there is a check in GearmanClient:L193 that throw a JobNotFoundException when we try to enqueue the job.
So we made a work-around on our project, overloading GearmanClient with our own one.
We could find some time to implement this feature, so if you think it could be useful, could you point us which solution should be the most appropriated.
Thanks !
The text was updated successfully, but these errors were encountered: