Skip to content
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

Ability to provide id and delete for everything #17

Closed
cemremengu opened this issue Jun 2, 2020 · 8 comments
Closed

Ability to provide id and delete for everything #17

cemremengu opened this issue Jun 2, 2020 · 8 comments
Milestone

Comments

@cemremengu
Copy link

Currently you can provide id/name for recurring tasks like:

BackgroundJob.scheduleRecurringly("my-recurring-job", () -> service.doWork(), Cron.daily()); and you can also delete them.

However, for others (enqueue and schedule) you cannot provide a custom id/name or delete them. I think it will be a good enhancement to allow these two options.

@cemremengu
Copy link
Author

By the way, if you agree to these changes I can send a PR for any of the enhancement issues I create. Just let me know please.

@rdehuyss
Copy link
Contributor

rdehuyss commented Jun 3, 2020

I'm happy to foresee a delete api.

But I don't see the need for specifying a custom id. Is there a reason why you need it?

@cemremengu
Copy link
Author

I wanted it so that deleting is easier if we could assign a label to jobs. Otherwise, you have to somehow do a book keeping of the jobids. Is there a way to know which jobid belongs to which job when deleting?

@rdehuyss
Copy link
Contributor

rdehuyss commented Jun 8, 2020

FYI, the delete api is progressing but was really difficult - take for example a long-running job that you want to delete (so it is already processing) when you delete it: I'm now interrupting the Thread so that the processing is cancelled and the job is stopped (even if it has not completed yet).

Regarding the book keeping of jobids - I don't understand your question: "Is there a way to know which jobid belongs to which job when deleting?"

For recurring jobs it makes sense to delete by a custom id that you can provide. But why do you need it for a normal enqueued job? Normally, if you enqueue a standard job and the queue is empty, it will be processed immediately - why would you delete it after enqueueing it?

Perhaps some extra business context can help me understand your exact problem?

@rdehuyss rdehuyss added this to the v0.9.8 milestone Jun 8, 2020
@cemremengu
Copy link
Author

cemremengu commented Jun 8, 2020

Thanks for the improvements, I really would like to contribute as well once I have time too.

Maybe I am overthinking and wrong but cant you have a delayed task that will run 5 hours later? In that case you may want to cancel. Say that you schedule to send an email if you dont receive a particular event in 5 hours. Once you receive the event, you cancel the delayed job. Here you can link the job and event name so that it is easier to match.

Also for deleting, some users may want a graceful option (i.e. wait currently running instance to finish)

@rdehuyss
Copy link
Contributor

rdehuyss commented Jun 9, 2020

I can understand the business scenario but I don't know yet if providing the id for the job is the way to go.

I think it can result in a lot of other issues (what when you have more than one job for the same business concept, what if you enqueue 2 totally different jobs with the same id, ... ).

I'll look if I cannot find another solution that solves the problem...

@cemremengu
Copy link
Author

You may be correct with that intituition since I am currently using redisson and it has no way of providing custom id as well (even for recurring tasks) so I guess it is users responsibility to keep track of those or linking meaningful names instead of the system. Feel free to close the issue whenever you need.

@rdehuyss
Copy link
Contributor

Closing as ok with original poster

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants