[
https://issues.apache.org/jira/browse/SOLR-17834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18011987#comment-18011987
]
Chris M. Hostetter commented on SOLR-17834:
-------------------------------------------
FWIW, I spent a little time skimming dd28664ab85c7ad5c541755ff7693128594e68b1,
and went down a few rabbit holes trying to figure out how it might be causing
this bug, by trying to focs n where/how the value substitutions happen. In the
commit, the only thing that seems to change about this is fixing a typo in the
method name...
{noformat}
- public String subtituteVal(String s) {
+ private static String substituteVal(String s) {
return PropertiesUtil.substitute(s, SUBSTITUTES.get());
}
{noformat}
...most of the dead ends i got stuck in where assuming that the changes to
when/how this method is called must have introduced some situations when it was
no longer being called.
But when i took a step back and really looked at how that method is defined, i
realized:
* The method call is static
* SUBSTITUTES is not an instance variable, it's also a static
...which made no sense, since we're not *only* dealing with system properties,
we're also dealing with collection & core properties.
And that's when i discovered that that SUBSTITUTES is a ThreadLocal variable.
... oy.
So this opens up a whole new set of possible ways that even minor changes to
this code (like this commit) could make things go wrong.
Here's one situation, that I don't *know* for ertain is the cause of this bug,
but i think *might* be the cause of this bug...
* Code Logic:
** Some caller code path sets the SUBSTITUTES thread local using
configoverlay.json
** That code path then creates a hierarchy of ConfigNode/DataConfigNode
instances from the config
** Then caller "resets" the SUBSTITUTES – expecting that the substitutions are
still "applied" to the hierarchy of ConfigNode's it's code
* Before dd28664ab85:
** The usage of {{SimpleMap}} in the API resulted in various calls to it's
{{asMap()}} method (and the underlying {{forEachEntry}} method) when creating
this hierarchy
** And because of how {{DataConfigNode.wrap(...)}} was defined, means that
anyone that consumed the result of one of these {{SimpleMap.asMap()}} calls
applied to it got a final map where {{SUBSTITUTES}} were applied _when that_
{{SimpleMap.asMap()}} _was invoked_
* After dd28664ab85:
** No usage of {{SimpleMap}} in the API, so no calls to {{asMap()}}
** The original maps are either used "as is" or are wrapped up in
{{SubstitutingMap}}
** But w/o some equivalent to the old {{asMap()}} call to iterate over all
those entries in that {{{}SubstitutingMap{}}}, nothing forces the substitutions
in the process of creating the ConfigNode hierarchy.
** So instead the final {{Map<String,String>}} instances have get, forEach &
entrySet methods that will happily do _deferred_ substitution – but by the time
they are called, the ThreadLocal is no longer populated.
----
In the absence of anyone having a more concrete understanding of exactly what &
where things are gong wrong – and a specific suggestion for a fix – I would
strongly suggest we revert dd28664ab85 ASAP.
> config API 'set-user-property' no longer has affect on solrconfig.xml:
> notably update.autoCreateFields
> -------------------------------------------------------------------------------------------------------
>
> Key: SOLR-17834
> URL: https://issues.apache.org/jira/browse/SOLR-17834
> Project: Solr
> Issue Type: Bug
> Affects Versions: 9.8, 9.9
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-17834.hack.test.patch
>
>
> As (indirectly) discovered by tim610156 on the solr-user mailing list,
> Something broke between 9.7.0 and 9.8.0 that (evidently) causes the
> {{set-user-property}} command to no longer modify the variables resolved when
> the {{solrconfig.xml}} is re-loaded as part of the resulting core/collection
> reload.
> *MOST NOTABLY*
> This mean that our well documented instructions for disabling
> {{autoCreateFields}} no longer seems to have any effect...
> {noformat}
> hossman@slate:~$ curl -sS 'http://localhost:8983/solr/test/schema/fields' |
> grep bogus
> hossman@slate:~$ curl http://localhost:8983/solr/test/config -d
> '{"set-user-property": {"update.autoCreateFields":"false"}}'
> {
> "responseHeader":{
> "status":0,
> "QTime":245
> },
> "WARNING":"This response format is experimental. It is likely to change in
> the future."
> }hossman@slate:~$
> hossman@slate:~$ curl
> 'http://localhost:8983/solr/test/update?commitWithin=1000&overwrite=true' -H
> 'Content-type: application/json' --data
> '[{"id":"hoss","bogus_field":"bogus_value"}]'
> {
> "responseHeader":{
> "status":0,
> "QTime":191
> }
> }hossman@slate:~$
> hossman@slate:~$ curl -sS 'http://localhost:8983/solr/test/schema/fields' |
> grep bogus
> "name":"bogus_field",
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
