Hi,
In the consul, I acquired a lock on a key (behaviour = release) and specified a TTL while creating a session. I was expecting the lock to be auto-released after TTL. But it was not released.
Below is my observations:
For TTL of 10sec, lock is auto-released in 35sec
15sec -> 45sec
20sec -> 55sec
25sec -> 65sec
Why is this happening?
[Edit: banks] For someone looking for a simple first issue to tackle, see the description in https://github.com/hashicorp/consul/issues/4508#issuecomment-475289571
How did you configure the LockDelay?
https://www.consul.io/api/session.html
Note the TTL might be doubled as explained in the URL given
Thanks for the response :)
I gave LockDelay of 0 seconds.
Yes, but here it is not double, but little unexpected.
I am not sure of setting 0 means, try with the same value 15s and retry maybe
Based on your suggestion, I tried LockDelay of 1sec as it can be anything from 0 to 60sec. Now, the lock is released in 2*TTL + 1 sec which is predictable :)
Thanks for that. But still, maybe someone can comment what is wrong with LockDelay of 0. Why unpredictable behaviour. This can help someone in the future.
@aakashgyl it actually sounds like if LockDelay has a default value of 15s
@aakashgyl Confirmed: https://github.com/hashicorp/consul/blob/master/agent/session_endpoint.go#L37 => 15s is the default LockDelay.
But I agree it should be in documentation
I do think the LockDelay default is documented: https://www.consul.io/api/session.html#lockdelay. Are you suggesting we should document the behavior differently? Or document the behavior with 0?
Behavior with Lock Delay as 0 should be documented :)
PR #5037 conflicts with the documentation which specifies that a zero value for LockDelay is valid:
While the default is to use a 15 second delay, clients are able to disable this mechanism by providing a zero delay value.
@bkeroackdsc thanks for catching that! Definitely possible that part of the PR could be incorrect. From my understanding of the behavior mentioned in this issue it appears it may be using the default when 0 is specified, but I didn't look too closely and was kind of unsure...if you have any suggestions would appreciate hearing them otherwise will plan to look further at that prior to merging that PR. I guess if the behavior is that it defaults to 15s it may be a bug given those docs.
@pearkes I haven't looked through that section of code, but my reading of https://www.consul.io/docs/internals/sessions.html#session-design (last paragraph of the Session Design section) leads me to believe that passing in a value of zero for LockDelay is valid and disables that feature.
It looks like this is an oversight - logically 0 lock delay is reasonable but in practice we seem to apply the default _after parsing user config_ and so apply the default of 15s if 0 is specified.
I think the fix would involve explicitly setting the default before user config is merged and then accepting 0 as valid afterwards but I've not looked at the code yet. This would probably be a simple change for someone interested to contribute.
Even though it's a bug I think it makes sense to merge https://github.com/hashicorp/consul/pull/5037 then, to document the behavior.
Sorry GitHub auto-closed this because of the syntax. Re-opening!
@aakashgyl Looking into this issue, I was able to use LockDelay: "0s" as a value when curling the Consul API.
I did notice https://github.com/hashicorp/consul/issues/1077, which is that the api.Client provided by github.com/hashicorp/consul/api has a bug where it does not allow LockDelay: 0 * time.Second to be sent.
How exactly did you reproduce this issue? Where you using the API client, or some other method?
@crhino : Sorry but I am not able to recall that. I raised it long back and no longer work on consul.
But if I got you right, I was doing consul operations using Go. And I was using https://github.com/hashicorp/consul/tree/master/api library for the operations.
No worries, that is the information I needed to know! Thanks.
Closing as duplicate of #1077
Hey there,
This issue has been automatically locked because it is closed and there hasn't been any activity for at least _30_ days.
If you are still experiencing problems, or still have questions, feel free to open a new one :+1:.
Most helpful comment
Behavior with Lock Delay as 0 should be documented :)