Beanstalkd: support reserving a specific job by id

[JensRantil]

Idea:

reserve-job <id>

Output:

RESERVED <id> <bytes>\r\n
<data>\r\n

or

ALREADY_RESERVED\r\n

or

NOT_FOUND\r\n

This would fix #109 and #20 and lots of other cases where one would like to modify a job. The ALREADY_RESERVED would make sure that noone is processing the job, before I modify it.

I don't know the code (yet), would it be somewhat efficient to execute reserve-job <id>?

[JensRantil]

This would also fix #170.

[JensRantil]

This would allow #222 to reserve a job, delete it and create it using a different delay.

[silviucpp]

I think @kr should approve or not the specs in case he believes will add a benefit to the project. For example I'm ok to spend my time in implementing/fixing different bugs but It will be a waste of time to work on something and to not receive any feedback.

[cmer]

This would be great @kr. It would allow the following use case:

• Web page displays a list of 50 "things" to review. Reserve all 50 things for the current user
• User looks at all the things on web page and clicks "approve", which makes a call to the backend
• Backend reserves the jobs again and deletes them.
• If user doesn't approve things fast enough, the jobs go back in the queue.

I'm not sure if this use case is currently possible since the beanstalk connection will likely be different for every request (displaying the web page, and approving the things)

[silviucpp]

If @kr approves the specs I can implement this . Is not so complicated

[contentfree]

Anyone hear from @kr?

[ysmolsky]

This might fix #240 as well by following sequence of commands:

• reserve-job id-of-a-job-to-move
• put job parameters...

[kr]

This is an excellent idea.

One orthogonal new feature that combines with the rest of the system to make several other commands more powerful.

Regarding the semantics, I kind of think it would be good to have this command get the job not just from the ready queue, but from anywhere (delay, buried) as long as the job isn't reserved by another connection. That would let clients also change the delay time (including to 0) of delayed jobs, and to unbury specific jobs. (That is, if we had had reserve-job from the beginning, we wouldn't have needed things like #120 kick-job.)

[ysmolsky]

it would be good to have this command get the job not just from the ready queue, but from anywhere

Yes, this is what I had in my mind too.

Also I would not introduce the ALREADY_RESERVED response and instead keep using NOT_FOUND for reserved jobs. What is the benefit for the client to know that the job was already reserved? Retry does not make sense because most likely the job will be processed or moved with some new id. Also, changing the response to this command means that we need to fix it for other commands for consistency, and that would definitely break the protocol for existing client libs.

[ysmolsky]

@tw99, please read the comments above.

[ysmolsky]

I am on it.