tryLock() in DynamoDbLockRegistry cannot claim back expired locks

[karllessard]

See this thread for details.

Basically, the Amazon DynamoDBLock client will never wait long enough to validate that a key has expired.

Optionally, the logic could also be revisited so that 'tryLock()' never waits, as it is expected (not even for the leaseDuration). It should claim the lock if it does not exists. tryLock(time, unit) should be used if waiting is desired. Note that if this logic is changed, current Kinesis channel adapter in spring-cloud-stream must be updated accordingly to make use of tryLock(time, unit) instead

CC: @artembilan

[artembilan]

That's not what we have talked about with you there.

Please, see that commit message:

Fix DynamoDbLockRegistry.tryLock for "fair" time

Since we don't have choice and wait at minimum leaseDuration to be
able to iterate in the Amazon LockClient at least two times and that is
going to be just a contract of this client, so we need to add up a
timeout for the tryLock to that leaseDuration

We can't abandon that tryLock() because it is a part of lock contract and that's really very important to return from the underlying service as quickly as possible.

I might agree that we need to wait as minimum leaseDuration to let it to check the expiration for the lock, but indeed the Kinesis Channel Adapter is not going to be changes since we would like to lock as quickly as possible.
We also can reconsider that withRefreshPeriod(0L) as configurable option to avoid "aggression" as you said.

So, what is your plan so far?

[karllessard]

We can't abandon that tryLock() because it is a part of lock contract...

No problem. Like I said, revisiting the logic in tryLock() was just a suggestion, but I agree keeping it that way.

So, what is your plan so far?

Want me to create a PR for it?

[artembilan]

Want me to create a PR for it?

Sure! That's fully organic evolution of our discussion! 😄