Gus Heck created SOLR-13439:
-------------------------------
Summary: 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
(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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]