[
https://issues.apache.org/jira/browse/SOLR-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815831#comment-17815831
]
Chris M. Hostetter commented on SOLR-17148:
-------------------------------------------
{quote}...we tend to be skeptical of Mocks... There is a feeling that without
having robust integration tests, all the components may work individually (i.e
in a heavily mocked sense) but totally fall apart when you connect them up!
{quote}
To be clear, i'm not skeptical of the mock testing – they are great at their
job which is unit testing the contracts of things that interact with the mocked
object(s) – but they are no substitute for a good integration test.
In this particular jira, the underlying bug (IIUC) was in how the config +
overlay was modeled "in memory"; and the mock test added by the patch (had it
existed in the past) may have caught this particular bug. But if at some point
in a the future a person makes a change that breaks where/how that "in memory"
model of the config is _used_ to construct the documentCache, the mock test
probably won't catch that ... but an integration test that introspects the
searcher definitely will.
{quote}Getting searcher object was tricky ... I search in the codebase as well
for other examples but did not find any in test cases.
{quote}
Fair point – it's because most tests only need to worry about the current
searcher, usually in the context of a {{req(...)}} lifecycle – you're in less
common territory of wanting to be able to assert things about a searcher, then
change config in a way that will reload (a new instance of) the SolrCore, then
assert different things about the newsearcher. it's a less common pattern so it
has less test helper code available
{quote}Instead, made a rest call to "admin/metrics" which returns all the cache
objects (documentCache, queryResultCache) registered through SolrIndexSearcher,
only if they are enabled.
{quote}
that also sounds like a perfectly good way to write an integration test of this.
{quote}Also one more point, earlier If cache disabled in SolrConfig then
running set-property to update size of disabled cache would enable the cache.
However, as per new changes that will not happen, it will stay disabled.
{quote}
+1
> Config API lies about setting cache enabled=false
> -------------------------------------------------
>
> Key: SOLR-17148
> URL: https://issues.apache.org/jira/browse/SOLR-17148
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: config-api
> Reporter: Chris M. Hostetter
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Using the stock solr {{gettingstarted}} example, you can run the command
> below and it will give all evidence that it has disabled the document cache:
> {noformat}
> curl -X POST 'http://localhost:8983/solr/gettingstarted/config/'
> -H'Content-type: application/json' -d
> '{"set-property":{"query.documentCache.enabled":false}}'
> {noformat}
> * Api command succeeds
> * {{configoverlay.json}} is updated in ZK
> * SolrCore reloads happen for all of the replicas of this collection
> ...but doesn't actually disable the cache. It's still there and in use (easy
> to verify by executing queries and looking at metrics)
> Explicitly stopping & restarting the solr nodes doesn't fix the problem
> either.
> They {{enabled}} property name appears to be explicitly allowed by the Config
> API, because trying to set other arbitrary properties fails (even when
> supported by the {{CaffieneCache}} impl)...
> {noformat}
> $ curl -X POST 'http://localhost:8983/solr/gettingstarted/config/'
> -H'Content-type: application/json' -d
> '{"set-property":{"query.documentCache.async":false}}'
> {
> "responseHeader":{
> "status":400,
> "QTime":8},
> "errorMessages":["error processing commands, errors:
> [{errorMessages=['query.documentCache.async' is not an editable property],
> set-property={query.documentCache.async=false}}], \n"],
> {noformat}
> ...suggesting that modifying the {{enabled}} property is intentionally
> supported – but doesn't work.
>
> ----
>
> A quick & dirty workaround is setting the size=-1 and ignoring the ERROR in
> the logs on every newSearcher...
> {noformat}
> curl -X POST 'http://localhost:8983/solr/gettingstarted/config/'
> -H'Content-type: application/json' -d
> '{"set-property":{"query.documentCache.size":-1}}'
> {noformat}
> (Which seems to indicate that whatever the problem is, it's specific to
> {{enabled}} – and not a general problem with modifying cache configuration
> via the Config API)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
