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-13439) Make collection properties easier and safer to use in code
Date Wed, 08 May 2019 04:16:00 GMT

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

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

bq. True, I'll need to adjust refreshAndWatch() to have a return value, but I see no reason
not to do that
can't you get it from {{watchedCollectionProps}} after calling {{refreshAndWatch()}}?

bq. As for expiring vs un-register, its a trade off that favors long term stability and ease
of use at the cost of a thread and some background cpu (and a small timestamp update during
access).
It's not about the thread/cpu. Now (without this patch), there is a consistent behavior for
the {{getCollectionProperties}} on when it comes from cache (there is a watch) or when it's
fetched from ZooKeeper (there is no watch). With the change, this consistency is gone, it
depends on if/when some other thread requested the properties before. If you were to use a
watcher instead of the cache, the fetch from ZooKeeper happens the minimum amount of times
possible (once when the watch is set, and then once per modification in ZooKeeper), if you
rely on the time cache, the amount of times Solr will go fetch the properties becomes both,
bigger, and uncertain.


> Make collection properties easier and safer to use in code
> ----------------------------------------------------------
>
>                 Key: SOLR-13439
>                 URL: https://issues.apache.org/jira/browse/SOLR-13439
>             Project: Solr
>          Issue Type: Improvement
>      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-13439.patch
>
>
> (breaking this out from SOLR-13420, please read there for further background)
> Before this patch the api is quite confusing (IMHO):
>  # any code that wanted to know what the properties for a collection are could call zkStateReader.getCollectionProperties(collection)
but this was a dangerous and trappy API because that was a query to zookeeper every time.
If a naive user auto-completed that in their IDE without investigating, heavy use of zookeeper
would ensue.
>  # To "do it right" for any code that might get called on a per-doc or per request basis
one had to cause caching by registering a watcher. At which point the getCollectionProperties(collection) magically
becomes safe to use, but the watcher pattern probably looks famillar induces a user who hasn't
read the solr code closely to create their own cache and update it when their watcher is
notified. If the caching side effect of watches isn't understood this will lead to many in-memory
copies of collection properties maintained in user code.
>  # This also creates a task to be scheduled on a thread (PropsNotification) and induces
an extra thread-scheduling lag before the changes can be observed by user code.
>  # The code that cares about collection properties needs to have a lifecycle tied to
either a collection or something other object with an even more ephemeral life cycle such
as an URP. The user now also has to remember to ensure the watch is unregistered, or there
is a leak.
> After this patch
>  # Calls to getCollectionProperties(collection) are always safe to use in any code anywhere.
Caching and cleanup are automatic.
>  # Code that really actually wants to know if a collection property changes so it can
wake up and do something (autoscaling?) still has the option of registering a watcher that
will asynchronously send them a notification.
>  # Updates can be observed sooner via getCollectionProperties with no need to wait for
a thread to run. (vs a cache held in user code)



--
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