[
https://issues.apache.org/jira/browse/CASSANDRA-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270807#comment-15270807
]
Marcus Olsson commented on CASSANDRA-11258:
-------------------------------------------
I've added the check for if the lease was acquired in the case of a WTE and
also added the mentioned tests to the same branch as before.
I also did some other changes:
* Added javadoc to package/classes (based on the ongoing proposal in the dev
mailing list regarding mandatory comments).
* Changed from insert to update when doing CAS for the lease.
The reason for changing from {{insert}} to {{update}} was that with the
previous {{insert}} a row marker is added with a TTL of 60(default TTL) and it
doesn't get updated when renewing the lease since that uses an {{update}}. So
if we would "forget" a lease or are unable to renew it in time we would have a
row marker that is blocking us from acquiring the lease until the TTL has
expired. Another alternative would be to do a {{SERIAL}} read and check if the
host column isn't set and then either delete it and retry or use update with
CAS. Always using update seemed cleaner for the implementation, but it might be
that this is a small enough issue that the 60 second wait isn't a problem since
it's only the first 60 seconds from when the lease was acquired.
bq. 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.
I had the same thoughts about dtest and it makes more sense to wait until we
have scheduled repairs until we test it like that.
---
Since the comments/implementation details regarding update vs insert shouldn't
affect the interface as such I'll start implementing the repair scheduling. :)
> 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)
