[
https://issues.apache.org/jira/browse/CASSANDRA-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267278#comment-15267278
]
Paulo Motta commented on CASSANDRA-11258:
-----------------------------------------
Thanks for the update. The API definition and initial tests are looking good.
Just a few more things:
- It seems we are still considering timeouts as failures to acquire the lock,
but we must also check if the lock was acquired with a {{SERIAL}} read after a
write timeout to avoid a resource being leased but no one using it.
- Can you add unit test cases manually removing or modifying rows on
{{resource_lease}} and {{resource_lease_priority}} and make sure {{isValid}}
and {{renew}} return false, as well as new locks cannot be acquired if the lock
is held on {{resource_lease}} but not on {{resource_lease_priority}} (these
would simulate nodes out of sync or manual tampering lease tables).
While it would be interesting to add dtests to make sure leases are working in
a distributed environment, we would probably need to expose the
{{LeaseFactory}} interface over JMX, but we want to keep this strictly internal
to avoid external misuse. So it's probably better to move on and test this more
extensively on dtests via scheduled repairs, for instance by triggering
simultaneous scheduled repair requests and modifying the resource lease tables
manually to test leases in scenarios with tampering, network partitions and
nodes out of sync, so let's leave this for a future task.
After the previous points are addressed we can probably start building repair
scheduling (CASSANDRA-11259) on top of it.
> Repair scheduling - Resource locking API
> ----------------------------------------
>
> Key: CASSANDRA-11258
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11258
> 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
(v6.3.4#6332)