[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16246858#comment-16246858
]
David Smiley commented on SOLR-11487:
-------------------------------------
* The zkVersion int need not be volatile because it is only ever read/written
from within synchronized block. Any way, if you want to try to put it back in
Aliases, that's fine. I found it a bit annoying to have Aliases with zkVersion
yet also find a way to set it despite Aliases immutability. Nothing that we
can't figure out but it was that trip-up that led me to the path of zkVersion
decoupled from the Aliases class.
* I introduced a bug causing the AliasIntegrationTest.test() failure.
ZkStateReader.createClusterStateWatchersAndUpdate should call refreshAliases
with the field reference aliasesHolder instead of constructing a new instance.
This took a while to figure out; DEBUG logging (with additional log statements
and references to "this" to get the object ID) proved indispensable. I think
this bug would never have happened if the AliasesManager did not implement
Watcher but instead had a newWatcher() method to return an anonymous instance.
* At the end of CreateAliasCmd.call, I sadly think we need to put back the
100ms wait (I added more commentary below):
{code}
// Give other nodes a bit of time to see these changes. Solr is eventually
consistent, so we expect other Solr nodes
// and even CloudSolrClient (ZkClientClusterStateProvider) to eventually
become aware of the change.
Thread.sleep(100);
{code}
If we remove it with this new change for metadata, we might add more test
instability (and it's already on fire) or increase the likelihood that some
real code out there won't work. The caller should sleep perhaps but that's also
sad. I've been ruminating on this a bit and may file an issue with more
specific ideas.
* in CollectionsHandler, LISTALIASES_OP (~line 480) add this line:
{code}
zkStateReader.aliasesHolder.update(); // just in case there are changes being
propagated through ZK
{code}
> 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_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]
