Timeout decreasing on each lock refresh

[rhizoome]

I am not at all sure, what component of the following bug is at fault. The components are LibreOffice using Neon and a commercial WebDav-Server.

The server returns the time until the lock expires as it currently measures it. So it will be less than the requested timeout.

The following happens:

client -> Second-3
server -> Second-2
client -> Second-2
server -> Second-1
client -> Second-0

BOOM. I don't know who is wrong. If I read the spec I think the client is wrong. The clients should always request the timeout it wants and not the timeout returned by the server. This line will update the requested timeout with the timeout returned by the server.

neon/src/ne_locks.c

Line 841 in 5a0f553

lock->timeout = ctx.active.timeout;

I am also not sure if how LibreOffice uses Neon is wrong. Please let me know what you think, so I can decide where to fix the problem.

[notroj]

Not clear to me what the problem is. In your example the lock timeout gets reduced to 0 from 3 in less than three seconds because with each refresh it gets rounded down by one?

[rhizoome]

Yes, exactly. The server sets a timestamp when the lock expires. Later in another function it will calculate timestamp - now cast it to an int, voila the returned timeout is rounded down. I think the server assumes that another connection could have setup that lock, so the calculation is independent.

[notroj]

OK. I'm not sure what neon could or should do different here, it is simply requesting and reporting exactly the timeout values which application request and server report respectively.

The point of doing a lock refresh is to extend the timeout so calling ne_lock_refresh() to request the same locks existing timeout (less <=1 second due to latency+rounding!) seems like an application bug to me.

[notroj]

Also: ne_lock_refresh() can be used to refresh the lock without requesting an adjusted timeout if you set lock->timeout to zero before calling the function, which would avoid the latency/rounding issue.

[rhizoome]

@notroj Thanks a lot, that helps a lot.