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

TTR documentation error #126

Open
pnabutovsky opened this issue Jul 19, 2016 · 4 comments
Open

TTR documentation error #126

pnabutovsky opened this issue Jul 19, 2016 · 4 comments

Comments

@pnabutovsky
Copy link

Looking at the Backburner README doc:

queue_respond_timeout 300 # number of seconds before job times out, 0 to avoid timeout

Looking at the Beanstalk protocol doc:


   The minimum ttr is 1. If the client sends 0, the server will silently
   increase the ttr to 1.

@nesquena
Copy link
Owner

Have you verified this? Was added here 1b06f8e 4e7ef38 by @zacviandier. If so, can you send a PR for the readme?

@pnabutovsky
Copy link
Author

Unfortunately the current job execution code is:


 timeout_job_after(task.ttr > 1 ? task.ttr - 1 : task.ttr) { job_class.perform(*args) }

@zacviandier
Copy link
Contributor

Effectively a change was made in 457bfdf, but anyway the goal here is to send -1 to avoid timeout.

Beanstalk protocol doc:

A positive value of timeout will limit the amount of
time the client will block on the reserve request until a job becomes
available.

I also made some test with different version of Beanstalkd and it doesn't react the same way every time. With 1.4.6-5: works really well but with 1.10 this create a infinite loop where Beanstalkd try to return 1 every time

@ryanjohns
Copy link
Contributor

I came across this issue when trying to implement a job without a timeout and I don't think it's possible with beanstalkd.

I think the confusion here is that you guys are talking about different timeouts. @pnabutovsky is referring to the job TTR which is how long beanstalkd gives the worker that reserved the job to either release, delete, or bury. @zacviandier is referring to the reserve timeout which is how long a client's call to reserve will wait for a job to become available.

A reserve timeout of <= 0 will cause the client to block forever waiting on a job. This makes sense and works well.

It is impossible for a job to have a TTR < 1 as this is enforced by beanstalkd. If you enqueue a job with TTR < 1 backburner will silently set it to 1 instead. So there is no way to set things up such that a job runs until completion ignoring all timeouts. In the line that @pnabutovsky mentioned above, task.ttr will always be >= 1 and therefore timeout_job_after will always raise an exception after >= 1 seconds.

Even if we modified backburner to not raise Timeout::Error, beanstalkd would automatically release the job anyway leading to it getting worked more than once. Probably not desirable for most users.

TL;DR
The only way to effectively have no TTR is to set it to some very high value.

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

4 participants