[
https://issues.apache.org/jira/browse/SOLR-17834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-17834:
--------------------------------------
Attachment: SOLR-17834.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
{quote}Perhaps simply addressing specifically that will resolve the regression.
{quote}
That's probably harder then it looks – and i don't think it's fair for users to
have to wait for use to re-architect a major chunk of our config parsing logic
to fix a bug this serious.
----
I polished my HACK test a bit, and then took a stab at a "simple" solution of
making DataConfigNode apply (the ThreadLocal) substitutions on construction,
and modifying SolrConfig to ensure the substition variables where set when
parsing the config. (that seemed like the minimally invasive change for now,
and a good pre-req for getting rid of the thread local later: instead apply
them when parsing the file)
But that caused some really weird test failures that I eventually tracked down
to the way the "root" {{ConfigNode}} objects for each config file get cached in
the {{CoreContainer}} 's {{ObjectCache}} for re-use by multiple-cores that
share the same configset. The cache key doesn't know/care about the variable
substitutions.
So with that in mind, I took a step back, and instead re-reviewed all the ways
the older {{SimpleMap}} based {{DataConfigNode}} was used and when exactly the
substitutions were applied.
In the "old" code, prior to {{dd28664ab85}} , anyone calling
{{DataConfigNode.attributes()}} was immediately calling {{.asMap()}} on the
result – and *THAT* is when the substitutions were getting applied to each of
the values. In {{{}dd28664ab85{}}}, all of those {{.asMap()}} were just
removed, since {{DataConfigNode.attributes()}} (now) returns a
{{{}Map<String,String>{}}}.
So if we ensure that the _result_ of calling {{DataConfigNode.attributes()}}
has the substitutions applied _when the method is called_ *W/O modifying
internal state* of {{DataConfigNode}} then we should at least get back to
everything working as well as it did before {{{}dd28664ab85{}}}. (There is no
guarantee that any code path that calls {{DataConfigNode.attributes()}} will do
so while the ThreadLocal values are set – but we didn't have that guarantee
before either – we just know that any place calling
{{DataConfigNode.attributes()}} gets the same result they would have back when
they were calling {{DataConfigNode.attributes().asMap()}}
So the attached path makes that change and has a new beefier test that passes –
still a few nocommits related to some more tests I still want to write.
> 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.9, 9.8
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-17834.hack.test.patch, SOLR-17834.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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
