[ https://issues.apache.org/jira/browse/SOLR-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232131#comment-14232131 ]
ASF subversion and git services commented on SOLR-6780: ------------------------------------------------------- Commit 1643006 from hoss...@apache.org in branch 'dev/branches/lucene_solr_4_10' [ https://svn.apache.org/r1643006 ] SOLR-6780: Fixed a bug in how default/appends/invariants params were affecting the set of all keys found in the request parameters, resulting in some key=value param pairs being duplicated (merge r1642727) > some param values are duplicated when they override defaults, or are combined > with appends values, or are an invariant that overrides a request param > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: SOLR-6780 > URL: https://issues.apache.org/jira/browse/SOLR-6780 > Project: Solr > Issue Type: Bug > Affects Versions: 4.1, 5.0, Trunk > Reporter: Alexandre Rafalovitch > Assignee: Hoss Man > Labels: parameters > Fix For: 4.10.3, 5.0, Trunk > > Attachments: SOLR-6780.patch > > > The {{DefaultSolrParams}} class, which is used as the basis for the > implementation of {{defaults}}, {{appends}} and {{invariants}} params had a > bug in it's implementation of {{getParameterNamesIterator()}} that could > result in the same param key being returned multiple times. > In many code paths of Solr, this bug had no effects -- but in other cases, it > resulted in code which iterated over the list of all parameters to take > action multiple times for the (valid) key=value pairs. > There were 4 main areas where this bug had unexpected & problematic behavior > for end users: > {panel:title=main problem areas & impacts} > * ExtractingRequestHandler > ** "literal.\*" params will be duplicated if overridden by > defaults/invariants/appends - this will result in redundent literal > field=value params being added to the document. > ** impact: multiple values in literal fields when not expected/desired > * FacetComponent > ** "facet.\*" params will be duplicated if overridden by > defaults/invariants/appends - this can result in redundent computation and > identical facet.field, facet.query, or facet.range blocks in the response > ** impact: wasted computation & increased response size > * SpellCheckComponent > ** when "custom params" (ie: "spellcheck.\[dictionary name\].XXXX=YYYY" are > used in used in defaults, appends, or invariants, it can cause redudent > XXXXX=YYYY params to be used. > ** when "spellcheck.collateParam.XXXX=YYYY" type params are used defaults, > appends, or invariants, it can cause redundent XXXX=YYYY params to exist in > the collation verification queries. > ** impact: unclear to me at first glance, probably just wasted computation & > increased response size > * AnalyticsComponent > ** "olap.\*" params will be duplicated if overridden by > defaults/invariants/appends - this can result in redundent computation > ** impact: unclear to me at first glance, probably just wasted computation & > increased response size > {panel} > Other less serious impacts were redundent values in "echoParams" as well as > some small amounts of wasted computation in other code paths that iterated > over the set of params (due to a slightly larger set of param values) > {panel:title=Original bug report: "Merging request parameters with defaults > produce duplicate entries"} > When a parameter (e.g. echoParams) is specified and overrides the default on > the handler, it actually generates two entries for that key with the same > value. > Most of the time it is just a confusion and not an issue, however, some > components will do the work twice. For example faceting component as > described in http://search-lucene.com/m/QTPaSlFUQ1/duplicate > It may also be connected to SOLR-6369 > The cause seems to be the interplay between > *DefaultSolrParams#getParameterNamesIterator()* which just returns param > names in sequence and *SolrParams#toNamedList()* which uses the first > (override then default) value for each key, without deduplication. > It's easily reproducible in trunk against schemaless example with > bq. curl > "http://localhost:8983/solr/schemaless/select?indent=true&echoParams=all" > I've also spot checked it and it seems to be reproducible back to Solr 4.1. > {panel} -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org