I dug into this some more and it looks like the issue is related to this
commit from February:
http://github.com/kr/beanstalkd/commit/65cb78d52a36055390cffa6068bd654273c96a1b

The socket activity thing is just a side effect of where conn_set_evq()
is called within the reply functions.

The problem as far as I can tell is that there is a race condition
between the timeout that is set inside conn_set_evq() and the while loop
inside h_conn_timeout().

If the condition is (j->deadline >= time(NULL)) then when the timeout
from conn_set_evq() is fired, deadline == time(NULL), the break happens,
and the job is not timed out.  Additionally, further timeouts on that
connection will not occur (as there is no code to set further timeout
events), leading to the problem I observed.

If the condition is (j->deadline > time(NULL)) then when the timeout
from conn_set_evq() is fired the break doesn't occur and the job timeout
logic is applied.

It seems that in the former case jobs will never timeout without some
external trigger (such as socket activity), regardless of TTR value.

In the latter case a timeout will definitely occr but up to 1 second
early in the worst case.

The only real fix for this is to use higher resolution timings as noted
in http://github.com/kr/beanstalkd/issues#issue/5.

Keith, how far away is the higher resolution timeout stuff? :)

Yun Huang Yong wrote:
> Using beanstalk 1.3 I find that if I put a job with TTR=5 and reserve it
> indefinitely the job will not time out until the client that reserved
> the job does something on its socket.
> 
> i.e. using 2 telnet sessions:
> 
> Session #1:
>     put 1 0 5 1
>     b
>     INSERTED 2
> 
> Session #2:
>     stats-job 2  (repeatedly)
> 
> I observe that the 'time-left' falls to 0, then overflows negative
> (time-left: 4294967249) but the 'timeouts' stays on 0.
> 
> As soon as I return to Session #1 and run a 'stats' or anything then the
> 'timeouts' increments and the job returns to ready state.
> 
> Is this the expected behaviour?
> 
> From the protocol doc I would have expected the TTR to be enforced
> regardless of what the client does.
> 
> cheers,
> yun
> 
> 


-- 
Yun Huang Yong
[email protected]                           ...nom nom nom
+61 408 131 419
--

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"beanstalk-talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/beanstalk-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to