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

[Policeman Jenkins Server]

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

3 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([A321E23AFA287531:C9C06C51C7B2C349]: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.TestLocalFSCloudBackupRestore.test

Error Message:
Collection not found: backuprestore

Stack Trace:

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+168) - Build # 3497 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 13284 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/temp/junit4-J1-20170512_040309_2541744926669638523809.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/heapdumps/java_pid25835.hprof ...
   [junit4] Heap dump file created [121961991 bytes in 0.662 secs]
   [junit4] <<< JVM J1: EOF 

[...truncated 7480 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:727: Some of the tests 
produced a heap dump, but did not fail. Maybe a suppressed OutOfMemoryError? 
Dumps created:
* java_pid25835.hprof

Total time: 61 minutes 18 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Updated] (SOLR-10405) v2 API introspect response contains multiple copies of the experimental format WARNING

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-10405:

Attachment: SOLR-10405.patch

A patch for this ticket.

> v2 API introspect response contains multiple copies of the experimental 
> format WARNING
> --
>
> Key: SOLR-10405
> URL: https://issues.apache.org/jira/browse/SOLR-10405
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Affects Versions: 6.5
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-10405.patch
>
>
> E.g. after {{bin/solr start -e cloud -noprompt}} and {{curl 
> "http://localhost:8983/solr/admin/collections?action=CREATE=.system=2"}}:
> {{curl "http://localhost:8983/v2/c/.system/blob/_introspect?indent=on"}} 
> returns:
> {noformat}
> {
>   "spec":[ [...] ],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "availableSubPaths":{ [...] }
> }
> {noformat}
> and {{curl "http://localhost:8983/v2/c/_introspect?indent=on}} returns:
> {noformat}
> {
>   "responseHeader":{ "status":0, "QTime":2 },
>   "spec":[ [...] ],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "availableSubPaths":{ [...] }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (SOLR-10408) v2 API introspect should return useful message for non-existent command

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat closed SOLR-10408.
---
   Resolution: Fixed
Fix Version/s: master (7.0)

> v2 API introspect should return useful message for non-existent command
> ---
>
> Key: SOLR-10408
> URL: https://issues.apache.org/jira/browse/SOLR-10408
> 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-10408.patch
>
>
> Instead of failing, v2 API introspect requests that filter for a non-existent 
> command succeed and show {{null}} for the command spec.
> E.g., after {{bin/solr start -e cloud -noprompt}}, {{curl 
> "http://localhost:8983/v2/c/gettingstarted/_introspect?method=POST=X=on"}}
>  returns:
> {noformat}
> {
>   "spec":[{
>   
> "documentation":"https://cwiki.apache.org/confluence/display/solr/Collections+API;,
>   "description":"Several collection-level operations are supported with 
> this endpoint: modify collection attributes; reload a collection; migrate 
> documents to a different collection; rebalance collection leaders; balance 
> properties across shards; and add or delete a replica property.",
>   "methods":["POST"],
>   "url":{"paths":["/collections/{collection}",
>   "/c/{collection}"]},
>   "commands":{"X":null}}],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "availableSubPaths":{ [...] }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 4003 - Unstable!

[Policeman Jenkins Server]

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

6 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter

Error Message:
Collection not found: routeFieldColl

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: routeFieldColl
at 
__randomizedtesting.SeedInfo.seed([54D2A85F34CF9491:FCE43682ABAE7FCB]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1416)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1099)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1074)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter(CustomCollectionTest.java:166)
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)

[jira] [Commented] (SOLR-10408) v2 API introspect should return useful message for non-existent command

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10408:


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

SOLR-10408: v2 API introspect should return useful message for non-existent 
command


> v2 API introspect should return useful message for non-existent command
> ---
>
> Key: SOLR-10408
> URL: https://issues.apache.org/jira/browse/SOLR-10408
> 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
> Attachments: SOLR-10408.patch
>
>
> Instead of failing, v2 API introspect requests that filter for a non-existent 
> command succeed and show {{null}} for the command spec.
> E.g., after {{bin/solr start -e cloud -noprompt}}, {{curl 
> "http://localhost:8983/v2/c/gettingstarted/_introspect?method=POST=X=on"}}
>  returns:
> {noformat}
> {
>   "spec":[{
>   
> "documentation":"https://cwiki.apache.org/confluence/display/solr/Collections+API;,
>   "description":"Several collection-level operations are supported with 
> this endpoint: modify collection attributes; reload a collection; migrate 
> documents to a different collection; rebalance collection leaders; balance 
> properties across shards; and add or delete a replica property.",
>   "methods":["POST"],
>   "url":{"paths":["/collections/{collection}",
>   "/c/{collection}"]},
>   "commands":{"X":null}}],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "availableSubPaths":{ [...] }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10675:

Attachment: draft-background.png
SOLR-10675.patch


Here's patch makes a few changes to the way the ref guide is built...

* build.xml now allows differantiation from the *solr* version the guide covers 
(ex: 6.6) and the *guide* version (ex: 6.6, 6.6.1)
** This will typically be the same - but now if we want to do a "bug fix 
release" of the guide itself, we can -- and if we do so, the bug fix number for 
the doc doesn't need to be tied to any particular code bug fix that has/has not 
yet happened on the same branch_X_Y
* both the PDF & HTML versions will now note their "Guide Version"
** HTML in {{}} and page footer
** PDF in the page footer
* by default, anyone building the PDF or html site wil now get "DRAFT" copies 
of these files
** the guide version# will default to ending in {{-DRAFT}}
** the the HTML guide will include a DRAFT watermark and special note in the 
sidebar w/link to official versions
** the PDF filename will include the {{-DRAFT}} suffix
* To build a "release" of the docs, just specify `-Dsolr-guide-version=X.Y` on 
the command line.
** `ant build-site build-pdf -Dsolr-guide-version=X.Y`
* I also updated the {{meta-docs}} where approrpiate to reflect these changes

(watermark file {{draft-background.png}} attached independently - assume it's 
in {{solr/solr-ref-guide/src/}}

[~ctargett]: what do you think?



> differentiate DRAFT builds of the html/pdf ref-guides vs the official releases
> --
>
> Key: SOLR-10675
> URL: https://issues.apache.org/jira/browse/SOLR-10675
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
> Attachments: draft-background.png, SOLR-10675.patch
>
>
> We should tweak the build system for the new ref guide so that it's obvious 
> from the artifacts when they are unofficial "DRAFT" copies (default) vs 
> official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10675) differentiate DRAFT builds of the html/pdf ref-guides vs the official releases

[Hoss Man (JIRA)]

Hoss Man created SOLR-10675:
---

 Summary: differentiate DRAFT builds of the html/pdf ref-guides vs 
the official releases
 Key: SOLR-10675
 URL: https://issues.apache.org/jira/browse/SOLR-10675
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


We should tweak the build system for the new ref guide so that it's obvious 
from the artifacts when they are unofficial "DRAFT" copies (default) vs 
official releases



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_131) - Build # 889 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/889/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testRecreateTaxonomy

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\replicator\test\J1\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_4191C6DAA3B51432-001\replicationClientTest-003\1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\replicator\test\J1\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_4191C6DAA3B51432-001\replicationClientTest-003\1
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\replicator\test\J1\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_4191C6DAA3B51432-001\replicationClientTest-003\1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\replicator\test\J1\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_4191C6DAA3B51432-001\replicationClientTest-003\1

at 
__randomizedtesting.SeedInfo.seed([4191C6DAA3B51432:7D622EBBC874C233]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.replicator.PerSessionDirectoryFactory.cleanupSession(PerSessionDirectoryFactory.java:58)
at 
org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.java:259)
at 
org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.java:401)
at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testRecreateTaxonomy(IndexAndTaxonomyReplicationClientTest.java:278)
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.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 
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] [Comment Edited] (SOLR-10408) v2 API introspect should return useful message for non-existent command

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat edited comment on SOLR-10408 at 5/12/17 1:10 AM:
--

Trivial patch for this ticket. Non exist command will return 
{code}
{
  "spec":[{
  
"documentation":"https://cwiki.apache.org/confluence/display/solr/Collections+API;,
  "description":"Several collection-level operations are supported with 
this endpoint: modify collection attributes; reload a collection; migrate 
documents to a different collection; rebalance collection leaders; balance 
properties across shards; and add or delete a replica property.",
  "methods":["POST"],
  "url":{"paths":["/collections/{collection}",
  "/c/{collection}"]},
  "commands":{"X":"Command not found!"}}],
  "WARNING":"This response format is experimental.  It is likely to change in 
the future.",
  "availableSubPaths":{ [...] }
}
{code}


was (Author: caomanhdat):
Trivial patch for this ticket. 

> v2 API introspect should return useful message for non-existent command
> ---
>
> Key: SOLR-10408
> URL: https://issues.apache.org/jira/browse/SOLR-10408
> 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
> Attachments: SOLR-10408.patch
>
>
> Instead of failing, v2 API introspect requests that filter for a non-existent 
> command succeed and show {{null}} for the command spec.
> E.g., after {{bin/solr start -e cloud -noprompt}}, {{curl 
> "http://localhost:8983/v2/c/gettingstarted/_introspect?method=POST=X=on"}}
>  returns:
> {noformat}
> {
>   "spec":[{
>   
> "documentation":"https://cwiki.apache.org/confluence/display/solr/Collections+API;,
>   "description":"Several collection-level operations are supported with 
> this endpoint: modify collection attributes; reload a collection; migrate 
> documents to a different collection; rebalance collection leaders; balance 
> properties across shards; and add or delete a replica property.",
>   "methods":["POST"],
>   "url":{"paths":["/collections/{collection}",
>   "/c/{collection}"]},
>   "commands":{"X":null}}],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "availableSubPaths":{ [...] }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10408) v2 API introspect should return useful message for non-existent command

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-10408:

Summary: v2 API introspect should return useful message for non-existent 
command  (was: v2 API introspect should fail when filtering for a non-existent 
command)

> v2 API introspect should return useful message for non-existent command
> ---
>
> Key: SOLR-10408
> URL: https://issues.apache.org/jira/browse/SOLR-10408
> 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
> Attachments: SOLR-10408.patch
>
>
> Instead of failing, v2 API introspect requests that filter for a non-existent 
> command succeed and show {{null}} for the command spec.
> E.g., after {{bin/solr start -e cloud -noprompt}}, {{curl 
> "http://localhost:8983/v2/c/gettingstarted/_introspect?method=POST=X=on"}}
>  returns:
> {noformat}
> {
>   "spec":[{
>   
> "documentation":"https://cwiki.apache.org/confluence/display/solr/Collections+API;,
>   "description":"Several collection-level operations are supported with 
> this endpoint: modify collection attributes; reload a collection; migrate 
> documents to a different collection; rebalance collection leaders; balance 
> properties across shards; and add or delete a replica property.",
>   "methods":["POST"],
>   "url":{"paths":["/collections/{collection}",
>   "/c/{collection}"]},
>   "commands":{"X":null}}],
>   "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>   "availableSubPaths":{ [...] }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7821) Classic, flexible, and Solr's standard/"lucene" query parsers: range queries should require " TO ", and accept TO as range endpoints

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-7821:
--

Right you are... I previously searched visually and then for ".jj", but I must 
have had a typo.

> Classic, flexible, and Solr's standard/"lucene" query parsers: range queries 
> should require " TO ", and accept TO as range endpoints
> 
>
> Key: LUCENE-7821
> URL: https://issues.apache.org/jira/browse/LUCENE-7821
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Attachments: LUCENE-7821.patch, LUCENE-7821.patch
>
>
> A post on the solr-user mailing list drew my attention to the fact that this 
> is apparently a valid range query under the QueryParser.jj grammer (both for 
> the classic parser and the solr variant -- i didn't check flexible)...
> {noformat}
> [x z]   // parsed the same as [x TO z]
> {noformat}
> it's parsed as a valid range query even though there is no {{ TO }} -- even 
> though there is nothing in the docs to suggest that the {{ TO }} is intended 
> to be optional.
> Furthermore, in my experimenting i realized that how the grammer looks for 
> the {{ TO }} keyword seems to be a bit sloppy, making some range queries that 
> should be easy to validate (because they are unambiguous) fail to parse...
> {noformat}
> [TO TO z] // fails
> [a TO TO] // fails
> [a TO "TO"]   // works, but why should quoting be neccessary here?
> {noformat}
> 
> If the "sloppy" parsing behavior is intentional, then the docs should reflect 
> that the {{ TO }} is optional -- but it seems like in general we should make 
> these other unambiguous cases parse cleanly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8440:


bq. Problem with SOLR_PID_DIR and SOLR_TIP/bin is that it does not support an 
install with multiple instances run from same binaries.

Isn't it the case that all of those instances will be part of the same 
SolrCloud cluster, and hence they *should* have the same basicAuth.conf? 
However, when this feature is extended to cover standalone mode, then we could 
suffix the file with a port (or somehow figure out how to use a SOLR_HOME).

bq. Guess we have to move the SOLR_HOME resolution lines higher up in the script
Trying to use SOLR_HOME by "moving" the logic up the logic would break the 
resolution of the SOLR_HOME in the case of a "start" command. I am trying to do 
it both higher up as well as where it is currently done, but that also is 
breaking the "start" command. Also, the whole $SOLR_SERVER_DIR block also needs 
to be copied/moved higher up, since $SOLR_HOME depends on that. Here's that 
block:
{code}
if [[ "$2" == "." || "$2" == "./" || "$2" == ".." || "$2" == "../" 
]]; then
  SOLR_SERVER_DIR="$(pwd)/$2"
else
  # see if the arg value is relative to the tip vs full path
  if [[ "$2" != /* ]] && [[ -d "$SOLR_TIP/$2" ]]; then
SOLR_SERVER_DIR="$SOLR_TIP/$2"
  else
SOLR_SERVER_DIR="$2"
  fi
fi
{code}

Needless to say, trying to use SOLR_HOME is proving quite tricky. I am still 
trying, though..

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440-follow-up.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 19612 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=15793, name=jetty-launcher-2640-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=15787, name=jetty-launcher-2640-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=15793, name=jetty-launcher-2640-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Commented] (LUCENE-7821) Classic, flexible, and Solr's standard/"lucene" query parsers: range queries should require " TO ", and accept TO as range endpoints

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7821:


bq. I don't see any changes to the grammar files in the patch?

Hoss'ss patch is test-only.  Mine includes grammar file changes.

> Classic, flexible, and Solr's standard/"lucene" query parsers: range queries 
> should require " TO ", and accept TO as range endpoints
> 
>
> Key: LUCENE-7821
> URL: https://issues.apache.org/jira/browse/LUCENE-7821
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Attachments: LUCENE-7821.patch, LUCENE-7821.patch
>
>
> A post on the solr-user mailing list drew my attention to the fact that this 
> is apparently a valid range query under the QueryParser.jj grammer (both for 
> the classic parser and the solr variant -- i didn't check flexible)...
> {noformat}
> [x z]   // parsed the same as [x TO z]
> {noformat}
> it's parsed as a valid range query even though there is no {{ TO }} -- even 
> though there is nothing in the docs to suggest that the {{ TO }} is intended 
> to be optional.
> Furthermore, in my experimenting i realized that how the grammer looks for 
> the {{ TO }} keyword seems to be a bit sloppy, making some range queries that 
> should be easy to validate (because they are unambiguous) fail to parse...
> {noformat}
> [TO TO z] // fails
> [a TO TO] // fails
> [a TO "TO"]   // works, but why should quoting be neccessary here?
> {noformat}
> 
> If the "sloppy" parsing behavior is intentional, then the docs should reflect 
> that the {{ TO }} is optional -- but it seems like in general we should make 
> these other unambiguous cases parse cleanly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7821) Classic, flexible, and Solr's standard/"lucene" query parsers: range queries should require " TO ", and accept TO as range endpoints

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-7821:
--

nice catch! +1 to the syntax of 
{code}[ TO ]
{code}
I don't see any changes to the grammar files in the patch?

> Classic, flexible, and Solr's standard/"lucene" query parsers: range queries 
> should require " TO ", and accept TO as range endpoints
> 
>
> Key: LUCENE-7821
> URL: https://issues.apache.org/jira/browse/LUCENE-7821
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Attachments: LUCENE-7821.patch, LUCENE-7821.patch
>
>
> A post on the solr-user mailing list drew my attention to the fact that this 
> is apparently a valid range query under the QueryParser.jj grammer (both for 
> the classic parser and the solr variant -- i didn't check flexible)...
> {noformat}
> [x z]   // parsed the same as [x TO z]
> {noformat}
> it's parsed as a valid range query even though there is no {{ TO }} -- even 
> though there is nothing in the docs to suggest that the {{ TO }} is intended 
> to be optional.
> Furthermore, in my experimenting i realized that how the grammer looks for 
> the {{ TO }} keyword seems to be a bit sloppy, making some range queries that 
> should be easy to validate (because they are unambiguous) fail to parse...
> {noformat}
> [TO TO z] // fails
> [a TO TO] // fails
> [a TO "TO"]   // works, but why should quoting be neccessary here?
> {noformat}
> 
> If the "sloppy" parsing behavior is intentional, then the docs should reflect 
> that the {{ TO }} is optional -- but it seems like in general we should make 
> these other unambiguous cases parse cleanly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7821) Classic, flexible, and Solr's standard/"lucene" query parsers: range queries should require " TO ", and accept TO as range endpoints

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-7821:
---
Summary: Classic, flexible, and Solr's standard/"lucene" query parsers: 
range queries should require " TO ", and accept TO as range endpoints  (was: 
classic parser range query parsing is sloppy about "TO")

> Classic, flexible, and Solr's standard/"lucene" query parsers: range queries 
> should require " TO ", and accept TO as range endpoints
> 
>
> Key: LUCENE-7821
> URL: https://issues.apache.org/jira/browse/LUCENE-7821
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Attachments: LUCENE-7821.patch, LUCENE-7821.patch
>
>
> A post on the solr-user mailing list drew my attention to the fact that this 
> is apparently a valid range query under the QueryParser.jj grammer (both for 
> the classic parser and the solr variant -- i didn't check flexible)...
> {noformat}
> [x z]   // parsed the same as [x TO z]
> {noformat}
> it's parsed as a valid range query even though there is no {{ TO }} -- even 
> though there is nothing in the docs to suggest that the {{ TO }} is intended 
> to be optional.
> Furthermore, in my experimenting i realized that how the grammer looks for 
> the {{ TO }} keyword seems to be a bit sloppy, making some range queries that 
> should be easy to validate (because they are unambiguous) fail to parse...
> {noformat}
> [TO TO z] // fails
> [a TO TO] // fails
> [a TO "TO"]   // works, but why should quoting be neccessary here?
> {noformat}
> 
> If the "sloppy" parsing behavior is intentional, then the docs should reflect 
> that the {{ TO }} is optional -- but it seems like in general we should make 
> these other unambiguous cases parse cleanly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (LUCENE-7821) classic parser range query parsing is sloppy about "TO"

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned LUCENE-7821:
--

Assignee: Steve Rowe

> classic parser range query parsing is sloppy about "TO"
> ---
>
> Key: LUCENE-7821
> URL: https://issues.apache.org/jira/browse/LUCENE-7821
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Attachments: LUCENE-7821.patch, LUCENE-7821.patch
>
>
> A post on the solr-user mailing list drew my attention to the fact that this 
> is apparently a valid range query under the QueryParser.jj grammer (both for 
> the classic parser and the solr variant -- i didn't check flexible)...
> {noformat}
> [x z]   // parsed the same as [x TO z]
> {noformat}
> it's parsed as a valid range query even though there is no {{ TO }} -- even 
> though there is nothing in the docs to suggest that the {{ TO }} is intended 
> to be optional.
> Furthermore, in my experimenting i realized that how the grammer looks for 
> the {{ TO }} keyword seems to be a bit sloppy, making some range queries that 
> should be easy to validate (because they are unambiguous) fail to parse...
> {noformat}
> [TO TO z] // fails
> [a TO TO] // fails
> [a TO "TO"]   // works, but why should quoting be neccessary here?
> {noformat}
> 
> If the "sloppy" parsing behavior is intentional, then the docs should reflect 
> that the {{ TO }} is optional -- but it seems like in general we should make 
> these other unambiguous cases parse cleanly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7821) classic parser range query parsing is sloppy about "TO"

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-7821:
---
Attachment: LUCENE-7821.patch

Patch with beefed up tests and fixes for classic query parser, flexible query 
parser, and Solr's standard/"lucene" query parser.

I think it's ready to go.

> classic parser range query parsing is sloppy about "TO"
> ---
>
> Key: LUCENE-7821
> URL: https://issues.apache.org/jira/browse/LUCENE-7821
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-7821.patch, LUCENE-7821.patch
>
>
> A post on the solr-user mailing list drew my attention to the fact that this 
> is apparently a valid range query under the QueryParser.jj grammer (both for 
> the classic parser and the solr variant -- i didn't check flexible)...
> {noformat}
> [x z]   // parsed the same as [x TO z]
> {noformat}
> it's parsed as a valid range query even though there is no {{ TO }} -- even 
> though there is nothing in the docs to suggest that the {{ TO }} is intended 
> to be optional.
> Furthermore, in my experimenting i realized that how the grammer looks for 
> the {{ TO }} keyword seems to be a bit sloppy, making some range queries that 
> should be easy to validate (because they are unambiguous) fail to parse...
> {noformat}
> [TO TO z] // fails
> [a TO TO] // fails
> [a TO "TO"]   // works, but why should quoting be neccessary here?
> {noformat}
> 
> If the "sloppy" parsing behavior is intentional, then the docs should reflect 
> that the {{ TO }} is optional -- but it seems like in general we should make 
> these other unambiguous cases parse cleanly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6560/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.lucene.mockfile.TestShuffleFS

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.mockfile.TestShuffleFS_95A04A3AF52032FB-001\tempDir-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.mockfile.TestShuffleFS_95A04A3AF52032FB-001\tempDir-001

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.mockfile.TestShuffleFS_95A04A3AF52032FB-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.mockfile.TestShuffleFS_95A04A3AF52032FB-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.mockfile.TestShuffleFS_95A04A3AF52032FB-001\tempDir-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.mockfile.TestShuffleFS_95A04A3AF52032FB-001\tempDir-001
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.mockfile.TestShuffleFS_95A04A3AF52032FB-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.mockfile.TestShuffleFS_95A04A3AF52032FB-001

at __randomizedtesting.SeedInfo.seed([95A04A3AF52032FB]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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.HttpPartitionTest.test

Error Message:
The partitioned replica did not get marked down expected:<[down]> but 
was:<[active]>

Stack Trace:
org.junit.ComparisonFailure: The partitioned replica did not get marked down 
expected:<[down]> but was:<[active]>
at 
__randomizedtesting.SeedInfo.seed([235C86E5EEFF8329:AB08B93F4003EED1]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.solr.cloud.HttpPartitionTest.testMinRf(HttpPartitionTest.java:246)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:127)
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 

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[JIRA]

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

Jan Høydahl commented on SOLR-8440:
---

bq. Actually, I found it quite difficult to test the changes I've introduced to 
SolrCLI
Guess I was thinking more along the lines of simple unit tests that tests 
{{updateIncludeFileEnableAuth()}}, {{updateIncludeFileDisableAuth()}} and 
perhaps factor out more code in testable methods.

Haven't checked very hard, but it should be possible to add another tests to 
{{BasicAuthIntegrationTest}} that instead of explicitly uploading the hardcoded 
security.json, programatically instantiates {{AuthTool}} and calls enable, then 
later in the test verify that you need to authenticate. You could then test 
disable and -blockUnknown afterwards in the same test, and we'd exercise much 
of the new functionality?

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440-follow-up.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[JIRA]

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

Jan Høydahl commented on SOLR-8440:
---

Great progress!

bq. I found that using $SOLR_PID_DIR was much simpler than the $SOLR_HOME 
(which more or less point to the same location). On Windows, used $SOLR_TIP/bin.

Problem with SOLR_PID_DIR and SOLR_TIP/bin is that it does not support an 
install with multiple instances run from same binaries. Once you set password 
for the second instance, it will overwrite the {{$SOLR_TIP/bin/basicAuth.conf}} 
which was placed there by any prior auth settings for other instances. 
{{$SOLR_PID_DIR}} works for PID files, since they are unique, containing port 
name in filename.

So I would still prefer using {{$SOLR_HOME}} for the basicAuth.conf. 
Alternatively name it {{basicAuth_$PORT.conf}} and use that name in the 
{{SOLR_AUTHENTICATION_OPTS}} var; then it could go in SOLR_PID DIR without 
problems.

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440-follow-up.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Reopened] (SOLR-10644) solr.in.sh installed by install script should be writable by solr user

[JIRA]

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

Jan Høydahl reopened SOLR-10644:


Reopening...

That's why I opened SOLR-10646, to avoid putting at least basic auth pwd on the 
command line. But then it turns out that kerberos mode needs them...

I know there are other efforts under way to secure other passwords better, so 
perhaps we'll at some point get rid of pws both in solr.in and in cmdline.

An option someone proposed was to pass passwords through shell env variables 
but *not* as Java Option. That way it is not visible in ps, but Solr could 
still read the variable with {{System.getenv()}}... In that case it could make 
sense to have password in a {{o-rwx}} solr.in.sh file?

> solr.in.sh installed by install script should be writable by solr user
> --
>
> Key: SOLR-10644
> URL: https://issues.apache.org/jira/browse/SOLR-10644
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10644.patch
>
>
> Spinoff from SOLR-8440
> {{install_solr_service.sh}} installs {{solr.in.sh}} as world-readable but not 
> solr user writable:
> {noformat}
> -rw-r--r-- 1 root root 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}
> For better security, and ease for scripts to update solr.in.sh, this should 
> change to:
> {noformat}
> -rw-rw 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10670) [ref-guide] Various top-bar fixes

[JIRA]

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

Jan Høydahl updated SOLR-10670:
---
Attachment: SOLR-10670.patch

That was a smart move :)

I improved on it somewhat more by adding a conditional  too in 
head.html, which simplifies the header title of the home page even more:
{code:xml}
{% if page.title == "Home" %}
{{ site.site_title }}
{% else %}
{{ page.title }} | {{ site.site_title }}
{% endif %}
{code}

I built a guide with all these changes which can be previewed at 
http://cominvent.com/solr-refguide/. New patch attached.

But now the text above the left-hand menu is "Home", which I guess is fine if 
it was clickable, but it is not. So then perhaps it should say something else?

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-8440) Script support for enabling basic auth

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-8440 at 5/11/17 10:22 PM:
--

bq. The new sub command auth is not advertised in help
Fixed

bq. Running solr auth -enable without starting Solr throws a stack trace 
instead of printing usage.
Done, printed a message to the effect that Solr should've been started in cloud 
mode or zkHost should've been provided.

bq. If you move the getZkHost(cli) check to after the credentials check, then 
it's a bit better.
Done

bq. it should be -Dbasicauth= without uppercase "A".
Fixed

bq. Method updateIncludeFileEnableAuth takes username, password as args but 
they are never used
Fixed.

bq. Wrong code indent in SolrCLI#3629-3671
Fixed.

bq. Guess we have to move the SOLR_HOME resolution lines higher up in the script
I found that using $SOLR_PID_DIR was much simpler than the $SOLR_HOME (which 
more or less point to the same location). On Windows, used $SOLR_TIP/bin.

bq. Are you confident that this feature will have good enough quality to go in 
6.6?
This is a new feature. So long as it doesn't trip up any existing parts of 
Solr, and it works for the cases we've tested manually, I am confident to have 
it in 6.6. Any bugs, if they escape attention, can be fixed later. Not putting 
it in 6x would delay the actual adoption by users, who are more likely, in the 
short term, to upgrade to 6.6 than 7.0.

bq. I would expect it to be possible to cover most of the SolrCLI functionality 
in with unit tests. 
Actually, I found it quite difficult to test the changes I've introduced to 
SolrCLI without writing some fundamental support to test external systems here. 
For example, I would've liked to test if the correct security.json is being 
uploaded to ZK or not. But without significant effort in building such 
scaffolding in our test framework, I couldn't see a way to test for that. Did I 
miss something obvious? Can you point me to any existing tests which I can 
derive any clues from? I didn't find the tests for the Examples very useful.

For this patch, I have tested manually on Linux, and still testing on Windows.




was (Author: ichattopadhyaya):
bq. The new sub command auth is not advertised in help
Fixed

bq. Running solr auth -enable without starting Solr throws a stack trace 
instead of printing usage.
Done, brought up the usage

bq. If you move the getZkHost(cli) check to after the credentials check, then 
it's a bit better.
Done

bq. it should be -Dbasicauth= without uppercase "A".
Fixed

bq. Method updateIncludeFileEnableAuth takes username, password as args but 
they are never used
Fixed.

bq. Wrong code indent in SolrCLI#3629-3671
Fixed.

bq. Guess we have to move the SOLR_HOME resolution lines higher up in the script
I found that using $SOLR_PID_DIR was much simpler than the $SOLR_HOME (which 
more or less point to the same location). On Windows, used $SOLR_TIP/bin.

bq. Are you confident that this feature will have good enough quality to go in 
6.6?
This is a new feature. So long as it doesn't trip up any existing parts of 
Solr, and it works for the cases we've tested manually, I am confident to have 
it in 6.6. Any bugs, if they escape attention, can be fixed later. Not putting 
it in 6x would delay the actual adoption by users, who are more likely, in the 
short term, to upgrade to 6.6 than 7.0.

bq. I would expect it to be possible to cover most of the SolrCLI functionality 
in with unit tests. 
Actually, I found it quite difficult to test the changes I've introduced to 
SolrCLI without writing some fundamental support to test external systems here. 
For example, I would've liked to test if the correct security.json is being 
uploaded to ZK or not. But without significant effort in building such 
scaffolding in our test framework, I couldn't see a way to test for that. Did I 
miss something obvious? Can you point me to any existing tests which I can 
derive any clues from? I didn't find the tests for the Examples very useful.

For this patch, I have tested manually on Linux, and still testing on Windows.



> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440-follow-up.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> 

[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10568:
---

bq. I'll clone that one into a new job "Solr-reference-guide-master" and change 
the branch accordingly in the job config, then remove the original job (I seem 
to recall that renaming Jenkins jobs is problematic).

Done: https://builds.apache.org/job/Solr-reference-guide-master/ . I deleted 
the {{jira/solr-10290}} branch job.

bq. also, it seems that build isn't pulling from the repo properly...the last 
good build is from today, but the console output shows build errors that Hoss 
and I have definitely fixed, and the sha is from 27 April (49c92bf0)

I changed the git repo from 
{{https://git-wip-us.apache.org/repos/asf/lucene-solr.git}} to 
{{git://git.apache.org/lucene-solr.git}}, the latter of which is used by some 
(all?) of the other Lucene/Solr ASF Jenkins jobs.  I *think* these are usable 
interchangeably, but maybe not?

Also, in the Advanced section for the git repository, the {{Refspec}} was 
configured as {{+refs/heads/master:refs/remotes/origin/master}} (I cloned the 
original job from one of the existing ones on the {{git-websites}} label, and I 
must have forgotten to unfurl the Advanced section, so didn't notice this).  
<== I'm guessing this was the problem, but I'm not sure.

Anyway, I manually built the new job, and it succeeded after pulling the most 
recent master commit (2f6700972).

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8440:


bq. The new sub command auth is not advertised in help
Fixed

bq. Running solr auth -enable without starting Solr throws a stack trace 
instead of printing usage.
Done, brought up the usage

bq. If you move the getZkHost(cli) check to after the credentials check, then 
it's a bit better.
Done

bq. it should be -Dbasicauth= without uppercase "A".
Fixed

bq. Method updateIncludeFileEnableAuth takes username, password as args but 
they are never used
Fixed.

bq. Wrong code indent in SolrCLI#3629-3671
Fixed.

bq. Guess we have to move the SOLR_HOME resolution lines higher up in the script
I found that using $SOLR_PID_DIR was much simpler than the $SOLR_HOME (which 
more or less point to the same location). On Windows, used $SOLR_TIP/bin.

bq. Are you confident that this feature will have good enough quality to go in 
6.6?
This is a new feature. So long as it doesn't trip up any existing parts of 
Solr, and it works for the cases we've tested manually, I am confident to have 
it in 6.6. Any bugs, if they escape attention, can be fixed later. Not putting 
it in 6x would delay the actual adoption by users, who are more likely, in the 
short term, to upgrade to 6.6 than 7.0.

bq. I would expect it to be possible to cover most of the SolrCLI functionality 
in with unit tests. 
Actually, I found it quite difficult to test the changes I've introduced to 
SolrCLI without writing some fundamental support to test external systems here. 
For example, I would've liked to test if the correct security.json is being 
uploaded to ZK or not. But without significant effort in building such 
scaffolding in our test framework, I couldn't see a way to test for that. Did I 
miss something obvious? Can you point me to any existing tests which I can 
derive any clues from? I didn't find the tests for the Examples very useful.

For this patch, I have tested manually on Linux, and still testing on Windows.



> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440-follow-up.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-8440) Script support for enabling basic auth

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8440:
---
Attachment: SOLR-8440-follow-up.patch

Updated patch.

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440-follow-up.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10568:
---

bq. Steve Rowe - Now that the ref guide is on master, we should change up the 
job https://builds.apache.org/job/Solr-reference-guide-jira-SOLR-10290/ to run 
from master?

Yeah, I'll clone that one into a new job "Solr-reference-guide-master" and 
change the branch accordingly in the job config, then remove the original job 
(I seem to recall that renaming Jenkins jobs is problematic).

bq. Did we decide what to do about the branches? Do we need a job for each 
branch?

We have a job for each active branch for unit tests, and I think it makes sense 
to do the same for the ref guide.

bq. also, it seems that build isn't pulling from the repo properly...the last 
good build is from today, but the console output shows build errors that Hoss 
and I have definitely fixed, and the sha is from 27 April (49c92bf0)

I'll investigate.

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Cassandra Targett (JIRA)]

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

Cassandra Targett edited comment on SOLR-10568 at 5/11/17 9:31 PM:
---

[~steve_rowe] - Now that the ref guide is on master, we should change up the 
job https://builds.apache.org/job/Solr-reference-guide-jira-SOLR-10290/ to run 
from master?

Did we decide what to do about the branches? Do we need a job for each branch?

*edit*: also, it seems that build isn't pulling from the repo properly...the 
last good build is from today, but the console output shows build errors that 
Hoss and I have definitely fixed, and the sha is from 27 April (49c92bf0)


was (Author: ctargett):
[~steve_rowe] - Now that the ref guide is on master, we should change up the 
job https://builds.apache.org/job/Solr-reference-guide-jira-SOLR-10290/ to run 
from master?

Did we decide what to do about the branches? Do we need a job for each branch?

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10568:
--

[~steve_rowe] - Now that the ref guide is on master, we should change up the 
job https://builds.apache.org/job/Solr-reference-guide-jira-SOLR-10290/ to run 
from master?

Did we decide what to do about the branches? Do we need a job for each branch?

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8440:


bq. ... Alternatively, ...

I think fundementally there are 3 distinct points here...

# any {{bin/solr}} subcommand that wants to write to a file should always give 
a clear error message if the current effective UID doesn't have the neccessary 
permissions
# {{bin/solr}} should never assume any particular file ownership/permissions 
just based on the convention/defaults of the installer -- users might change 
them later, so the checks/warnings/msgs produced by #1 should always account 
for that possibility.
# it may make sense for any {{auth}} related subcommands to require that the 
user running the command be root -- that might be a good check to have 
independent of whether the current effective UID already has write permissions 
to whatever files it wants to modify.



> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10644) solr.in.sh installed by install script should be writable by solr user

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10644:
-

bq. This would produce ...

that seems fine by me.

personally I don't see any downside to it being world readable -- yes it may 
contain "passwords", but anyone with local access to the system who can read a 
world readable file can also read "ps" output and see any property from that 
file that might be passed to a running solr process.

> solr.in.sh installed by install script should be writable by solr user
> --
>
> Key: SOLR-10644
> URL: https://issues.apache.org/jira/browse/SOLR-10644
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10644.patch
>
>
> Spinoff from SOLR-8440
> {{install_solr_service.sh}} installs {{solr.in.sh}} as world-readable but not 
> solr user writable:
> {noformat}
> -rw-r--r-- 1 root root 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}
> For better security, and ease for scripts to update solr.in.sh, this should 
> change to:
> {noformat}
> -rw-rw 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10617) JDBCStream: support more data types

[James Dyer (JIRA)]

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

James Dyer updated SOLR-10617:
--
Attachment: SOLR-10617.patch

Another patch. Tests & precommit pass.  Javadoc for JDBCStream renders ok.  I 
plan to commit this tomorrow.

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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

[Mike Drob]

Wanted to follow up on this, since I've been steadily working away at old
JIRA issues when I have some time for them. I think read through 100s of
issues and closed about 20 as either duplicates or already committed, which
is a tiny drop in the ocean of what we have open. In an attempt to cut the
task to a more manageable size, I only looked at Solr issues.

I'd like to adjust my earlier statement that most of the attachments are
patches. Most of the really old attachments are patches, the mid-age ones
are bug reports (indices, screen captures, logs) and the recent ones being
actively worked are patches again. So, the situation isn't as bad as I
imagined it at first. For a lot of these old issues, there's not much to be
done going forward. I don't expect to have much traction asking
contributors to rebase their patches from 1.x, 3.x or even 4.x onto the
current code line, and without that many of them are just unworkable.

For current patches, I think we could really benefit from a Patch Available
JIRA state. It would be a bright big flag for committers, instead of making
contributors have to hound us periodically to look. Additionally, we could
use that to start running precommit checks on Jenkins whenever a new patch
is put up. See Apache Yetus for how this might work.

Is there interest in the community for this path? I'm personally a big fan
of enabling static analysis and always like to explore ways to improve in
that area.

Mike

On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey  wrote:

> On 4/28/2017 9:42 AM, Mike Drob wrote:
> > Thanks for this hint, Alex.
> >
> > I ran the following JQL to get some idea of our current status:
> > project in (lucene, solr) and "Attachment count" > 0 and status =
> Open
> >
> > There were 1500 results.
> >
> > 1500. I couldn't believe it. This is a huge number of patches that are
> > out there.
> >
> > I did a spot check, thinking that a lot of these might be bug reports
> > with error logs or screen shots attached, but nope. These are mostly
> > patches. I'm going to try starting with the oldest ones to see if they
> > can be rebase, have already been committed, or generally try to triage
> > them. Would appreciate any volunteers that want to help.
>
> This doesn't surprise me at all.  Many users submit patches for issues
> they encounter, but for one reason or another, no committer action ever
> happens.  There are many possible reasons.
>
> 1) The patch has bugs or some other problem that makes it unacceptable.
> 2) When the issue/patch is reviewed, one of these situations exists:
>  a) Committers don't think it's worth pursuing.
>  b) The code is behaving as designed.
>  c) The committer cannot reproduce the problem.
>  d) The committer doesn't understand the problem.
>  e) The committer doesn't think it's actually a problem.
>  f) A workaround exists that is just as effective as the patch.
> 3) Nobody has had time to review the issue/patch.
>
> In some of these situations, the reviewing committer should probably
> close the issue with an appropriate reason ... but issue triage is a
> difficult and unrewarding job.  Sometimes it just doesn't happen.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (SOLR-10451) Remove contrib/ltr/lib from lib includes in the techproducts example config

[JIRA]

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

Jan Høydahl updated SOLR-10451:
---
Description: 
As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the 
{{contrib/ltr/lib}} folder.

-So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr 
binary release (it currently contains just a boilerplate {{README.txt}} file).-

The {{}} line in 
https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml
 can also be removed.

  was:
As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the 
{{contrib/ltr/lib}} folder.

So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr 
binary release (it currently contains just a boilerplate {{README.txt}} file).

The {{}} line in 
https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml
 can also be removed.


> Remove contrib/ltr/lib from lib includes in the techproducts example config
> ---
>
> Key: SOLR-10451
> URL: https://issues.apache.org/jira/browse/SOLR-10451
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
>  Labels: newdev
> Attachments: SOLR-10451.patch
>
>
> As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the 
> {{contrib/ltr/lib}} folder.
> -So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr 
> binary release (it currently contains just a boilerplate {{README.txt}} 
> file).-
> The {{ regex=".*\.jar" />}} line in 
> https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml
>  can also be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10451) Remove contrib/ltr/lib from lib includes in the techproducts example config

[JIRA]

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

Jan Høydahl commented on SOLR-10451:


Modified the title and labeled this as {{newdev}} so some new committer could 
pick it up.
Anyone, including Christine, feel free to assign yourself and complete it...

> Remove contrib/ltr/lib from lib includes in the techproducts example config
> ---
>
> Key: SOLR-10451
> URL: https://issues.apache.org/jira/browse/SOLR-10451
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
>  Labels: newdev
> Attachments: SOLR-10451.patch
>
>
> As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the 
> {{contrib/ltr/lib}} folder.
> So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr 
> binary release (it currently contains just a boilerplate {{README.txt}} file).
> The {{ regex=".*\.jar" />}} line in 
> https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml
>  can also be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10451) Remove contrib/ltr/lib from lib includes in the techproducts example config

[JIRA]

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

Jan Høydahl updated SOLR-10451:
---
Summary: Remove contrib/ltr/lib from lib includes in the techproducts 
example config  (was: remove (almost) empty contrib/ltr folder from Solr binary 
release)

> Remove contrib/ltr/lib from lib includes in the techproducts example config
> ---
>
> Key: SOLR-10451
> URL: https://issues.apache.org/jira/browse/SOLR-10451
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
>  Labels: newdev
> Attachments: SOLR-10451.patch
>
>
> As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the 
> {{contrib/ltr/lib}} folder.
> So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr 
> binary release (it currently contains just a boilerplate {{README.txt}} file).
> The {{ regex=".*\.jar" />}} line in 
> https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml
>  can also be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10451) remove (almost) empty contrib/ltr folder from Solr binary release

[JIRA]

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

Jan Høydahl updated SOLR-10451:
---
Labels: newdev  (was: )

> remove (almost) empty contrib/ltr folder from Solr binary release
> -
>
> Key: SOLR-10451
> URL: https://issues.apache.org/jira/browse/SOLR-10451
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
>  Labels: newdev
> Attachments: SOLR-10451.patch
>
>
> As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the 
> {{contrib/ltr/lib}} folder.
> So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr 
> binary release (it currently contains just a boilerplate {{README.txt}} file).
> The {{ regex=".*\.jar" />}} line in 
> https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml
>  can also be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10644) solr.in.sh installed by install script should be writable by solr user

[JIRA]

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

Jan Høydahl commented on SOLR-10644:


Good point. Let's keep it root owned. But can we make it "solr" readable 
without also being readable to the world (given that the file may contain 
passwords)? We could do:
{noformat}
chown root:${SOLR_USER} "/etc/default/$SOLR_SERVICE.in.sh"
chmod 0640 "/etc/default/$SOLR_SERVICE.in.sh"
{noformat}
This would produce
{noformat}
-rw-r- 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
{noformat}
This will only work if the usergroup with same name is there, which I believe 
is default on Debian based systems at least...

> solr.in.sh installed by install script should be writable by solr user
> --
>
> Key: SOLR-10644
> URL: https://issues.apache.org/jira/browse/SOLR-10644
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10644.patch
>
>
> Spinoff from SOLR-8440
> {{install_solr_service.sh}} installs {{solr.in.sh}} as world-readable but not 
> solr user writable:
> {noformat}
> -rw-r--r-- 1 root root 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}
> For better security, and ease for scripts to update solr.in.sh, this should 
> change to:
> {noformat}
> -rw-rw 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[JIRA]

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

Jan Høydahl commented on SOLR-8440:
---

Hi, sorry for the quick commit on SOLR-10644. I'm willing to revert that any 
time.

So if I'm reading you correctly [~hossman], a safer way for this is to let 
{{solr.in.sh}} still be owned by root, and print the manual instructions as 
today if we cannot write, but if {{solr auth...}} is run by root/sudo, then the 
{{solr.in.sh}} edit will succeed. Alternatively, we could always require root 
for all auth commands? Whatever we decide should be documentedt in the refGuide 
and usage.

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9882) ClassCastException: BasicResultContext cannot be cast to SolrDocumentList

[Russell Black (JIRA)]

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

Russell Black commented on SOLR-9882:
-

Looks like the same issue.

> ClassCastException: BasicResultContext cannot be cast to SolrDocumentList
> -
>
> Key: SOLR-9882
> URL: https://issues.apache.org/jira/browse/SOLR-9882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Yago Riveiro
> Attachments: SOLR-9882.patch
>
>
> After talk with [~yo...@apache.org] in the mailing list I open this Jira 
> ticket
> I'm hitting this bug in Solr 6.3.0.
> null:java.lang.ClassCastException:
> org.apache.solr.response.BasicResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:315)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> 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.StatisticsHandler.handle(StatisticsHandler.java:169)
> 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:745)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-9882) ClassCastException: BasicResultContext cannot be cast to SolrDocumentList

[Russell Black (JIRA)]

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

Russell Black edited comment on SOLR-9882 at 5/11/17 7:39 PM:
--

I'm seeing this as well on 6.1.0.  I have extended [~ysee...@gmail.com]'s patch 
in this ticket to address the NPE reported by [~abbenoir] above. I've also 
addressed the NPE in the related ticket SOLR-7987 in the same patch.  Today I 
started testing this patch on one of our production shards.  So far so good.  
If it proves stable, I'll post the patch.


was (Author: rblack):
I'm seeing this as well on 6.1.0.  I have extended [~ysee...@gmail.com]'s patch 
in this ticket to address the NPE reported by [~abbenoir] above. I've also 
addressed the NPE in the related ticket SOLR-7987.  Today I started testing 
this patch on one of our production shards.  So far so good.  If it proves 
stable, I'll post the patch.

> ClassCastException: BasicResultContext cannot be cast to SolrDocumentList
> -
>
> Key: SOLR-9882
> URL: https://issues.apache.org/jira/browse/SOLR-9882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Yago Riveiro
> Attachments: SOLR-9882.patch
>
>
> After talk with [~yo...@apache.org] in the mailing list I open this Jira 
> ticket
> I'm hitting this bug in Solr 6.3.0.
> null:java.lang.ClassCastException:
> org.apache.solr.response.BasicResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:315)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> 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.StatisticsHandler.handle(StatisticsHandler.java:169)
> 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:745)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-9882) ClassCastException: BasicResultContext cannot be cast to SolrDocumentList

[Russell Black (JIRA)]

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

Russell Black edited comment on SOLR-9882 at 5/11/17 7:39 PM:
--

I'm seeing this as well on 6.1.0.  I have extended [~ysee...@gmail.com]'s patch 
in this ticket to address the NPE reported by [~abbenoir] above. I've also 
addressed the NPE in the related ticket SOLR-7987.  Today I started testing 
this patch on one of our production shards.  So far so good.  If it proves 
stable, I'll post the patch.


was (Author: rblack):
I'm seeing this as well on 6.1.0.  I have extended [~ysee...@gmail.com]'s patch 
to address the NPE reported by [~abbenoir] above. I've also addressed the NPE 
in the related ticket SOLR-7987.  Today I started testing this patch on one of 
our production shards.  So far so good.  If it proves stable, I'll post the 
patch.

> ClassCastException: BasicResultContext cannot be cast to SolrDocumentList
> -
>
> Key: SOLR-9882
> URL: https://issues.apache.org/jira/browse/SOLR-9882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Yago Riveiro
> Attachments: SOLR-9882.patch
>
>
> After talk with [~yo...@apache.org] in the mailing list I open this Jira 
> ticket
> I'm hitting this bug in Solr 6.3.0.
> null:java.lang.ClassCastException:
> org.apache.solr.response.BasicResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:315)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> 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.StatisticsHandler.handle(StatisticsHandler.java:169)
> 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:745)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9882) ClassCastException: BasicResultContext cannot be cast to SolrDocumentList

[Russell Black (JIRA)]

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

Russell Black commented on SOLR-9882:
-

I'm seeing this as well on 6.1.0.  I have extended [~ysee...@gmail.com]]'s 
patch to address the NPE reported by [~abbenoir] above. I've also addressed the 
NPE in the related ticket SOLR-7987.  Today I started testing this patch on one 
of our production shards.  So far so good.  If it proves stable, I'll post the 
patch.

> ClassCastException: BasicResultContext cannot be cast to SolrDocumentList
> -
>
> Key: SOLR-9882
> URL: https://issues.apache.org/jira/browse/SOLR-9882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Yago Riveiro
> Attachments: SOLR-9882.patch
>
>
> After talk with [~yo...@apache.org] in the mailing list I open this Jira 
> ticket
> I'm hitting this bug in Solr 6.3.0.
> null:java.lang.ClassCastException:
> org.apache.solr.response.BasicResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:315)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> 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.StatisticsHandler.handle(StatisticsHandler.java:169)
> 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:745)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-9882) ClassCastException: BasicResultContext cannot be cast to SolrDocumentList

[Russell Black (JIRA)]

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

Russell Black edited comment on SOLR-9882 at 5/11/17 7:38 PM:
--

I'm seeing this as well on 6.1.0.  I have extended [~ysee...@gmail.com]'s patch 
to address the NPE reported by [~abbenoir] above. I've also addressed the NPE 
in the related ticket SOLR-7987.  Today I started testing this patch on one of 
our production shards.  So far so good.  If it proves stable, I'll post the 
patch.


was (Author: rblack):
I'm seeing this as well on 6.1.0.  I have extended [~ysee...@gmail.com]]'s 
patch to address the NPE reported by [~abbenoir] above. I've also addressed the 
NPE in the related ticket SOLR-7987.  Today I started testing this patch on one 
of our production shards.  So far so good.  If it proves stable, I'll post the 
patch.

> ClassCastException: BasicResultContext cannot be cast to SolrDocumentList
> -
>
> Key: SOLR-9882
> URL: https://issues.apache.org/jira/browse/SOLR-9882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Yago Riveiro
> Attachments: SOLR-9882.patch
>
>
> After talk with [~yo...@apache.org] in the mailing list I open this Jira 
> ticket
> I'm hitting this bug in Solr 6.3.0.
> null:java.lang.ClassCastException:
> org.apache.solr.response.BasicResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:315)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> 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.StatisticsHandler.handle(StatisticsHandler.java:169)
> 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:745)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 19610 - Still unstable!

[Policeman Jenkins Server]

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

1 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([F4F5877D6EC1345C:2CB8AA2A991C91FC]: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 

[jira] [Updated] (LUCENE-7824) Multi-word synonyms rule with common terms at the same position are buggy

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi updated LUCENE-7824:
-
Attachment: LUCENE-7824.patch

> Multi-word synonyms rule with common terms at the same position are buggy
> -
>
> Key: LUCENE-7824
> URL: https://issues.apache.org/jira/browse/LUCENE-7824
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7824.patch
>
>
> The automaton built from the graph token stream tries to pack common terms in 
> multi word synonyms that appear at the same position. This means that some 
> states inside a multi word synonym can have multiple transitions.
> As a result the intersection point of the graph are not computed correctly.
> For example the synonym rule: "ny, new york city, new york" is not applied 
> correctly to the query "ny police".
> In this case "police" is detected as part of the multi synonyms path and we 
> create the disjunction between:
>  "ny police", "new york police", ...
> I pushed a patch that removes this optim (and creates a single transition 
> from each state) in order to ensure that the intersection points of the graph 
> always showed up at the end of the multi synonym paths.
> [~mattweber] can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7824) Multi-word synonyms rule with common terms at the same position are buggy

[Jim Ferenczi (JIRA)]

Jim Ferenczi created LUCENE-7824:


 Summary: Multi-word synonyms rule with common terms at the same 
position are buggy
 Key: LUCENE-7824
 URL: https://issues.apache.org/jira/browse/LUCENE-7824
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Jim Ferenczi


The automaton built from the graph token stream tries to pack common terms in 
multi word synonyms that appear at the same position. This means that some 
states inside a multi word synonym can have multiple transitions.
As a result the intersection point of the graph are not computed correctly.

For example the synonym rule: "ny, new york city, new york" is not applied 
correctly to the query "ny police".
In this case "police" is detected as part of the multi synonyms path and we 
create the disjunction between:
 "ny police", "new york police", ...

I pushed a patch that removes this optim (and creates a single transition from 
each state) in order to ensure that the intersection points of the graph always 
showed up at the end of the multi synonym paths.
[~mattweber] can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10612) make ':toclevels:' work in our jekyll templates

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10612:
--

This isn't a solution, just jotting this down as a use case...

The Streaming Expressions page is one where it would be nice to have some 
flexibility in placement of the TOC.

Let's assume for a moment that we split that page up and move all the 
expressions to new pages for their types  (sources, decorators, & evaluators), 
with the main discussion content staying on a parent Streaming Expressions 
page, something like:

- Streaming Expressions
-- Stream Sources
-- Stream Decorators
-- Stream Evaluators

These new children pages basically become parameter reference & example pages. 
They'll still be quite long, and a TOC on the right of the screen would be 
easier to work with than on the top.

> make ':toclevels:' work in our jekyll templates
> ---
>
> Key: SOLR-10612
> URL: https://issues.apache.org/jira/browse/SOLR-10612
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: lang-analysis-1-level-toc.png
>
>
> asciidoc has a concept called {{:toclevels:}} which is suppose to determine 
> which how deep down a page's section/header depth the generated table of 
> contents will show -- ie: some LONG pages have a huge number of level 2 
> headings, and on those pages we only want to show level 1.
> but in jekyll, asciidoctor isn't responsible for generating the TOC -- 
> instead it's done by some javascript (which is better for a variety of 
> reasons) and at the moment this javascript doesn't know anything about 
> {{:toclevels:}}
> But it should be possible to tweak our rendering templates to include 
> {{:toclevels:}} as an attribute in the generated HTML, and then we can tweak 
> the javascript call made to generate the TOC so that it respects it on a 
> per-page basis



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10572) (from 7.0.0 onwards) remove three no-longer-supported warnings in SolrIndexConfig

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10572:
-

wait a minute -- the {{mergePolicy}} warning may date back to 2012, but the 
code to parse & use a {{mergePolicy}} declaration if it exists is still in the 
6x code (and for that matter master too)

we shouldn't be removing the {{assertWarnOrFail}} call until *AFTER* the 
functionality is removed ... that's the entire point of that method: while the 
functionality is still supported (but deprecated) it can warn, once the 
functionality is removed it can fail.

As things stand right now, if 7.0 is released tomorow someone with an old 
config (who may not have ever noticed the warnings in past versions, or may 
upgraded to 7.0 from a version before we deprecated that syntax) won't get a 
warning about their {{mergePolicy}} config usage at all -- but in some future 
version it will just silently stop working.



> (from 7.0.0 onwards) remove three no-longer-supported warnings in 
> SolrIndexConfig
> -
>
> Key: SOLR-10572
> URL: https://issues.apache.org/jira/browse/SOLR-10572
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10572.patch
>
>
> The mergeScheduler, mergePolicy and luceneAutoCommit [no-longer-supported 
> warnings|https://github.com/apache/lucene-solr/blame/48ca9fc3f4f8d95293cee7bb59eff61247ede181/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L130-L140]
>  date back to 
> [2012|https://github.com/apache/lucene-solr/commit/058179d177208450850c5e3e3103710cadd3b53e].
>  Let's remove them from 7.0.0 onwards for clarity. This caught my attention 
> as part of SOLR-8668's mergePolicy support removal.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 346 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/346/

3 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=4107, name=Thread-942, 
state=RUNNABLE, group=TGRP-FullSolrCloudDistribCmdsTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4107, name=Thread-942, state=RUNNABLE, 
group=TGRP-FullSolrCloudDistribCmdsTest]
Caused by: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: 
Error from server at http://127.0.0.1:55985/b_/collection2_shard3_replica1: 
Exception writing document id thread2_9_3 to the index; possible analysis error.
at __randomizedtesting.SeedInfo.seed([A2FEA6BF206E2B5A]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1263)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest$1IndexThread.run(FullSolrCloudDistribCmdsTest.java:641)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:55985/b_/collection2_shard3_replica1: Exception 
writing document id thread2_9_3 to the index; possible analysis error.
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:610)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:447)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:388)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:796)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
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)


FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload

Error Message:
expected:<[{indexVersion=1494516003384,generation=2,filelist=[_bk.fdt, _bk.fdx, 
_bk.fnm, _bk.nvd, _bk.nvm, _bk.si, _bk_MockRandom_0.doc, _bk_MockRandom_0.sd, 
_bk_MockRandom_0.tfp, _bl.fdt, _bl.fdx, _bl.fnm, _bl.nvd, _bl.nvm, _bl.si, 
_bl_MockRandom_0.doc, _bl_MockRandom_0.sd, _bl_MockRandom_0.tio, 
_bl_MockRandom_0.tipo, _bm.fdt, _bm.fdx, _bm.fnm, _bm.nvd, _bm.nvm, _bm.si, 
_bm_MockRandom_0.doc, _bm_MockRandom_0.sd, _bm_MockRandom_0.tbk, 
_bm_MockRandom_0.tix, _bn.fdt, _bn.fdx, _bn.fnm, _bn.nvd, _bn.nvm, _bn.si, 
_bn_MockRandom_0.doc, _bn_MockRandom_0.sd, _bn_MockRandom_0.tib, 
_bn_MockRandom_0.tii, _bo.fdt, _bo.fdx, _bo.fnm, _bo.nvd, _bo.nvm, _bo.si, 
_bo_MockRandom_0.doc, _bo_MockRandom_0.sd, _bo_MockRandom_0.tio, 
_bo_MockRandom_0.tipo, _bp.fdt, _bp.fdx, _bp.fnm, _bp.nvd, _bp.nvm, _bp.si, 
_bp_MockRandom_0.doc, _bp_MockRandom_0.sd, _bp_MockRandom_0.tio, 
_bp_MockRandom_0.tipo, _bq.fdt, _bq.fdx, _bq.fnm, _bq.nvd, _bq.nvm, _bq.si, 
_bq_MockRandom_0.doc, _bq_MockRandom_0.sd, _bq_MockRandom_0.tib, 
_bq_MockRandom_0.tiv, _br.fdt, _br.fdx, _br.fnm, _br.nvd, _br.nvm, _br.si, 
_br_MockRandom_0.doc, _br_MockRandom_0.sd, _br_MockRandom_0.tim, 
_br_MockRandom_0.tip, _bs.fdt, _bs.fdx, _bs.fnm, _bs.nvd, _bs.nvm, _bs.si, 
_bs_MockRandom_0.doc, _bs_MockRandom_0.sd, _bs_MockRandom_0.tfp, _bt.fdt, 
_bt.fdx, _bt.fnm, _bt.nvd, _bt.nvm, _bt.si, _bt_MockRandom_0.doc, 
_bt_MockRandom_0.sd, _bt_MockRandom_0.tio, _bt_MockRandom_0.tipo, _bu.fdt, 
_bu.fdx, _bu.fnm, _bu.nvd, _bu.nvm, _bu.si, _bu_MockRandom_0.doc, 
_bu_MockRandom_0.sd, _bu_MockRandom_0.tim, _bu_MockRandom_0.tip, _bv.fdt, 
_bv.fdx, _bv.fnm, _bv.nvd, _bv.nvm, _bv.si, _bv_MockRandom_0.doc, 
_bv_MockRandom_0.sd, _bv_MockRandom_0.tim, _bv_MockRandom_0.tip, _bw.fdt, 
_bw.fdx, _bw.fnm, _bw.nvd, _bw.nvm, _bw.si, _bw_MockRandom_0.doc, 
_bw_MockRandom_0.sd, _bw_MockRandom_0.tib, _bw_MockRandom_0.tiv, _bx.fdt, 
_bx.fdx, _bx.fnm, _bx.nvd, _bx.nvm, _bx.si, _bx_MockRandom_0.doc, 
_bx_MockRandom_0.sd, _bx_MockRandom_0.tib, _bx_MockRandom_0.tiv, _by.fdt, 
_by.fdx, _by.fnm, _by.nvd, _by.nvm, _by.si, _by_MockRandom_0.doc, 
_by_MockRandom_0.sd, 

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8440:


bq. if people feel this goal is important then as i mentioned in SOLR-10644 ...
In my opinion, it is not necessary. The changes supposed to be made to 
solr.in.sh in this issue are printed out for the user to put in 
himself/herself, in case the file is not writeable.

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-8776) Support RankQuery in grouping

[Diego Ceccarelli (JIRA)]

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

Diego Ceccarelli updated SOLR-8776:
---
Fix Version/s: (was: 6.0)
   master (7.0)

> Support RankQuery in grouping
> -
>
> Key: SOLR-8776
> URL: https://issues.apache.org/jira/browse/SOLR-8776
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 6.0
>Reporter: Diego Ceccarelli
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch, 
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch
>
>
> Currently it is not possible to use RankQuery [1] and Grouping [2] together 
> (see also [3]). In some situations Grouping can be replaced by Collapse and 
> Expand Results [4] (that supports reranking), but i) collapse cannot 
> guarantee that at least a minimum number of groups will be returned for a 
> query, and ii) in the Solr Cloud setting you will have constraints on how to 
> partition the documents among the shards.
> I'm going to start working on supporting RankQuery in grouping. I'll start 
> attaching a patch with a test that fails because grouping does not support 
> the rank query and then I'll try to fix the problem, starting from the non 
> distributed setting (GroupingSearch).
> My feeling is that since grouping is mostly performed by Lucene, RankQuery 
> should be refactored and moved (or partially moved) there. 
> Any feedback is welcome.
> [1] https://cwiki.apache.org/confluence/display/solr/RankQuery+API 
> [2] https://cwiki.apache.org/confluence/display/solr/Result+Grouping
> [3] 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201507.mbox/%3ccahm-lpuvspest-sw63_8a6gt-wor6ds_t_nb2rope93e4+s...@mail.gmail.com%3E
> [4] 
> https://cwiki.apache.org/confluence/display/solr/Collapse+and+Expand+Results



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: lucene-solr:solr10644: SOLR-10644: solr.in.sh installed by install script should be writable by solr user

[Chris Hostetter]

NOTE: I'm -0 to this change, see detailed comments in SOLR-10644


: Date: Tue,  9 May 2017 11:00:33 + (UTC)
: From: jan...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: lucene-solr:solr10644: SOLR-10644: solr.in.sh installed by install
: script should be writable by solr user
: 
: Repository: lucene-solr
: Updated Branches:
:   refs/heads/solr10644 [created] cfc1571ba
: 
: 
: SOLR-10644: solr.in.sh installed by install script should be writable by solr 
user
: 
: 
: Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
: Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/cfc1571b
: Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/cfc1571b
: Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/cfc1571b
: 
: Branch: refs/heads/solr10644
: Commit: cfc1571bab64c7c619282141c49fc793176f0846
: Parents: c9541c2
: Author: Jan H??ydahl 
: Authored: Tue May 9 11:30:40 2017 +0200
: Committer: Jan H??ydahl 
: Committed: Tue May 9 11:30:40 2017 +0200
: 
: --
:  solr/CHANGES.txt | 2 ++
:  solr/bin/install_solr_service.sh | 4 ++--
:  2 files changed, 4 insertions(+), 2 deletions(-)
: --
: 
: 
: 
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/cfc1571b/solr/CHANGES.txt
: --
: diff --git a/solr/CHANGES.txt b/solr/CHANGES.txt
: index 41586ed..d2ce667 100644
: --- a/solr/CHANGES.txt
: +++ b/solr/CHANGES.txt
: @@ -398,6 +398,8 @@ Other Changes
:was an improvement for the json "arrntv" format, it caused problems for 
the default json format.
:(James Dyer, reported by Nikita Pchelintsev)
:  
: +* SOLR-10644: solr.in.sh installed by install script should be writable by 
solr user (janhoy)
: +
:  ==  6.5.1 ==
:  
:  Bug Fixes
: 
: 
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/cfc1571b/solr/bin/install_solr_service.sh
: --
: diff --git a/solr/bin/install_solr_service.sh 
b/solr/bin/install_solr_service.sh
: index f42dd5a..54b62e5 100755
: --- a/solr/bin/install_solr_service.sh
: +++ b/solr/bin/install_solr_service.sh
: @@ -331,8 +331,8 @@ SOLR_LOGS_DIR=\"$SOLR_VAR_DIR/logs\"
:  SOLR_PORT=\"$SOLR_PORT\"
:  " >> "/etc/default/$SOLR_SERVICE.in.sh"
:  fi
: -chown root: "/etc/default/$SOLR_SERVICE.in.sh"
: -chmod 0644 "/etc/default/$SOLR_SERVICE.in.sh"
: +chown ${SOLR_USER}: "/etc/default/$SOLR_SERVICE.in.sh"
: +chmod 0660 "/etc/default/$SOLR_SERVICE.in.sh"
:  
:  # install data directories and files
:  mkdir -p "$SOLR_VAR_DIR/data"
: 
: 

-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8440:


NOTE: i posted a longish comment in SOLR-10644 against that change...

bq. FWIW: I'm -0 on the installer making {{solr.in.sh}} writable by any user 
other then the user running the installer (ie: "root"). ...

Since that jira seems to have been motivated entirely by this feature, It seems 
important for me to cross post here a -0 towards the current solution of how 
the changes script should be able to modify {{solr.in.sh}} ... if people feel 
this goal is important then as i mentioned in SOLR-10644 ...

bq. ... the solution to that objective should be error checking and help 
messages instructing the user that those specific commands need to be run as 
root via {{sudo bin/solr ... }}

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10644) solr.in.sh installed by install script should be writable by solr user

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10644:
-

wait ... what?

FWIW: I'm -0 on the installer making {{solr.in.sh}} writable by any user other 
then the user running the installer (ie: "root").

In general this seems like a really risky step that could make potential 
security holes in the future 10x worse then they would be otherwise.  Example: 
imagine a hypothetical future security hole where a solr request handler allows 
writting to files on disk.  if the filesystem permissions of {{solr.in.sh}} 
mean it's writable by the {{solr}} user running the webapp, now an attacker can 
influence the way the solr webapp is run on restart, opening up more holes.

if the motivation here is to allow {{bin/solr ...}} subcommands to easily muck 
with {{solr.in.sh}} then the solution to that objective should be error 
checking and help messages instructing the user that those specific commands 
need to be run as root via {{sudo bin/solr ... }}

In general, the places a service's effective UID should be able to write to 
should be *VERY* limited, and constrained tothe well known place where that 
service keeps it's "data" ... enabling apps with the ability to overwrite their 
configuration is a big red flag.

> solr.in.sh installed by install script should be writable by solr user
> --
>
> Key: SOLR-10644
> URL: https://issues.apache.org/jira/browse/SOLR-10644
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10644.patch
>
>
> Spinoff from SOLR-8440
> {{install_solr_service.sh}} installs {{solr.in.sh}} as world-readable but not 
> solr user writable:
> {noformat}
> -rw-r--r-- 1 root root 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}
> For better security, and ease for scripts to update solr.in.sh, this should 
> change to:
> {noformat}
> -rw-rw 1 root solr 5968 Feb 15 14:55 /etc/default/solr.in.sh
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10617) JDBCStream: support more data types

[James Dyer (JIRA)]

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

James Dyer updated SOLR-10617:
--
Attachment: SOLR-10617.patch

ok, here's another patch that moves CalciteJDBCStream into oas.Handler in 
solr-core.  Also, the sha1, licence & notice are updated for the newer version 
of hsqldb, in an effort to get precommit to pass.  My aim is to commit this 
tomorrow.

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Reopened] (SOLR-10565) SolrJmxReporterTest.testEnabled() failure

[Hoss Man (JIRA)]

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

Hoss Man reopened SOLR-10565:
-

> SolrJmxReporterTest.testEnabled() failure
> -
>
> Key: SOLR-10565
> URL: https://issues.apache.org/jira/browse/SOLR-10565
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
> Fix For: 6.6, master (7.0)
>
>
> My Jenkins found a reproducing branch_6x seed:
> {noformat}
> Checking out Revision ea3f9bb87d1e6c3cf812122c3a6f9160a8b49a19 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> 86968 INFO  
> (TEST-SolrJmxReporterTest.testEnabled-seed#[79BD33EADDE24AC0]) [
> x:collection1] o.a.s.SolrTestCaseJ4 ###Ending testEnabled
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrJmxReporterTest -Dtests.method=testEnabled 
> -Dtests.seed=79BD33EADDE24AC0 -Dtests.slow=true -Dtests.locale=cs 
> -Dtests.timezone=Europe/Amsterdam -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.82s J6  | SolrJmxReporterTest.testEnabled <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([79BD33EADDE24AC0:4E7C92349C473AB0]:0)
>[junit4]>  at 
> org.apache.solr.metrics.reporters.SolrJmxReporterTest.testEnabled(SolrJmxReporterTest.java:197)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
> docValues:{}, maxPointsInLeafNode=1415, maxMBSortInHeap=6.528209197753226, 
> sim=RandomSimilarity(queryNorm=false,coord=yes): {}, locale=cs, 
> timezone=Europe/Amsterdam
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_77 (64-bit)/cpus=16,threads=1,free=154074736,total=443023360
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10565) SolrJmxReporterTest.testEnabled() failure

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10565:
-

increasing the size of the randomly generated name(s) doesn't do anything to 
ensure that they don't collide.

if we need unique ObjectNames then the test should either generate the random 
strings in a loop untill it gets enough unique ones, or use some unique counter 
as part of the name.

> SolrJmxReporterTest.testEnabled() failure
> -
>
> Key: SOLR-10565
> URL: https://issues.apache.org/jira/browse/SOLR-10565
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
> Fix For: 6.6, master (7.0)
>
>
> My Jenkins found a reproducing branch_6x seed:
> {noformat}
> Checking out Revision ea3f9bb87d1e6c3cf812122c3a6f9160a8b49a19 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> 86968 INFO  
> (TEST-SolrJmxReporterTest.testEnabled-seed#[79BD33EADDE24AC0]) [
> x:collection1] o.a.s.SolrTestCaseJ4 ###Ending testEnabled
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrJmxReporterTest -Dtests.method=testEnabled 
> -Dtests.seed=79BD33EADDE24AC0 -Dtests.slow=true -Dtests.locale=cs 
> -Dtests.timezone=Europe/Amsterdam -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.82s J6  | SolrJmxReporterTest.testEnabled <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([79BD33EADDE24AC0:4E7C92349C473AB0]:0)
>[junit4]>  at 
> org.apache.solr.metrics.reporters.SolrJmxReporterTest.testEnabled(SolrJmxReporterTest.java:197)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
> docValues:{}, maxPointsInLeafNode=1415, maxMBSortInHeap=6.528209197753226, 
> sim=RandomSimilarity(queryNorm=false,coord=yes): {}, locale=cs, 
> timezone=Europe/Amsterdam
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_77 (64-bit)/cpus=16,threads=1,free=154074736,total=443023360
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10674) Don't delete core.properties when a core is unloaded

[Simon Rosenthal (JIRA)]

Simon Rosenthal created SOLR-10674:
--

 Summary: Don't delete core.properties when a core is unloaded
 Key: SOLR-10674
 URL: https://issues.apache.org/jira/browse/SOLR-10674
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.5.1, 6.3
 Environment: Centos 7 on AWS, Java 8
Reporter: Simon Rosenthal
Priority: Minor



In earlier versions of Solr, unloading a core caused it's core.properties file 
to be renamed to something like core.properties.unloaded. The current behavior 
(observed in 6.3.0 and 6.5.1, running in non-cloud mode) is to delete 
core.properties, which is extremely inconvenient if it is anticipated that the 
core will be reloaded.

here's the logfile entry for the unload request
INFO  - 2017-05-11 09:39:23.960; [   ] org.apache.solr.servlet.HttpSolrCall; 
[admin] webapp=null path=/admin/cores 
params={core=dev0510=UNLOAD=json&_=1494513368797} status=0 QTime=624

Please consider restoring the  previous behavior.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10617) JDBCStream: support more data types

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10617 at 5/11/17 3:57 PM:


Looks good. From a standpoint of separating the Parallel SQL logic I think this 
patch is ready to go. And yes I think CalciteJDBCStream belongs in core. 


was (Author: joel.bernstein):
Looks good. From a standpoint of severing the tie to Parallel SQL I think this 
patch is ready to go. And yes I think CalciteJDBCStream belongs in core. 

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10617:
---

Looks good. From a standpoint of severing the tie to Parallel SQL I think this 
patch is ready to go. And yes I think CalciteJDBCStream belongs in core. 

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10617) JDBCStream: support more data types

[James Dyer (JIRA)]

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

James Dyer edited comment on SOLR-10617 at 5/11/17 3:47 PM:


[~joel.bernstein]  Please review the updated patch.  With a small refactoring 
we can avoid all the copy/paste.  If this is in line with what you'd want, do 
you think it would make sense to go one step further and combine 
CalciteJDBCStream with SqlHandler#SqlHandlerStream and locate this in solr-core?


was (Author: jdyer):
[~joel.bernstein]  Please review the updated patch.  With a small refactoring 
we can avoid all the copy/paste.  If this is in line with what you'd want, do 
you think it would make sense to go one step further and combine 
CalciteJDBCStream with SqlHandler#SqlHandlerStream and locate this in solr-core.

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10617) JDBCStream: support more data types

[James Dyer (JIRA)]

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

James Dyer updated SOLR-10617:
--
Attachment: SOLR-10617.patch

[~joel.bernstein]  Please review the updated patch.  With a small refactoring 
we can avoid all the copy/paste.  If this is in line with what you'd want, do 
you think it would make sense to go one step further and combine 
CalciteJDBCStream with SqlHandler#SqlHandlerStream and locate this in solr-core.

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch, 
> SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+168) - Build # 19609 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19609/
Java: 64bit/jdk-9-ea+168 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenew

Error Message:
expected:<200> but was:<403>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([C07366081C48B469:F7E89216248469CD]: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.security.hadoop.TestDelegationWithHadoopAuth.renewDelegationToken(TestDelegationWithHadoopAuth.java:118)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.verifyDelegationTokenRenew(TestDelegationWithHadoopAuth.java:302)
at 
org.apache.solr.security.hadoop.TestDelegationWithHadoopAuth.testDelegationTokenRenew(TestDelegationWithHadoopAuth.java:319)
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:563)
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 
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 

[jira] [Commented] (SOLR-10672) Full Import for an entity is not importing anything

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-10672:
--

These kinds of questions are best to start with the User mailing list and then 
- if the issue is confirmed as a bug - open a JIRA.

I suspect the issue here is that you are trying to trigger DIH twice in 
parallel. It is not design for that, as it runs asynchronously. However, I 
believe that if you have several request handlers (in solrconfig.xml) for DIH, 
you can invoke them in parallel. They can share the same configuration file. 

I would try that first.

> Full Import for an entity is not importing anything
> ---
>
> Key: SOLR-10672
> URL: https://issues.apache.org/jira/browse/SOLR-10672
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Affects Versions: 6.4.1
>Reporter: Torsten Faltinat
>
> Hi,
> we are using a DIH via JDBC to index documents out of our database. Due to 
> our design, this full import is/can be executed entity per entity. We are 
> using a http request out of .Net client to execute these imports.
> If we execute requests (multiple full imports) very fast, Solr accepts the 
> request but the import is not executed. In such a case the following log 
> entry is visible:
> 2017-05-11 13:28:10.317 INFO  (qtp1654589030-16) [   x:iET] o.a.s.c.S.Request 
> [iET]  webapp=/solr path=/dataimport 
> params={connectionString=jdbc:sqlserver://...=false=sa=2.2=full-import=ts2_it_change_text_search}
>  status=0 QTime=0
> That's all for this entity. We stumbled over this entry because the QTime=0.
> Whereas a successfull import produces entries like this:
> 2017-05-11 13:28:10.298 INFO  (qtp1654589030-14) [   x:iET] o.a.s.c.S.Request 
> [iET]  webapp=/solr path=/dataimport 
> params={connectionString=jdbc:sqlserver://...=false=sa=2.2=full-import=ts1_it_change_text_search}
>  status=0 QTime=15
> ...
> 2017-05-11 13:28:10.339 INFO  (Thread-16) [   x:iET] o.a.s.h.d.JdbcDataSource 
> Creating a connection for entity ts1_it_change_text_search with URL: 
> jdbc:sqlserver://...
> ...
> 2017-05-11 13:28:10.715 INFO  (Thread-16) [   x:iET] 
> o.a.s.u.p.LogUpdateProcessorFactory [iET]  webapp=/solr path=/dataimport 
> params={connectionString=jdbc:sqlserver://...=false=sa=2.2=full-import=ts1_it_change_text_search}
>  status=0 QTime=15{add=[82628015d12ac6be (1567106573943177216), 
> 3f314c79dd29634f (1567106573948420096), 37e6a5139ac7640d 
> (1567106573950517248), 6b44fa32c4aee1b4 (1567106573952614400), 
> f5695f69c3aac089 (1567106573954711552), 7a34e505265071ce 
> (1567106573956808704), b2729ff2de7d3b8e (1567106573958905856), 
> b92b779c74481ef0 (1567106573963100160), 5d42a3619ddc50fd 
> (1567106573967294464), 9793b2036f2491db (1567106573969391616), ... (12 
> adds)],commit=} 0 433
> If we wait some ms between each request, everything works fine. From our 
> perspective it looks like an issue. Or do you have any idea what we are doing 
> wrong?
> Thx
> Torsten



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7392) Add point based GeoBoundingBoxField as a new RangeField type

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7392:
--

Regarding which branches it should go into, both options work for me. The 
benefit of not putting new features in 6.x is that it reduces the likeliness of 
us having to do a bugfix release once 7.0 is out (which is always problematic 
because we need to make sure the index format is forward-compatible), so I 
think your plan to only put it in 7.0 makes sense.

> Add point based GeoBoundingBoxField as a new RangeField type
> 
>
> Key: LUCENE-7392
> URL: https://issues.apache.org/jira/browse/LUCENE-7392
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-7392.patch
>
>
> This issue will add a new point based {{GeoBoundingBoxField}} type for 
> indexing and querying 2D or 3D Geo bounding boxes. The intent is to construct 
> this as a RangeField type and limit the first two dimensions to the lat/lon 
> geospatial bounds (at 4 bytes each like {{LatLonPoint}}, while allowing an 
> optional 8 byte ({{double}}) third dimension to serve as an altitude 
> component for indexing 3D geospatial bounding boxes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7392) Add point based GeoBoundingBoxField as a new RangeField type

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7392:
--

This is an exciting feature!
 * I'm wondering whether we should stick to 2 dimensions to be symmetric with 
LatLonPoint? Maybe also call it something like LatLonBox ("LatLon" prefix to 
indicate it works similarly to "LatLonPoint" and removing the "Field" suffix 
like we did for ranges).
 * The impl of {{newXDLQuery}} is a bit suspicious, the west builder is not 
useful since it wraps a single query, which means the queryType is mostly 
ignored? I haven't thought much about it but I'm wondering it could just do 
{{return bboxQuery(field, minLat, minLon, minAlt, maxLat, 360.0D + maxLon, 
maxAlt, queryType);}} given how we index?
 * It looks like toString does not read bytes at the correct offsets, 
especially for the longitude.

[~mikemccand] and/or [~rcmuir]: you might be interested to have a look since 
you worked on LatLonPoint?

> Add point based GeoBoundingBoxField as a new RangeField type
> 
>
> Key: LUCENE-7392
> URL: https://issues.apache.org/jira/browse/LUCENE-7392
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-7392.patch
>
>
> This issue will add a new point based {{GeoBoundingBoxField}} type for 
> indexing and querying 2D or 3D Geo bounding boxes. The intent is to construct 
> this as a RangeField type and limit the first two dimensions to the lat/lon 
> geospatial bounds (at 4 bytes each like {{LatLonPoint}}, while allowing an 
> optional 8 byte ({{double}}) third dimension to serve as an altitude 
> component for indexing 3D geospatial bounding boxes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10670) [ref-guide] Various top-bar fixes

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10670:
-
Attachment: SOLR-10670-home.patch

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670-home.patch, SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10634) Move calculation of some aggregations to collection phase

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-10634:

Attachment: SOLR-10634.patch

Here's a first-cut patch.  Existing tests pass, but no specific tests yet to 
even see if it's being exercised.  I don't think that limit:-1 is exercised 
much at all either.

> Move calculation of some aggregations to collection phase
> -
>
> Key: SOLR-10634
> URL: https://issues.apache.org/jira/browse/SOLR-10634
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
> Attachments: SOLR-10634.patch
>
>
> From http://markmail.org/message/pwgnt7iqxkzcnckh
> {quote}
> The current code is more optimized for finding the top K buckets from
> a total of N.
> When one asks to return the top 10 buckets when there are potentially
> millions of buckets, it makes sense to defer calculating other metrics
> for those buckets until we know which ones they are.  After we
> identify the top 10 buckets, we calculate the domain for that bucket
> and use that to calculate the remaining metrics.
> The current method is obviously much slower when one is requesting
> *all* buckets.  We might as well just calculate all metrics in the
> first pass rather than trying to defer them.
> {quote}
> So we should move aggregations from the second pass to the first pass under 
> the following conditions:
> - no limit (or a high limit compared to the number of potential buckets?)
> - no sub-facets (or anything else) that will need the domain calculated anyway
> - aggregation is not really memory intensive per-slot (i.e. moving some 
> calculations from per-bucket in the second phase, to all-buckets-in-parallel 
> in the first phase could be really bad for peak memory usage)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10670) [ref-guide] Various top-bar fixes

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10670:
--

I figured out a way to make it all work the way we want...

First, {{index.adoc}} is going to have to be a "special" page, with some 
special rules. Hopefully comments in the right places will make it clear to all 
of us in the future what's going on.

I set two new attributes to {{index.adoc}} at the top:
* I removed the {{= Apache Solr Reference Guide}} at the top and replaced it 
with {{:doctitle: Home}}. This sets the document title to Home but it will get 
treated different by the asciidoc preprocessor (see this issue for how I got 
the idea: https://github.com/asciidoctor/asciidoctor-pdf/issues/95). This is 
totally valid syntax, so doesn't cause either Jekyll or asciidoc-pdf to 
complain.
* I added a new attribute {{:page-displayname: Apache Solr Reference Guide}}

Next I added a conditional statement to {{index.adoc}} as follows:

{code}
ifdef::backend-pdf[:notitle:]
ifdef::backend-pdf[]
= {page-displaytitle}
endif::[]
{code}

That says, if it's a PDF, don't set the document title (that {{:doctitle: 
attribute}}). Instead, use the page-displaytitle attribute ("Apache Solr 
Reference Guide"). In the PDF that's generated, the user doesn't see "Home" - 
only "Apache Solr Reference Guide" in TOC and page title. We could call this 
something else if desired. 

For the HTML page, if we set the page title to "Home" with something like {{= 
Home}}, then the first thing the user would see at the top of the page is 
"Home", which is bad. So I added a conditional to {{page.html}} where that 
title is set to use the page-displaytitle instead:

{code}

   {% if page.title == "Home" %}
   {{ page.displaytitle }}
   {% else %}
   {{ page.title }}
   {% endif %}

{code}

Now what happens is that the HTML page is generated with metadata that defines 
{{Home | Apache Solr Reference Guide}} as the title, but displays "Apache Solr 
Reference Guide" on the page.

This all seems to work fine - nothing complains during build. I'll attach a 
patch so you can see it for yourself.

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10617:
---

I agree this is a useful ticket and we shouldn't block it's progress. 

I think the best approach is to have an internal JdbcStream for the Calcite 
Integration that supports specific Calcite needs.

We could simply copy the existing JdbcStream and rename it CalciteJdbcStream 
and use it in the SQLHandler. Then this ticket can progress without worrying 
about the larger Parallel SQL structure.

[~jdyer], would you be OK with doing this as part of this commit?

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Release 6.6

[Ishan Chattopadhyaya]

Done, Adrien. Thanks!

On Thu, May 11, 2017 at 7:34 PM, Adrien Grand  wrote:

> Ishan, wdyt about running addVersion on the branch_6x/master as well? I
> think it would help realize that the 6.6 branch has been cut when looking
> at the CHANGES.txt file and not forget about backporting?
>
> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> a écrit :
>
>> I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>> bugfixes to the branch, if needed.
>> Planning to build the first RC on 15 May. Please let me know if there are
>> any objections.
>>
>> Thanks,
>> Ishan
>>
>> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Planning to cut the release branch in another 10-12 hours.
>>>
>>> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty 
>>> wrote:
>>>
 i was wondering if there was a specific test for SpanPayloadCheckQuery
 method

 matches = payloadToMatch.get(upto).bytesEquals(payload);


 the only implementation i could locate was in collectLeaf of
 SpanPayloadCheckQuery


 I will submit JIRA with Patch


 as a CS *dinosaur* I am more familiar with LISP for dissecting sentence
 fragments (what we called phenomes) than current SEO implementations


 Can you suggest a book to read to better understand Lucenes pattern
 dissection and match algorithms?


 Many Thanks for helpful guidance
 Martin
 __




 --
 *From:* Erik Hatcher 
 *Sent:* Sunday, April 30, 2017 2:06 PM

 *To:* dev@lucene.apache.org
 *Subject:* Re: Release 6.6

 Martin -

 I have to admit to still being unsure what the gist is here - is there
 a bug?   Apologies for not catching what you’re saying/showing here.
 Again, as far as I can tell SpanPayloadCheckQuery is working as expected
 now.

 I’m going to focus purely on SOLR-1485 this week to get it committed
 for 6.6.  If there is an issue to address with your work would you please
 open a JIRA and include your patch there?

 Thanks,
 Erik


 On Apr 30, 2017, at 7:47 AM, Martin Gainty  wrote:

 Mornin' Erik

 there is a collectLeaf  override in org.apache.lucene.queries.payloads.
 TestPayloadSpans ..but its never called:

 static class VerifyingCollector implements SpanCollector {
 List payloads = new ArrayList<>();
 @Override
 public void collectLeaf(PostingsEnum postings, int position, Term
 term) throws IOException {
  
  }
 }


 the modification in 
 org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests
 collectLeaf for query

 //initialise term

 log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before
 term1=new org.apache.lucene.index.Term('field','withPayload')");
 org.apache.lucene.index.Term term1=new 
 org.apache.lucene.index.Term("field",
 "withPayload");
 log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
 term1="+term1);

 //assume position is 5
 int position=5;
 log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
 position="+position);

 BytesRef pay = new BytesRef("pos: " + position);
 log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
 pay="+pay);

 //build spanQuery with term parameter
 org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
 SpanTermQuery(term1);
 log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
 spanQuery1="+spanQuery1);

 //add BytesRef to payloadToMatch list
 java.util.List payloadToMatch=new
 java.util.ArrayList();
 log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
 payloadToMatch="+payloadToMatch);
 payloadToMatch.add(pay);

 //build SpanPayloadCheckQuery

 query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
 (org.apache.lucene.search.spans.SpanQuery)query,
 (java.util.List)payloadToMatch);
 log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
 query="+query);

 //build lucene Directory (TODO: we should use an existing directory
 with REAL test-data)
 org.apache.lucene.store.Directory ram = newDirectory(com.carrotsearch.
 randomizedtesting.RandomizedContext.current().getRandom());

 //build SegmentReader from Directory
 log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
 ram="+ram);
 SegmentReader reader = getOnlySegmentReader(org.apache.lucene.index.
 DirectoryReader.open(ram));
 log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[James Dyer (JIRA)]

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

James Dyer commented on SOLR-10617:
---

[~joel.bernstein] I would rather not expand the scope of this issue to address 
additional concerns, but we can follow up with more tickets as needed.  I only 
bring up the Array support because it is in the same part of the code, yet the 
spirit of the implementation didn't match the rest of the class.  If its 
intended as an internal-only feature, that is fine to me.  I only wish there 
were a comment in there saying as much.  In the future, it might be nice to 
(better) support Array types from external sources, but this could be a lot of 
work for what might prove to be a niche use-case.

Do you see anything done here that blocks the efforts on the 3 items you 
mention?  Any reason why this can't be committed now?  Without BigDecimal 
support, its very difficult to work with numeric types from db2 and Oracle.  
The date/time/clob types would also be very helpful if we could support these 
near-term.

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10654) Expose Metrics in Prometheus format

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-10654:


Seems like there a few things here:

1.  
  - a: Pull reporter framework. An interesting idea, but is it over engineering 
for an initial effort? I'm not aware any other mainstream metrics frameworks 
that pull metrics in a very specific format. Any home rolled thing can consume 
the default format we expose. 
  - b: Additionally, we can expose these metrics under {{/metrics/prometheus}} 
like suggested above, to avoid having to change the api if we later decide 
there is a need for more generic framework.

2. Response writers. It might be interesting to expose response writers 
dynamically with a plugin-style interface. Or add a Function to the response 
object that can dictate the writer to be used (optionally). Either way, I think 
this is separate enough from metrics, and useful in other places, that it 
should be pursued in a separate issue. 

3. Dropwizard Exports - yes, there is not feature parity with default solr 
metrics, but is it required for an initial patch? To me it seems like a lot of 
work that isn't required on day one. But I agree it should be added at some 
point. 

I propose that we tackle #2 and #1.b for the initial patch. And circle back to 
#3 and #1.a if we find it necessary.

> Expose Metrics in Prometheus format
> ---
>
> Key: SOLR-10654
> URL: https://issues.apache.org/jira/browse/SOLR-10654
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Keith Laban
>
> Expose metrics via a `wt=prometheus` response type.
> Example scape_config in prometheus.yml:
> {code}
> scrape_configs:
>   - job_name: 'solr'
> metrics_path: '/solr/admin/metrics'
> params:
>   wt: ["prometheus"]
> static_configs:
>   - targets: ['localhost:8983']
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7823) Have a naive bayes classifier which uses plain BM25 scores instead of plain frequencies

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili commented on LUCENE-7823:
-

checked in {{BM25NBClassifier}} implementation; when compared with 
{{SimpleNaiveBayesClassifier}}, it gives a 0.06 improvement in f1 over 20 
newsgroups dataset.

> Have a naive bayes classifier which uses plain BM25 scores instead of plain 
> frequencies
> ---
>
> Key: LUCENE-7823
> URL: https://issues.apache.org/jira/browse/LUCENE-7823
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: master (7.0)
>
>
> {{SimpleNaiveBayesClassifier}} users term frequencies with add one smoothing 
> to calculate likelihood and just tf for prior. Given Lucene has switched to 
> BM25 it would be better to have a different impl which uses BM25 
> scoring as a probability measure of both prior and likelihood.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7823) Have a naive bayes classifier which uses plain BM25 scores instead of plain frequencies

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7823:
-

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

LUCENE-7823 - added bm25 nb classifier


> Have a naive bayes classifier which uses plain BM25 scores instead of plain 
> frequencies
> ---
>
> Key: LUCENE-7823
> URL: https://issues.apache.org/jira/browse/LUCENE-7823
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/classification
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: master (7.0)
>
>
> {{SimpleNaiveBayesClassifier}} users term frequencies with add one smoothing 
> to calculate likelihood and just tf for prior. Given Lucene has switched to 
> BM25 it would be better to have a different impl which uses BM25 
> scoring as a probability measure of both prior and likelihood.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7823) Have a naive bayes classifier which uses plain BM25 scores instead of plain frequencies

[Tommaso Teofili (JIRA)]

Tommaso Teofili created LUCENE-7823:
---

 Summary: Have a naive bayes classifier which uses plain BM25 
scores instead of plain frequencies
 Key: LUCENE-7823
 URL: https://issues.apache.org/jira/browse/LUCENE-7823
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/classification
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: master (7.0)


{{SimpleNaiveBayesClassifier}} users term frequencies with add one smoothing to 
calculate likelihood and just tf for prior. Given Lucene has switched to BM25 
it would be better to have a different impl which uses BM25 
scoring as a probability measure of both prior and likelihood.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10617:
---

Because the JdbcStream in now part of the Parallel SQL structure, does it make 
sense to wrap this ticket into a bigger piece of work that is coming around 
expanding SQL and JDBC functionality. Here is what's on the table:

1) Hooking in the Avatica Jdbc driver SOLR-9963.
2) Expanding the general functionality of Parallel SQL. No ticket yet but this 
will be a big push in the coming months.
3) The addition of the sql Streaming Expression SOLR-10623.

Or we could create a separate internal JdbcStream just for the Calcite 
integration in case we need to do something Calcite specific. Then we can 
continue to make progress on the JdbcStream to external sources.




> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7817) LRUQueryCache.onQueryCache is always called with null as first parameter

[Christoph Kaser (JIRA)]

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

Christoph Kaser commented on LUCENE-7817:
-

Perfect, thank you! :)

> LRUQueryCache.onQueryCache is always called with null as first parameter
> 
>
> Key: LUCENE-7817
> URL: https://issues.apache.org/jira/browse/LUCENE-7817
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0), 6.4.1, 6.5.1
>Reporter: Christoph Kaser
> Fix For: master (7.0), 6.6
>
>
> According to the javadocs, LRUQueryCache.onQueryCache can be used to track 
> usage statistics on cached queries. Unfortunately, due to a bug, the query 
> parameter is always passed as null, making the method practically useless.
> This PR fixes the problem:
> https://github.com/apache/lucene-solr/pull/199



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10617:
---

The JdbcStream is also used as part of the Apache Calcite integration. As part 
of that work there was some code added to support Arrays. We have some time 
before the 7.0 release,  so I think it makes sense to take a little time and 
review how the JdbcStream is hooked into Calcite.

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10451) remove (almost) empty contrib/ltr folder from Solr binary release

[Grant Ingersoll (JIRA)]

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

Grant Ingersoll commented on SOLR-10451:


Was just looking at and created SOLR-10667.  I think we should ship the 
examples.  I was surprised they weren't there when I built the package and thus 
none of the LTR docs really applied.

> remove (almost) empty contrib/ltr folder from Solr binary release
> -
>
> Key: SOLR-10451
> URL: https://issues.apache.org/jira/browse/SOLR-10451
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10451.patch
>
>
> As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the 
> {{contrib/ltr/lib}} folder.
> So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr 
> binary release (it currently contains just a boilerplate {{README.txt}} file).
> The {{ regex=".*\.jar" />}} line in 
> https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml
>  can also be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10451) remove (almost) empty contrib/ltr folder from Solr binary release

[Grant Ingersoll (JIRA)]

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

Grant Ingersoll edited comment on SOLR-10451 at 5/11/17 2:06 PM:
-

Was just looking at and created SOLR-10667.  I think we should ship the 
examples which I think means keeping this folder.  I was surprised they weren't 
there when I built the package and thus none of the LTR docs really applied.


was (Author: gsingers):
Was just looking at and created SOLR-10667.  I think we should ship the 
examples.  I was surprised they weren't there when I built the package and thus 
none of the LTR docs really applied.

> remove (almost) empty contrib/ltr folder from Solr binary release
> -
>
> Key: SOLR-10451
> URL: https://issues.apache.org/jira/browse/SOLR-10451
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10451.patch
>
>
> As [~varunthacker] mentioned in SOLR-8542 there are actually no jars in the 
> {{contrib/ltr/lib}} folder.
> So to avoid confusion, let's remove the {{contrib/ltr}} folder from the Solr 
> binary release (it currently contains just a boilerplate {{README.txt}} file).
> The {{ regex=".*\.jar" />}} line in 
> https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/sample_techproducts_configs/conf/solrconfig.xml
>  can also be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (LUCENE-7817) LRUQueryCache.onQueryCache is always called with null as first parameter

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7817.
--
   Resolution: Fixed
Fix Version/s: 6.6
   master (7.0)

> LRUQueryCache.onQueryCache is always called with null as first parameter
> 
>
> Key: LUCENE-7817
> URL: https://issues.apache.org/jira/browse/LUCENE-7817
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0), 6.4.1, 6.5.1
>Reporter: Christoph Kaser
> Fix For: master (7.0), 6.6
>
>
> According to the javadocs, LRUQueryCache.onQueryCache can be used to track 
> usage statistics on cached queries. Unfortunately, due to a bug, the query 
> parameter is always passed as null, making the method practically useless.
> This PR fixes the problem:
> https://github.com/apache/lucene-solr/pull/199



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7817) LRUQueryCache.onQueryCache is always called with null as first parameter

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7817:
--

Sorry, I have been busy with other things over the last few days. I just merged 
your patch, thank you! It should be included in the upcoming 6.6 release. We'll 
soon start the release process so it should be a matter of a week or two before 
it is available.

> LRUQueryCache.onQueryCache is always called with null as first parameter
> 
>
> Key: LUCENE-7817
> URL: https://issues.apache.org/jira/browse/LUCENE-7817
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0), 6.4.1, 6.5.1
>Reporter: Christoph Kaser
>
> According to the javadocs, LRUQueryCache.onQueryCache can be used to track 
> usage statistics on cached queries. Unfortunately, due to a bug, the query 
> parameter is always passed as null, making the method practically useless.
> This PR fixes the problem:
> https://github.com/apache/lucene-solr/pull/199



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Release 6.6

[Adrien Grand]

Ishan, wdyt about running addVersion on the branch_6x/master as well? I
think it would help realize that the 6.6 branch has been cut when looking
at the CHANGES.txt file and not forget about backporting?

Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya 
a écrit :

> I've cut the branch for 6.6. (branch_6_6). Please feel free to add
> bugfixes to the branch, if needed.
> Planning to build the first RC on 15 May. Please let me know if there are
> any objections.
>
> Thanks,
> Ishan
>
> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Planning to cut the release branch in another 10-12 hours.
>>
>> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty 
>> wrote:
>>
>>> i was wondering if there was a specific test for SpanPayloadCheckQuery
>>> method
>>>
>>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>
>>>
>>> the only implementation i could locate was in collectLeaf of
>>> SpanPayloadCheckQuery
>>>
>>>
>>> I will submit JIRA with Patch
>>>
>>>
>>> as a CS *dinosaur* I am more familiar with LISP for dissecting sentence
>>> fragments (what we called phenomes) than current SEO implementations
>>>
>>>
>>> Can you suggest a book to read to better understand Lucenes pattern
>>> dissection and match algorithms?
>>>
>>>
>>> Many Thanks for helpful guidance
>>> Martin
>>> __
>>>
>>>
>>>
>>>
>>> --
>>> *From:* Erik Hatcher 
>>> *Sent:* Sunday, April 30, 2017 2:06 PM
>>>
>>> *To:* dev@lucene.apache.org
>>> *Subject:* Re: Release 6.6
>>>
>>> Martin -
>>>
>>> I have to admit to still being unsure what the gist is here - is there a
>>> bug?   Apologies for not catching what you’re saying/showing here.  Again,
>>> as far as I can tell SpanPayloadCheckQuery is working as expected now.
>>>
>>> I’m going to focus purely on SOLR-1485 this week to get it committed for
>>> 6.6.  If there is an issue to address with your work would you please open
>>> a JIRA and include your patch there?
>>>
>>> Thanks,
>>> Erik
>>>
>>>
>>> On Apr 30, 2017, at 7:47 AM, Martin Gainty  wrote:
>>>
>>> Mornin' Erik
>>>
>>> there is a collectLeaf  override in 
>>> org.apache.lucene.queries.payloads.TestPayloadSpans
>>> ..but its never called:
>>>
>>> static class VerifyingCollector implements SpanCollector {
>>> List payloads = new ArrayList<>();
>>> @Override
>>> public void collectLeaf(PostingsEnum postings, int position, Term
>>> term) throws IOException {
>>>  
>>>  }
>>> }
>>>
>>>
>>> the modification in
>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests collectLeaf
>>> for query
>>>
>>> //initialise term
>>>
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before
>>> term1=new org.apache.lucene.index.Term('field','withPayload')");
>>> org.apache.lucene.index.Term term1=new
>>> org.apache.lucene.index.Term("field", "withPayload");
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>> term1="+term1);
>>>
>>> //assume position is 5
>>> int position=5;
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>>> position="+position);
>>>
>>> BytesRef pay = new BytesRef("pos: " + position);
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>>> pay="+pay);
>>>
>>> //build spanQuery with term parameter
>>> org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>> SpanTermQuery(term1);
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>>> spanQuery1="+spanQuery1);
>>>
>>> //add BytesRef to payloadToMatch list
>>> java.util.List payloadToMatch=new
>>> java.util.ArrayList();
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>>> payloadToMatch="+payloadToMatch);
>>> payloadToMatch.add(pay);
>>>
>>> //build SpanPayloadCheckQuery
>>>
>>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>> (org.apache.lucene.search.spans.SpanQuery)query,
>>> (java.util.List)payloadToMatch);
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>> query="+query);
>>>
>>> //build lucene Directory (TODO: we should use an existing directory with
>>> REAL test-data)
>>> org.apache.lucene.store.Directory ram =
>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());
>>>
>>> //build SegmentReader from Directory
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>> ram="+ram);
>>> SegmentReader reader =
>>> getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>> reader="+reader);
>>>
>>> //populate SlowCompositeReaderWrapper with SegmentReader
>>> org.apache.lucene.index.LeafReader sr =
>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>> 

[GitHub] lucene-solr pull request #199: pass cached query to onQueryCache instead of ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/lucene-solr/pull/199


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (LUCENE-7817) LRUQueryCache.onQueryCache is always called with null as first parameter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7817:
-

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

LUCENE-7817: pass cached query to onQueryCache instead of null

Closes #199


> LRUQueryCache.onQueryCache is always called with null as first parameter
> 
>
> Key: LUCENE-7817
> URL: https://issues.apache.org/jira/browse/LUCENE-7817
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0), 6.4.1, 6.5.1
>Reporter: Christoph Kaser
>
> According to the javadocs, LRUQueryCache.onQueryCache can be used to track 
> usage statistics on cached queries. Unfortunately, due to a bug, the query 
> parameter is always passed as null, making the method practically useless.
> This PR fixes the problem:
> https://github.com/apache/lucene-solr/pull/199



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7817) LRUQueryCache.onQueryCache is always called with null as first parameter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7817:
-

Commit 506485c4403bce29cc06272f3341c6afc2f1d479 in lucene-solr's branch 
refs/heads/branch_6_6 from ChristophKaser
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=506485c ]

LUCENE-7817: pass cached query to onQueryCache instead of null

Closes #199


> LRUQueryCache.onQueryCache is always called with null as first parameter
> 
>
> Key: LUCENE-7817
> URL: https://issues.apache.org/jira/browse/LUCENE-7817
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0), 6.4.1, 6.5.1
>Reporter: Christoph Kaser
>
> According to the javadocs, LRUQueryCache.onQueryCache can be used to track 
> usage statistics on cached queries. Unfortunately, due to a bug, the query 
> parameter is always passed as null, making the method practically useless.
> This PR fixes the problem:
> https://github.com/apache/lucene-solr/pull/199



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7817) LRUQueryCache.onQueryCache is always called with null as first parameter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7817:
-

Commit 4465e265d90f701f61f9e2cc8eb303a4515c4764 in lucene-solr's branch 
refs/heads/branch_6x from ChristophKaser
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4465e26 ]

LUCENE-7817: pass cached query to onQueryCache instead of null

Closes #199


> LRUQueryCache.onQueryCache is always called with null as first parameter
> 
>
> Key: LUCENE-7817
> URL: https://issues.apache.org/jira/browse/LUCENE-7817
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0), 6.4.1, 6.5.1
>Reporter: Christoph Kaser
>
> According to the javadocs, LRUQueryCache.onQueryCache can be used to track 
> usage statistics on cached queries. Unfortunately, due to a bug, the query 
> parameter is always passed as null, making the method practically useless.
> This PR fixes the problem:
> https://github.com/apache/lucene-solr/pull/199



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test

Error Message:
Time allowed to handle this request exceeded

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Time allowed to handle this 
request exceeded
at 
__randomizedtesting.SeedInfo.seed([C60C68B599ECC0B1:4E58576F3710AD49]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:424)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1383)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.assertPartialResults(CloudExitableDirectoryReaderTest.java:106)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTimeoutTests(CloudExitableDirectoryReaderTest.java:78)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test(CloudExitableDirectoryReaderTest.java:56)
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:563)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Commented] (LUCENE-7822) IllegalArgumentException thrown instead of a CorruptIndexException

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7822:
--

For such a small file, maybe we should call eg. 
{{CodecUtil.checksumEntireFile}} before starting to read it. This would give a 
clearer error message?

> IllegalArgumentException thrown instead of a CorruptIndexException
> --
>
> Key: LUCENE-7822
> URL: https://issues.apache.org/jira/browse/LUCENE-7822
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.5.1
>Reporter: Martin Amirault
>Priority: Minor
>
> Similarly to LUCENE-7592 , When an {{*.si}} file is corrupted on very 
> specific part an IllegalArgumentException is thrown instead of a 
> CorruptIndexException.
> StackTrace (Lucene 6.5.1):
> {code}
> java.lang.IllegalArgumentException: Illegal minor version: 12517381
>   at 
> __randomizedtesting.SeedInfo.seed([1FEB5987CFA44BE:B8755B5574F9F3BF]:0)
>   at org.apache.lucene.util.Version.(Version.java:385)
>   at org.apache.lucene.util.Version.(Version.java:371)
>   at org.apache.lucene.util.Version.fromBits(Version.java:353)
>   at 
> org.apache.lucene.codecs.lucene62.Lucene62SegmentInfoFormat.read(Lucene62SegmentInfoFormat.java:97)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:357)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:288)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:448)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:445)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:692)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:644)
>   at 
> org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:450)
>   at 
> org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:260)
> {code}
> Simple fix would be to add IllegalArgumentException to the catch list at 
> {{org/apache/lucene/index/SegmentInfos.java:289}}
> Other variations for the stacktraces:
> {code}
> java.lang.IllegalArgumentException: invalid codec filename '_�.cfs', must 
> match: _[a-z0-9]+(_.*)?\..*
>   at 
> __randomizedtesting.SeedInfo.seed([8B3FDE317B8D634A:A8EE07E5EB4B0B13]:0)
>   at 
> org.apache.lucene.index.SegmentInfo.checkFileNames(SegmentInfo.java:270)
>   at org.apache.lucene.index.SegmentInfo.addFiles(SegmentInfo.java:252)
>   at org.apache.lucene.index.SegmentInfo.setFiles(SegmentInfo.java:246)
>   at 
> org.apache.lucene.codecs.lucene62.Lucene62SegmentInfoFormat.read(Lucene62SegmentInfoFormat.java:248)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:357)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:288)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:448)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:445)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:692)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:644)
>   at 
> org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:450)
>   at 
> org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:260)
> {code}
> {code}
> java.lang.IllegalArgumentException: An SPI class of type 
> org.apache.lucene.codecs.Codec with name 'LucenI62' does not exist.  You need 
> to add the corresponding JAR file supporting this SPI to your classpath.  The 
> current classpath supports the following names: [Lucene62, Lucene50, 
> Lucene53, Lucene54, Lucene60]
>   at 
> __randomizedtesting.SeedInfo.seed([925DE160F7260F99:B026EB9373CB6368]:0)
>   at org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:116)
>   at org.apache.lucene.codecs.Codec.forName(Codec.java:116)
>   at org.apache.lucene.index.SegmentInfos.readCodec(SegmentInfos.java:424)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:356)
>   at 
> org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:288)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:448)
>   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:445)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:692)
>   at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:644)
>   at 
> org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:450)
>   at 
> org.apache.lucene.index.DirectoryReader.listCommits(DirectoryReader.java:260)
> {code}



--
This 

[jira] [Created] (SOLR-10673) [subquery] sort by geodist

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created SOLR-10673:
---

 Summary: [subquery] sort by geodist
 Key: SOLR-10673
 URL: https://issues.apache.org/jira/browse/SOLR-10673
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mikhail Khludnev


reported 
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201705.mbox/%3ca64be8fa-b011-44c6-9f81-023a90dfc...@posteo.de%3E
 
still not really clear. Test cases and patches are welcome. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6559/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Unexpected number of elements in the group for intGSF: 5

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 5
at 
__randomizedtesting.SeedInfo.seed([E2EA4330C3C5DDF9:79512D688E9DEFA7]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:376)
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 11568 lines...]
   [junit4] Suite: org.apache.solr.cloud.DocValuesNotIndexedTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-10670) [ref-guide] Various top-bar fixes

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10670:
--

+1 to adding the favicon, I was going to get to that before release.

The other link changes are fine with me if folks think they are preferable. Go 
for it, as we say :)

As for the title...The html file is built after {{BuildNavandPDFBody.java}} is 
run. That script develops the data files to populate the sidenav and also the 
file that is used to make a single page for PDF generation. I think it would be 
too much "magic" to have a script that overwrites the title of any page. Say 
someday in the future we decide to change the page, who's going to remember 
exactly why we have a file named {{index.adoc}} that declares it's title as 
"Apache Solr Reference Guide" but appears online as "Home"? I'd like to 
minimize the # of leaps people need to make in order to figure out what's going 
on, where possible. And some of us don't know Java so can't just hop into Java 
files to figure out why certain things are happening.

If what you prefer is that it appear something like {{Home | Apache Solr 
Reference Guide 7.0}}, then I think it would be best just to make the page 
title in {{index.adoc}} "Home". However, that means the PDF would have a page 
named "Home" for the first page, which doesn't feel right to me. 

Unless we can come up with a page name that is short, descriptive for 
bookmarks, and works in both formats, there is a possible other option, that I 
have not tried yet, which is to add an {{ifdef}} statement that changes the 
title for the PDF. That would evaluate if the page is being generated for the 
PDF version, and if so, apply a different title. That would go in 
{{index.adoc}} so anyone looking at it will see why we are doing that (we can 
add a comment to explain). I will give this a try now to see if that solves it 
for us.

> [ref-guide] Various top-bar fixes
> -
>
> Key: SOLR-10670
> URL: https://issues.apache.org/jira/browse/SOLR-10670
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Jan Høydahl
>  Labels: asciidoc, html
> Fix For: 6.6
>
> Attachments: SOLR-10670.patch
>
>
> A few suggestions for the new ref-guide HTML format:
> * Favicon is not displayed, image missing in folder
> * Topnav link to community should point to 
> http://lucene.apache.org/solr/community.html
> * Replace "Solr News" link with a "Solr Website" link - we should link to the 
> website
> * Instead of pointint the Source Code link to cryptic apache GIT, point to 
> https://lucene.apache.org/solr/community.html#version-control where people 
> get more context and can also find the GitHub link



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10672) Full Import for an entity is not importing anything

[Torsten Faltinat (JIRA)]

Torsten Faltinat created SOLR-10672:
---

 Summary: Full Import for an entity is not importing anything
 Key: SOLR-10672
 URL: https://issues.apache.org/jira/browse/SOLR-10672
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - DataImportHandler
Affects Versions: 6.4.1
Reporter: Torsten Faltinat


Hi,

we are using a DIH via JDBC to index documents out of our database. Due to our 
design, this full import is/can be executed entity per entity. We are using a 
http request out of .Net client to execute these imports.

If we execute requests (multiple full imports) very fast, Solr accepts the 
request but the import is not executed. In such a case the following log entry 
is visible:

2017-05-11 13:28:10.317 INFO  (qtp1654589030-16) [   x:iET] o.a.s.c.S.Request 
[iET]  webapp=/solr path=/dataimport 
params={connectionString=jdbc:sqlserver://...=false=sa=2.2=full-import=ts2_it_change_text_search}
 status=0 QTime=0

That's all for this entity. We stumbled over this entry because the QTime=0.

Whereas a successfull import produces entries like this:

2017-05-11 13:28:10.298 INFO  (qtp1654589030-14) [   x:iET] o.a.s.c.S.Request 
[iET]  webapp=/solr path=/dataimport 
params={connectionString=jdbc:sqlserver://...=false=sa=2.2=full-import=ts1_it_change_text_search}
 status=0 QTime=15
...
2017-05-11 13:28:10.339 INFO  (Thread-16) [   x:iET] o.a.s.h.d.JdbcDataSource 
Creating a connection for entity ts1_it_change_text_search with URL: 
jdbc:sqlserver://...
...
2017-05-11 13:28:10.715 INFO  (Thread-16) [   x:iET] 
o.a.s.u.p.LogUpdateProcessorFactory [iET]  webapp=/solr path=/dataimport 
params={connectionString=jdbc:sqlserver://...=false=sa=2.2=full-import=ts1_it_change_text_search}
 status=0 QTime=15{add=[82628015d12ac6be (1567106573943177216), 
3f314c79dd29634f (1567106573948420096), 37e6a5139ac7640d (1567106573950517248), 
6b44fa32c4aee1b4 (1567106573952614400), f5695f69c3aac089 (1567106573954711552), 
7a34e505265071ce (1567106573956808704), b2729ff2de7d3b8e (1567106573958905856), 
b92b779c74481ef0 (1567106573963100160), 5d42a3619ddc50fd (1567106573967294464), 
9793b2036f2491db (1567106573969391616), ... (12 adds)],commit=} 0 433

If we wait some ms between each request, everything works fine. From our 
perspective it looks like an issue. Or do you have any idea what we are doing 
wrong?

Thx
Torsten



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10617) JDBCStream: support more data types

[James Dyer (JIRA)]

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

James Dyer commented on SOLR-10617:
---

bq.  The idea here is that an object array would be placed in the Tuple under 
the field name.

How about type conversion?  In this class we're going to pains to convert all 
the sql types to the 4 supported tuple types?  Wouldn't the elements of the 
Array be subject to type conversion also?  My concern here is the Array 
functionality might not work as intended.  I do not see where it is documented 
or tested.

> JDBCStream: support more data types
> ---
>
> Key: SOLR-10617
> URL: https://issues.apache.org/jira/browse/SOLR-10617
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch
>
>
> It would be nice if JDBCStream could support Decimal types as well as 
> Timestamp-related types, and CLOBs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+168) - Build # 19608 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19608/
Java: 64bit/jdk-9-ea+168 -XX:+UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([C82748D2E7362A57:72F527AA6418C442]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:898)
at 
org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:373)
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:563)
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 
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.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=0]
xml response was: 

00500500500500muLti-Default422017-05-11T12:05:52.986Z156710139643664793642


request was:q=id:500=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:891)
... 39 more


FAILED:  

[jira] [Updated] (SOLR-10671) tweak SolrMetricReporter implementations' init/validate/start logic

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-10671:
---
Attachment: SOLR-10671.patch

Attaching patch with proposed changes. Yet to run all the tests.

> tweak SolrMetricReporter implementations' init/validate/start logic
> ---
>
> Key: SOLR-10671
> URL: https://issues.apache.org/jira/browse/SOLR-10671
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10671.patch
>
>
> This ticket proposes to
> * leave SolrJmxReporter unchanged
> * turn Solr(Cluster|Shard)Reporter.validate into 
> Solr(Cluster|Shard)Reporter.init
> * factor out Solr(Ganglia|Graphite|Slf4j)Reporter.init from 
> Solr(Ganglia|Graphite|Slf4j)Reporter.validate
> Motivation and Intention:
> * Consistency w.r.t. what logic SolrMetricReport implementations should place 
> in which method.
> * Even reporters that are not enabled to pass the validate() check.
> * The validate() method to have no (init-ialising) side effects.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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