[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225618#comment-16225618
]
David Smiley commented on SOLR-11487:
-------------------------------------
*Aliases.java*
* cloneAliases: you can probably reduce the LOC a lot here using Java 8
streams; see https://stackoverflow.com/a/28288729/92186 for similar code
* AFAICT you've changed the storage of the value side of the map of the
"collections" key to be a List<String> instead of a String (comma delimited).
But since this map is serialized to JSON and back and stored in ZooKeeper,
wouldn't this affect compatibility with aliases.json in existing setups? We
definitely don't want to break things.
* It's a shame that getCollectionAliasMap and getCollectionAliasListMap are no
longer simple getters (albeit with unmodifiable wrappers). I don't think the
extra code & cost is worth true immutability. This is internal code. As a
compromise, perhaps instead you might consider creating a view that splits the
comma on the fly only when it's value is asked for? See Guava
{{Maps.transformValues()}}.
*ZkStateReader*
* The TODO in "exportAliasToZk" is a real concern; we don't want race
conditions between various alias modifications to cause some to be
overridden/ignored. I think there are two parts to this: firstly use ZK
versions when reading/writing aliases.json so that we overwrite the version we
are expecting. This will mean putting the version number in Aliases (see
DocCollection.zknodeversion for the same idea) whenever we read the aliases.
Also, if we do need to retry, that retry loop needs to incorporate fetching the
aliases and doing the modification over again, rather than repeatedly trying in
vain to save the serialized aliases from when it started.
* In AliasWatcher, the LOG.debug should use "{}" template to avoid possible
expensive aliases.toString()
* I very much like that you're removing the hot loop and thinking about
creating abstractions/mechanisms to make it nicer. But I admit the change here
with Observer & Observable seem very odd to me. IMO weird that ZkStateReader
is an Observer (Observable seems more intuitive -- it has state that can be
observed) and likewise it's weird that a Watcher is Observable (wouldn't it
fundamentally be an Observer?). I think you're trying to chain some existing
observable stuff which means the Watchers thus become Observable themselves...
but I don't like the result even if it works. Perhaps instead, you could have
a Watcher subclass called ChainableWatcher, and thus remove the need for
Observable/Observer altogether? I don't know if it's that simple without
trying to tackle it myself, but it's at least an idea.
> 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
> Attachments: 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
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
