[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055220#comment-16055220
 ] 

Noble Paul commented on SOLR-10494:
---

We should also set {{json.nl=map}} as the default

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10494, SOLR-10494
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-10435) homogenise syntax error and API errors in v2 API

[Cao Manh Dat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cao Manh Dat resolved SOLR-10435.
-
   Resolution: Fixed
 Assignee: Cao Manh Dat
Fix Version/s: master (7.0)

> homogenise syntax error and API errors in v2 API
> 
>
> Key: SOLR-10435
> URL: https://issues.apache.org/jira/browse/SOLR-10435
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Noble Paul
>Assignee: Cao Manh Dat
> Fix For: master (7.0)
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10435) homogenise syntax error and API errors in v2 API

[Cao Manh Dat (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055183#comment-16055183
 ] 

Cao Manh Dat commented on SOLR-10435:
-

I think the commit at SOLR-10406 also resolve this issue.

> homogenise syntax error and API errors in v2 API
> 
>
> Key: SOLR-10435
> URL: https://issues.apache.org/jira/browse/SOLR-10435
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Noble Paul
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10406) v2 API error messages list the URL request path as /solr/____v2/... when the original path was /v2/...

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055182#comment-16055182
 ] 

ASF subversion and git services commented on SOLR-10406:


Commit b1b566f57bba46cadae33bc8198246fa05609287 in lucene-solr's branch 
refs/heads/master from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b1b566f ]

SOLR-10406: v2 API error messages list the URL request path as /solr/v2/... 
when the original path was /v2/...


> v2 API error messages list the URL request path as /solr/v2/... when the 
> original path was /v2/...
> --
>
> Key: SOLR-10406
> URL: https://issues.apache.org/jira/browse/SOLR-10406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Steve Rowe
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10406.patch, SOLR-10406.patch
>
>
> E.g. attempting introspect on {{/v2/c/.system/blob}} will fail if the 
> {{.system}} collection has not yet been CREATE'd - after {{bin/solr start -e 
> cloud -noprompt}}:
> {noformat}
> $ curl "http://localhost:8983/v2/c/.system/blob/_introspect?indent=on";
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/c/.system/blob/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-10406) v2 API error messages list the URL request path as /solr/____v2/... when the original path was /v2/...

[Cao Manh Dat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cao Manh Dat resolved SOLR-10406.
-
   Resolution: Fixed
 Assignee: Cao Manh Dat
Fix Version/s: master (7.0)

> v2 API error messages list the URL request path as /solr/v2/... when the 
> original path was /v2/...
> --
>
> Key: SOLR-10406
> URL: https://issues.apache.org/jira/browse/SOLR-10406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10406.patch, SOLR-10406.patch
>
>
> E.g. attempting introspect on {{/v2/c/.system/blob}} will fail if the 
> {{.system}} collection has not yet been CREATE'd - after {{bin/solr start -e 
> cloud -noprompt}}:
> {noformat}
> $ curl "http://localhost:8983/v2/c/.system/blob/_introspect?indent=on";
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/c/.system/blob/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10914) RecoveryStrategy's sendPrepRecoveryCmd can get stuck for 5 minutes if leader is unloaded

[Shalin Shekhar Mangar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shalin Shekhar Mangar updated SOLR-10914:
-
Attachment: SOLR-10914.patch

This patch changes the sendPrepRecoveryCmd method to use a small connection 
timeout (10s) as before and a read timeout which is 5 seconds longer than the 
max timeout of prep recovery on the server side. It makes no retries anymore. 
So once the prep recovery returns a 404 after 30s, the recovery fails and can 
be retries again with the new/correct leader URL.

I'll commit this but I'll open another issue to explore removing the wait time 
on core not found from prep recovery.

> RecoveryStrategy's sendPrepRecoveryCmd can get stuck for 5 minutes if leader 
> is unloaded
> 
>
> Key: SOLR-10914
> URL: https://issues.apache.org/jira/browse/SOLR-10914
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.4, 6.5, 6.6
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0)
>
> Attachments: SOLR-10914.patch
>
>
> tl;dr; a recovering replica is stuck for 5 minutes in the prep recovery 
> request if the leader core is unloaded before the prep recovery request is 
> made.
> SOLR-9716 changed the sendPrepRecoveryCmd to retry on read timeouts (earlier 
> it had no connection/read timeout at all) but the fix has caused another 
> problem. Say 
> # A replica starts up (or is newly created) and goes into recovery, 
> # Replica finds that leader=X
> # The core X is unloaded but the node that used to host X is still running 
> and taking requests
> # Replica calls sendPrepRecoveryCmd to X
> At this point, the node X receives the prep recovery command, finds that the 
> core X does not exist and keeps checking again in a sleep-loop until a 
> timeout happens. I am not sure why prep recovery core admin command needs to 
> continue waiting if a local core does not exist. The default timeout here is 
> usually longer than 10 seconds.
> On the recovering replica's side, the prep recovery has a connection/read 
> timeout of only 10s, so the request always times out and is retried upto 5 
> minutes. Only then does the recovery attempt fails and may be restarted again 
> with the right leader URL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored so we can simplify points randomization in our schemas

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-10864:

Description: 
(I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's own 
jira# w/ it's own summary for increased visibility/comments)

In the interest of making it easier & more straight forward to get good 
randomized test coverage of Points fields, I'd like to add the following to the 
{{PointField}} class...

{code}
 /**
  * 
  * The Test framework can set this global variable to instruct PointField that
  * (on init) it should be tollerant of the precisionStep argument 
used by TrieFields.
  * This allows for simple randomization of TrieFields and PointFields w/o 
extensive duplication
  * of  declarations.
  * 
  *
  * NOTE: When {@link TrieField} is removed, this boolean must also be 
removed
  *
  * @lucene.internal
  * @lucene.experimental
  */
 public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;

 /** 
  * NOTE: This method can be removed completely when
  * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed 
  */
 @Override
 protected void init(IndexSchema schema, Map args) {
   super.init(schema, args);
   if (TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS) {
 args.remove("precisionStep");
   }
 }
{code}

Then in SolrTestCaseJ4, set 
{{PointField.TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS}} on a class by class 
basis when randomizing Trie/Points (and unset \@AfterClass).

(details to follow in comment)

  was:

(I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's own 
jira# w/ it's own summary for increased visibility/comments)

In the interest of making it easier & more straight forward to get good 
randomized test coverage of Points fields, I'd like to add the following to the 
{{PointField}} class...

{code}
 /**
  * 
  * The Test framework can set this global variable to instruct PointField that
  * (on init) it should be tollerant of the precisionStep argument 
used by TrieFields.
  * This allows for simple randomization of TrieFields and PointFields w/o 
extensive duplication
  * of  declarations.
  * 
  *
  * NOTE: When {@link TrieField} is removed, this boolean must also be 
removed
  *
  * @lucene.internal
  * @lucene.experimental
  */
 public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;

 /** 
  * NOTE: This method can be removed completely when
  * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed 
  */
 @Override
 protected void init(IndexSchema schema, Map args) {
   super.init(schema, args);
   if (TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS) {
 args.remove("precisionStep");
   }
 }
{code}

Then in SolrTestCaseJ4, set 
{{PointField.TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS}} on a class by class 
basis when randomizing Trie/Points (and unset \@AfterClass).

(details to follow in comment)

Summary: Add static (test only) boolean to PointField indicating 
'precisionStep' should be ignored so we can simplify points randomization in 
our schemas  (was: Add static (test only) boolean to PointField indicating 
'precisionStep' should be ignored)

> Add static (test only) boolean to PointField indicating 'precisionStep' 
> should be ignored so we can simplify points randomization in our schemas
> 
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's 
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good 
> randomized test coverage of Points fields, I'd like to add the following to 
> the {{PointField}} class...
> {code}
>  /**
>   * 
>   * The Test framework can set this global variable to instruct PointField 
> that
>   * (on init) it should be tollerant of the precisionStep 
> argument used by TrieFields.
>   * This allows for simple randomization of TrieFields and PointFields w/o 
> extensive duplication
>   * of  declarations.
>   * 
>   *
>   * NOTE: When {@link TrieField} is removed, this boolean must also be 
> removed
>   *
>   * @lucene.internal
>   * @lucene.experimental
>   */
>  public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;
>  /** 
>   * NOTE: This method can be removed completely when
>   * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed 
>   */
>  @Override
>  protected vo

[jira] [Updated] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-10864:

Attachment: SOLR-10864.patch


bq. +1, I like how it'll be standardized, simplified (fieldtypes only instead 
of fields; and fewer fields) and (more) comprehensive than the current setup.

Thanks -- I was second guessing myself and needed outside eyes to tell me if i 
was over thinking things.

bq. How about introducing a new (independently) randomized sysprop usable as 
docValues="${solr.tests.numeric.docvalues}"? Tests that need it to be one way 
or the other can set it in a @BeforeClass-annotated static method.

That's a great idea -- but In the attach patch I tried to tweak your idea 
slightly to "improve" it by being 
{{docValues="$\{solr.tests.numeric.points.dv}"}}.  When Triefields are choosen 
it's always false, when points fields are choosen _then_ it will randomly be 
selected.  So depending on your test/config...

* Always need DV regardless of underlying type...
** Use {{docValues="true"}} in the schema
* Know you are doing something that requires DV if the numerics are points...
** {{System.setProperty("solr.tests.numeric.points.dv", "true");}} in your setup
* Know that DVs shouldn't matter for your test...
** {{docValues="$\{solr.tests.numeric.points.dv}"}}

...but actually in hindsight, I think your idea is just plain objectively 
better, because it would keep the usage simpler...

* (almost) every numeric field type should have 
{{docValues="$\{solr.tests.numeric.dv}"}}
* Always need DV regardless of underlying type...
** {{System.setProperty("solr.tests.numeric.dv", "true");}} in your test setup
* Know you are doing something that requires DV if the numerics are points...
** in Setup... {code}
if (Boolean.getBoolean("solr.tests.numeric.points") {
  System.setProperty("solr.tests.numeric.dv", "true");
 }
{code}
* Know that it shouldn't matter for your test...
** Do nothing, baseclass has already randomized
 
Sound Good?

---

As things stand now, the patch cleans up all tests/schemas to use the (current) 
variables, with the neccessary fixes / System.setProperty / 
@SuppressPointFields to tests that had assumptions/expectations about types.

There's a handful of nocommits, that generally fall into 4 categories...
* javadocs in SolrTestCaseJ4
* notes to file/fix (2) independent bugs
* randomize the variables that i currently hardcoded for forcing points testing
* notes in schema files to remove explict Point field types and update the 
affected tests
** I'm actually thinking that this should really be done as a distinctly 
seperate jira after we change the randomization logic

one other question I had was about changing the semantics of the current 
{{solr.tests.preferPointFields}} users can set ... it can currently only be 
used to "prefer points" for tests that don't have {{\@SuppressPointFields}}, 
but I think it would be better to change that to 
{{solr.tests.use.numeric.points}} such that the semantics are:

* if {{\@SuppressPointFields}} use trie fields
* else: if user set {{-Dsolr.tests.use.numeric.points=foo}}
** if {{foo==true}} force points, else force trie
* else: randomly pick between trie and points

any objections?



My next steps unless someone has concerns...

# change the DV sys prop name/usage as mentioned above
# file/fix the two nocommits related to new jiras
# create a new subtask of SOLR-10807 to deal with auditing/removing most of the 
hardcoded {{solr.FooPointFields}} and related fields (after the randomization 
work has been rolled out to _all_ schemas and remove those nocommits from these 
schema files)
# fix the jdoc & hardcoded sysprop related nocommits



> Add static (test only) boolean to PointField indicating 'precisionStep' 
> should be ignored
> -
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's 
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good 
> randomized test coverage of Points fields, I'd like to add the following to 
> the {{PointField}} class...
> {code}
>  /**
>   * 
>   * The Test framework can set this global variable to instruct PointField 
> that
>   * (on init) it should be tollerant of the precisionStep 
> argument used by TrieFields.
>   * This allows for simple randomization of TrieFields and PointFields w/o 
> extensive duplication
>   * of 

[jira] [Updated] (SOLR-10910) Clean up a few details left over from pluggable transient core and untangling CoreDescriptor/CoreContainer references

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-10910:
--
Attachment: SOLR-10910.patch

Here's what this patch is looking like. Precommit and all tests pass, will 
commit in a day or two unless there are objections.

> Clean up a few details left over from pluggable transient core and untangling 
> CoreDescriptor/CoreContainer references
> -
>
> Key: SOLR-10910
> URL: https://issues.apache.org/jira/browse/SOLR-10910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-10910.patch
>
>
> There are a few bits of the code from SOLR-10007, SOLR-8906 that could stand 
> some cleanup. For instance, the TransientSolrCoreCache is rather awkwardly 
> hanging around in CoreContainer and would fit more naturally in SolrCores.
> What I've seen so far shouldn't result in incorrect behavior, just cleaning 
> up for the future.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7880) Make boolean query clause limit configurable per-query

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055126#comment-16055126
 ] 

Mark Miller commented on LUCENE-7880:
-

The difference is probably that people that also work on Solr were not pushing 
for that. It's easy to get cooperation or an attitude of consensus building in 
that case. It's also simple to add technically simple enhancements without 
religious ideas on clearly subjective changes. 

> Make boolean query clause limit configurable per-query
> --
>
> Key: LUCENE-7880
> URL: https://issues.apache.org/jira/browse/LUCENE-7880
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over 
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have 
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it 
> to be overridden on a per-query basis when we know it is the desired behavior 
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on 
> BooleanQuery.Builder that configures the limit for that instance only?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)

[Cao Manh Dat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cao Manh Dat resolved SOLR-9989.

   Resolution: Fixed
 Assignee: Cao Manh Dat
Fix Version/s: master (7.0)

> Add support for PointFields in FacetModule (JSON Facets)
> 
>
> Key: SOLR-9989
> URL: https://issues.apache.org/jira/browse/SOLR-9989
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Tomás Fernández Löbbe
>Assignee: Cao Manh Dat
> Fix For: master (7.0)
>
> Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055100#comment-16055100
 ] 

ASF subversion and git services commented on SOLR-9989:
---

Commit 294026ffa8bbef46b65e4a517fa018ae1250903a in lucene-solr's branch 
refs/heads/master from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=294026f ]

SOLR-9989: Add support for PointFields in FacetModule (JSON Facets)


> Add support for PointFields in FacetModule (JSON Facets)
> 
>
> Key: SOLR-9989
> URL: https://issues.apache.org/jira/browse/SOLR-9989
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 949 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/949/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([D8063D4CD08AE408:B2E7B327ED105270]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:245)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter

Error Message:
Collection not found: routeFieldColl

Stack Trace:
org.apache.solr.co

[jira] [Commented] (LUCENE-7880) Make boolean query clause limit configurable per-query

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055078#comment-16055078
 ] 

David Smiley commented on LUCENE-7880:
--

By the way, this {{maxBooleanClauseCount}} is, I think, extremely similar to 
{{maxDeterminizeStates}} for AutomatonQuery (thus WildCardQuery, RegexpQuery).  
Both ideas are self-imposed limits that _usually_ don't need to be increased 
beyond the defaults but cases happen.  In both cases, a RuntimeException 
derivative is thrown if the limit is exceeded.  maxDeterminizeStates is 
configurable for the query instance, and the setting is configurable in the 
classic query parser's QueryParserBase.  maxBooleanClauseCount has neither.  
Why the difference [~jpountz]?

> Make boolean query clause limit configurable per-query
> --
>
> Key: LUCENE-7880
> URL: https://issues.apache.org/jira/browse/LUCENE-7880
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over 
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have 
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it 
> to be overridden on a per-query basis when we know it is the desired behavior 
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on 
> BooleanQuery.Builder that configures the limit for that instance only?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4089 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4089/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle 
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException: 
Time allowed to handle this request exceeded  at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:436)
  at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
  at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:748) ,time=1}

Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info: 
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle 
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException: 
Time allowed to handle this request exceeded
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:436)
at 
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
,time=1}
at 
__randomizedtesting.SeedInfo.seed([3918DC1B6351AFA1:B14CE3C1CDADC259]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.TestDistributedSearch.comparePartialResponses(TestDistributedSearch.java:1186)
at 
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1127)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:987)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1011)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtestin

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1331 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1331/

No tests ran.

Build Log:
[...truncated 22 lines...]
ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/test-data
org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS of 
'/repos/asf/lucene/test-data': 403 Forbidden (http://svn.apache.org)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:68)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:798)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:391)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:862)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:698)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:149)
at 
org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.createRepository(SvnRepositoryAccess.java:121)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepository(SvnNgRepositoryAccess.java:211)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:194)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:111)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:40)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgUpdate.run(SvnNgUpdate.java:18)
at 
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at 
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
at 
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:158)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:162)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:996)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:972)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:948)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2731)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
ERROR: Subversion update failed
hudson.remoting.ProxyException: 
org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: OPTIONS of 
'/repos/asf/lucene/test-data': 403 Forbidden (http://svn.apache.org)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:68)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:798)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:391)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:862)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:698)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:149)
at 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_131) - Build # 19911 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19911/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard

Error Message:
Error from server at https://127.0.0.1:44265/solr: deleteshard the collection 
time out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:44265/solr: deleteshard the collection time 
out:180s
at 
__randomizedtesting.SeedInfo.seed([D97F7D4C628D03A2:1C21C950E478C95F]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:595)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:231)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:220)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:459)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:389)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1135)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:876)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard(CollectionsAPISolrJTest.java:143)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.rando

[JENKINS] Lucene-Solr-Tests-master - Build # 1882 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1882/

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestPullReplicaErrorHandling

Error Message:
ObjectTracker found 2 object(s) that were not released!!! 
[MockDirectoryWrapper, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:480)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:328) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:419) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$12(ReplicationHandler.java:1183)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1033)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:855)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:979)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:914)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:374)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:318)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:748)  

Stack Trace:
java.lang.AssertionError: ObjectTracker f

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_131) - Build # 6663 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6663/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  
'org.apache.solr.core.BlobStoreTestRequestHandler' for path 
'overlay/requestHandler/\/test1/class' full output: {   "responseHeader":{ 
"status":0, "QTime":0},   "overlay":{ "znodeVersion":0, 
"runtimeLib":{"colltest":{ "name":"colltest", "version":1,  
from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  
'org.apache.solr.core.BlobStoreTestRequestHandler' for path 
'overlay/requestHandler/\/test1/class' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "overlay":{
"znodeVersion":0,
"runtimeLib":{"colltest":{
"name":"colltest",
"version":1,  from server:  null
at 
__randomizedtesting.SeedInfo.seed([1FDA3DD11EEFCFD7:C7971086E9326A77]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdap

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+173) - Build # 3792 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3792/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([893BB68D5EF357DD:21C655C1FF5FC59]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.

[jira] [Commented] (SOLR-10912) Adding automatic patch validation

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054869#comment-16054869
 ] 

Jan Høydahl commented on SOLR-10912:


This would be awesome

> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10919) ord & rord functions give confusing errors with PointFields

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054853#comment-16054853
 ] 

Hoss Man commented on SOLR-10919:
-

Examples failures found in SOLR-10807 when forcing points for al numeric 
types...

{noformat}

   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=DisMaxRequestHandlerTest -Dtests.method=testSomeStuff 
-Dtests.seed=40DB535C83C56F23 -Dtests.slow=true -Dtests.locale=sl 
-Dtests.timezone=Atlantic/South_Georgia -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.00s J2 | DisMaxRequestHandlerTest.testSomeStuff <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([40DB535C83C56F23:AEC94260775C9E19]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:940)
   [junit4]>at 
org.apache.solr.DisMaxRequestHandlerTest.doTestSomeStuff(DisMaxRequestHandlerTest.java:76)
   [junit4]>at 
org.apache.solr.DisMaxRequestHandlerTest.testSomeStuff(DisMaxRequestHandlerTest.java:72)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
   [junit4]> Caused by: java.lang.IllegalStateException: unexpected 
docvalues type NONE for field 'iind' (expected one of [SORTED, SORTED_SET]). 
Re-index with correct docvalues type.
   [junit4]>at 
org.apache.lucene.index.DocValues.checkField(DocValues.java:340)
   [junit4]>at 
org.apache.lucene.index.DocValues.getSortedSet(DocValues.java:433)
   [junit4]>at 
org.apache.solr.search.function.ReverseOrdFieldSource.getValues(ReverseOrdFieldSource.java:98)


   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=DisMaxRequestHandlerTest -Dtests.method=testExtraBlankBQ 
-Dtests.seed=40DB535C83C56F23 -Dtests.slow=true -Dtests.locale=sl 
-Dtests.timezone=Atlantic/South_Georgia -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.01s J2 | DisMaxRequestHandlerTest.testExtraBlankBQ <<<
   [junit4]> Throwable #1: java.lang.IllegalStateException: unexpected 
docvalues type NONE for field 'iind' (expected one of [SORTED, SORTED_SET]). 
Re-index with correct docvalues type.
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([40DB535C83C56F23:F5DCCAEC43212E62]:0)
   [junit4]>at 
org.apache.lucene.index.DocValues.checkField(DocValues.java:340)
   [junit4]>at 
org.apache.lucene.index.DocValues.getSortedSet(DocValues.java:433)
   [junit4]>at 
org.apache.solr.search.function.ReverseOrdFieldSource.getValues(ReverseOrdFieldSource.java:98)

{noformat}

> ord & rord functions give confusing errors with PointFields
> ---
>
> Key: SOLR-10919
> URL: https://issues.apache.org/jira/browse/SOLR-10919
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> as discovered in SOLR-10807...
> If you try to use either the {{ord()}} or {{rord()}} functions on a Numeric 
> PointsField, the error is confusing.  
> We should make them give clean errors if someone attempts this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10919) ord & rord functions give confusing errors with PointFields

[Hoss Man (JIRA)]

Hoss Man created SOLR-10919:
---

 Summary: ord & rord functions give confusing errors with 
PointFields
 Key: SOLR-10919
 URL: https://issues.apache.org/jira/browse/SOLR-10919
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


as discovered in SOLR-10807...

If you try to use either the {{ord()}} or {{rord()}} functions on a Numeric 
PointsField, the error is confusing.  

We should make them give clean errors if someone attempts this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-5958) Document (and fix) numShards and router selection parameter in SolrCloud

[Anshum Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054839#comment-16054839
 ] 

Anshum Gupta commented on SOLR-5958:


Coming back to this after a really long time. It's a low hanging one, and would 
make things easier for the end user to understand if we standardize it.
Should we default numShards to 1 and keep things simple? We should segregate 
the router selection, and numShards and have simple defaults for both.
Default numShards = 1, and router = compositeId (so the user can come back 
later and split shard, etc.).


> Document (and fix) numShards and router selection parameter in SolrCloud
> 
>
> Key: SOLR-5958
> URL: https://issues.apache.org/jira/browse/SOLR-5958
> Project: Solr
>  Issue Type: Task
>  Components: documentation, SolrCloud
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Minor
>
> Right now numShards works in rather mysterious ways (unless you know how it 
> works). We should clearly document the following:
> * If we start SolrCloud with bootstrapping, without mentioning numShards 
> parameter, it defaults to 1 and also defaults the router to 'implicit'.
> * Mentioning numShards param, defaults the router to compositeId.
> * Though the bootstrap does not treat numShards as a required param, the 
> Collection API does and throw an error if we don't specify numShards.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-5958) Document (and fix) numShards and router selection parameter in SolrCloud

[Anshum Gupta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshum Gupta updated SOLR-5958:
---
Issue Type: Improvement  (was: Task)

> Document (and fix) numShards and router selection parameter in SolrCloud
> 
>
> Key: SOLR-5958
> URL: https://issues.apache.org/jira/browse/SOLR-5958
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation, SolrCloud
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Minor
>
> Right now numShards works in rather mysterious ways (unless you know how it 
> works). We should clearly document the following:
> * If we start SolrCloud with bootstrapping, without mentioning numShards 
> parameter, it defaults to 1 and also defaults the router to 'implicit'.
> * Mentioning numShards param, defaults the router to compositeId.
> * Though the bootstrap does not treat numShards as a required param, the 
> Collection API does and throw an error if we don't specify numShards.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10307) Provide SSL/TLS keystore password a more secure way

[Mano Kovacs (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054833#comment-16054833
 ] 

Mano Kovacs commented on SOLR-10307:


Hi [~michaelsuzuki], thanks for the followup. I am trying to reproduce the 
issue but I might be missing something.

bq. The only way to get this to work is by setting the environment as follow:
What way would you prefer to use instead? Could you send an example?

Here is how I run:
{noformat}
export KEYSTORE=$PWD/keystore.jks
export TRUSTSTORE=$PWD/truststore.jks
rm $KEYSTORE
rm $TRUSTSTORE
keytool -genkey -noprompt \
 -alias alias1 \
 -dname "CN=mydomain.com, OU=ID, O=ABC, L=John, S=Doe, C=GB" \
 -ext "SAN=dns:localhost" \
 -keystore $KEYSTORE \
 -storepass abc123 \
 -keypass abc123 \
 -keyalg RSA

keytool -genkey -noprompt \
 -alias alias1 \
 -dname "CN=mydomain.com, OU=ID, O=ABC, L=John, S=Doe, C=GB" \
 -ext "SAN=dns:localhost" \
 -keystore $TRUSTSTORE \
 -storepass abc456 \
 -keypass abc456 \
 -keyalg RSA

export SOLR_SSL_ENABLED=true
export SOLR_SSL_KEY_STORE=$KEYSTORE
export SOLR_SSL_KEY_STORE_PASSWORD=abc123
export SOLR_SSL_TRUST_STORE=$TRUSTSTORE
export SOLR_SSL_TRUST_STORE_PASSWORD=abc456

bin/solr start -c -s ./example/cloud/node1/solr -f
{noformat}

Priorly, I downloaded the {{master}} branch, ran {{ant server}} and cloud 
example. It is working for me. Note that I did not uncomment anything from 
{{solr.in.sh}}.


Also, SOLR-10783 will restore sysprop option as the configuration handling is 
moved out from {{jetty-ssl.xml}}.



> Provide SSL/TLS keystore password a more secure way
> ---
>
> Key: SOLR-10307
> URL: https://issues.apache.org/jira/browse/SOLR-10307
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10307.patch, SOLR-10307.patch, SOLR-10307.patch
>
>
> Currently the only way to pass server and client side SSL keytstore and 
> truststore passwords is to set specific environment variables that will be 
> passed as system properties, through command line parameter.
> First option is to pass passwords through environment variables which gives a 
> better level of protection. Second option would be to use hadoop credential 
> provider interface to access credential store.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7880) Make boolean query clause limit configurable per-query

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054831#comment-16054831
 ] 

Adrien Grand commented on LUCENE-7880:
--

I think the source of the disagreement is that to me there is almost no good 
reason to build large boolean queries. So users who really need to do this can 
increase the limit. They would indeed lose the safety of that limit but it 
still sounds like a better trade-off to me than removing the max clause count 
entirely or making it configurable per-query.

As far as multi-tenancy is concerned, it should still be extremely rare that 
large boolean queries are needed on a per-cluster basis. So I'd make it a 
per-cluster option and raise the limit if any tenant needs to build large 
boolean queries.

I understand my assumptions do not seem to match the reality some other 
committers are seeing based on the comments on SOLR-4586. Also I don't want to 
prevent Solr from setting a limit equal to MAX_VALUE or making it configurable 
per-core given my position. So I won't object if you want to follow either of 
those paths but I still think we should keep things as they are in Lucene since 
it is our best option from a Lucene perspective.

> Make boolean query clause limit configurable per-query
> --
>
> Key: LUCENE-7880
> URL: https://issues.apache.org/jira/browse/LUCENE-7880
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over 
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have 
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it 
> to be overridden on a per-query basis when we know it is the desired behavior 
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on 
> BooleanQuery.Builder that configures the limit for that instance only?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7863) Don't repeat postings (and perhaps positions) on ReverseWF, EdgeNGram, etc

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated LUCENE-7863:
-
Summary: Don't repeat postings (and perhaps positions) on ReverseWF, 
EdgeNGram, etc(was: Don't repeat postings and positions on ReverseWF, 
EdgeNGram, etc  )

> Don't repeat postings (and perhaps positions) on ReverseWF, EdgeNGram, etc  
> 
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7863.hazard
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes. 
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm 
> shuddering to think about EdgeNGrams...
> h2. Proposal 
> _DRY_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7863) Don't repeat postings and positions on ReverseWF, EdgeNGram, etc

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054803#comment-16054803
 ] 

Mikhail Khludnev commented on LUCENE-7863:
--

Got it. Nice decision! 

So, instead of searching for name:\*ar, it flips query to name_rev:ra*, then 
for every doc (if we need phrase logic or highlighting): it seeks original 
term's postings to the same doc, and read positions and offsets.  

Thinking about EdgeNGramms (searching for name:\*a\*), derivative field should 
go like this: {{ar_bar}}, {{r_bar}} to be able to switch to original term's 
posting. So, I still think that even with this approach (second DOCS_ONLY 
field) blowing postings by these derivative terms still might not be 
affordable.   

And coming back to your question:
bq. have you thought of using another field that only has the reversed terms?
No. I haven't thought about it. It's a great idea! Thanks for contributing it.  


> Don't repeat postings and positions on ReverseWF, EdgeNGram, etc  
> --
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7863.hazard
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes. 
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm 
> shuddering to think about EdgeNGrams...
> h2. Proposal 
> _DRY_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10918) StatsComponent cardinality descrepencies between regular vs pre-hashed values whe using PointsField

[Hoss Man (JIRA)]

Hoss Man created SOLR-10918:
---

 Summary: StatsComponent cardinality descrepencies between regular 
vs pre-hashed values whe using PointsField
 Key: SOLR-10918
 URL: https://issues.apache.org/jira/browse/SOLR-10918
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


discovered as part of SOLR-10807...

when using Points based numerics, the HLL estimates using the raw values vs the 
hashed values disagree slightly -- this suggests some possible bug (or the very 
least: room for optimization) when using Points fields.

Example from SOLR-10807 when swaping IntPointField in place of TrieIntField...

{code}

   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestDistributedStatsComponentCardinality -Dtests.method=test 
-Dtests.seed=63854996088ED7B7 -Dtests.slow=true -Dtests.locale=de-GR 
-Dtests.timezone=Etc/UCT -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 13.3s J2 | TestDistributedStatsComponentCardinality.test <<<
   [junit4]> Throwable #1: java.lang.AssertionError: int_i: hashed vs 
prehashed, real=7260, 
p=q=id:[1186+TO+8445]&rows=0&stats=true&stats.field={!cardinality%3Dtrue+hllLog2m%3D7+hllRegwidth%3D8}int_i&stats.field={!cardinality%3Dtrue+hllLog2m%3D7+hllRegwidth%3D8+hllPreHashed%3Dtrue}int_i_prehashed_l&stats.field={!cardinality%3Dtrue+hllLog2m%3D7+hllRegwidth%3D8}long_l&stats.field={!cardinality%3Dtrue+hllLog2m%3D7+hllRegwidth%3D8+hllPreHashed%3Dtrue}long_l_prehashed_l&stats.field={!cardinality%3Dtrue+hllLog2m%3D7+hllRegwidth%3D8}string_s&stats.field={!cardinality%3Dtrue+hllLog2m%3D7+hllRegwidth%3D8+hllPreHashed%3Dtrue}string_s_prehashed_l
 expected:<6632> but was:<7929>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([63854996088ED7B7:EBD1764CA672BA4F]:0)
   [junit4]>at 
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality.test(TestDistributedStatsComponentCardinality.java:149)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-master - Build # 1881 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1881/

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.TestPolicyCloud.testCreateCollectionAddReplica

Error Message:
Error from server at http://127.0.0.1:53050/solr: delete the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:53050/solr: delete the collection time out:180s
at 
__randomizedtesting.SeedInfo.seed([E368B11F397F78C5:6348D431283C9063]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:595)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:231)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:220)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:459)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:389)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1135)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:876)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:442)
at 
org.apache.solr.cloud.autoscaling.TestPolicyCloud.after(TestPolicyCloud.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:965)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

[jira] [Updated] (LUCENE-7873) Remove context classloader from SPI lookups by default

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-7873:
--
Attachment: LUCENE-7873.patch

Simple patch, all tests seem to pass.

I added no support for a sysprop, because people that rely on the context 
classloader can easily add support again. They just have to call: 
{{Codec.reloadCodecs(Thread.curentThread().getContentClassLoader())}} to 
restore previous behaviour. I would add a statement in MIGRATE.txt

I scanned the source code: In Lucene we only have one more context classloader 
and in Solr many stupid references to it (because the code writer "just needed 
a classloader"). We should fix those. I will open another issue to fix this. 
After that we should add the context class loader to the forbidden API list!

> Remove context classloader from SPI lookups by default
> --
>
> Key: LUCENE-7873
> URL: https://issues.apache.org/jira/browse/LUCENE-7873
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7873.patch
>
>
> As discussed on LUCENE-7870, we should really remove the context class loader 
> from Lucene's SPI lookup (NamedSPLoader, SPIClassIterator, AnalysisSPI stuff).
> {quote}
> My idea would be (as stated before): Get rid of the Context Classloader in 
> SPI lookups! Lucene never uses it, it is just there for backwards 
> compatibility. The current setup of SPI does not work with modules of Java 9 
> and it does not work with stuff in completely different classloaders. So OSGI 
> fails in any case, if you have lucene-core.jar and 
> lucene-backwards-codecs.jar as OSGI modules, because both would use different 
> loaders. The context loader won't help.
> The problem is that we may break some apps that rely on the context loader 
> traversal. In my opinion, we may add a system property that is read on setup 
> of NamedSPILoader / SPIClassIterator that can be set to true (e.g. 
> lucene.useContextLoaderForSPI, defaulting to false). This may fix legacy apps 
> and new apps would only traverse the classloader that loaded lucene-core.jar.
> For Java 9 and "Lucene as Java 9 module") we have to refactor this anyways, 
> becaue we need to respect module-info,java and look for SPI exports.
> FYI: Context class loaders were the worst idea ever in Java. I personally 
> hate them and I would do anything - just to make them disappear from the 
> spec! When drinking beers with Mark Reinhold in Brussels, I am always 
> reminding him about this together with the inability to unmap byte buffers... 
> :-)
> {quote}
> Unfortunately the sysprop approach is the only way to handle this as this 
> must be done very early on JVM/Lucene setup. If somebody called 
> Codec.forName() its too late to change the default... But I am fine with 
> using a sysprop with AccessController.doPrivileged(), as this is only 
> required for those legacy WEBAPP stuff. Normal applications should see the 
> META-INF files on the application classloader anyways.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7863) Don't repeat postings and positions on ReverseWF, EdgeNGram, etc

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054727#comment-16054727
 ] 

David Smiley commented on LUCENE-7863:
--

bq. I suppose if it repeats postings, it also repeats positions, offsets, 
payloads. Doesn't it?

Nope!  Configure it for IndexOptions.DOCS only -- no rest of that stuff.  Then 
you could write a TermsEnum wrapper that delegates to the original field that 
has all the rest of that stuff.  For inspiration, see 
TermVectorFilteredTermsEnum in the unified highlighter.  It's not the same but 
the idea is that you blend 2 TermsEnum.

> Don't repeat postings and positions on ReverseWF, EdgeNGram, etc  
> --
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7863.hazard
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes. 
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm 
> shuddering to think about EdgeNGrams...
> h2. Proposal 
> _DRY_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7863) Don't repeat postings and positions on ReverseWF, EdgeNGram, etc

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054717#comment-16054717
 ] 

Mikhail Khludnev commented on LUCENE-7863:
--

bq. It's true my suggestion repeats the postings (doc ID list) but at least not 
the rest.
I suppose if it repeats postings, it also repeats positions, offsets, payloads. 
 Doesn't it?  

> Don't repeat postings and positions on ReverseWF, EdgeNGram, etc  
> --
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7863.hazard
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes. 
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm 
> shuddering to think about EdgeNGrams...
> h2. Proposal 
> _DRY_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7863) Don't repeat postings and positions on ReverseWF, EdgeNGram, etc

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054688#comment-16054688
 ] 

David Smiley commented on LUCENE-7863:
--

oh right I was thinking of freq, positions, offsets, payloads.  It's true my 
suggestion repeats the postings (doc ID list) but at least not the rest.  I 
don't see how auxiliary docs would help.  Maybe something is possibly by 
wrapping another codec.

> Don't repeat postings and positions on ReverseWF, EdgeNGram, etc  
> --
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7863.hazard
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes. 
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm 
> shuddering to think about EdgeNGrams...
> h2. Proposal 
> _DRY_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1382 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1382/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([FB48FBD172ED434D:3E5E3F4A625B7B2D]:0)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2487)
at org.apache.solr.util.TestHarness.query(TestHarness.java:337)
at org.apache.solr.util.TestHarness.query(TestHarness.java:319)
at 
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.ja

[jira] [Comment Edited] (SOLR-10307) Provide SSL/TLS keystore password a more secure way

[Michael Suzuki (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054676#comment-16054676
 ] 

Michael Suzuki edited comment on SOLR-10307 at 6/19/17 8:23 PM:


[~manokovacs] I have upgraded and tried this feature on solr 7 and 6.x and 
found an issue... I am unable to make this work unless the password is "secret".
Any attempt to set a new password for my keystrore or truststore is ignored, 
after reviewing the code and comments I understand why you excluded the option 
to pass it as a system param.

The only way to get this to work is by setting the environment as follow:
{code}
export SOLR_SSL_TRUST_STORE_PASSWORD=bob
{code}
Please note that upon runtime the value entered is ignored and instead it will 
take the value set in solr.ini.sh.
This seems to be a bit counter intuitive, making ssl setup more complicated and 
confusing. Is this the intended behaviour or are we missing this export line in 
solr.sh. Again thanks for adding this much needed feature!


was (Author: michaelsuzuki):
[~manokovacs] I have upgraded and tried this feature on solr 7 and 6.x and 
found an issue... I am unable to make this work unless the password is secret.
Any attempt to set a new password for my keystrore or truststore is ignored, 
after reviewing the code and comments I understand why you excluded the option 
to pass it as a system param.

The only way to get this to work is by setting the environment as follow:
{code}
export SOLR_SSL_TRUST_STORE_PASSWORD=bob
{code}
Please note that upon runtime the value entered is ignored and instead it will 
take the value set in solr.ini.sh.
This seems to be a bit counter intuitive, making ssl setup more complicated and 
confusing. Is this the intended behaviour or are we missing this export line in 
solr.sh. Again thanks for adding this much needed feature!

> Provide SSL/TLS keystore password a more secure way
> ---
>
> Key: SOLR-10307
> URL: https://issues.apache.org/jira/browse/SOLR-10307
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10307.patch, SOLR-10307.patch, SOLR-10307.patch
>
>
> Currently the only way to pass server and client side SSL keytstore and 
> truststore passwords is to set specific environment variables that will be 
> passed as system properties, through command line parameter.
> First option is to pass passwords through environment variables which gives a 
> better level of protection. Second option would be to use hadoop credential 
> provider interface to access credential store.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7863) Don't repeat postings and positions on ReverseWF, EdgeNGram, etc

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054679#comment-16054679
 ] 

Mikhail Khludnev commented on LUCENE-7863:
--

[~dsmiley], thanks for breaking silence. 
It gives six docs
||name||name_rev||
|foo|oof|
|foo|oof|
|foo|oof|
|bar|rab|
|bar|rab|
|bar|rab|

the term dictionary is

||field/term||posting offset (relative)||
||name|| ||
|bar|0|
|foo|3|
||name_rev|| ||
|oof|3|
|rab|3|

||Postings (absolute values)||
|3,4,5|
|0,1,2|
|0,1,2|
|3,4,5|

Thus, we still see 12 postings, that's duplication, which I want to avoid. Or 
you propose to have an auxiliary docs like foo->oof?  


> Don't repeat postings and positions on ReverseWF, EdgeNGram, etc  
> --
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7863.hazard
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes. 
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm 
> shuddering to think about EdgeNGrams...
> h2. Proposal 
> _DRY_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10307) Provide SSL/TLS keystore password a more secure way

[Michael Suzuki (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054676#comment-16054676
 ] 

Michael Suzuki commented on SOLR-10307:
---

[~manokovacs] I have upgraded and tried this feature on solr 7 and 6.x and 
found an issue... I am unable to make this work unless the password is secret.
Any attempt to set a new password for my keystrore or truststore is ignored, 
after reviewing the code and comments I understand why you excluded the option 
to pass it as a system param.

The only way to get this to work is by setting the environment as follow:
{code}
export SOLR_SSL_TRUST_STORE_PASSWORD=bob
{code}
Please note that upon runtime the value entered is ignored and instead it will 
take the value set in solr.ini.sh.
This seems to be a bit counter intuitive, making ssl setup more complicated and 
confusing. Is this the intended behaviour or are we missing this export line in 
solr.sh. Again thanks for adding this much needed feature!

> Provide SSL/TLS keystore password a more secure way
> ---
>
> Key: SOLR-10307
> URL: https://issues.apache.org/jira/browse/SOLR-10307
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10307.patch, SOLR-10307.patch, SOLR-10307.patch
>
>
> Currently the only way to pass server and client side SSL keytstore and 
> truststore passwords is to set specific environment variables that will be 
> passed as system properties, through command line parameter.
> First option is to pass passwords through environment variables which gives a 
> better level of protection. Second option would be to use hadoop credential 
> provider interface to access credential store.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10878) MOVEREPLICA command may lose data when replicationFactor==1

[Andrzej Bialecki (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054616#comment-16054616
 ] 

Andrzej Bialecki  commented on SOLR-10878:
--

Current WIP is available on branch jira/solr-10878. With Shalin's help we were 
able to discover that tests were failing also due to SOLR-10914, which 
currently blocks this issue.

> MOVEREPLICA command may lose data when replicationFactor==1
> ---
>
> Key: SOLR-10878
> URL: https://issues.apache.org/jira/browse/SOLR-10878
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.6, master (7.0), 6.7
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.7
>
>
> Follow-up to SOLR-10704, a similar scenario occurs in {{MoveReplicaCmd}} when 
> replication factor is 1 - the only copy of the source replica may be deleted 
> while the target replica is still recovering.
> Also, even when replicationFactor > 1 but the only remaining replicas are of 
> the PULL type then leader election won't be able to find any replica to 
> become a leader for this shard, which will result in effective data loss for 
> that shard.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10824) java.lang.NullPointerException ExactSharedStatsCache.getPerShardTermStats

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054614#comment-16054614
 ] 

Varun Thacker commented on SOLR-10824:
--

Hi Mikhail,

I'll take a look at it within the next 2-3 days. Please don't hold it up for me 
if you are confident about the patch 

> java.lang.NullPointerException ExactSharedStatsCache.getPerShardTermStats 
> --
>
> Key: SOLR-10824
> URL: https://issues.apache.org/jira/browse/SOLR-10824
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-10824.patch, SOLR-10824.patch, SOLR-10824.patch
>
>
> {quote}
>  INFO [qtp411311908-32] (SolrCore.java:2304) - [collection1_shard3_replica2]  
> webapp=/solr path=/select 
> params={..&distrib=false&_stateVer_=collection1:5...&shards.purpose=32768&shard.url=http://127.0.0.1:57114/solr/collection1_shard3_replica2/|http://127.0.0.1:57112/solr/collection1_shard3_replica1/&version=2)&NOW=1496751847089&isShard=true&applicability.frm=FRM&wt=javabin}
>  status=0 QTime=18
> INFO [qtp2123780104-30] (SolrCore.java:2304) - [collection1_shard1_replica1] 
> ...
>  INFO [qtp411311908-45] (SolrCore.java:2304) - [collection1_shard2_replica1]  
> ...
> ERROR [qtp411311908-33] (SolrException.java:148) - 
> java.lang.NullPointerException
>   at 
> org.apache.solr.search.stats.ExactSharedStatsCache.getPerShardTermStats(ExactSharedStatsCache.java:76)
>   at 
> org.apache.solr.search.stats.ExactStatsCache.sendGlobalStats(ExactStatsCache.java:233)
>   at 
> org.apache.solr.handler.component.QueryComponent.createMainQuery(QueryComponent.java:930)
>   at 
> org.apache.solr.handler.component.QueryComponent.regularDistributedProcess(QueryComponent.java:726)
>   at 
> org.apache.solr.handler.component.QueryComponent.distributedProcess(QueryComponent.java:679)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:345)
>  INFO [qtp411311908-33] (SolrCore.java:2304) - [collection1_shard3_replica2]  
> webapp=/solr path=/select params={...&wt=javabin&version=2} status=500 
> QTime=82
> {quote}
> Switching to {{LRUStatsCache}} seems help.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10917) Port starvation issue in Luke

[David Johnson (JIRA)]

David Johnson created SOLR-10917:


 Summary: Port starvation issue in Luke
 Key: SOLR-10917
 URL: https://issues.apache.org/jira/browse/SOLR-10917
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI, SolrCloud
Affects Versions: 6.3
Reporter: David Johnson


If a collection replicated in multiple nodes in a cluster is completely down a 
request to Luke for that collection can sometimes result in a port starvation 
issue as the request is handed around the cluster and rejected by each node.
We experienced an issue in which 1 requests were made (3300 per node) in 
under a second, rendering the entire cluster unresponsive - this required a 
full restart of all nodes in the cluster to restore service.

Logged connections were all similar to:
2017-06-19 17:54:51.461 ERROR (qtp606548741-15083) [   ] o.a.s.s.HttpSolrCall 
null:org.apache.solr.common.SolrException: Error trying to proxy request for 
url: http://redacted/solr/collection/config
at 
org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:590)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:444)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:518)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.eclipse.jetty.io.EofException
at 
org.eclipse.jetty.server.HttpConnection$SendCallback.reset(HttpConnection.java:666)
at 
org.eclipse.jetty.server.HttpConnection$SendCallback.access$300(HttpConnection.java:630)
at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:511)
at 
org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:668)
at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:722)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:179)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:163)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:415)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2147)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:2102)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2123)
at 
org.apache.solr.servlet.HttpSolrCall.remoteQuery(HttpSolrCall.java:586)
... 27 more




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_131) - Build # 19909 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19909/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteCollection

Error Message:
expected:<4> but was:<3>

Stack Trace:
java.lang.AssertionError: expected:<4> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([3D31C2035CAE4837:3AE4C3487B3A2D3A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteCollection(CollectionsAPISolrJTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 11494 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPISolr

[jira] [Commented] (SOLR-10916) Any Solr test using MiniSolrCloud or Solr Core's should extend SolrTestCaseJ4

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054522#comment-16054522
 ] 

Hoss Man commented on SOLR-10916:
-

As a quick example: here are a few tests that extend LuceneTestCase and use 
MiniSolrCloudCluster (they seem to have been copied/pasted from the 
TestMiniSolrCloudCluster which was explicitly written as a demo for external 
clients that might want ot use MiniSolrCloudCluster even w/o using JUnit.

These tests should all be changed to subclass SolrCloudTestCase...

{code}
hossman@tray:~/lucene/dev/solr/core [master] $ find -name \*.java | xargs grep 
-l "extends LuceneTestCase" | xargs grep -l MiniSolrCloud
./src/test/org/apache/solr/cloud/TestAuthenticationFramework.java
./src/test/org/apache/solr/cloud/TestSolrCloudWithKerberosAlt.java
./src/test/org/apache/solr/cloud/TestMiniSolrCloudCluster.java
{code}

...that last test, TestMiniSolrCloudCluster, is still left over from SOLR-8961 
and should be renamed to represent what it does 
(TestCollectionsAPIViaSolrCloudCluster or some such)

> Any Solr test using MiniSolrCloud or Solr Core's should extend SolrTestCaseJ4
> -
>
> Key: SOLR-10916
> URL: https://issues.apache.org/jira/browse/SOLR-10916
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> We have a non-trivial number of tests  that extend LuceneTestCase directly.
> For "utility" method minded tests, this is fine - but for any test that wants 
> to instantiate re-use shared config files to instantiate SolrCores, or 
> instances of MiniSolrCloudCluster, this makes these tests really cumbersome 
> to maintain and deal with because htye don't leverage the existing 
> randomization setup logic in SolrTestCaseJ4.
> we should fix these tests where applicable



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10916) Any Solr test using MiniSolrCloud or Solr Core's should extend SolrTestCaseJ4/SolrCloudTestCase

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-10916:

Summary: Any Solr test using MiniSolrCloud or Solr Core's should extend 
SolrTestCaseJ4/SolrCloudTestCase  (was: Any Solr test using MiniSolrCloud or 
Solr Core's should extend SolrTestCaseJ4)

> Any Solr test using MiniSolrCloud or Solr Core's should extend 
> SolrTestCaseJ4/SolrCloudTestCase
> ---
>
> Key: SOLR-10916
> URL: https://issues.apache.org/jira/browse/SOLR-10916
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> We have a non-trivial number of tests  that extend LuceneTestCase directly.
> For "utility" method minded tests, this is fine - but for any test that wants 
> to instantiate re-use shared config files to instantiate SolrCores, or 
> instances of MiniSolrCloudCluster, this makes these tests really cumbersome 
> to maintain and deal with because htye don't leverage the existing 
> randomization setup logic in SolrTestCaseJ4.
> we should fix these tests where applicable



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10916) Any Solr test using MiniSolrCloud or Solr Core's should extend SolrTestCaseJ4

[Hoss Man (JIRA)]

Hoss Man created SOLR-10916:
---

 Summary: Any Solr test using MiniSolrCloud or Solr Core's should 
extend SolrTestCaseJ4
 Key: SOLR-10916
 URL: https://issues.apache.org/jira/browse/SOLR-10916
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


We have a non-trivial number of tests  that extend LuceneTestCase directly.

For "utility" method minded tests, this is fine - but for any test that wants 
to instantiate re-use shared config files to instantiate SolrCores, or 
instances of MiniSolrCloudCluster, this makes these tests really cumbersome to 
maintain and deal with because htye don't leverage the existing randomization 
setup logic in SolrTestCaseJ4.

we should fix these tests where applicable



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10242) Cores created by Solr RESTORE end up with stale searches after indexing

[John Marquiss (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054497#comment-16054497
 ] 

John Marquiss commented on SOLR-10242:
--

I am not issuing an explicit commit in this case. I have autoCommit set in 
solrconfig but not autoSoftCommit.

Here is the relevant update handler from solrconfig.

{code}
  

  ${solr.ulog.dir:}


  15000
  false

  
{code}

> Cores created by Solr RESTORE end up with stale searches after indexing
> ---
>
> Key: SOLR-10242
> URL: https://issues.apache.org/jira/browse/SOLR-10242
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore, search
>Affects Versions: 6.3
> Environment: Behavior observed on both Linux and Windows:
> Linux version 3.10.0-327.36.3.el7.x86_64 
> (mockbu...@x86-037.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red 
> Hat 4.8.5-4) (GCC) ) #1 SMP Thu Oct 20 04:56:07 EDT 2016
> java version "1.8.0_77"
> Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> Windows 10 Enterprise Version 1607 Build 14393.693
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>Reporter: John Marquiss
>Assignee: Varun Thacker
>
> Index files created by the Solr RESTORE feature are placed in a directory 
> with a name like "restore.20170307173236270" instead of the standard "index" 
> directory. This seems to break Solr's ability to detect index changes leading 
> to stale searchers on the restored cores.
> Detailed information including steps to replicate can be found in this 
> solr-user mail thread. [http://markmail.org/message/wsm56jgbh53fx24u]
> (The markmail site seems to be down... linking the relevant messages from the 
> Apache archive)
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3CCO2PR06MB6345317732A4D7C22C00BCCFD2F0%40CO2PR06MB634.namprd06.prod.outlook.com%3E]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3CCO2PR06MB6342202F82CFD4A2F5617AEFD2F0%40CO2PR06MB634.namprd06.prod.outlook.com%3E]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4088 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4088/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

9 tests failed.
FAILED:  org.apache.solr.cloud.ReplaceNodeTest.test

Error Message:
org/apache/solr/client/solrj/request/CollectionAdminRequest$ReplaceNode

Stack Trace:
java.lang.NoClassDefFoundError: 
org/apache/solr/client/solrj/request/CollectionAdminRequest$ReplaceNode
at 
__randomizedtesting.SeedInfo.seed([7375FB5FDE81BAA5:FB21C485707DD75D]:0)
at org.apache.solr.cloud.ReplaceNodeTest.test(ReplaceNodeTest.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: 
org.apache.solr.client.solrj.request.CollectionAdminRequest$ReplaceNode
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLo

[jira] [Commented] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054453#comment-16054453
 ] 

Hoss Man commented on SOLR-10503:
-


* now that CurrencyField extends CurrencyFieldType, can't we move CurrencyValue 
and FileExchangeRateProvider back into CurrencyFieldType.java (or make them 
static inner classes of CurrencyFieldType) ?
* you removed the error checking from ValueSourceParser.java? ... if someone 
tries to use the currency() function on a non CurrencyFieldType it should still 
through a clean error, not a ClassCastException
* do we need to bother parameterizing fieldTypeClass in CurrencyFieldTypeTest? 
isn't it enough to just assert that it's an instanceof CurrencyFieldType? ... 
the test methods really shouldn't be affected at all by this distinction
** If we're going to consolidate the existing tests like this, it seems better 
to parameterize the expected provider class, and add a getter to 
CurrencyFieldType for that.
** then we could also fix the assume in testAsymmetricPointQuery so it isn't 
dependent on us remembering to keep the list of field names accurate.
* I think these (2) comments are suppose to refer to subclass (not superclass) 
??...
{{// Don't initialize if superclass already has done so}}
* FWIW: I'm still -0 to CurrencyFieldType having hardcoded defalts for 
these...{code}
  fieldSuffixAmountRaw = args.get(PARAM_FIELD_SUFFIX_AMOUNT_RAW);
  if (fieldSuffixAmountRaw == null) {  // not specified; use default raw 
field type
fieldSuffixAmountRaw = DEFAULT_FIELD_SUFFIX_AMOUNT_RAW;
fieldTypeAmountRaw = new LongPointField();
...
  fieldSuffixCurrency = args.get(PARAM_FIELD_SUFFIX_CURRENCY);
  if (fieldSuffixCurrency == null) {   // not specified; use default 
currency field type
fieldSuffixCurrency = DEFAULT_FIELD_SUFFIX_CURRENCY;
fieldTypeCurrency = new StrField();
{code}...I think it would be a lot better if the suffixes were mandatory in 
this new class
** If we did that, then the CurrencyFieldType.inform logic would be simpler as 
well: all it would have to worry about is ensuring the suffixes exist (the 
subclass can do it's own createDynamicCurrencyField before calling 
super.inform())
* The existence of the {{dynamicFieldDocValuesArg()}} method feels more awkward 
and clunky then just making {{createDynamicCurrencyField()}} a protected method 
that the subclass can override.
** of course: if I can convince you to eliminte the  
DEFAULT_FIELD_SUFFIX_AMOUNT_\* logic from the CurrencyFieldType parent class, 
that gets much simpler: only the CurrencyField subclass needs to bother 
implementing/calling {{createDynamicCurrencyField()}}


> CurrencyField should be changed from TrieLongField to LongPointField for 
> underlying raw-polyfield
> -
>
> Key: SOLR-10503
> URL: https://issues.apache.org/jira/browse/SOLR-10503
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10503.patch, SOLR-10503.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Jason Gerlowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054452#comment-16054452
 ] 

Jason Gerlowski commented on SOLR-10915:


That all makes sense; I'll do this later today (folding in the SOLR-9535 
changes as you suggested above).

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9535) SolrClients should have protected constructors

[Anshum Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054451#comment-16054451
 ] 

Anshum Gupta commented on SOLR-9535:


How about having constructor accepting the Builder object instead of this 
opening it up ? I think we would end up with the kitchen-sink again if we go 
this way.

> SolrClients should have protected constructors
> --
>
> Key: SOLR-9535
> URL: https://issues.apache.org/jira/browse/SOLR-9535
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9535.patch
>
>
> Recent SolrJ changes (SOLR-8097) resulted in {{SolrClient}} ending up with 
> {{protected}} ctors.  This achieved the purpose at the time, and steered 
> consumers towards using the *Builder types.  However the change was overly 
> restrictive, as this visibility prevents consumers from extending 
> {{SolrClient}} in any meaningful way.
> This issue involves changing the visibility of the SolrClient "kitchen sink" 
> ctors to better support extension.
> (See recent discussion on SOLR-8097 for more discussion on this topic.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9535) SolrClients should have protected constructors

[Anshum Gupta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshum Gupta updated SOLR-9535:
---
Fix Version/s: master (7.0)

> SolrClients should have protected constructors
> --
>
> Key: SOLR-9535
> URL: https://issues.apache.org/jira/browse/SOLR-9535
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9535.patch
>
>
> Recent SolrJ changes (SOLR-8097) resulted in {{SolrClient}} ending up with 
> {{protected}} ctors.  This achieved the purpose at the time, and steered 
> consumers towards using the *Builder types.  However the change was overly 
> restrictive, as this visibility prevents consumers from extending 
> {{SolrClient}} in any meaningful way.
> This issue involves changing the visibility of the SolrClient "kitchen sink" 
> ctors to better support extension.
> (See recent discussion on SOLR-8097 for more discussion on this topic.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Anshum Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054443#comment-16054443
 ] 

Anshum Gupta commented on SOLR-10915:
-

Also, SOLR-9535 seems to overlap with this to a reasonable extent. We could 
either commit this together as we're trying to solve the common problem of 
being able to extend the clients in a meaningful manner without duplicating 
code.

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Anshum Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054432#comment-16054432
 ] 

Anshum Gupta commented on SOLR-10915:
-

[~gerlowskija], ideally I'd want to build my extended client with something 
like:
{code:java}
MyClient client = new 
MyBuilder().withBaseSolrUrl("http://myBaseUrl/solr";).build();
{code}

but MyBuilder wouldn't have access to anything from the parent Builder class. 
The constructor for the client would need the object and so we'd have a 
deadlock.

I could just add a setter and get things taken care of there but I wouldn't be 
able to do anything at construction time. 
Also, adding everything to the client itself instead of through the builder 
breaks how it should be extended in my opinion and shouldn't be recommended. 

I haven't started working on this but I know what to do. If you want to take a 
shot at it, go for it and I can review it and get this in.

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Anshum Gupta (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshum Gupta reassigned SOLR-10915:
---

Assignee: Anshum Gupta

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7877) Replace PrefixAwareTokenStream

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054421#comment-16054421
 ] 

Uwe Schindler commented on LUCENE-7877:
---

[~dsmiley]: Your stream does something different than the one on this issue as 
replacement for the PrefixAwareTokenStream. Our's appends different token 
streams so they appear as one. It is therefor not a filter is the opposite of 
TeeSink.

> Replace PrefixAwareTokenStream
> --
>
> Key: LUCENE-7877
> URL: https://issues.apache.org/jira/browse/LUCENE-7877
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: LUCENE-7877.patch, LUCENE-7877.patch
>
>
> PrefixAwareTokenStream/PrefixAndSuffixAwareTokenStream use the deprecated and 
> broken Token class, which means they will not work with custom attributes.  
> We should fix/replace them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10880) Support replica filtering by flavour

[Domenico Fabio Marino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Domenico Fabio Marino updated SOLR-10880:
-
Attachment: SOLR-10880.patch

> Support replica filtering by flavour
> 
>
> Key: SOLR-10880
> URL: https://issues.apache.org/jira/browse/SOLR-10880
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Domenico Fabio Marino
>Priority: Minor
> Attachments: SOLR-10880.patch, SOLR-10880.patch
>
>
> Add a mechanism to allow queries to use only a subset of replicas(by 
> specifying the wanted replica "flavour").
> Some replicas have to be marked as "flavoured" before running the query.
> A query can specify ShardParams.SHARDS_REQUIRED_FLAVOUR to specify the 
> flavour it wants to use (Only one flavour can be specified) together with  
> ShardParams.SHARDS_CONSIDER_FLAVOURS set to true.
> The property Replica.REPLICA_FLAVOUR can be used to give a flavour to a 
> replica, the parameter it takes is a pipe ('|') separated list of flavours 
> (e.g. "chocolate|vanilla").
> The mappings between flavours is only computed when 
> ShardParams.SHARDS_CONSIDER_FLAVOURS is true, and it is computed separately 
> for each request.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10880) Support replica filtering by flavour

[Domenico Fabio Marino (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054386#comment-16054386
 ] 

Domenico Fabio Marino commented on SOLR-10880:
--

Patch updated


> Support replica filtering by flavour
> 
>
> Key: SOLR-10880
> URL: https://issues.apache.org/jira/browse/SOLR-10880
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Domenico Fabio Marino
>Priority: Minor
> Attachments: SOLR-10880.patch, SOLR-10880.patch
>
>
> Add a mechanism to allow queries to use only a subset of replicas(by 
> specifying the wanted replica "flavour").
> Some replicas have to be marked as "flavoured" before running the query.
> A query can specify ShardParams.SHARDS_REQUIRED_FLAVOUR to specify the 
> flavour it wants to use (Only one flavour can be specified) together with  
> ShardParams.SHARDS_CONSIDER_FLAVOURS set to true.
> The property Replica.REPLICA_FLAVOUR can be used to give a flavour to a 
> replica, the parameter it takes is a pipe ('|') separated list of flavours 
> (e.g. "chocolate|vanilla").
> The mappings between flavours is only computed when 
> ShardParams.SHARDS_CONSIDER_FLAVOURS is true, and it is computed separately 
> for each request.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7877) Replace PrefixAwareTokenStream

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054385#comment-16054385
 ] 

David Smiley commented on LUCENE-7877:
--

LOL yes a ConcatenatingTokenStream is something I've used twice already too.  
Here's mine: 
https://github.com/OpenSextant/SolrTextTagger/blob/master/src/main/java/org/opensextant/solrtexttagger/ConcatenateFilter.java
Shall I contribute [~thetaphi] ?

> Replace PrefixAwareTokenStream
> --
>
> Key: LUCENE-7877
> URL: https://issues.apache.org/jira/browse/LUCENE-7877
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: LUCENE-7877.patch, LUCENE-7877.patch
>
>
> PrefixAwareTokenStream/PrefixAndSuffixAwareTokenStream use the deprecated and 
> broken Token class, which means they will not work with custom attributes.  
> We should fix/replace them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10911) Fix inspection warnings reported by IntelliJ

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054377#comment-16054377
 ] 

Mike Drob commented on SOLR-10911:
--

Would love to have a shared profile (even better tie into {{ant idea}}).

Like the "fix javac warnings" jira, I think it makes sense to split this off 
into subtasks so people can tackle them as they have time. Unless you're 
volunteering to fix them all, Shalin. (smile)

> Fix inspection warnings reported by IntelliJ
> 
>
> Key: SOLR-10911
> URL: https://issues.apache.org/jira/browse/SOLR-10911
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: master (7.0)
>
>
> I'd like to fix some warnings reported by IntelliJ Idea that seem pertinent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Jason Gerlowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054373#comment-16054373
 ] 

Jason Gerlowski commented on SOLR-10915:


Yes, this is true.  Most (see below) of the SolrClient implementations have 
their constructors at protected visibility, so this is less of a problem with 
extending the SolrClients and more of a problem of being able to re-use the 
Builder code/pattern when you do so?  (I ask this not in an attempt to minimize 
the issue, but purely for clarification).

(Related to this issue in my mind is the fact that CloudSolrClient *doesn't* 
have a protected constructor.  This was raised on the mailing list, and a patch 
was put forward in SOLR-9535 .  Might be a good time to give that a little 
attention too, though it's not as important as the concerns you raise in this 
JIRA)

Getting back to this issue, I plan to push a patch for this tonight, unless 
you've already started on it [~anshumg]?

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7877) Replace PrefixAwareTokenStream

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054344#comment-16054344
 ] 

Uwe Schindler commented on LUCENE-7877:
---

Thanks David!

So we can seafely remove them!
Anyways, a ConcatenatingTokenStream is a good thing to have - I had the problem 
of concatting TokenStreams for several times.!

> Replace PrefixAwareTokenStream
> --
>
> Key: LUCENE-7877
> URL: https://issues.apache.org/jira/browse/LUCENE-7877
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: LUCENE-7877.patch, LUCENE-7877.patch
>
>
> PrefixAwareTokenStream/PrefixAndSuffixAwareTokenStream use the deprecated and 
> broken Token class, which means they will not work with custom attributes.  
> We should fix/replace them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Anshum Gupta (JIRA)]

Anshum Gupta created SOLR-10915:
---

 Summary: Make SolrClient classes extendable without code 
duplication
 Key: SOLR-10915
 URL: https://issues.apache.org/jira/browse/SOLR-10915
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: clients - java
Reporter: Anshum Gupta
Priority: Blocker
 Fix For: master (7.0)


SolrClient used to be easily extendable but our move to Builder pattern has 
made it impossible to extend those classes without code duplication. 
As an example, if we wanted to extend HttpSolrClient we would also want to 
extend the Builder. The problem is that the constructor of the main class, does 
not accept the builder object but explicit parameters, and the inherited class 
doesn't have access to any of those values from the Builder object as they are 
all private. 

Generally, we'd want to have the client object constructor accept the Builder, 
instead of explicit values, and also make the Builder values protected so the 
inherited classes could use them.

I'm marking this as a blocker for 7.0 as this is an important piece that needs 
to be fixed before the major release, specially now that we know that this 
problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7723) LongValuesSource/DoubleValuesSource impls should implement equals/hashCode

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054290#comment-16054290
 ] 

Alan Woodward commented on LUCENE-7723:
---

Any objections to me committing this?

> LongValuesSource/DoubleValuesSource impls should implement equals/hashCode
> --
>
> Key: LUCENE-7723
> URL: https://issues.apache.org/jira/browse/LUCENE-7723
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
> Attachments: LUCENE-7723.patch, LUCENE-7723.patch
>
>
> Given that we embed values sources in queries and sorts, from which we expect 
> that they have working equals/hashCode, we should also implement 
> equals/hashCode on LongValuesSource/DoubleValuesSource impls.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10779) JavaBinCodec should use close consistently rather than having marshal() and close() call finish() (which closes the underlying stream)

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054279#comment-16054279
 ] 

David Smiley commented on SOLR-10779:
-

Nice cleanup; thanks.

> JavaBinCodec should use close consistently rather than having marshal() and 
> close() call finish() (which closes the underlying stream)
> --
>
> Key: SOLR-10779
> URL: https://issues.apache.org/jira/browse/SOLR-10779
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: master (7.0)
>
> Attachments: SOLR-10779.patch, SOLR-10779.patch, SOLR-10779.patch
>
>
> Having the marshal() code call finish which in turn calls close() is trappy. 
> The marshal code is not robust anyway since if there's an exception before 
> the try loop, it will not close the resource.
> Sub task of SOLR-10778



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7863) Don't repeat postings and positions on ReverseWF, EdgeNGram, etc

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054262#comment-16054262
 ] 

David Smiley commented on LUCENE-7863:
--

Instead of hacking the index/codec, have you thought of using another field 
that only has the reversed terms?

> Don't repeat postings and positions on ReverseWF, EdgeNGram, etc  
> --
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7863.hazard
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes. 
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm 
> shuddering to think about EdgeNGrams...
> h2. Proposal 
> _DRY_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10911) Fix inspection warnings reported by IntelliJ

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054254#comment-16054254
 ] 

David Smiley commented on SOLR-10911:
-

There are a *ton* of inspections IntelliJ offers that vary a great deal between 
code taste and a likely bug.  Do you have a wholistic approach to this in mind 
(e.g. develop a share an inspection profile that we all use) or is this about 
some random observations in particular source files?

> Fix inspection warnings reported by IntelliJ
> 
>
> Key: SOLR-10911
> URL: https://issues.apache.org/jira/browse/SOLR-10911
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: master (7.0)
>
>
> I'd like to fix some warnings reported by IntelliJ Idea that seem pertinent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7880) Make boolean query clause limit configurable per-query

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054250#comment-16054250
 ] 

Yonik Seeley commented on LUCENE-7880:
--

First, lets assume that having this global limit is a valuable way to catch 
bugs (I disagree, but let's assume it for the sake of argument).
Now what if someone finds a place in their code where they legitimately need to 
build a bigger scoring boolean query?  What should they do?  If they raise the 
global static limit, they lose this valuable way to catch bugs.  If one accepts 
the first assumption, then it seems like one needs a way to override this limit 
on a per query basis.  If one does not accept the first assumption, then the 
limit should simply be removed.

Even at a higher granularity, what if one collection wants one limit and a 
different collection wants another limit (they could even be different 
customers collocated in the same JVM).  How should that be solved?  See 
SOLR-4586  for a more background / arguments.

If you are against the proposal in this issue, then what is your proposal to 
address these issues Adrien?

> Make boolean query clause limit configurable per-query
> --
>
> Key: LUCENE-7880
> URL: https://issues.apache.org/jira/browse/LUCENE-7880
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Yonik Seeley
>
> As we know, the magic BooleanQuery.maxClauseCount has bitten many people over 
> time.
> It's also a static, which really hurts multi-tenancy (i.e. we can't have 
> different settings for different users, clients, or use-cases).
> If we want to keep this static as a default, then at least we should allow it 
> to be overridden on a per-query basis when we know it is the desired behavior 
> and not a bug.
> Perhaps the simplest way to achieve this would be a setter on 
> BooleanQuery.Builder that configures the limit for that instance only?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [6/8] lucene-solr:master: SOLR-10882: ArrayEvaluator now works with all types and allows sorts (deleted ArraySortEvaluator)

[Erick Erickson]

Thanks, I was worried about the commit I did last night but it's not that. Whew!

On Sun, Jun 18, 2017 at 11:24 PM, Shalin Shekhar Mangar
 wrote:
> This commit has broken StreamExpressionTest.testArraySort
>
> On Sun, Jun 18, 2017 at 9:24 PM,   wrote:
>> SOLR-10882: ArrayEvaluator now works with all types and allows sorts 
>> (deleted ArraySortEvaluator)
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/113459a8
>> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/113459a8
>> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/113459a8
>>
>> Branch: refs/heads/master
>> Commit: 113459a840e8ca3482ebd36a76dda551fac885ec
>> Parents: 5fca6a4
>> Author: Dennis Gove 
>> Authored: Thu Jun 15 22:10:37 2017 -0400
>> Committer: Dennis Gove 
>> Committed: Sun Jun 18 11:50:58 2017 -0400
>>
>> --
>>  .../org/apache/solr/handler/StreamHandler.java  | 479 +--
>>  .../client/solrj/io/eval/ArrayEvaluator.java|  48 +-
>>  .../solrj/io/eval/ArraySortEvaluator.java   |  77 ---
>>  .../client/solrj/io/eval/ComplexEvaluator.java  |  18 +-
>>  .../io/stream/eval/ArrayEvaluatorTest.java  | 155 ++
>>  5 files changed, 452 insertions(+), 325 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/113459a8/solr/core/src/java/org/apache/solr/handler/StreamHandler.java
>> --
>> diff --git a/solr/core/src/java/org/apache/solr/handler/StreamHandler.java 
>> b/solr/core/src/java/org/apache/solr/handler/StreamHandler.java
>> index 7889bf7..4616204 100644
>> --- a/solr/core/src/java/org/apache/solr/handler/StreamHandler.java
>> +++ b/solr/core/src/java/org/apache/solr/handler/StreamHandler.java
>> @@ -77,7 +77,7 @@ public class StreamHandler extends RequestHandlerBase 
>> implements SolrCoreAware,
>>private StreamFactory streamFactory = new StreamFactory();
>>private static final Logger logger = 
>> LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
>>private String coreName;
>> -  private Map daemons = 
>> Collections.synchronizedMap(new HashMap());
>> +  private Map daemons = 
>> Collections.synchronizedMap(new HashMap());
>>
>>@Override
>>public PermissionNameProvider.Name getPermissionName(AuthorizationContext 
>> request) {
>> @@ -89,202 +89,202 @@ public class StreamHandler extends RequestHandlerBase 
>> implements SolrCoreAware,
>>}
>>
>>public void inform(SolrCore core) {
>> -
>> -/* The stream factory will always contain the zkUrl for the given 
>> collection
>> - * Adds default streams with their corresponding function names. These
>> - * defaults can be overridden or added to in the solrConfig in the 
>> stream
>> - * RequestHandler def. Example config override
>> - *  
>> - *> name="group">org.apache.solr.client.solrj.io.stream.ReducerStream
>> - *> name="count">org.apache.solr.client.solrj.io.stream.RecordCountStream
>> - *  
>> - * */
>> +
>> +/*
>> + * The stream factory will always contain the zkUrl for the given 
>> collection Adds default streams with their
>> + * corresponding function names. These defaults can be overridden or 
>> added to in the solrConfig in the stream
>> + * RequestHandler def. Example config override
>> + * 
>> + *  > name="group">org.apache.solr.client.solrj.io.stream.ReducerStream
>> + *  > name="count">org.apache.solr.client.solrj.io.stream.RecordCountStream
>> + * 
>> + */
>>
>>  String defaultCollection;
>>  String defaultZkhost;
>>  CoreContainer coreContainer = core.getCoreContainer();
>>  this.coreName = core.getName();
>>
>> -if(coreContainer.isZooKeeperAware()) {
>> +if (coreContainer.isZooKeeperAware()) {
>>defaultCollection = core.getCoreDescriptor().getCollectionName();
>>defaultZkhost = 
>> core.getCoreContainer().getZkController().getZkServerAddress();
>>streamFactory.withCollectionZkHost(defaultCollection, defaultZkhost);
>>streamFactory.withDefaultZkHost(defaultZkhost);
>>modelCache = new ModelCache(250,
>> -  defaultZkhost,
>> -  clientCache);
>> -}
>> -
>> - streamFactory
>> -   // source streams
>> -  .withFunctionName("search", CloudSolrStream.class)
>> -  .withFunctionName("facet", FacetStream.class)
>> -  .withFunctionName("update", UpdateStream.class)
>> -  .withFunctionName("jdbc", JDBCStream.class)
>> -  .withFunctionName("topic", TopicStream.class)
>> -  .withFunctionName("commit", CommitStream.class)
>> -  .withFunctionName("random", RandomStream.class)
>> -  .withFunctionName("knn", KnnStream.class)
>> -
>> -

[jira] [Commented] (SOLR-10914) RecoveryStrategy's sendPrepRecoveryCmd can get stuck for 5 minutes if leader is unloaded

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054243#comment-16054243
 ] 

Shalin Shekhar Mangar commented on SOLR-10914:
--

Thanks to [~ab] for catching this with the tests he wrote for SOLR-10878.

> RecoveryStrategy's sendPrepRecoveryCmd can get stuck for 5 minutes if leader 
> is unloaded
> 
>
> Key: SOLR-10914
> URL: https://issues.apache.org/jira/browse/SOLR-10914
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.4, 6.5, 6.6
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0)
>
>
> tl;dr; a recovering replica is stuck for 5 minutes in the prep recovery 
> request if the leader core is unloaded before the prep recovery request is 
> made.
> SOLR-9716 changed the sendPrepRecoveryCmd to retry on read timeouts (earlier 
> it had no connection/read timeout at all) but the fix has caused another 
> problem. Say 
> # A replica starts up (or is newly created) and goes into recovery, 
> # Replica finds that leader=X
> # The core X is unloaded but the node that used to host X is still running 
> and taking requests
> # Replica calls sendPrepRecoveryCmd to X
> At this point, the node X receives the prep recovery command, finds that the 
> core X does not exist and keeps checking again in a sleep-loop until a 
> timeout happens. I am not sure why prep recovery core admin command needs to 
> continue waiting if a local core does not exist. The default timeout here is 
> usually longer than 10 seconds.
> On the recovering replica's side, the prep recovery has a connection/read 
> timeout of only 10s, so the request always times out and is retried upto 5 
> minutes. Only then does the recovery attempt fails and may be restarted again 
> with the right leader URL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Solr JSON Facet API & aggregation functions documentation

[Cassandra Targett]

The JSON facet docs were in the "in progress" area of the old Ref
Guide: https://cwiki.apache.org/confluence/display/solr/Faceted+Search.
That page is probably rather out-of-date, since nearly all changes
from the time the page was first created are still listed on the TODO
list as undone (as Bram mentioned).

The various "in progress" files were exported from Confluence when I
did that for the Ref Guide migration in May, but have not yet been
converted to AsciiDoc format or committed to master.

On Mon, Jun 19, 2017 at 10:38 AM, Erick Erickson
 wrote:
> I don't see it in the ref guide. BTW, I download the full PDF as
> searching that is sometimes helpful.
>
> We've recently gone to AsciiDoc which is much easier to edit IMO, and
> also allows anyone (hint hint) to attach a patch to a JIRA for the
> documentation that makes it into the next version of reference guide
> as well as the current online version.
>
> IntelliJ has a plugin that has a pretty good previewer, and Atom is
> free and does the same.
>
> Best,
> Erick
>
> On Mon, Jun 19, 2017 at 7:58 AM, Bram Van Dam  wrote:
>> Hey folks,
>>
>> Yonik's blog [1] contains a list of aggregation functions supported by
>> the JSON Facet API (the json.facet parameter) butI can't seem to find
>> documentation for these on the cwiki.
>>
>> There's an old TODO list on the cwiki which mentions that this still
>> needs to happen. [2]
>>
>> Is anyone working on this? Do I simply suck at searching the cwiki? Or
>> can we kindly borrow Yonik's blog post and use its contents for
>> documentation?
>>
>> [1] http://yonik.com/solr-facet-functions/
>> [2] https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List
>>
>>  - Bram
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: JIRA Status - Finding Patch Submissions

[Mano Kovacs]

Hi,

Mike pointed to this thread after I created SOLR-10912 (I missed this
conversation). I am for running validations automatically against patches,
similarly what Hadoop or Oziee (and probably others) have. I don't have
strong opinion what and when to check, but I believe that it could be
finalized or adjusted later.

If that is ok with you, I would create a pilot using Yetus and some of our
existing validations, running on sample jiras. That would give us
opportunity to workout the details of the ideal solution.

Regards,
Mano



On Thu, May 18, 2017 at 4:10 AM, David Smiley 
wrote:

> On Wed, May 17, 2017 at 7:36 PM Mike Drob  wrote:
>
>> David, what do you mean by
>>
>> > Hopefully without generating comments that trigger email/watcher
>> notifications and thus no more dev list traffic.
>>
>> How else other than a comment could the system communicate results back
>> to the user? Or do you mean that whatever runs should post a comment, but
>> suppress email notification somehow.
>>
>
> Yes; that.  The rationale being that if someone posts a patch, it'll
> become inevitable that there will be a follow-up bot comment.  It's not a
> big deal though.
>
>
>> I'm not sure that last bit is possible... would have to talk to INFRA
>> about it maybe.
>>
>> > I'm not sure what to make of it... perhaps you can make a specific
>> proposal.
>>
>> Nothing concrete yet, but it's likely a good candidate tool for the job
>> here. There are already ASF Jenkins jobs to look for JIRA updates on other
>> projects, download patches, and try to run precommit checks. If this is
>> something we were interested in, I think it wouldn't be too hard to add
>> ourselves to the list. I'd much rather use an existing tool than worry
>> abotu coming up with something myself.
>>
>
> +1 to that last bit especially.  No reason to reinvent any wheels here.
>
> 
>
>> If the state is set automatically, how do we know when to set it?
>>
>> Maybe this could be an extra (optional?) step for the committer looking
>> at the issue? Change to "Patch Available" triggers a run on the most recent
>> attached patch?
>>
>
> +1 nice idea; seems straight-forward compared to other ideas.  I don't
> think we need to limit this transition to only committers though; even the
> submitter might do it to demonstrate their patch is ready.
>
> Cheers,
> ~ David
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>

Re: Solr JSON Facet API & aggregation functions documentation

[Erick Erickson]

I don't see it in the ref guide. BTW, I download the full PDF as
searching that is sometimes helpful.

We've recently gone to AsciiDoc which is much easier to edit IMO, and
also allows anyone (hint hint) to attach a patch to a JIRA for the
documentation that makes it into the next version of reference guide
as well as the current online version.

IntelliJ has a plugin that has a pretty good previewer, and Atom is
free and does the same.

Best,
Erick

On Mon, Jun 19, 2017 at 7:58 AM, Bram Van Dam  wrote:
> Hey folks,
>
> Yonik's blog [1] contains a list of aggregation functions supported by
> the JSON Facet API (the json.facet parameter) butI can't seem to find
> documentation for these on the cwiki.
>
> There's an old TODO list on the cwiki which mentions that this still
> needs to happen. [2]
>
> Is anyone working on this? Do I simply suck at searching the cwiki? Or
> can we kindly borrow Yonik's blog post and use its contents for
> documentation?
>
> [1] http://yonik.com/solr-facet-functions/
> [2] https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List
>
>  - Bram
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)

[Cao Manh Dat (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054225#comment-16054225
 ] 

Cao Manh Dat commented on SOLR-9989:


bq. One question I had during review was the FacetRange.Calc implementations 
and why the ifs vs having separate implementations?

I don't know the reason for the having separate implementation in PointField, 
either
>From {{PointFields.createFields}}
{code}
if (!sf.multiValued()) {
if (numericValue instanceof Integer || numericValue instanceof Long) {
bits = numericValue.longValue();
} else if (numericValue instanceof Float) {
bits = Float.floatToIntBits(numericValue.floatValue());
} else {
assert numericValue instanceof Double;
bits = Double.doubleToLongBits(numericValue.doubleValue());
}
fields.add(new NumericDocValuesField(sf.getName(), bits));
} else {
// MultiValued
if (numericValue instanceof Integer || numericValue instanceof Long) {
bits = numericValue.longValue();
} else if (numericValue instanceof Float) {
bits = 
NumericUtils.floatToSortableInt(numericValue.floatValue());
} else {
assert numericValue instanceof Double;
bits = 
NumericUtils.doubleToSortableLong(numericValue.doubleValue());
}
fields.add(new SortedNumericDocValuesField(sf.getName(), bits));
}
{code}

Thanks [~ysee...@gmail.com]

> Add support for PointFields in FacetModule (JSON Facets)
> 
>
> Key: SOLR-9989
> URL: https://issues.apache.org/jira/browse/SOLR-9989
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10914) RecoveryStrategy's sendPrepRecoveryCmd can get stuck for 5 minutes if leader is unloaded

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-10914:


 Summary: RecoveryStrategy's sendPrepRecoveryCmd can get stuck for 
5 minutes if leader is unloaded
 Key: SOLR-10914
 URL: https://issues.apache.org/jira/browse/SOLR-10914
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 6.6, 6.5, 6.4
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: master (7.0)


tl;dr; a recovering replica is stuck for 5 minutes in the prep recovery request 
if the leader core is unloaded before the prep recovery request is made.

SOLR-9716 changed the sendPrepRecoveryCmd to retry on read timeouts (earlier it 
had no connection/read timeout at all) but the fix has caused another problem. 
Say 
# A replica starts up (or is newly created) and goes into recovery, 
# Replica finds that leader=X
# The core X is unloaded but the node that used to host X is still running and 
taking requests
# Replica calls sendPrepRecoveryCmd to X

At this point, the node X receives the prep recovery command, finds that the 
core X does not exist and keeps checking again in a sleep-loop until a timeout 
happens. I am not sure why prep recovery core admin command needs to continue 
waiting if a local core does not exist. The default timeout here is usually 
longer than 10 seconds.

On the recovering replica's side, the prep recovery has a connection/read 
timeout of only 10s, so the request always times out and is retried upto 5 
minutes. Only then does the recovery attempt fails and may be restarted again 
with the right leader URL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-10242) Cores created by Solr RESTORE end up with stale searches after indexing

[Varun Thacker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Varun Thacker reassigned SOLR-10242:


Assignee: Varun Thacker

> Cores created by Solr RESTORE end up with stale searches after indexing
> ---
>
> Key: SOLR-10242
> URL: https://issues.apache.org/jira/browse/SOLR-10242
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore, search
>Affects Versions: 6.3
> Environment: Behavior observed on both Linux and Windows:
> Linux version 3.10.0-327.36.3.el7.x86_64 
> (mockbu...@x86-037.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red 
> Hat 4.8.5-4) (GCC) ) #1 SMP Thu Oct 20 04:56:07 EDT 2016
> java version "1.8.0_77"
> Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> Windows 10 Enterprise Version 1607 Build 14393.693
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>Reporter: John Marquiss
>Assignee: Varun Thacker
>
> Index files created by the Solr RESTORE feature are placed in a directory 
> with a name like "restore.20170307173236270" instead of the standard "index" 
> directory. This seems to break Solr's ability to detect index changes leading 
> to stale searchers on the restored cores.
> Detailed information including steps to replicate can be found in this 
> solr-user mail thread. [http://markmail.org/message/wsm56jgbh53fx24u]
> (The markmail site seems to be down... linking the relevant messages from the 
> Apache archive)
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3CCO2PR06MB6345317732A4D7C22C00BCCFD2F0%40CO2PR06MB634.namprd06.prod.outlook.com%3E]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3CCO2PR06MB6342202F82CFD4A2F5617AEFD2F0%40CO2PR06MB634.namprd06.prod.outlook.com%3E]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7877) Replace PrefixAwareTokenStream

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054221#comment-16054221
 ] 

David Smiley commented on LUCENE-7877:
--

I was curious what this thing was, since I hadn't noticed it before.  It 
appears to have been introduced with LUCENE-1320 ShingleMatrixFilter.  
ShingleMatrixFilter is today nowhere to be found; it was removed in LUCENE-2920 
by [~thetaphi] because, in his words, it was unmaintained and buggy.  I wonder 
if it's worthwhile to even have these Prefix-etc. token filters?  Any way I 
have no opinion but I wanted to share what I dug up.

> Replace PrefixAwareTokenStream
> --
>
> Key: LUCENE-7877
> URL: https://issues.apache.org/jira/browse/LUCENE-7877
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: LUCENE-7877.patch, LUCENE-7877.patch
>
>
> PrefixAwareTokenStream/PrefixAndSuffixAwareTokenStream use the deprecated and 
> broken Token class, which means they will not work with custom attributes.  
> We should fix/replace them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Release planning for 7.0

[Erick Erickson]

Anshum:

I'm one of the people that expect a 6.7 release, but it's more along
the lines of setting expectations than having features I really want
to get in to the 6x code line. We nearly always have "just a few
things" that someone would like to put in, and/or a bug fix or two
that surfaces.

I expect people to back-port stuff they consider easy/beneficial to
6.x for "a while" as 7.0 solidifies, at their discretion of course.
Think of my position as giving people a target for tidying up 6.x
rather than a concrete plan ;). Just seems to always happen.

And if there is no 6.7, that's OK too. Additions to master-2 usually
pretty swiftly stop as the hassle of merging any change into 3 code
lines causes people to pick what goes into master-2 more carefully ;)

Erick

On Mon, Jun 19, 2017 at 8:03 AM, Alan Woodward  wrote:
> I’d like to get https://issues.apache.org/jira/browse/LUCENE-7877 in for 7.0
> - should be able to commit in the next couple of days.
>
> Alan Woodward
> www.flax.co.uk
>
>
> On 19 Jun 2017, at 15:45, Anshum Gupta  wrote:
>
> Hi everyone,
>
> Here's the update about 7.0 release:
>
> There are still  unresolved blockers for 7.0.
> Solr (12):
> https://issues.apache.org/jira/browse/SOLR-6630?jql=project%20%3D%20Solr%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3D%20Blocker
>
> Lucene (None):
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20%22Lucene%20-%20Core%22%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker
>
> Here are the ones that are unassigned:
> https://issues.apache.org/jira/browse/SOLR-6630
> https://issues.apache.org/jira/browse/SOLR-10887
> https://issues.apache.org/jira/browse/SOLR-10803
> https://issues.apache.org/jira/browse/SOLR-10756
> https://issues.apache.org/jira/browse/SOLR-10710
> https://issues.apache.org/jira/browse/SOLR-9321
> https://issues.apache.org/jira/browse/SOLR-8256
>
> The ones that are already assigned, I'd request you to update the JIRA so we
> can track it better.
>
> In addition, I am about to create another one as I wasn’t able to extend
> SolrClient easily without a code duplication on master.
>
> This brings us to - 'when can we cut the branch'. I can create the branch
> this week and we can continue to work on these as long as none of these are
> 'new features' but I'd be happy to hear what everyone has to say.
>
> I know there were suggestions around a 6.7 release, does anyone who's
> interested in leading that have a timeline or an idea around what features
> did you want in that release? If yes, I’d really want to wait until at least
> the branch for 6.7 is cur for the purpose of easy back-compat management and
> guarantee.
>
> Also, sorry for being on radio silence for the last few days. I’d been
> traveling but now I’m back :).
>
> -Anshum Gupta
>
> On Sun, Jun 18, 2017 at 8:57 AM Dennis Gove  wrote:
>>
>> I've committed the most critical changes I wanted to make. Please don't
>> hold up on a v7 release on my part.
>>
>> Thanks!
>>
>> Dennis
>>
>> On Tue, Jun 13, 2017 at 9:27 AM, Dennis Gove  wrote:
>>>
>>> Hi,
>>>
>>> I also have some cleanup I'd like to do prior to a cut of 7. There are
>>> some new stream evaluators that I'm finding don't flow with the general
>>> flavor of evaluators. I'm using
>>> https://issues.apache.org/jira/browse/SOLR-10882 for the cleanup, but I do
>>> intend to be complete by June 16th.
>>>
>>> Thanks,
>>> Dennis
>>>
>>>
>>> On Sat, Jun 10, 2017 at 11:21 AM, Ishan Chattopadhyaya
>>>  wrote:

 Hi Anshum,
 I would like to request you to consider delaying the branch cutting by a
 bit till we finalize the SOLR-10574 discussions and make the changes.
 Alternatively, we could backport the changes to that branch after you cut
 the branch now.
 Regards,
 Ishan

 On Sat, Jun 3, 2017 at 1:02 AM, Steve Rowe  wrote:
>
>
> > On Jun 2, 2017, at 5:40 PM, Shawn Heisey  wrote:
> >
> > On 6/2/2017 10:23 AM, Steve Rowe wrote:
> >
> >> I see zero benefits from cutting branch_7x now.  Shawn, can you
> >> describe why you think we should do this?
> >>
> >> My interpretation of your argument is that you’re in favor of
> >> delaying cutting branch_7_0 until feature freeze - which BTW is the 
> >> status
> >> quo - but I don’t get why that argues for cutting branch_7x now.
> >
> > I think I read something in the message I replied to that wasn't
> > actually stated.  I hate it when I don't read things closely enough.
> >
> > I meant to address the idea of making both branch_7x and branch_7_0
> > at
> > the same time, whenever the branching happens.  Somehow I came up
> > with
> > the idea that the gist of the discussion included making the branches
> > now, which I can see is not the case.
> >
> > My point, which I think applies equally to branch_7x, is to wait as

[jira] [Commented] (SOLR-10242) Cores created by Solr RESTORE end up with stale searches after indexing

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054215#comment-16054215
 ] 

Varun Thacker commented on SOLR-10242:
--

Hi John,

I'm trying to reproduce the problem

{code}
7)  Index 2 new documents to 'test2'
{code}

At this point do you issue a hard commit? Do you have a soft commit set in your 
solrconfig?

> Cores created by Solr RESTORE end up with stale searches after indexing
> ---
>
> Key: SOLR-10242
> URL: https://issues.apache.org/jira/browse/SOLR-10242
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore, search
>Affects Versions: 6.3
> Environment: Behavior observed on both Linux and Windows:
> Linux version 3.10.0-327.36.3.el7.x86_64 
> (mockbu...@x86-037.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red 
> Hat 4.8.5-4) (GCC) ) #1 SMP Thu Oct 20 04:56:07 EDT 2016
> java version "1.8.0_77"
> Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
> Windows 10 Enterprise Version 1607 Build 14393.693
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>Reporter: John Marquiss
>
> Index files created by the Solr RESTORE feature are placed in a directory 
> with a name like "restore.20170307173236270" instead of the standard "index" 
> directory. This seems to break Solr's ability to detect index changes leading 
> to stale searchers on the restored cores.
> Detailed information including steps to replicate can be found in this 
> solr-user mail thread. [http://markmail.org/message/wsm56jgbh53fx24u]
> (The markmail site seems to be down... linking the relevant messages from the 
> Apache archive)
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3CCO2PR06MB6345317732A4D7C22C00BCCFD2F0%40CO2PR06MB634.namprd06.prod.outlook.com%3E]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201703.mbox/%3CCO2PR06MB6342202F82CFD4A2F5617AEFD2F0%40CO2PR06MB634.namprd06.prod.outlook.com%3E]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9989) Add support for PointFields in FacetModule (JSON Facets)

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054203#comment-16054203
 ] 

Yonik Seeley commented on SOLR-9989:


One question I had during review was the FacetRange.Calc implementations and 
why the ifs vs having separate implementations?
Anyway, this is all implementation which can be further refined later (as much 
of the rest of the FacetModule needs), so +1 to commit now.  Nice job!


> Add support for PointFields in FacetModule (JSON Facets)
> 
>
> Key: SOLR-9989
> URL: https://issues.apache.org/jira/browse/SOLR-9989
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9989.patch, SOLR-9989.patch, SOLR-9989.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-EA] Lucene-Solr-master-Windows (32bit/jdk-9-ea+173) - Build # 6662 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6662/
Java: 32bit/jdk-9-ea+173 -client -XX:+UseParallelGC

3 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  
'org.apache.solr.core.BlobStoreTestRequestHandler' for path 
'overlay/requestHandler/\/test1/class' full output: {   "responseHeader":{ 
"status":0, "QTime":0},   "overlay":{ "znodeVersion":0, 
"runtimeLib":{"colltest":{ "name":"colltest", "version":1,  
from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  
'org.apache.solr.core.BlobStoreTestRequestHandler' for path 
'overlay/requestHandler/\/test1/class' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "overlay":{
"znodeVersion":0,
"runtimeLib":{"colltest":{
"name":"colltest",
"version":1,  from server:  null
at 
__randomizedtesting.SeedInfo.seed([3012E2A546AAB657:E85FCFF2B17713F7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:97)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache

[jira] [Commented] (LUCENE-7737) Remove spatial-extras dependency on queries

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054168#comment-16054168
 ] 

David Smiley commented on LUCENE-7737:
--

[~romseygeek] now that LUCENE-7741 is done, can you update this ticket to have 
the score explanations?  It would be nice to make a change like this in 7.0.

> Remove spatial-extras dependency on queries
> ---
>
> Key: LUCENE-7737
> URL: https://issues.apache.org/jira/browse/LUCENE-7737
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial-extras
>Reporter: Alan Woodward
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: LUCENE-7737.patch
>
>
> The spatial-extras module uses ValueSources for a number of different 
> purposes, requiring a dependency on the queries module.  I'd like to try 
> using core-only interfaces here instead, allowing us to remove the dependency



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-Tests-master - Build # 1879 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1879/

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ObjectTracker found 6 object(s) that were not released!!! [MMapDirectory, 
SolrCore, MMapDirectory, MDCAwareThreadPoolExecutor, SolrIndexSearcher, 
MMapDirectory] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:753)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:948)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:855)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:979)  at 
org.apache.solr.core.CoreContainer.lambda$load$7(CoreContainer.java:611)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1033)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:855)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:979)  at 
org.apache.solr.core.CoreContainer.lambda$load$7(CoreContainer.java:611)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:490)  
at org.apache.solr.core.SolrCore.(SolrCore.java:942)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:855)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:979)  at 
org.apache.solr.core.CoreContainer.lambda$load$7(CoreContainer.java:611)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:884)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:855)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:979)  at 
org.apache.solr.core.CoreContainer.lambda$load$7(CoreContainer.java:611)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.search.SolrIndexSearcher  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.search.SolrIndexSearcher.(SolrIndexSearcher.java:323)  at 
org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:2047)  at 

[jira] [Commented] (SOLR-10710) LTR contrib failures

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054159#comment-16054159
 ] 

Steve Rowe commented on SOLR-10710:
---

[~tomasflobbe], looks like this issue can be resolved?

> LTR contrib failures
> 
>
> Key: SOLR-10710
> URL: https://issues.apache.org/jira/browse/SOLR-10710
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Steve Rowe
>Priority: Blocker
> Fix For: master (7.0)
>
>
> Reproducing failures 
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1304/] - {{git 
> bisect}} says {{06a6034d9}}, the commit on LUCENE-7730, is where the 
> {{TestFieldLengthFeature.testRanking()}} failure started:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestFieldLengthFeature -Dtests.method=testRanking 
> -Dtests.seed=740EF58DAA5926DA -Dtests.slow=true -Dtests.locale=ja-JP 
> -Dtests.timezone=America/Port_of_Spain -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.06s J1 | TestFieldLengthFeature.testRanking <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '8'!='1' 
> @ response/docs/[0]/id
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([740EF58DAA5926DA:EB385C1332233915]:0)
>[junit4]>  at 
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
>[junit4]>  at 
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
>[junit4]>  at 
> org.apache.solr.ltr.feature.TestFieldLengthFeature.testRanking(TestFieldLengthFeature.java:117)
> {noformat}
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestParallelWeightCreation 
> -Dtests.method=testLTRScoringQueryParallelWeightCreationResultOrder 
> -Dtests.seed=740EF58DAA5926DA -Dtests.slow=true -Dtests.locale=ar-SD 
> -Dtests.timezone=Europe/Skopje -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   1.59s J1 | 
> TestParallelWeightCreation.testLTRScoringQueryParallelWeightCreationResultOrder
>  <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='4' 
> @ response/docs/[0]/id
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([740EF58DAA5926DA:1142D5ED603B4132]:0)
>[junit4]>  at 
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
>[junit4]>  at 
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
>[junit4]>  at 
> org.apache.solr.ltr.TestParallelWeightCreation.testLTRScoringQueryParallelWeightCreationResultOrder(TestParallelWeightCreation.java:45)
> {noformat}
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestSelectiveWeightCreation 
> -Dtests.method=testSelectiveWeightsRequestFeaturesFromDifferentStore 
> -Dtests.seed=740EF58DAA5926DA -Dtests.slow=true -Dtests.locale=hr-HR 
> -Dtests.timezone=Australia/Victoria -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.03s J1 | 
> TestSelectiveWeightCreation.testSelectiveWeightsRequestFeaturesFromDifferentStore
>  <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: mismatch: '3'!='4' 
> @ response/docs/[0]/id
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([740EF58DAA5926DA:293FE248276551B1]:0)
>[junit4]>  at 
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
>[junit4]>  at 
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
>[junit4]>  at 
> org.apache.solr.ltr.TestSelectiveWeightCreation.testSelectiveWeightsRequestFeaturesFromDifferentStore(TestSelectiveWeightCreation.java:230)
> {noformat}
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestLTRQParserPlugin -Dtests.method=ltrMoreResultsThanReRankedTest 
> -Dtests.seed=740EF58DAA5926DA -Dtests.slow=true -Dtests.locale=es-NI 
> -Dtests.timezone=Africa/Mogadishu -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   0.03s J1 | 
> TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: mismatch: 
> '0.09271725'!='0.105360515' @ response/docs/[3]/score
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([740EF58DAA5926DA:BD7644EA7596711B]:0)
>[junit4]>  at 
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
>[junit4]>  at 
> org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
>[junit4]>  at 
> org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest(TestLTRQParserPlugin.java:94)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

--

Re: Release planning for 7.0

[Alan Woodward]

I’d like to get https://issues.apache.org/jira/browse/LUCENE-7877 
 in for 7.0 - should be able 
to commit in the next couple of days.

Alan Woodward
www.flax.co.uk


> On 19 Jun 2017, at 15:45, Anshum Gupta  wrote:
> 
> Hi everyone,
> 
> Here's the update about 7.0 release:
> 
> There are still  unresolved blockers for 7.0. 
> Solr (12):
> https://issues.apache.org/jira/browse/SOLR-6630?jql=project%20%3D%20Solr%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3D%20Blocker
>  
> 
> 
> Lucene (None):
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20%22Lucene%20-%20Core%22%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker
>  
> 
> 
> Here are the ones that are unassigned:
> https://issues.apache.org/jira/browse/SOLR-6630 
> 
> https://issues.apache.org/jira/browse/SOLR-10887 
> 
> https://issues.apache.org/jira/browse/SOLR-10803 
> 
> https://issues.apache.org/jira/browse/SOLR-10756 
> 
> https://issues.apache.org/jira/browse/SOLR-10710 
> 
> https://issues.apache.org/jira/browse/SOLR-9321 
> 
> https://issues.apache.org/jira/browse/SOLR-8256 
> 
> 
> The ones that are already assigned, I'd request you to update the JIRA so we 
> can track it better.
> 
> In addition, I am about to create another one as I wasn’t able to extend 
> SolrClient easily without a code duplication on master. 
> 
> This brings us to - 'when can we cut the branch'. I can create the branch 
> this week and we can continue to work on these as long as none of these are 
> 'new features' but I'd be happy to hear what everyone has to say. 
> 
> I know there were suggestions around a 6.7 release, does anyone who's 
> interested in leading that have a timeline or an idea around what features 
> did you want in that release? If yes, I’d really want to wait until at least 
> the branch for 6.7 is cur for the purpose of easy back-compat management and 
> guarantee.
> 
> Also, sorry for being on radio silence for the last few days. I’d been 
> traveling but now I’m back :).
> 
> -Anshum Gupta
> 
> On Sun, Jun 18, 2017 at 8:57 AM Dennis Gove  > wrote:
> I've committed the most critical changes I wanted to make. Please don't hold 
> up on a v7 release on my part.
> 
> Thanks!
> 
> Dennis
> 
> On Tue, Jun 13, 2017 at 9:27 AM, Dennis Gove  > wrote:
> Hi,
> 
> I also have some cleanup I'd like to do prior to a cut of 7. There are some 
> new stream evaluators that I'm finding don't flow with the general flavor of 
> evaluators. I'm using https://issues.apache.org/jira/browse/SOLR-10882 
>  for the cleanup, but I do 
> intend to be complete by June 16th.
> 
> Thanks,
> Dennis
> 
> 
> On Sat, Jun 10, 2017 at 11:21 AM, Ishan Chattopadhyaya 
> mailto:ichattopadhy...@gmail.com>> wrote:
> Hi Anshum,
> I would like to request you to consider delaying the branch cutting by a bit 
> till we finalize the SOLR-10574 discussions and make the changes. 
> Alternatively, we could backport the changes to that branch after you cut the 
> branch now.
> Regards,
> Ishan
> 
> On Sat, Jun 3, 2017 at 1:02 AM, Steve Rowe  > wrote:
> 
> > On Jun 2, 2017, at 5:40 PM, Shawn Heisey  > > wrote:
> >
> > On 6/2/2017 10:23 AM, Steve Rowe wrote:
> >
> >> I see zero benefits from cutting branch_7x now.  Shawn, can you describe 
> >> why you think we should do this?
> >>
> >> My interpretation of your argument is that you’re in favor of delaying 
> >> cutting branch_7_0 until feature freeze - which BTW is the status quo - 
> >> but I don’t get why that argues for cutting branch_7x now.
> >
> > I think I read something in the message I replied to that wasn't
> > actually stated.  I hate it when I don't read things closely enough.
> >
> > I meant to address the idea of making both branch_7x and branch_7_0 at
> > the same time, whenever the branching happens.  Somehow I came up with
> > the idea that the gist of the discussion included making the branches
> > now, which I can see is not the case.
> >
> > My point, which I

[jira] [Commented] (SOLR-10912) Adding automatic patch validation

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054147#comment-16054147
 ] 

Mike Drob commented on SOLR-10912:
--

[~manokovacs] - I'm on board with this. There was some discussion already at 
https://lists.apache.org/thread.html/21ad23ec5449171739d87681cf2d011f20d39c39420c1e610a3b1751@%3Cdev.lucene.apache.org%3E
 but I didn't have time to drive it further.

> Adding automatic patch validation
> -
>
> Key: SOLR-10912
> URL: https://issues.apache.org/jira/browse/SOLR-10912
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Reporter: Mano Kovacs
>
> Proposing introduction of automated patch validation, similar what Hadoop or 
> other Apache projects are using (see link). This would ensure that every 
> patch passes a certain set of criterions before getting approved. It would 
> save time for developer (faster feedback loop), save time for committers 
> (less step to do manually), and would increase quality.
> Hadoop is currently using Apache Yetus to run validations, which seems to be 
> a good direction to start. This jira could be the board of discussing the 
> preferred solution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Solr JSON Facet API & aggregation functions documentation

[Bram Van Dam]

Hey folks,

Yonik's blog [1] contains a list of aggregation functions supported by
the JSON Facet API (the json.facet parameter) butI can't seem to find
documentation for these on the cwiki.

There's an old TODO list on the cwiki which mentions that this still
needs to happen. [2]

Is anyone working on this? Do I simply suck at searching the cwiki? Or
can we kindly borrow Yonik's blog post and use its contents for
documentation?

[1] http://yonik.com/solr-facet-functions/
[2] https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List

 - Bram

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Release planning for 7.0

[Anshum Gupta]

Hi everyone,

Here's the update about 7.0 release:

There are still  unresolved blockers for 7.0.
Solr (12):
https://issues.apache.org/jira/browse/SOLR-6630?jql=project%20%3D%20Solr%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3D%20Blocker

Lucene (None):
https://issues.apache.org/jira/issues/?jql=project%20%3D%20%22Lucene%20-%20Core%22%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker

Here are the ones that are unassigned:
https://issues.apache.org/jira/browse/SOLR-6630
https://issues.apache.org/jira/browse/SOLR-10887
https://issues.apache.org/jira/browse/SOLR-10803
https://issues.apache.org/jira/browse/SOLR-10756
https://issues.apache.org/jira/browse/SOLR-10710
https://issues.apache.org/jira/browse/SOLR-9321
https://issues.apache.org/jira/browse/SOLR-8256

The ones that are already assigned, I'd request you to update the JIRA so
we can track it better.

In addition, I am about to create another one as I wasn’t able to extend
SolrClient easily without a code duplication on master.

This brings us to - 'when can we cut the branch'. I can create the branch
this week and we can continue to work on these as long as none of these are
'new features' but I'd be happy to hear what everyone has to say.

I know there were suggestions around a 6.7 release, does anyone who's
interested in leading that have a timeline or an idea around what features
did you want in that release? If yes, I’d really want to wait until at
least the branch for 6.7 is cur for the purpose of easy back-compat
management and guarantee.

Also, sorry for being on radio silence for the last few days. I’d been
traveling but now I’m back :).

-Anshum Gupta

On Sun, Jun 18, 2017 at 8:57 AM Dennis Gove  wrote:

> I've committed the most critical changes I wanted to make. Please don't
> hold up on a v7 release on my part.
>
> Thanks!
>
> Dennis
>
> On Tue, Jun 13, 2017 at 9:27 AM, Dennis Gove  wrote:
>
>> Hi,
>>
>> I also have some cleanup I'd like to do prior to a cut of 7. There are
>> some new stream evaluators that I'm finding don't flow with the general
>> flavor of evaluators. I'm using
>> https://issues.apache.org/jira/browse/SOLR-10882 for the cleanup, but I
>> do intend to be complete by June 16th.
>>
>> Thanks,
>> Dennis
>>
>>
>> On Sat, Jun 10, 2017 at 11:21 AM, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Hi Anshum,
>>> I would like to request you to consider delaying the branch cutting by a
>>> bit till we finalize the SOLR-10574 discussions and make the changes.
>>> Alternatively, we could backport the changes to that branch after you cut
>>> the branch now.
>>> Regards,
>>> Ishan
>>>
>>> On Sat, Jun 3, 2017 at 1:02 AM, Steve Rowe  wrote:
>>>

 > On Jun 2, 2017, at 5:40 PM, Shawn Heisey  wrote:
 >
 > On 6/2/2017 10:23 AM, Steve Rowe wrote:
 >
 >> I see zero benefits from cutting branch_7x now.  Shawn, can you
 describe why you think we should do this?
 >>
 >> My interpretation of your argument is that you’re in favor of
 delaying cutting branch_7_0 until feature freeze - which BTW is the status
 quo - but I don’t get why that argues for cutting branch_7x now.
 >
 > I think I read something in the message I replied to that wasn't
 > actually stated.  I hate it when I don't read things closely enough.
 >
 > I meant to address the idea of making both branch_7x and branch_7_0 at
 > the same time, whenever the branching happens.  Somehow I came up with
 > the idea that the gist of the discussion included making the branches
 > now, which I can see is not the case.
 >
 > My point, which I think applies equally to branch_7x, is to wait as
 long
 > as practical before creating a branch, so that there is as little
 > backporting as we can manage, particularly minimizing the amount of
 time
 > that we have more than two branches being actively changed.

 +1

 --
 Steve
 www.lucidworks.com


 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


>>>
>>
>

[jira] [Updated] (LUCENE-7877) Replace PrefixAwareTokenStream

[Alan Woodward (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Woodward updated LUCENE-7877:
--
Attachment: LUCENE-7877.patch

Here's an updated patch folding in comments.

> Replace PrefixAwareTokenStream
> --
>
> Key: LUCENE-7877
> URL: https://issues.apache.org/jira/browse/LUCENE-7877
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: LUCENE-7877.patch, LUCENE-7877.patch
>
>
> PrefixAwareTokenStream/PrefixAndSuffixAwareTokenStream use the deprecated and 
> broken Token class, which means they will not work with custom attributes.  
> We should fix/replace them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10882) Restructure and Cleanup Stream Evaluators

[Dennis Gove (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054002#comment-16054002
 ] 

Dennis Gove commented on SOLR-10882:


Appears this
{code}
Comparator comparator = "asc".equals(sortOrder) ? (left,right) -> 
left.compareTo(right) : (left,right) -> right.compareTo(left);
list = list.stream().map(value -> 
(Comparable)value).sorted(comparator).collect(Collectors.toList());
{code}

doesn't take into account differing types (double and long). Will correct with 
a type normalization pass.


> Restructure and Cleanup Stream Evaluators
> -
>
> Key: SOLR-10882
> URL: https://issues.apache.org/jira/browse/SOLR-10882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Dennis Gove
> Attachments: SOLR-10882.patch
>
>
> There are a suite of new Stream Evaluators that I'd like to cleanup and 
> restructure prior to the cutting of v7. This ticket is to track that progress.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (LUCENE-7882) Maybe expression compiler should cache recently compiled expressions?

[Dawid Weiss (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053984#comment-16053984
 ] 

Dawid Weiss edited comment on LUCENE-7882 at 6/19/17 1:27 PM:
--

It probably does slow down over time because they're loaded into their own 
class loaders? Are they GCed properly?


was (Author: dweiss):
It probably does because they're loaded into their own class loaders?

> Maybe expression compiler should cache recently compiled expressions?
> -
>
> Key: LUCENE-7882
> URL: https://issues.apache.org/jira/browse/LUCENE-7882
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/expressions
>Reporter: Michael McCandless
>
> I've been running search performance tests using a simple expression 
> ({{_score + ln(1000+unit_sales)}}) for sorting and hit this odd bottleneck:
> {noformat}
> "pool-1-thread-30" #70 prio=5 os_prio=0 tid=0x7eea7000a000 nid=0x1ea8a 
> waiting for monitor entry [0x7eea867dd000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.apache.lucene.expressions.js.JavascriptCompiler$CompiledExpression.evaluate(_score
>  + ln(1000+unit_sales))
>   at 
> org.apache.lucene.expressions.ExpressionFunctionValues.doubleValue(ExpressionFunctionValues.java:49)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collectInternal(OrderedVELeafCollector.java:123)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collect(OrderedVELeafCollector.java:108)
>   at 
> org.apache.lucene.search.MultiCollectorManager$Collectors$LeafCollectors.collect(MultiCollectorManager.java:102)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:241)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:184)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:658)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:600)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:597)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I couldn't see any {{synchronized}} in the sources here, so I'm not sure 
> which object monitor it's blocked on.
> I was accidentally compiling a new expression for every query, and that 
> bottleneck would cause overall QPS to slow down drastically (~4X slower after 
> ~1 hour of redline tests), as if the JVM is getting slower and slower to 
> evaluate each expression the more expressions I had compiled.
> I tested JDK 9-ea and it also kept slowing down over time as the performance 
> test ran.
> Maybe we should put a small cache in front of the expressions compiler to 
> make it less trappy?  Or maybe we can get to the root cause of why the JVM 
> slows down more and more, the more expressions you compile?
> I won't have time to work on this in the near future so if anyone else feels 
> the itch, please scratch it!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7882) Maybe expression compiler should cache recently compiled expressions?

[Dawid Weiss (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053984#comment-16053984
 ] 

Dawid Weiss commented on LUCENE-7882:
-

It probably does because they're loaded into their own class loaders?

> Maybe expression compiler should cache recently compiled expressions?
> -
>
> Key: LUCENE-7882
> URL: https://issues.apache.org/jira/browse/LUCENE-7882
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/expressions
>Reporter: Michael McCandless
>
> I've been running search performance tests using a simple expression 
> ({{_score + ln(1000+unit_sales)}}) for sorting and hit this odd bottleneck:
> {noformat}
> "pool-1-thread-30" #70 prio=5 os_prio=0 tid=0x7eea7000a000 nid=0x1ea8a 
> waiting for monitor entry [0x7eea867dd000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.apache.lucene.expressions.js.JavascriptCompiler$CompiledExpression.evaluate(_score
>  + ln(1000+unit_sales))
>   at 
> org.apache.lucene.expressions.ExpressionFunctionValues.doubleValue(ExpressionFunctionValues.java:49)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collectInternal(OrderedVELeafCollector.java:123)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collect(OrderedVELeafCollector.java:108)
>   at 
> org.apache.lucene.search.MultiCollectorManager$Collectors$LeafCollectors.collect(MultiCollectorManager.java:102)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:241)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:184)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:658)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:600)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:597)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I couldn't see any {{synchronized}} in the sources here, so I'm not sure 
> which object monitor it's blocked on.
> I was accidentally compiling a new expression for every query, and that 
> bottleneck would cause overall QPS to slow down drastically (~4X slower after 
> ~1 hour of redline tests), as if the JVM is getting slower and slower to 
> evaluate each expression the more expressions I had compiled.
> I tested JDK 9-ea and it also kept slowing down over time as the performance 
> test ran.
> Maybe we should put a small cache in front of the expressions compiler to 
> make it less trappy?  Or maybe we can get to the root cause of why the JVM 
> slows down more and more, the more expressions you compile?
> I won't have time to work on this in the near future so if anyone else feels 
> the itch, please scratch it!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10856) ExtendedDismaxQParser (edismax) override OR when mm=100%

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-10856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sébastien LECACHEUR updated SOLR-10856:
---
Description: 
Since Solr 5.5.1, edismax parser override OR (with AND behavior) in queries 
when mm=100%. This behavior is new from Solr 5.5.1 to 6.6.0.

Concerned query :

{code:none}
curl -s 
'http://localhost:8983/solr/mycorename/select?q=type_s%3A(A+OR+C)&wt=json&defType=edismax&mm=100%25&indent=true&debugQuery=true'

{code}

1) Solr 5.4.1 :

{code:javascript}
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+(type_s:A type_s:C))/no_coord",
"parsedquery_toString":"+(type_s:A type_s:C)",
"explain":{...},
"QParser":"ExtendedDismaxQParser",
{code}


Returns docs as expected.

2) Solr 5.5.1 :

{code:javascript}
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+((type_s:A type_s:C)~2))/no_coord",
"parsedquery_toString":"+((type_s:A type_s:C)~2)",
"explain":{},
"QParser":"ExtendedDismaxQParser",
{code}


Returns no results

3) Solr 6.6.0 :

{code:javascript}
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+(type_s:A type_s:C)~2)/no_coord",
"parsedquery_toString":"+((type_s:A type_s:C)~2)",
"explain":{},
"QParser":"ExtendedDismaxQParser",
{code}

Returns no results

This bug looks like SOLR-8812 issue.

  was:
Since Solr 5.5.1, edismax parser override OR (with AND behavior) in queries 
when mm=100%. This behavior is new from Solr 5.5.1 to 6.6.0.

Concerned query :

{code:shell}
curl -s 
'http://localhost:8983/solr/mycorename/select?q=type_s%3A(A+OR+C)&wt=json&defType=edismax&mm=100%25&indent=true&debugQuery=true'

{code}

1) Solr 5.4.1 :

{code:javascript}
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+(type_s:A type_s:C))/no_coord",
"parsedquery_toString":"+(type_s:A type_s:C)",
"explain":{...},
"QParser":"ExtendedDismaxQParser",
{code}


Returns docs as expected.

2) Solr 5.5.1 :

{code:javascript}
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+((type_s:A type_s:C)~2))/no_coord",
"parsedquery_toString":"+((type_s:A type_s:C)~2)",
"explain":{},
"QParser":"ExtendedDismaxQParser",
{code}


Returns no results

3) Solr 6.6.0 :

{code:javascript}
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+(type_s:A type_s:C)~2)/no_coord",
"parsedquery_toString":"+((type_s:A type_s:C)~2)",
"explain":{},
"QParser":"ExtendedDismaxQParser",
{code}

Returns no results

This bug looks like SOLR-8812 issue.


> ExtendedDismaxQParser (edismax) override OR when mm=100%
> 
>
> Key: SOLR-10856
> URL: https://issues.apache.org/jira/browse/SOLR-10856
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 5.5, 6.0, 6.6
>Reporter: Sébastien LECACHEUR
>
> Since Solr 5.5.1, edismax parser override OR (with AND behavior) in queries 
> when mm=100%. This behavior is new from Solr 5.5.1 to 6.6.0.
> Concerned query :
> {code:none}
> curl -s 
> 'http://localhost:8983/solr/mycorename/select?q=type_s%3A(A+OR+C)&wt=json&defType=edismax&mm=100%25&indent=true&debugQuery=true'
> {code}
> 1) Solr 5.4.1 :
> {code:javascript}
> "rawquerystring":"type_s:(A OR C)",
> "querystring":"type_s:(A OR C)",
> "parsedquery":"(+(type_s:A type_s:C))/no_coord",
> "parsedquery_toString":"+(type_s:A type_s:C)",
> "explain":{...},
> "QParser":"ExtendedDismaxQParser",
> {code}
> Returns docs as expected.
> 2) Solr 5.5.1 :
> {code:javascript}
> "rawquerystring":"type_s:(A OR C)",
> "querystring":"type_s:(A OR C)",
> "parsedquery":"(+((type_s:A type_s:C)~2))/no_coord",
> "parsedquery_toString":"+((type_s:A type_s:C)~2)",
> "explain":{},
> "QParser":"ExtendedDismaxQParser",
> {code}
> Returns no results
> 3) Solr 6.6.0 :
> {code:javascript}
> "rawquerystring":"type_s:(A OR C)",
> "querystring":"type_s:(A OR C)",
> "parsedquery":"(+(type_s:A type_s:C)~2)/no_coord",
> "parsedquery_toString":"+((type_s:A type_s:C)~2)",
> "explain":{},
> "QParser":"ExtendedDismaxQParser",
> {code}
> Returns no results
> This bug looks like SOLR-8812 issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10856) ExtendedDismaxQParser (edismax) override OR when mm=100%

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-10856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sébastien LECACHEUR updated SOLR-10856:
---
Description: 
Since Solr 5.5.1, edismax parser override OR (with AND behavior) in queries 
when mm=100%. This behavior is new from Solr 5.5.1 to 6.6.0.

Concerned query :

{code:shell}
curl -s 
'http://localhost:8983/solr/mycorename/select?q=type_s%3A(A+OR+C)&wt=json&defType=edismax&mm=100%25&indent=true&debugQuery=true'

{code}

1) Solr 5.4.1 :

{code:javascript}
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+(type_s:A type_s:C))/no_coord",
"parsedquery_toString":"+(type_s:A type_s:C)",
"explain":{...},
"QParser":"ExtendedDismaxQParser",
{code}


Returns docs as expected.

2) Solr 5.5.1 :

{code:javascript}
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+((type_s:A type_s:C)~2))/no_coord",
"parsedquery_toString":"+((type_s:A type_s:C)~2)",
"explain":{},
"QParser":"ExtendedDismaxQParser",
{code}


Returns no results

3) Solr 6.6.0 :

{code:javascript}
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+(type_s:A type_s:C)~2)/no_coord",
"parsedquery_toString":"+((type_s:A type_s:C)~2)",
"explain":{},
"QParser":"ExtendedDismaxQParser",
{code}

Returns no results

This bug looks like SOLR-8812 issue.

  was:
Since Solr 5.5.1, edismax parser override OR (with AND behavior) in queries 
when mm=100%. This behavior is new from Solr 5.5.1 to 6.6.0.

Concerned query :
curl -s 
'http://localhost:8983/solr/mycorename/select?q=type_s%3A(A+OR+C)&wt=json&defType=edismax&mm=100%25&indent=true&debugQuery=true'

1) Solr 5.4.1 :
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+(type_s:A type_s:C))/no_coord",
"parsedquery_toString":"+(type_s:A type_s:C)",
"explain":{...},
"QParser":"ExtendedDismaxQParser",

Returns docs as expected.

2) Solr 5.5.1 :
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+((type_s:A type_s:C)~2))/no_coord",
"parsedquery_toString":"+((type_s:A type_s:C)~2)",
"explain":{},
"QParser":"ExtendedDismaxQParser",

Returns no results

3) Solr 6.6.0 :
"rawquerystring":"type_s:(A OR C)",
"querystring":"type_s:(A OR C)",
"parsedquery":"(+(type_s:A type_s:C)~2)/no_coord",
"parsedquery_toString":"+((type_s:A type_s:C)~2)",
"explain":{},
"QParser":"ExtendedDismaxQParser",
Returns no results

This bug looks like SOLR-8812 issue.


> ExtendedDismaxQParser (edismax) override OR when mm=100%
> 
>
> Key: SOLR-10856
> URL: https://issues.apache.org/jira/browse/SOLR-10856
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 5.5, 6.0, 6.6
>Reporter: Sébastien LECACHEUR
>
> Since Solr 5.5.1, edismax parser override OR (with AND behavior) in queries 
> when mm=100%. This behavior is new from Solr 5.5.1 to 6.6.0.
> Concerned query :
> {code:shell}
> curl -s 
> 'http://localhost:8983/solr/mycorename/select?q=type_s%3A(A+OR+C)&wt=json&defType=edismax&mm=100%25&indent=true&debugQuery=true'
> {code}
> 1) Solr 5.4.1 :
> {code:javascript}
> "rawquerystring":"type_s:(A OR C)",
> "querystring":"type_s:(A OR C)",
> "parsedquery":"(+(type_s:A type_s:C))/no_coord",
> "parsedquery_toString":"+(type_s:A type_s:C)",
> "explain":{...},
> "QParser":"ExtendedDismaxQParser",
> {code}
> Returns docs as expected.
> 2) Solr 5.5.1 :
> {code:javascript}
> "rawquerystring":"type_s:(A OR C)",
> "querystring":"type_s:(A OR C)",
> "parsedquery":"(+((type_s:A type_s:C)~2))/no_coord",
> "parsedquery_toString":"+((type_s:A type_s:C)~2)",
> "explain":{},
> "QParser":"ExtendedDismaxQParser",
> {code}
> Returns no results
> 3) Solr 6.6.0 :
> {code:javascript}
> "rawquerystring":"type_s:(A OR C)",
> "querystring":"type_s:(A OR C)",
> "parsedquery":"(+(type_s:A type_s:C)~2)/no_coord",
> "parsedquery_toString":"+((type_s:A type_s:C)~2)",
> "explain":{},
> "QParser":"ExtendedDismaxQParser",
> {code}
> Returns no results
> This bug looks like SOLR-8812 issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10882) Restructure and Cleanup Stream Evaluators

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053969#comment-16053969
 ] 

ASF subversion and git services commented on SOLR-10882:


Commit 3ff8c870243c576f73650309715f6cbd3bc8c869 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3ff8c87 ]

SOLR-10882: Comment out broken test case


> Restructure and Cleanup Stream Evaluators
> -
>
> Key: SOLR-10882
> URL: https://issues.apache.org/jira/browse/SOLR-10882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Dennis Gove
> Attachments: SOLR-10882.patch
>
>
> There are a suite of new Stream Evaluators that I'd like to cleanup and 
> restructure prior to the cutting of v7. This ticket is to track that progress.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: VOTE: Apache Solr Reference Guide for 6.6 (RC1)

[Cassandra Targett]

Thanks everyone - this vote passed.

Sorry for the delay, I was traveling all week last week and since
there are a few things I wanted to clean up at the same time as this
release, I didn't want to leave it half-done. I'll start on those
today.

On Tue, Jun 13, 2017 at 11:15 AM, Steve Rowe  wrote:
> +1
>
> I filed an issue for invisible arrow characters in the PDF: 
> .  I don’t think a respin 
> is required.  I plan on looking into whether we can automatically flag this 
> problem in the future via precommit check(s).
>
> Another no-respin-indicated change I committed: some `monospace` syntax 
> cleanup. There were some conflicts with `something`’s , where Asciidoc 
> renders the "`’" as a curly apostrophe, and the monospace region extends 
> beyond where it should to the next encountered backtick on the line.  Also 
> usages of /“`/ and /‘`/ were not rendering as expected (non-monospace quotes 
> around monospaced text), since Asciidoc interprets those as curly quotes; as 
> a result, monospace wasn’t applied.  (I committed this change to branch_6_6 
> in case there is a respin.)
>
> --
> Steve
> www.lucidworks.com
>
>> On Jun 9, 2017, at 3:51 PM, Cassandra Targett  wrote:
>>
>> Please vote for the release of the Apache Solr Reference Guide for 6.6.
>>
>> The artifacts can be downloaded from
>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.6-RC1/
>>
>> $ cat apache-solr-ref-guide-6.6.pdf.sha1
>> 1463d3297f9c5eeef6651bd6989f4c5a8ece5a3e  apache-solr-ref-guide-6.6.pdf
>>
>> The HTML files have also been updated: 
>> https://lucene.apache.org/solr/guide/6_6/
>>
>> Steve Rowe gave me several comments to improve the PDF, so there are
>> several things different about this RC (besides several typos and
>> formatting issues he also found):
>>
>> * replaced small sun logo on title page with full Solr logo
>> * added some additional metadata to the title page for authorship and
>> publication date
>> * cut back # of items listed in Table of Contents, saving about 10 or so 
>> pages
>> * increased monospace font size so it's more the same size as "normal" text
>>
>> Here's my +1.
>>
>> Cassandra
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-7882) Maybe expression compiler should cache recently compiled expressions?

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7882:
--

 Summary: Maybe expression compiler should cache recently compiled 
expressions?
 Key: LUCENE-7882
 URL: https://issues.apache.org/jira/browse/LUCENE-7882
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/expressions
Reporter: Michael McCandless


I've been running search performance tests using a simple expression ({{_score 
+ ln(1000+unit_sales)}}) for sorting and hit this odd bottleneck:

{noformat}
"pool-1-thread-30" #70 prio=5 os_prio=0 tid=0x7eea7000a000 nid=0x1ea8a 
waiting for monitor entry [0x7eea867dd000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at 
org.apache.lucene.expressions.js.JavascriptCompiler$CompiledExpression.evaluate(_score
 + ln(1000+unit_sales))
at 
org.apache.lucene.expressions.ExpressionFunctionValues.doubleValue(ExpressionFunctionValues.java:49)
at 
com.amazon.lucene.OrderedVELeafCollector.collectInternal(OrderedVELeafCollector.java:123)
at 
com.amazon.lucene.OrderedVELeafCollector.collect(OrderedVELeafCollector.java:108)
at 
org.apache.lucene.search.MultiCollectorManager$Collectors$LeafCollectors.collect(MultiCollectorManager.java:102)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:241)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:184)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:658)
at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:600)
at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:597)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}

I couldn't see any {{synchronized}} in the sources here, so I'm not sure which 
object monitor it's blocked on.

I was accidentally compiling a new expression for every query, and that 
bottleneck would cause overall QPS to slow down drastically (~4X slower after 
~1 hour of redline tests), as if the JVM is getting slower and slower to 
evaluate each expression the more expressions I had compiled.

I tested JDK 9-ea and it also kept slowing down over time as the performance 
test ran.

Maybe we should put a small cache in front of the expressions compiler to make 
it less trappy?  Or maybe we can get to the root cause of why the JVM slows 
down more and more, the more expressions you compile?

I won't have time to work on this in the near future so if anyone else feels 
the itch, please scratch it!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10882) Restructure and Cleanup Stream Evaluators

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053955#comment-16053955
 ] 

Joel Bernstein commented on SOLR-10882:
---

Looks like we've got a failing test now on jenkins:

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1381/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testArraySort

Error Message:
--> http://127.0.0.1:58938/solr/collection1:Invalid stream expression 
arraySort(array(11.5,12.3,4,3,1,0)) - function 'arraySort' is unknown (not 
mapped to a valid TupleStream)

Stack Trace:
java.io.IOException: --> http://127.0.0.1:58938/solr/collection1:Invalid stream 
expression arraySort(array(11.5,12.3,4,3,1,0)) - function 'arraySort' is 
unknown (not mapped to a valid TupleStream)
at 
__randomizedtesting.SeedInfo.seed([9148EF6FDEB90373:A7FE39425960FF0A]:0)
at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:219)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.getTuples(StreamExpressionTest.java:7487)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testArraySort(StreamExpressionTest.java:5840)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)

> Restructure and Cleanup Stream Evaluators
> -
>
> Key: SOLR-10882
> URL: https://issues.apache.org/jira/browse/SOLR-10882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Dennis Gove
> Attachments: SOLR-10882.patch
>
>
> There are a suite of new Stream Evaluators that I'd like to cleanup and 
> restructure prior to the cutting of v7. This ticket is to track that progress.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7868) Use multiple threads to apply deletes and DV updates

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053944#comment-16053944
 ] 

Michael McCandless commented on LUCENE-7868:


Thank you [~simonw], I'll look!

> Use multiple threads to apply deletes and DV updates
> 
>
> Key: LUCENE-7868
> URL: https://issues.apache.org/jira/browse/LUCENE-7868
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, 
> LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch
>
>
> Today, when users delete documents or apply doc values updates, IndexWriter 
> buffers them up into frozen packets and then eventually uses a single thread 
> (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms 
> to docids.  This thread also holds IW's monitor lock, so it also blocks 
> refresh, merges starting/finishing, commits, etc.
> We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, 
> LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it 
> can't use multiple CPU cores commonly available now.
> This doesn't affect append-only usage, but for update-heavy users (me!) this 
> can be a big bottleneck, and causes long stop-the-world hangs during indexing.
> I have an initial exploratory patch to make these lookups concurrent, without 
> holding IW's lock, so that when a new packet of deletes is pushed, which 
> happens when we flush a new segment, we immediately use that same indexing 
> thread to and resolve the deletions.
> This is analogous to when we made segment flushing concurrent (LUCENE-3023), 
> just for deletes and DV updates as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_131) - Build # 19907 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19907/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testArraySort

Error Message:
--> https://127.0.0.1:43665/solr/collection1:Invalid stream expression 
arraySort(array(11.5,12.3,4,3,1,0)) - function 'arraySort' is unknown (not 
mapped to a valid TupleStream)

Stack Trace:
java.io.IOException: --> https://127.0.0.1:43665/solr/collection1:Invalid 
stream expression arraySort(array(11.5,12.3,4,3,1,0)) - function 'arraySort' is 
unknown (not mapped to a valid TupleStream)
at 
__randomizedtesting.SeedInfo.seed([F2D6CCEA47D3CAF9:C4601AC7C00A3680]:0)
at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:219)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.getTuples(StreamExpressionTest.java:7487)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testArraySort(StreamExpressionTest.java:5840)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.rand