cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11258) Repair scheduling - Resource locking API
Date Mon, 16 May 2016 23:33:12 GMT


Paulo Motta commented on CASSANDRA-11258:

bq. Since renewLease() is both for creating new leases and renewing them I think it should
check both that the lease is held by the local node and that the TTL has been updated, otherwise
the call to lease.renew() might be successful even though the update of the lease was unsuccessful.

Sounds good! Perhaps we can add an {{expirationTime}} column to the lease table and compare
it with the current value to see if it was updated, to avoid keeping track of TTLs? This would
also provide a means for other nodes to check when the current lease will expire if necessary.

bq. I'm more for the "return false" approach here the code feels both easier and cleaner,

+1 to returning false.

bq. In our case we have a TTL of 60 seconds for the primary key column so this is only a problem
if you create the lease and renew it directly for a small duration like 10 seconds and let
it expire.

Got it, thanks for the clarification! I was initially thinking {{renewLease}} would only extend
the current lease period, but updating it for a smaller period might be a valid use case.
We should probably make this more explicit  in the {{renewLease}} javadoc.

> Repair scheduling - Resource locking API
> ----------------------------------------
>                 Key: CASSANDRA-11258
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Marcus Olsson
>            Assignee: Marcus Olsson
>            Priority: Minor
> Create a resource locking API & implementation that is able to lock a resource in
a specified data center. It should handle priorities to avoid node starvation.

This message was sent by Atlassian JIRA

View raw message