[
https://issues.apache.org/jira/browse/SOLR-17704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133079#comment-18133079
]
Amrit Sarkar commented on SOLR-17704:
-------------------------------------
[~dsmiley] I'd like to take this on. Here's how it maps onto Curator 5.9.0, and
two questions before I start.
Plan (main / 11 only):
* Locks we own use {{InterProcessReadWriteLock.ReadLock}}/{{WriteLock}} on the
existing lock dirs. Their blocking rules match ours (reads blocked by a lower
write, writes by any lower node). Lock ids come from {{getLockPath()}}.
* Mirrored locks (SOLR-18011) stay Solr-side. Curator keys ownership by thread,
and {{release()}} always deletes the node, so it can't adopt the parent's lock.
The mirror only needs to check the parent's node exists.
* ConfigSet locks move in the same PR.
* Adds {{curator-recipes}} (same version as framework/client). Class names keep
"Zk".
What we gain: the hand-written wait/watch logic in {{ZkDistributedLock}} and
the NoNode retry go away. Lock nodes get {{withProtection()}}, so a create
retried after connection loss can't leave a ghost node blocking everyone until
session expiry. Creating each level's node only once the level above is
acquired also fixes an existing leak, where a failure creating a lower level
orphans the upper levels' nodes. The mirror path stays custom.
Questions:
* {{isAcquired()}} has no production callers, and Curator can't answer it
without holding a node. OK to drop it and rewrite the lock tests to assert on a
{{waitUntilAcquired()}} future?
* Mixed versions: old read locks look for a {{W_}} prefix and won't see Curator
write nodes, so 10.x and 11 nodes could run conflicting commands during a
rolling upgrade. Since the 10 upgrade notes already say Overseer mode isn't
rolling-safe, I'd document a full restart for Overseer-disabled clusters moving
to 11, rather than gating on {{fetchLowestSolrVersion}} and shipping both
implementations. Does that work?
> Change ZkDistributedLock to use Curator Recipes
> -----------------------------------------------
>
> Key: SOLR-17704
> URL: https://issues.apache.org/jira/browse/SOLR-17704
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Now that Solr is using Curator Recipes for connection management, we can
> finally use it to replace Solr code. ZkDistributedLock looks like very
> low-hanging fruit, used by the non-Overseer distributed mode. That mode is
> still experimental so we can change it in backwards-incompatible ways in Solr
> 10.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
