[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16435662#comment-16435662
]
Gus Heck commented on SOLR-11487:
---------------------------------
{quote}Decomposing aliases.json has pros/cons, but it won't remove the
possibility of races between modifying some portion of the aliases state; it
just makes it more rare. So we still need to deal with races in code.... using
a zkVersion with a retry and eventual timeout, etc.
{quote}
The context of the above comment was a discussion where I was suggesting an
alternate storage for the alias metadata (properties). I was proposing a
different style of storing the data (in zk nodes, not as part of aliases.json).
This idea was deemed too costly in terms of "bookkeeping" and dropped. Existing
behavior was retained, and nowhere was there an intent in this ticket to change
the existing behavior with respect to updating aliases. Before and after this
ticket, an update to an alias should have detected prior update to any part of
aliases.json (version change), reloaded state and retried. There is a limit on
the retry loop.
So it depends on what your user means by "running into a race condition..."
* If writing one alias lost an update to a *different* alias, that would be a
bug.
* If two updates to the same alias are racing, that's a "feature." and is
documented the first paragraph of the ref guide docs for CREATEALIAS.
* If the retries were exceeded and the second update eventually returns an
error, that's a feature, and something is causing a LOT of churn in
aliases.json. The retry limit is set high to accommodate a fairly aggressive
unit test I wrote. See
org.apache.solr.common.cloud.ZkStateReader.AliasesManager#applyModificationAndExportToZk
for details.
Much cleanup was done in this code so if there was a bug with one alias
interfering with another it may well have been eliminated but this should be
tested since it was not the focus of our work.
> Collection Alias metadata for time partitioned collections
> ----------------------------------------------------------
>
> Key: SOLR-11487
> URL: https://issues.apache.org/jira/browse/SOLR-11487
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch, SOLR_11487.patch
>
>
> SOLR-11299 outlines an approach to using a collection Alias to refer to a
> series of collections of a time series. We'll need to store some metadata
> about these time series collections, such as which field of the document
> contains the timestamp to route on.
> The current {{/aliases.json}} is a Map with a key {{collection}} which is in
> turn a Map of alias name strings to a comma delimited list of the collections.
> _If we change the comma delimited list to be another Map to hold the existing
> list and more stuff, older CloudSolrClient (configured to talk to ZooKeeper)
> will break_. Although if it's configured with an HTTP Solr URL then it would
> not break. There's also some read/write hassle to worry about -- we may need
> to continue to read an aliases.json in the older format.
> Alternatively, we could add a new map entry to aliases.json, say,
> {{collection_metadata}} keyed by alias name?
> Perhaps another very different approach is to attach metadata to the
> configset in use?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
