Include jobID in redis keys when using redis as persistent queue

[alionurdemetoglu]

With the current implementation, gearman inserts jobs to Redis using the following format as Redis keys: prefix-functionName-jobUnique => "_gear_-reverse-2fergre34-05h5-123f-asd4-70106fbb4dd8"

I use gearman with Redis as a persistent queue and with another client subscribe Redis queue to track jobs using PSUBSCRIBE. I want to be able to remove a job from the queue. According to the TEXT protocol cancel job requires the jobID (E.g: H:adm:1 ).

A similar issue has already posted before ( #81 ). In addition to that request if gearman includes jobID in Redis keys as the following format : prefix-functionName-jobUnique_jobID => "_gear_-reverse-2fergre34-05h5-123f-asd4-70106fbb4dd8_H:adm:1" getting jobID would be easy without sending another request ( --show-jobs )

Is there any plan to improve plugins/accept requests or spare some time to PRs to improve plugins?

Any response would be kindly accepted.

[p-alik]

Is there any plan to improve plugins/accept requests or spare some time to PRs to improve plugins?

As far as I know there is no such plan.

[esabol]

The current maintainers feel that the persistence plugins were a bad idea, and they don't feel it's worth putting effort into improving them. Maintaining them, certainly. There's no plan to remove them. And @SpamapS has said that, if someone submits a PR to fix some issue with the plugins, the PR will certainly be considered.

For the record, it's more scaleable to have a worker that persists jobs and then another worker to spawn jobs from that persistence store. There are various implementations of this design pattern available if you check other issues related to this topic or search for "GearStore".

[SpamapS]

In addition to all that @esabol said, it's important to note that none of the persistence layers actually persist the job ID. That is a reference to things that are in memory now on the gearmand that you are cancelling from. This is a mistake, and probably should have been implemented with a cancel-by-unique equivalent.

As such, this would be new functionality, and not something I think the project should take on.

I understand it would help you a lot to add the ID, so I'm sorry that this is the answer. However, what will help you even more is if you refactor around a worker that will store your important data safely, and then restore it as-needed.

In fact, as much as I love gearmand, if you're already accepting Redis as a safe place to put data (I personally won't after reading https://aphyr.com/posts/283-call-me-maybe-redis and https://aphyr.com/posts/307-call-me-maybe-redis-redux , though I hear things may have improved), you can use it as a task queue, which is probably what you're using gearmand for as well.