lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <j...@apache.org>
Subject [jira] [Commented] (SOLR-13420) Allow Routed Aliases to use Collection Properties instead of core properties
Date Thu, 02 May 2019 04:19:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-13420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831405#comment-16831405
] 

Tomás Fernández Löbbe commented on SOLR-13420:
----------------------------------------------

{quote}I'm not sure I understand your concern. It doesn't sound like a problem if a watcher
isn't notified when nobody is watching?
{quote}
At least right now, the watched collections and collection properties are not bundled. A node
could be watching the collection but not the properties or vice-versa. An example of global
component (i.e. a custom CollectionsHandler) could watch properties but not the collection
(meaning, there is no core for the collection in the node)
{quote}Quite the opposite, here's the full context
{quote}
Maybe I’m missing something, but if someone calls {{registerCollectionPropsWatcher}}, then
{{collectionPropsWatches}} will have “collection1”->properties_of_collection1. If you
call {{getCollectionProperties}} on “collection1”, you get the values from cache, however,
the first time there is a change in the properties, the watch will be unset (because watchedCollectionProps
doesn’t necessarily include the same collections as collectionPropsWatches). Since the watch
is unset, new changes in the collection properties won’t be updated.

Again, I don’t think there is need for this caching change, all you need to do is register
a watcher on the properties somewhere in the TRA code, then every time you call {{getCollectionProperties}}
it’ll come from memory.bq. I'm not sure I understand your concern. It doesn't sound like
a problem if a watcher isn't notified when nobody is watching?
 At least right now, the watched collections and collection properties are not bundled. A
node could be watching the collection but not the properties or vice-versa. An example of
global component (i.e. a custom CollectionsHandler) could watch properties but not the collection
(meaning, there is no core for the collection in the node)

> Allow Routed Aliases to use Collection Properties instead of core properties
> ----------------------------------------------------------------------------
>
>                 Key: SOLR-13420
>                 URL: https://issues.apache.org/jira/browse/SOLR-13420
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrCloud
>    Affects Versions: master (9.0)
>            Reporter: Gus Heck
>            Assignee: Gus Heck
>            Priority: Major
>         Attachments: SOLR-13420.patch, SOLR-13420.patch, SOLR-13420.patch
>
>
> The current routed alias code is relying on a core property named routedAliasName to
detect when the Routed Alias wrapper URP should be applied to Distributed Update Request
Processor. 
> {code:java}
> #Written by CorePropertiesLocator
> #Sun Mar 03 06:21:14 UTC 2019
> routedAliasName=testalias21
> numShards=2
> collection.configName=_default
> ... etc...
> {code}
> Core properties are not changeable after the core is created, and they are written to
the file system for every core. To support a unit test for SOLR-13419 I need to create some
legacy formatted collection names, and arrange them into a TRA, but this is impossible due
to the fact that I can't change the core property from the test. There's a TODO dating back
to the original TRA implementation in the routed alias code to switch to collection properties
instead, so this ticket will address that TOD to support the test required for SOLR-13419.
> Back compatibility with legacy core based TRA's and CRA's will of course be maintained.
I also expect that this will facilitate some more nimble handling or routed aliases with future
auto-scaling capabilities such as possibly detaching and archiving collections to cheaper, slower machines
rather than deleting them. (presently such a collection would still attempt to use the routed
alias if it received an update even if it were no longer in the list of collections for the
alias)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message