[jira] [Commented] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-7534:
--

cygwin's find messed windows' find up

> smokeTestRelease.py on cygwin [Errno 2] No such file or directory: 
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
>  Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1440, in 
> main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
>   File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
>   File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' % 
> java_home).read().decode('utf-8').strip()
>   File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
>   File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u 
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and 
> args should be either supplied as array of terms or supplied as {{shell=True}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18207/
Java: 64bit/jdk-9-ea+140 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.handler.component.SpellCheckComponentTest.testNumericQuery

Error Message:
List size mismatch @ spellcheck/suggestions

Stack Trace:
java.lang.RuntimeException: List size mismatch @ spellcheck/suggestions
at 
__randomizedtesting.SeedInfo.seed([A4795526442DA537:AF5502E6DBE41998]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:900)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:847)
at 
org.apache.solr.handler.component.SpellCheckComponentTest.testNumericQuery(SpellCheckComponentTest.java:154)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)




Build Log:
[...truncated 11257 lines...]
   [junit4] Suite: 

[jira] [Commented] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-7534:
--

ok. I changed smokeTestRelease.py to invoke solr.cmd, the fail is following  
{quote}
$ ./solr/bin/solr.cmd stop -p 8983
find: ‘TCP ’: No such file or directory
find: ‘:8983 ’: No such file or directory
find: ‘:0 ’: No such file or directory
No Solr found running on port 8983
{quote}

> smokeTestRelease.py on cygwin [Errno 2] No such file or directory: 
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
>  Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1440, in 
> main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
>   File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
>   File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' % 
> java_home).read().decode('utf-8').strip()
>   File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
>   File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u 
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and 
> args should be either supplied as array of terms or supplied as {{shell=True}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: JMX monitoring of Solr<->Solr (and Solr<->Zookeeper?) errors.

[Otis Gospodnetić]

Hi,

Sematext SPM  monitors both Solr and ZK and should
be able to alert you if either of them have issues.  It doesn't
specifically watch for Solr<==>Solr or Solr<==>ZK errors, but I think
problems on either side would manifest as changes in metrics for which you
could set up either threshold-based or anomaly detection based alerts.

Furthermore, if you ship your logs to a log management solution like Logsene
, assuming Solr and/or ZK log errors about S-S
or S-ZK communication, you'll be able to pick those up and alert on them,
too.

In short, very much doable.

Otis
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training - http://sematext.com/


On Thu, Nov 3, 2016 at 5:32 PM, Erick Erickson 
wrote:

> I was recently involved in a conversation where the question was
> raised whether there were any stats exposed to JMX for monitoring
> Solr<->Solr errors and Solr<->Zookeeper errors. The scenario here is
> that you'd like to use some JMX-enabled tool to raise alerts when
> connections between Solr nodes went wonky and/or you started seeing
> errors in reading from ZK etc.
>
> Before diving in I thought I'd ask if there's any "prior art" here. Or
> if anyone's thought along these lines before.
>
> The current stats and JMX stuff in Solr is pretty core-specific, which
> made me uncertain about piggy-backing on, say, the current
> SolrInfoMBean capabilities. This seems like it's more an admin
> function or perhaps something new specified at the solr.xml level.
>
> Erick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-9725) Allow Variables for All Data Import Handler Data Source Configuration Values

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9725:


Hello,

can we have a test for it?

> Allow Variables for All Data Import Handler Data Source Configuration Values
> 
>
> Key: SOLR-9725
> URL: https://issues.apache.org/jira/browse/SOLR-9725
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Affects Versions: 5.5.3
>Reporter: Jamie Jackson
>Priority: Minor
>  Labels: patch
>
> I need to be able to use a variable for a password when also using 
> {{encryptKeyFile}}.
> For instance:
> {code:xml}
>  driver="${custom.dataimporter.datasource.driver}"
>   url="${custom.dataimporter.datasource.url}"
>   user="${custom.dataimporter.datasource.user}"
>   password="${custom.dataimporter.datasource.password}"
>   encryptKeyFile="/opt/solr/credentials/encrypt.key"
>   />
> {code}
> Because I need to change certain variables based on the environment. I'd 
> start like this:
> {code}
>  -a
>   -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
>   
> -Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
>   -Dcustom.dataimporter.datasource.user=root
>   
> -Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
> {code}
> If I hardcode the password, it works; if I use a variable reference, it 
> doesn't.
> As far as I know [this pull 
> request|https://github.com/apache/lucene-solr/pull/46] was submitted to 
> address this issue, but it didn't come with a Jira ticket or a full 
> explanation.
> Also, note that I'm not using a variable for the value of {{encryptKeyFile}}, 
> because [it's not possible in 5.x, though it seems to be fixed in 
> 6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above 
> patch would encompass {{encryptKeyFile}}'s value, as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9360) Solr script not properly checking SOLR_PID

[Erick Erickson (JIRA)]

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

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

I think this does it, I'll check it in probably tomorrow unless people object.

> Solr script not properly checking SOLR_PID
> --
>
> Key: SOLR-9360
> URL: https://issues.apache.org/jira/browse/SOLR-9360
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Alessandro Benedetti
>Assignee: Erick Erickson
> Attachments: SOLR-9360.patch, SOLR_9360.patch
>
>
> In the solr script we see in 3-4 areas  this check :
> SOLR_PID=`ps auxww | grep start\.jar | grep -w $SOLR_PORT | grep -v grep | 
> awk '{print $2}' | sort -r`
> This can potentially prevent a solr instance to start in the case another 
> process by any chance contains the port int the command itself ( not 
> necessarily actually using the port) .
> e.g.
> java -server -Djetty.port=10504 -DSTOP.PORT=9504 -DSTOP.KEY=solrrocks 
> -DMASTER_CORE_URL=external-server:10500/solr -jar start.jar --module=http
> A solr is running on 10504.
> A new Solr will not be able to start on 10500 ( but actually the port is 
> free).
> This should be replaced by a real check if the port is used ( like netstat or 
> similar) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9360) Solr script not properly checking SOLR_PID

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-9360 at 11/4/16 2:52 AM:
---

Oh, and the script _does_ use a pid file(s), this is a bit of extra logic using 
these patterns.



was (Author: erickerickson):
Oh, and the script _does_ use a pid file, these patterns are only examined as a 
fallback for stopping Solr and in the loop waiting up to 30 seconds to see solr 
loop. You wouldn't want to use the pid file there anyway as it might just be a 
leftover.

FWIW.

> Solr script not properly checking SOLR_PID
> --
>
> Key: SOLR-9360
> URL: https://issues.apache.org/jira/browse/SOLR-9360
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Alessandro Benedetti
>Assignee: Erick Erickson
> Attachments: SOLR_9360.patch
>
>
> In the solr script we see in 3-4 areas  this check :
> SOLR_PID=`ps auxww | grep start\.jar | grep -w $SOLR_PORT | grep -v grep | 
> awk '{print $2}' | sort -r`
> This can potentially prevent a solr instance to start in the case another 
> process by any chance contains the port int the command itself ( not 
> necessarily actually using the port) .
> e.g.
> java -server -Djetty.port=10504 -DSTOP.PORT=9504 -DSTOP.KEY=solrrocks 
> -DMASTER_CORE_URL=external-server:10500/solr -jar start.jar --module=http
> A solr is running on 10504.
> A new Solr will not be able to start on 10500 ( but actually the port is 
> free).
> This should be replaced by a real check if the port is used ( like netstat or 
> similar) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9716) RecoveryStrategy send prep recovery cmd without setting request time out

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-9716:
---
Attachment: SOLR-9716.patch

Updated patch, modified TestInjection.injectPrepRecoveryOpPauseForever() to 
make sure that it won't continuous pause all the times. If not, the test will 
be failed some time because of timeout waiting for the collection to be active.

> RecoveryStrategy send prep recovery cmd without setting request time out
> 
>
> Key: SOLR-9716
> URL: https://issues.apache.org/jira/browse/SOLR-9716
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-9716.patch, SOLR-9716.patch, SOLR-9716.patch, 
> SOLR-9716.patch
>
>
> Currently, RecoveryStrategy sends prep recovery cmd without setting request 
> time out. But this can be long running request, so if we have network 
> partition in the middle of the request. Recovering core will stay down 
> forever.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_102) - Build # 18206 - Still Failing!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 65876 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1157626820
 [ecj-lint] Compiling 306 source files to /tmp/ecj1157626820
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java
 (at line 879)
 [ecj-lint] new LBHttpSolrClient(httpSolrClientBuilder, httpClient, 
solrServerUrls) :
 [ecj-lint] 
^^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/solrj/src/java/org/apache/solr/client/solrj/io/Tuple.java
 (at line 25)
 [ecj-lint] import java.util.function.BiConsumer;
 [ecj-lint]^
 [ecj-lint] The import java.util.function.BiConsumer is never used
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/solrj/src/java/org/apache/solr/client/solrj/io/Tuple.java
 (at line 28)
 [ecj-lint] import org.apache.solr.common.SolrDocument;
 [ecj-lint]^^^
 [ecj-lint] The import org.apache.solr.common.SolrDocument is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/Explanation.java
 (at line 20)
 [ecj-lint] import java.util.HashMap;
 [ecj-lint]^
 [ecj-lint] The import java.util.HashMap is never used
 [ecj-lint] --
 [ecj-lint] 4 problems (3 errors, 1 warning)

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:765: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:101: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build.xml:671: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/solrj/build.xml:67: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2031: 
Compile failed; see the compiler error output for details.

Total time: 77 minutes 50 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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_102) - Build # 2103 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2103/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 64523 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj761107448
 [ecj-lint] Compiling 305 source files to /tmp/ecj761107448
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java
 (at line 855)
 [ecj-lint] new LBHttpSolrClient(httpSolrClientBuilder, httpClient, 
solrServerUrls) :
 [ecj-lint] 
^^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/solrj/src/java/org/apache/solr/client/solrj/io/Tuple.java
 (at line 25)
 [ecj-lint] import java.util.function.BiConsumer;
 [ecj-lint]^
 [ecj-lint] The import java.util.function.BiConsumer is never used
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/solrj/src/java/org/apache/solr/client/solrj/io/Tuple.java
 (at line 28)
 [ecj-lint] import org.apache.solr.common.SolrDocument;
 [ecj-lint]^^^
 [ecj-lint] The import org.apache.solr.common.SolrDocument is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/Explanation.java
 (at line 20)
 [ecj-lint] import java.util.HashMap;
 [ecj-lint]^
 [ecj-lint] The import java.util.HashMap is never used
 [ecj-lint] --
 [ecj-lint] 4 problems (3 errors, 1 warning)

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:765: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:101: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build.xml:671: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/solrj/build.xml:67: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:2031: 
Compile failed; see the compiler error output for details.

Total time: 76 minutes 57 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] [Commented] (SOLR-9360) Solr script not properly checking SOLR_PID

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9360:
--

Oh, and the script _does_ use a pid file, these patterns are only examined as a 
fallback for stopping Solr and in the loop waiting up to 30 seconds to see solr 
loop. You wouldn't want to use the pid file there anyway as it might just be a 
leftover.

FWIW.

> Solr script not properly checking SOLR_PID
> --
>
> Key: SOLR-9360
> URL: https://issues.apache.org/jira/browse/SOLR-9360
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Alessandro Benedetti
>Assignee: Erick Erickson
> Attachments: SOLR_9360.patch
>
>
> In the solr script we see in 3-4 areas  this check :
> SOLR_PID=`ps auxww | grep start\.jar | grep -w $SOLR_PORT | grep -v grep | 
> awk '{print $2}' | sort -r`
> This can potentially prevent a solr instance to start in the case another 
> process by any chance contains the port int the command itself ( not 
> necessarily actually using the port) .
> e.g.
> java -server -Djetty.port=10504 -DSTOP.PORT=9504 -DSTOP.KEY=solrrocks 
> -DMASTER_CORE_URL=external-server:10500/solr -jar start.jar --module=http
> A solr is running on 10504.
> A new Solr will not be able to start on 10500 ( but actually the port is 
> free).
> This should be replaced by a real check if the port is used ( like netstat or 
> similar) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9360) Solr script not properly checking SOLR_PID

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9360:
--

OK, the grep -w option does match whole words only, so this works.

-D is a flag for grep (how universal I'm not sure) and at least one other place 
greps (incorrectly) just for jetty.port rather than jetty\.port so I'll just 
use the jetty\.port=$WOLR_PORT version

There's a couple of greps for "solr.solr.home" as well that I'll fix on the way 
by.

I took a brief look at the windows script and it uses another mechanism, so I'm 
not going to touch that one especially as I have no way to test it.

> Solr script not properly checking SOLR_PID
> --
>
> Key: SOLR-9360
> URL: https://issues.apache.org/jira/browse/SOLR-9360
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Alessandro Benedetti
>Assignee: Erick Erickson
> Attachments: SOLR_9360.patch
>
>
> In the solr script we see in 3-4 areas  this check :
> SOLR_PID=`ps auxww | grep start\.jar | grep -w $SOLR_PORT | grep -v grep | 
> awk '{print $2}' | sort -r`
> This can potentially prevent a solr instance to start in the case another 
> process by any chance contains the port int the command itself ( not 
> necessarily actually using the port) .
> e.g.
> java -server -Djetty.port=10504 -DSTOP.PORT=9504 -DSTOP.KEY=solrrocks 
> -DMASTER_CORE_URL=external-server:10500/solr -jar start.jar --module=http
> A solr is running on 10504.
> A new Solr will not be able to start on 10500 ( but actually the port is 
> free).
> This should be replaced by a real check if the port is used ( like netstat or 
> similar) .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_102) - Build # 2102 - Failure!

[Joel Bernstein]

Pushing a fix for this.

Joel Bernstein
http://joelsolr.blogspot.com/

On Thu, Nov 3, 2016 at 4:06 PM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2102/
> Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseSerialGC
>
> All tests passed
>
> Build Log:
> [...truncated 65912 lines...]
> -ecj-javadoc-lint-src:
> [mkdir] Created dir: /tmp/ecj2024499890
>  [ecj-lint] Compiling 992 source files to /tmp/ecj2024499890
>  [ecj-lint] invalid Class-Path header in manifest of jar file:
> /home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/
> org.restlet-2.3.0.jar
>  [ecj-lint] invalid Class-Path header in manifest of jar file:
> /home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.
> servlet/jars/org.restlet.ext.servlet-2.3.0.jar
>  [ecj-lint] --
>  [ecj-lint] 1. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/cloud/Assign.java
> (at line 101)
>  [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
>  [ecj-lint]^^^
>  [ecj-lint] (Recovered) Internal inconsistency detected during lambda
> shape analysis
>  [ecj-lint] --
>  [ecj-lint] 2. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/cloud/Assign.java
> (at line 101)
>  [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
>  [ecj-lint]^^^
>  [ecj-lint] (Recovered) Internal inconsistency detected during lambda
> shape analysis
>  [ecj-lint] --
>  [ecj-lint] 3. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/cloud/Assign.java
> (at line 101)
>  [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
>  [ecj-lint]^^^
>  [ecj-lint] (Recovered) Internal inconsistency detected during lambda
> shape analysis
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 4. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/
> cloud/rule/ReplicaAssigner.java (at line 216)
>  [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
>  [ecj-lint]   ^^^
>  [ecj-lint] (Recovered) Internal inconsistency detected during lambda
> shape analysis
>  [ecj-lint] --
>  [ecj-lint] 5. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/
> cloud/rule/ReplicaAssigner.java (at line 216)
>  [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
>  [ecj-lint]   ^^^
>  [ecj-lint] (Recovered) Internal inconsistency detected during lambda
> shape analysis
>  [ecj-lint] --
>  [ecj-lint] 6. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/
> cloud/rule/ReplicaAssigner.java (at line 216)
>  [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
>  [ecj-lint]   ^^^
>  [ecj-lint] (Recovered) Internal inconsistency detected during lambda
> shape analysis
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 7. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/core/HdfsDirectoryFactory.java
> (at line 227)
>  [ecj-lint] dir = new BlockDirectory(path, hdfsDir, cache, null,
> blockCacheReadEnabled, false, cacheMerges, cacheReadOnce);
>  [ecj-lint] ^^
> 
> 
>  [ecj-lint] Resource leak: 'dir' is never closed
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 8. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/handler/
> AnalysisRequestHandlerBase.java (at line 120)
>  [ecj-lint] reader = cfiltfac.create(reader);
>  [ecj-lint] 
>  [ecj-lint] Resource leak: 'reader' is not closed at this location
>  [ecj-lint] --
>  [ecj-lint] 9. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/handler/
> AnalysisRequestHandlerBase.java (at line 144)
>  [ecj-lint] return namedList;
>  [ecj-lint] ^
>  [ecj-lint] Resource leak: 'listBasedTokenStream' is not closed at this
> location
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 10. WARNING in /home/jenkins/workspace/
> Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/handler/ClassifyStream.java
> (at line 88)
>  [ecj-lint] SolrCore solrCore = (SolrCore) solrCoreObj;
>  [ecj-lint]  
>  [ecj-lint] Resource leak: 'solrCore' is never closed
>  [ecj-lint] --
>  [ecj-lint] --
>  [ecj-lint] 11. WARNING in /home/jenkins/workspace/
> 

[jira] [Created] (LUCENE-7538) Uploading large text file to a field causes "this IndexWriter is closed" error

[Steve Chen (JIRA)]

Steve Chen created LUCENE-7538:
--

 Summary: Uploading large text file to a field causes "this 
IndexWriter is closed" error
 Key: LUCENE-7538
 URL: https://issues.apache.org/jira/browse/LUCENE-7538
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 5.5.1
Reporter: Steve Chen


We have seen "this IndexWriter is closed" error after we tried to upload a 
large text file to a single Solr text field. The field definition in the 
schema.xml is:
{noformat}

{noformat}

After that, the IndexWriter remained closed and couldn't be recovered until we 
reloaded the Solr core.  The text file had size of 800MB, containing only 
numbers and English characters.

Stack trace is shown below:
{noformat}
2016-11-02 23:00:17,913 [http-nio-19082-exec-3] ERROR 
org.apache.solr.handler.RequestHandlerBase - 
org.apache.solr.common.SolrException: Exception writing document id 1487_0_1 to 
the index; possible analysis error.
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:180)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:68)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:934)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1089)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:712)
at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.doAdd(ExtractingDocumentLoader.java:126)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.addDoc(ExtractingDocumentLoader.java:131)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:237)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:651)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
at 
veeva.ecm.common.interfaces.web.SolrDispatchOverride.doFilter(SolrDispatchOverride.java:43)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:521)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1096)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:674)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.lucene.store.AlreadyClosedException: this IndexWriter is 
closed
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:720)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:734)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1473)
at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:282)
at 

[jira] [Commented] (SOLR-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-9720:
---

The changes wrt Explanation appear fine. There isn't any test coverage of the 
toMap(...) function so that could be added on a future date.

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch, SOLR-9720.patch, 
> SOLR_9720_fix_JSONWriterTest.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_102) - Build # 18205 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 67255 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1073006428
 [ecj-lint] Compiling 995 source files to /tmp/ecj1073006428
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/Assign.java
 (at line 101)
 [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
 [ecj-lint]^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/Assign.java
 (at line 101)
 [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
 [ecj-lint]^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/Assign.java
 (at line 101)
 [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
 [ecj-lint]^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
 (at line 216)
 [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
 [ecj-lint]   ^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
 (at line 216)
 [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
 [ecj-lint]   ^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
 (at line 216)
 [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
 [ecj-lint]   ^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/core/HdfsDirectoryFactory.java
 (at line 227)
 [ecj-lint] dir = new BlockDirectory(path, hdfsDir, cache, null, 
blockCacheReadEnabled, false, cacheMerges, cacheReadOnce);
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'dir' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 8. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/handler/AnalysisRequestHandlerBase.java
 (at line 120)
 [ecj-lint] reader = cfiltfac.create(reader);
 [ecj-lint] 
 [ecj-lint] Resource leak: 'reader' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 9. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/handler/AnalysisRequestHandlerBase.java
 (at line 144)
 [ecj-lint] return namedList;
 [ecj-lint] ^
 [ecj-lint] Resource leak: 'listBasedTokenStream' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 10. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/handler/ClassifyStream.java
 (at line 88)
 [ecj-lint] SolrCore solrCore = (SolrCore) solrCoreObj;
 [ecj-lint]  
 [ecj-lint] Resource leak: 'solrCore' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 11. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java
 (at line 1252)
 [ecj-lint] DirectoryReader reader = s==null ? null : 
s.get().getIndexReader();
 [ecj-lint] ^^
 [ecj-lint] Resource leak: 'reader' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 12. WARNING in 

Re: Solr Ref Guide for 6.3

[Joel Bernstein]

Also I wrote a blog about batch processing in 6.3 that would be interesting
for adding to the users guide. Or this could just be sub page of Streaming
Expressions like Graph Traversal.

http://joelsolr.blogspot.com/2016/10/solr-63-batch-jobs-parallel-etl-and.html

Joel Bernstein
http://joelsolr.blogspot.com/

On Thu, Nov 3, 2016 at 5:36 PM, Joel Bernstein  wrote:

> Hi Cassandra,
>
> I plan on finishing the documentation for 6.3 tomorrow. I'll drop you an
> email when I finish up.
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Thu, Nov 3, 2016 at 1:31 PM, Cassandra Targett 
> wrote:
>
>> Joel, I noticed that you added sections to
>> https://cwiki.apache.org/confluence/display/solr/Streaming+Expressions
>> for new expressions in 6.3 - will you have time to work on those?
>>
>> I was hoping to get an RC out tomorrow, but there's quite a list of
>> new stuff in this area in 6.3 and I'm not sure your plans.
>>
>> On Mon, Oct 31, 2016 at 4:00 PM, Cassandra Targett
>>  wrote:
>> > I'll volunteer to release manage the Ref Guide for Solr 6.3.
>> >
>> > I've reviewed CHANGES.txt, cut some issues, and organized the rest by
>> > where I'm guessing they should go:
>> > https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List.
>> >
>> > Please think about what you worked on in 6.3 and try to make some time
>> > to update the Ref Guide accordingly. I'm happy to review your content
>> > or help you any way I can. We use the TODO list to tell us what needs
>> > to be documented - put your initials next to or under an item if you
>> > can work on it so we don't overlap efforts.
>> >
>> > With luck, maybe next time we'll be able to use a new process. But we
>> > aren't there yet so I ask for as much of your help as you can give.
>> >
>> > I intend to make an RC of the Ref Guide by the end of the week (by
>> > Friday, Nov 4). I'll update if I am delayed; if you'd like to work on
>> > something but need more time than that, please let me know.
>> >
>> > Thanks,
>> > Cassandra
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

Re: Solr Ref Guide for 6.3

[Joel Bernstein]

Hi Cassandra,

I plan on finishing the documentation for 6.3 tomorrow. I'll drop you an
email when I finish up.



Joel Bernstein
http://joelsolr.blogspot.com/

On Thu, Nov 3, 2016 at 1:31 PM, Cassandra Targett 
wrote:

> Joel, I noticed that you added sections to
> https://cwiki.apache.org/confluence/display/solr/Streaming+Expressions
> for new expressions in 6.3 - will you have time to work on those?
>
> I was hoping to get an RC out tomorrow, but there's quite a list of
> new stuff in this area in 6.3 and I'm not sure your plans.
>
> On Mon, Oct 31, 2016 at 4:00 PM, Cassandra Targett
>  wrote:
> > I'll volunteer to release manage the Ref Guide for Solr 6.3.
> >
> > I've reviewed CHANGES.txt, cut some issues, and organized the rest by
> > where I'm guessing they should go:
> > https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List.
> >
> > Please think about what you worked on in 6.3 and try to make some time
> > to update the Ref Guide accordingly. I'm happy to review your content
> > or help you any way I can. We use the TODO list to tell us what needs
> > to be documented - put your initials next to or under an item if you
> > can work on it so we don't overlap efforts.
> >
> > With luck, maybe next time we'll be able to use a new process. But we
> > aren't there yet so I ask for as much of your help as you can give.
> >
> > I intend to make an RC of the Ref Guide by the end of the week (by
> > Friday, Nov 4). I'll update if I am delayed; if you'd like to work on
> > something but need more time than that, please let me know.
> >
> > Thanks,
> > Cassandra
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

JMX monitoring of Solr<->Solr (and Solr<->Zookeeper?) errors.

[Erick Erickson]

I was recently involved in a conversation where the question was
raised whether there were any stats exposed to JMX for monitoring
Solr<->Solr errors and Solr<->Zookeeper errors. The scenario here is
that you'd like to use some JMX-enabled tool to raise alerts when
connections between Solr nodes went wonky and/or you started seeing
errors in reading from ZK etc.

Before diving in I thought I'd ask if there's any "prior art" here. Or
if anyone's thought along these lines before.

The current stats and JMX stuff in Solr is pretty core-specific, which
made me uncertain about piggy-backing on, say, the current
SolrInfoMBean capabilities. This seems like it's more an admin
function or perhaps something new specified at the solr.xml level.

Erick

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

[jira] [Commented] (LUCENE-7537) Add multi valued field support to index sorting

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7537:


I think this makes sense.

It seems like we just need to handle serializing of {{SortedSetSortField}} and 
{{SortedNumericSortField}}, with their selectors, as well?

> Add multi valued field support to index sorting
> ---
>
> Key: LUCENE-7537
> URL: https://issues.apache.org/jira/browse/LUCENE-7537
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Ferenczi Jim
>
> Today index sorting can be done on single valued field through the 
> NumericDocValues (for numerics) and SortedDocValues (for strings).
> I'd like to add the ability to sort on multi valued fields. Since index 
> sorting does not accept custom comparator we could just take the minimum 
> value of each document for an ascending sort and the maximum value for a 
> descending sort.
> This way we could handle all cases instead of throwing an exception during a 
> merge when we encounter a multi valued DVs. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_102) - Build # 2102 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 65912 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj2024499890
 [ecj-lint] Compiling 992 source files to /tmp/ecj2024499890
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/cloud/Assign.java
 (at line 101)
 [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
 [ecj-lint]^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/cloud/Assign.java
 (at line 101)
 [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
 [ecj-lint]^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/cloud/Assign.java
 (at line 101)
 [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
 [ecj-lint]^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
 (at line 216)
 [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
 [ecj-lint]   ^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
 (at line 216)
 [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
 [ecj-lint]   ^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
 (at line 216)
 [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
 [ecj-lint]   ^^^
 [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape 
analysis
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/core/HdfsDirectoryFactory.java
 (at line 227)
 [ecj-lint] dir = new BlockDirectory(path, hdfsDir, cache, null, 
blockCacheReadEnabled, false, cacheMerges, cacheReadOnce);
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'dir' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 8. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/handler/AnalysisRequestHandlerBase.java
 (at line 120)
 [ecj-lint] reader = cfiltfac.create(reader);
 [ecj-lint] 
 [ecj-lint] Resource leak: 'reader' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 9. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/handler/AnalysisRequestHandlerBase.java
 (at line 144)
 [ecj-lint] return namedList;
 [ecj-lint] ^
 [ecj-lint] Resource leak: 'listBasedTokenStream' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 10. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/handler/ClassifyStream.java
 (at line 88)
 [ecj-lint] SolrCore solrCore = (SolrCore) solrCoreObj;
 [ecj-lint]  
 [ecj-lint] Resource leak: 'solrCore' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 11. WARNING in 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java
 (at line 1245)
 [ecj-lint] DirectoryReader reader = s==null ? null : 
s.get().getIndexReader();
 [ecj-lint] ^^
 [ecj-lint] Resource leak: 'reader' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 12. WARNING in 

[jira] [Commented] (SOLR-9120) Luke NoSuchFileException

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9120:
--

Anything with a "resloution" of "fixed" is in some release, the "fixed version" 
field will tell you which ones.

This JIRA has not been added to any version as it's still "unresolved"

SOLR-8587 is in Solr 5.5 and 6.0 (and of course trunk the future 7.0)

> Luke NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
>   at 
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
>   at 
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
>   at java.nio.file.Files.readAttributes(Files.java:1737)
>   at java.nio.file.Files.size(Files.java:2332)
>   at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To 

[jira] [Commented] (SOLR-9326) Ability to create/delete/list snapshots for a solr collection

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-9326:
-

Sure. I'll put this into the Ref Guide backlog then, and we'll wait for the 
rest to be ready.

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9326
> URL: https://issues.apache.org/jira/browse/SOLR-9326
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: Yonik Seeley
> Fix For: 6.3, master (7.0)
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request #108: Minor - Fix error message

[hornn]

GitHub user hornn opened a pull request:

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

Minor - Fix error message

There was a missing space in error message

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hornn/lucene-solr patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/108.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #108


commit c33a87219d479ddfbc1c160bf0514ce011a4870b
Author: Noa Horn 
Date:   2016-11-03T19:44:51Z

Fix error message

There was a missing space in error message




---
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] (SOLR-9326) Ability to create/delete/list snapshots for a solr collection

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9326:


[~ctargett] I am waiting for SOLR-9688 ( which in turn requires SOLR-9055) to 
be committed. That way I can provide a comprehensive documentation. Does that 
make sense ?

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9326
> URL: https://issues.apache.org/jira/browse/SOLR-9326
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: Yonik Seeley
> Fix For: 6.3, master (7.0)
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9326) Ability to create/delete/list snapshots for a solr collection

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-9326:
-

[~hgadre], can you provide some better information on how this is used by users 
so we can add documentation on this for the Solr Ref Guide? Or perhaps it is 
not ready to be documented?

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9326
> URL: https://issues.apache.org/jira/browse/SOLR-9326
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: Yonik Seeley
> Fix For: 6.3, master (7.0)
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9120) Luke NoSuchFileException

[Gopalakrishnan B (JIRA)]

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

Gopalakrishnan B commented on SOLR-9120:


Can you please confirm if the patch is rolled out to fix this issue?

> Luke NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
>   at 
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
>   at 
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
>   at java.nio.file.Files.readAttributes(Files.java:1737)
>   at java.nio.file.Files.size(Files.java:2332)
>   at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9120) Luke NoSuchFileException

[Gopalakrishnan B (JIRA)]

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

Gopalakrishnan B commented on SOLR-9120:


Can you please confirm if the patch is rolled out to fix this issue?

> Luke NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
>   at 
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
>   at 
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
>   at java.nio.file.Files.readAttributes(Files.java:1737)
>   at java.nio.file.Files.size(Files.java:2332)
>   at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Issue Comment Deleted] (SOLR-9120) Luke NoSuchFileException

[Gopalakrishnan B (JIRA)]

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

Gopalakrishnan B updated SOLR-9120:
---
Comment: was deleted

(was: Can you please confirm if the patch is rolled out to fix this issue?)

> Luke NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
>   at 
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
>   at 
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
>   at java.nio.file.Files.readAttributes(Files.java:1737)
>   at java.nio.file.Files.size(Files.java:2332)
>   at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6664) Replace SynonymFilter with SynonymGraphFilter

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-6664:


bq. I think it means graph-producing stages must do their own flattening, to 
resolve side-paths into equivalent flattened positions? But maybe we could 
factor out a little thingy to share code.

+1

bq. If a side path spawns another side path it would get a new entity ID right?

I think so, yes, though that points to a problem: new entity IDs would have to 
be produced without knowing which ones have already been used - otherwise a 
filter would have to consume the whole stream before it could assign a new one. 
 I was assuming it would be one-up integers, but that won't work in this case.  
Hmm.

> Replace SynonymFilter with SynonymGraphFilter
> -
>
> Key: LUCENE-6664
> URL: https://issues.apache.org/jira/browse/LUCENE-6664
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-6664.patch, LUCENE-6664.patch, LUCENE-6664.patch, 
> LUCENE-6664.patch, usa.png, usa_flat.png
>
>
> Spinoff from LUCENE-6582.
> I created a new SynonymGraphFilter (to replace the current buggy
> SynonymFilter), that produces correct graphs (does no "graph
> flattening" itself).  I think this makes it simpler.
> This means you must add the FlattenGraphFilter yourself, if you are
> applying synonyms during indexing.
> Index-time syn expansion is a necessarily "lossy" graph transformation
> when multi-token (input or output) synonyms are applied, because the
> index does not store {{posLength}}, so there will always be phrase
> queries that should match but do not, and then phrase queries that
> should not match but do.
> http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html
> goes into detail about this.
> However, with this new SynonymGraphFilter, if instead you do synonym
> expansion at query time (and don't do the flattening), and you use
> TermAutomatonQuery (future: somehow integrated into a query parser),
> or maybe just "enumerate all paths and make union of PhraseQuery", you
> should get 100% correct matches (not sure about "proper" scoring
> though...).
> This new syn filter still cannot consume an arbitrary graph.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8610) DIH - Resolve variables in encryptKeyFile

[Jamie Jackson (JIRA)]

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

Jamie Jackson commented on SOLR-8610:
-

[~sashevsky], I made a [ticket|SOLR-9725] of your issue.

> DIH - Resolve variables in encryptKeyFile
> -
>
> Key: SOLR-8610
> URL: https://issues.apache.org/jira/browse/SOLR-8610
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 5.4.1
>Reporter: Kristine Jetzke
>Assignee: Mikhail Khludnev
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8610.patch, SOLR-8610.patch
>
>
> I would like to use a variable like {{$\{path.to.file\}}} for  
> {{encryptKeyFile}} in my DIH config files so that I don't have to specify the 
> concrete absolute path in all files. This is currently not possible since 
> variables are not resolved. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9725) Allow Variables for All Data Import Handler Data Source Configuration Values

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9725:
--

Github user jamiejackson commented on the issue:

https://github.com/apache/lucene-solr/pull/46
  
Please see https://issues.apache.org/jira/browse/SOLR-9725


> Allow Variables for All Data Import Handler Data Source Configuration Values
> 
>
> Key: SOLR-9725
> URL: https://issues.apache.org/jira/browse/SOLR-9725
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Affects Versions: 5.5.3
>Reporter: Jamie Jackson
>Priority: Minor
>  Labels: patch
>
> I need to be able to use a variable for a password when also using 
> {{encryptKeyFile}}.
> For instance:
> {code:xml}
>  driver="${custom.dataimporter.datasource.driver}"
>   url="${custom.dataimporter.datasource.url}"
>   user="${custom.dataimporter.datasource.user}"
>   password="${custom.dataimporter.datasource.password}"
>   encryptKeyFile="/opt/solr/credentials/encrypt.key"
>   />
> {code}
> Because I need to change certain variables based on the environment. I'd 
> start like this:
> {code}
>  -a
>   -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
>   
> -Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
>   -Dcustom.dataimporter.datasource.user=root
>   
> -Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
> {code}
> If I hardcode the password, it works; if I use a variable reference, it 
> doesn't.
> As far as I know [this pull 
> request|https://github.com/apache/lucene-solr/pull/46] was submitted to 
> address this issue, but it didn't come with a Jira ticket or a full 
> explanation.
> Also, note that I'm not using a variable for the value of {{encryptKeyFile}}, 
> because [it's not possible in 5.x, though it seems to be fixed in 
> 6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above 
> patch would encompass {{encryptKeyFile}}'s value, as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr issue #46: Variables in dataimport config doesn't resolve

[jamiejackson]

Github user jamiejackson commented on the issue:

https://github.com/apache/lucene-solr/pull/46
  
Please see https://issues.apache.org/jira/browse/SOLR-9725


---
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] [Created] (SOLR-9725) Allow Variables for All Data Import Handler Data Source Configuration Values

[Jamie Jackson (JIRA)]

Jamie Jackson created SOLR-9725:
---

 Summary: Allow Variables for All Data Import Handler Data Source 
Configuration Values
 Key: SOLR-9725
 URL: https://issues.apache.org/jira/browse/SOLR-9725
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - DataImportHandler
Affects Versions: 5.5.3
Reporter: Jamie Jackson
Priority: Minor


I need to be able to use a variable for a password when also using 
{{encryptKeyFile}}.

For instance:
{code:xml}

{code}

Because I need to change certain variables based on the environment. I'd start 
like this:

{code}
 -a
  -Dcustom.dataimporter.datasource.driver=org.mariadb.jdbc.Driver
  
-Dcustom.dataimporter.datasource.url=jdbc:mysql://local.mysite.com:3306/mysite
  -Dcustom.dataimporter.datasource.user=root
  
-Dcustom.dataimporter.datasource.password=U2FsdGVkX1/dqwTb8RBfFq82SM37DkDRGeWMOndftHY=
{code}

If I hardcode the password, it works; if I use a variable reference, it doesn't.

As far as I know [this pull 
request|https://github.com/apache/lucene-solr/pull/46] was submitted to address 
this issue, but it didn't come with a Jira ticket or a full explanation.

Also, note that I'm not using a variable for the value of {{encryptKeyFile}}, 
because [it's not possible in 5.x, though it seems to be fixed in 
6.1|https://issues.apache.org/jira/browse/SOLR-8610]. Presumably, the above 
patch would encompass {{encryptKeyFile}}'s value, as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9557) Every implicit requesthandler should have a default useParams

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-9557:
-

[~noble.paul] - can you provide some information on how people should use this, 
for the Solr Ref Guide? I'm guessing this should go in the 
https://cwiki.apache.org/confluence/display/solr/Request+Parameters+API section 
on useParams.

> Every implicit requesthandler should have a default useParams 
> --
>
> Key: SOLR-9557
> URL: https://issues.apache.org/jira/browse/SOLR-9557
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9557.patch
>
>
> If a user needs to set any request parameters on an implicitly defined 
> requesthandler , he has to define an {{}} section in 
> solrconfig.xml.  We should define a default paramset with all implicit 
> handlers
> example : the {{/update/json/docs}} can have a default 
> {{useParams="_UPDATE_JSON_DOCS"}}
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6664) Replace SynonymFilter with SynonymGraphFilter

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6664:


This is a neat approach!

I like that no explicit flattening stage is required, though I think it means 
graph-producing stages must do their own flattening, to resolve side-paths into 
equivalent flattened positions?  But maybe we could factor out a little thingy 
to share code.

If a side path spawns another side path it would get a new entity ID right?

And then, a node ID is really just the tuple of (entityID, position), and you 
can losslessly reconstruct the graph.

> Replace SynonymFilter with SynonymGraphFilter
> -
>
> Key: LUCENE-6664
> URL: https://issues.apache.org/jira/browse/LUCENE-6664
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-6664.patch, LUCENE-6664.patch, LUCENE-6664.patch, 
> LUCENE-6664.patch, usa.png, usa_flat.png
>
>
> Spinoff from LUCENE-6582.
> I created a new SynonymGraphFilter (to replace the current buggy
> SynonymFilter), that produces correct graphs (does no "graph
> flattening" itself).  I think this makes it simpler.
> This means you must add the FlattenGraphFilter yourself, if you are
> applying synonyms during indexing.
> Index-time syn expansion is a necessarily "lossy" graph transformation
> when multi-token (input or output) synonyms are applied, because the
> index does not store {{posLength}}, so there will always be phrase
> queries that should match but do not, and then phrase queries that
> should not match but do.
> http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html
> goes into detail about this.
> However, with this new SynonymGraphFilter, if instead you do synonym
> expansion at query time (and don't do the flattening), and you use
> TermAutomatonQuery (future: somehow integrated into a query parser),
> or maybe just "enumerate all paths and make union of PhraseQuery", you
> should get 100% correct matches (not sure about "proper" scoring
> though...).
> This new syn filter still cannot consume an arbitrary graph.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7537) Add multi valued field support to index sorting

[Ferenczi Jim (JIRA)]

Ferenczi Jim created LUCENE-7537:


 Summary: Add multi valued field support to index sorting
 Key: LUCENE-7537
 URL: https://issues.apache.org/jira/browse/LUCENE-7537
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Reporter: Ferenczi Jim


Today index sorting can be done on single valued field through the 
NumericDocValues (for numerics) and SortedDocValues (for strings).
I'd like to add the ability to sort on multi valued fields. Since index sorting 
does not accept custom comparator we could just take the minimum value of each 
document for an ascending sort and the maximum value for a descending sort.
This way we could handle all cases instead of throwing an exception during a 
merge when we encounter a multi valued DVs. 




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7536) ASCIIFoldingFilterFactory.getMultiTermComponent can emit two tokens

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7536:


 Summary: ASCIIFoldingFilterFactory.getMultiTermComponent can emit 
two tokens
 Key: LUCENE-7536
 URL: https://issues.apache.org/jira/browse/LUCENE-7536
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Adrien Grand
Priority: Minor


My understanding is that it is a requirement for multi-term analysis to only 
normalize tokens, and not eg. remove tokens (stop filter) or add tokens (by 
tokenizing or adding synonyms). Yet 
ASCIIFoldingFilterFactory.getMultiTermComponent will return a factory that 
emits synonyms if preserveOriginal is set to true on the original filter.

This looks like a bug to me but I'm not entirely sure how to fix it. Should the 
multi-term analysis component do ascii folding or not if the original factory 
has preserveOriginal set to true?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Solr Ref Guide for 6.3

[Cassandra Targett]

Joel, I noticed that you added sections to
https://cwiki.apache.org/confluence/display/solr/Streaming+Expressions
for new expressions in 6.3 - will you have time to work on those?

I was hoping to get an RC out tomorrow, but there's quite a list of
new stuff in this area in 6.3 and I'm not sure your plans.

On Mon, Oct 31, 2016 at 4:00 PM, Cassandra Targett
 wrote:
> I'll volunteer to release manage the Ref Guide for Solr 6.3.
>
> I've reviewed CHANGES.txt, cut some issues, and organized the rest by
> where I'm guessing they should go:
> https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List.
>
> Please think about what you worked on in 6.3 and try to make some time
> to update the Ref Guide accordingly. I'm happy to review your content
> or help you any way I can. We use the TODO list to tell us what needs
> to be documented - put your initials next to or under an item if you
> can work on it so we don't overlap efforts.
>
> With luck, maybe next time we'll be able to use a new process. But we
> aren't there yet so I ask for as much of your help as you can give.
>
> I intend to make an RC of the Ref Guide by the end of the week (by
> Friday, Nov 4). I'll update if I am delayed; if you'd like to work on
> something but need more time than that, please let me know.
>
> Thanks,
> Cassandra

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

[jira] [Updated] (SOLR-9721) Create a javabin writer/reader for streaming end point

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9721:
-
Attachment: SOLR-9721.patch

> Create a javabin writer/reader for streaming end point
> --
>
> Key: SOLR-9721
> URL: https://issues.apache.org/jira/browse/SOLR-9721
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
> Attachments: SOLR-9721.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9692) BlockUnknown property still breaks the internode communication

[Ewen Cluley (JIRA)]

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

Ewen Cluley commented on SOLR-9692:
---

I have not had a chance to test it yet, will try to do a build of  6.3 rc with 
my setup over the next few days.

> BlockUnknown property still breaks the internode communication
> --
>
> Key: SOLR-9692
> URL: https://issues.apache.org/jira/browse/SOLR-9692
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: BasicAuth, security
> Fix For: 6.3
>
>
> This is  still broken after fixing SOLR-9188



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9724) excludeTags support in conjunction with facet domain changes

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-9724:
--

 Summary: excludeTags support in conjunction with facet domain 
changes
 Key: SOLR-9724
 URL: https://issues.apache.org/jira/browse/SOLR-9724
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module
Reporter: Yonik Seeley


Currently excludeTags only works when there are no explicit facet domain change 
operations in a parent facet.  Only the implicit constraint/filter caused by 
the facet bucket itself is handled.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: 6.3.0

[Adrien Grand]

Thanks Shalin,

The Lucene notes look good to me. I rephrased a bit the point about the
BKDReader optimization to put more emphasis on the memory savings.

Le mar. 1 nov. 2016 à 06:23, Shalin Shekhar Mangar 
a écrit :

> I have created release notes for Lucene and Solr. Please edit to
> improve as you see fit.
>
> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote63
> Solr: https://wiki.apache.org/solr/ReleaseNote63
>
> On Wed, Oct 26, 2016 at 2:16 PM, Shalin Shekhar Mangar
>  wrote:
> > It looks like 6.3.0 has accumulated enough new features, optimizations
> and
> > fixes. How do folks feel about pushing this release out?
> >
> > I volunteer to be the RM. If there are no objections, I'd like to put the
> > first RC to vote on Monday.
> >
> > --
> > Regards,
> > Shalin Shekhar Mangar.
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Created] (SOLR-9723) "Error writing document" on document add caused by NegativeArraySizeException

[Seva Alekseyev (JIRA)]

Seva Alekseyev created SOLR-9723:


 Summary: "Error writing document" on document add caused by 
NegativeArraySizeException
 Key: SOLR-9723
 URL: https://issues.apache.org/jira/browse/SOLR-9723
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: update
Affects Versions: 6.2.1
 Environment: Windows Server 2012 R2 x64, Java 1.8.0_111
Reporter: Seva Alekseyev


I'm adding documents to SOLR 6.2.1 via /solr/corename/update in a tight loop on 
multiple threads. After some time, SOLR starts throwing intermittent errors. 
They don't reproduce. Here's one:

2016-11-02 02:29:10.997 ERROR (qtp1389647288-10719) [   x:fscan] 
o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Exception 
writing document id 72513253_HS-RNA-Valenzuela-2.xls to the index; possible 
analysis error.
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:178)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:335)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:74)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:939)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1094)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:720)
at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:48)
at 
org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:91)
at 
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:250)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:177)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:154)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2089)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:459)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
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 

Re: [VOTE] - Release Lucene/Solr 6.3.0 RC3

[Adrien Grand]

+1 SUCCESS! [1:02:33.485442]

Le jeu. 3 nov. 2016 à 00:19, Steve Rowe  a écrit :

> +1
>
> Smoke tester passed (lost the timing in a closed terminal window, it was
> 34 minutes or so IIRC).
>
> Changes, docs and javadocs look good.
>
> --
> Steve
> www.lucidworks.com
>
> > On Nov 2, 2016, at 3:35 PM, Tommaso Teofili 
> wrote:
> >
> > SUCCESS! [1:54:38.816517]
> >
> > +1
> >
> > Tommaso
> >
> >
> > Il giorno mer 2 nov 2016 alle ore 19:56 Jan Høydahl <
> jan@cominvent.com> ha scritto:
> > SUCCESS! [1:05:53.149540] (macOS)
> > +1
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >> 2. nov. 2016 kl. 17.34 skrev Shalin Shekhar Mangar :
> >>
> >> Please vote for the third release candidate for Lucene/Solr 6.3.0
> >>
> >> The artifacts can be downloaded from:
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316
> >>
> >> You can run the smoke tester directly with this command:
> >> python3 -u dev-tools/scripts/smokeTestRelease.py
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC3-reva66a44513ee8191e25b477372094bfa846450316
> >>
> >> Smoke tester passed for me:
> >> SUCCESS! [0:36:45.760510]
> >>
> >> Here's my +1 to release.
> >>
> >> --
> >> Regards,
> >> Shalin Shekhar Mangar.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[ASF subversion and git services (JIRA)]

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

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

Commit 9f9139ab429708916beab22c05312662dbd9eaa1 in lucene-solr's branch 
refs/heads/branch_6x from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9f9139a ]

SOLR-9720: Fix for JSONWriterTest

(cherry picked from commit 78b768f)


> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch, SOLR-9720.patch, 
> SOLR_9720_fix_JSONWriterTest.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9720: Fix for JSONWriterTest


> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch, SOLR-9720.patch, 
> SOLR_9720_fix_JSONWriterTest.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-7534:
--

I suppose it's worth to tweak it to call solr.cmd on cygwin, yet more work need 
to be done here... 

> smokeTestRelease.py on cygwin [Errno 2] No such file or directory: 
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
>  Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1440, in 
> main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
>   File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
>   File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' % 
> java_home).read().decode('utf-8').strip()
>   File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
>   File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u 
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and 
> args should be either supplied as array of terms or supplied as {{shell=True}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-7534:
--

although.. 
{quote}
test solr example w/ Java 8...
  start Solr instance 
(log=/tmp/smoke_lucene_6.3.0_1fe1a54db32b8c27bfae81887cd4d75242090613_7/unpack/solr-6.3.0-java8/solr-example.log)...
This script does not support cygwin due to severe limitations and lack of 
adherence
to BASH standards, such as lack of lsof, curl, and ps options.

Please use the native solr.cmd script on Windows!
  Running techproducts example on port 8983 from 
/tmp/smoke_lucene_6.3.0_1fe1a54db32b8c27bfae81887cd4d75242090613_7/unpack/solr-6.3.0-java8
This script does not support cygwin due to severe limitations and lack of 
adherence
to BASH standards, such as lack of lsof, curl, and ps options.

Please use the native solr.cmd script on Windows!
  stop server using: bin/solr stop -p 8983
This script does not support cygwin due to severe limitations and lack of 
adherence
to BASH standards, such as lack of lsof, curl, and ps options.

Please use the native solr.cmd script 
{quote}

> smokeTestRelease.py on cygwin [Errno 2] No such file or directory: 
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
>  Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1440, in 
> main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
>   File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
>   File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' % 
> java_home).read().decode('utf-8').strip()
>   File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
>   File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u 
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and 
> args should be either supplied as array of terms or supplied as {{shell=True}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7955) Auto create .system collection on first request if it does not exist

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7955:


Another TL;DR comment:

Something I touched on earlier: What will the default value for 
replicationFactor be when the collection is automatically built?  One idea, but 
I'm far from saying it's the best idea, is to set the default to the number of 
servers in the cloud.

If the replica count is hard-coded to 2, or uses the number of servers, the 
following scenario would result either in no .system collection at all (failed 
create due to insufficient servers) or no redundancy:  A user sets up a cloud, 
initially with one server, then creates a collection on that cloud to try 
things out before adding more servers and setting up their real collection(s).

I like the idea of not making the user do things manually, but if a user 
proceeds in the cautious manner I just described, I worry that we'll put that 
user in a bad situation at a later date when the server containing their 
.system collection dies.  We can create good documentation, but unless the user 
thinks to LOOK for that documentation, they might get a nasty surprise one day.

Related:  The reference guide probably needs a section describing problems that 
can arise from a lack of understanding, and how to remedy them.  A possible 
section title:  "Gotchas: Solving problems you may not know you have"


> Auto create .system collection on first request if it does not exist
> 
>
> Key: SOLR-7955
> URL: https://issues.apache.org/jira/browse/SOLR-7955
> Project: Solr
>  Issue Type: Improvement
>Reporter: Jan Høydahl
> Attachments: SOLR-7955.patch
>
>
> Why should a user need to create the {{.system}} collection manually? It 
> would simplify instructions related to BLOB store if user could assume it is 
> always there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9720:

Attachment: SOLR_9720_fix_JSONWriterTest.patch

This change makes the JSONWriterTest.testArrnvpWriterOverridesAllWrites fail 
because it expects that the ArrayOfNamedValuePairJSONWriter class added in 
SOLR-9442 overrides all public/protected writeXXX methods from JSONWriter. 
However, this change introduced two new public/protected methods 
writeJsonIter(java.util.Iterator) and 
writeArray(java.lang.String,java.util.List) which aren't overriden by 
ArrayOfNamedValuePairJSONWriter.

This patch fixes it by adding a writeArray(java.lang.String,java.util.List) in 
ArrayOfNamedValuePairJSONWriter which delegates to writeArray(String name, 
Iterator val) and making writeJsonIter private (which is used internally by 
both variants of writeArray in the super class. If we ever have a need for 
overriding writeJsonIter directly, we can make it protected then.

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch, SOLR-9720.patch, 
> SOLR_9720_fix_JSONWriterTest.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7672) introduce implicit _parent_:true

[Romain Rigaux (JIRA)]

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

Romain Rigaux commented on SOLR-7672:
-

+1 
Having the "paths/types" and name of the "type" fields would provide out of a 
the box a "schema" of the data that would greatly improve the user experience 
with nested objects.


> introduce implicit _parent_:true  
> --
>
> Key: SOLR-7672
> URL: https://issues.apache.org/jira/browse/SOLR-7672
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers, update
>Affects Versions: 5.2
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Fix For: 5.5, 6.0
>
>
> Solr provides block join support in non-invasive manner. It turns out, it 
> gives a chance to shoot a leg. As it was advised by [~thetaphi] at SOLR-7606, 
> let AddUpdateCommand add _parent_:true field to the document (not to 
> children). Do it *always* no matter whether it has children or not.
> Also, introduce default values for for block join qparsers \{!parent 
> *which=\_parent\_:true*} \{!child *of=\_parent\_:true*} (sometimes, I rather 
> want to hide them from the user, because they are misunderstood quite often). 
>  
> Please share your concerns and vote.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9716) RecoveryStrategy send prep recovery cmd without setting request time out

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-9716:
---
Attachment: SOLR-9716.patch

Cleaner test based on TestInjection.

> RecoveryStrategy send prep recovery cmd without setting request time out
> 
>
> Key: SOLR-9716
> URL: https://issues.apache.org/jira/browse/SOLR-9716
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-9716.patch, SOLR-9716.patch, SOLR-9716.patch
>
>
> Currently, RecoveryStrategy sends prep recovery cmd without setting request 
> time out. But this can be long running request, so if we have network 
> partition in the middle of the request. Recovering core will stay down 
> forever.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7955) Auto create .system collection on first request if it does not exist

[JIRA]

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

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

Simple patch which just logs a line in HttpSolrCall when we have detected 
.system collection not exists. Suppose we could put some auto-create logic 
there?

> Auto create .system collection on first request if it does not exist
> 
>
> Key: SOLR-7955
> URL: https://issues.apache.org/jira/browse/SOLR-7955
> Project: Solr
>  Issue Type: Improvement
>Reporter: Jan Høydahl
> Attachments: SOLR-7955.patch
>
>
> Why should a user need to create the {{.system}} collection manually? It 
> would simplify instructions related to BLOB store if user could assume it is 
> always there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7534:


Thanks for working on it Mikhail - I put in the original cygwin support but 
haven't used windows much in years.

I'll test your patch on Linux against the 6.3 RC.

> smokeTestRelease.py on cygwin [Errno 2] No such file or directory: 
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
>  Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1440, in 
> main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
>   File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
>   File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' % 
> java_home).read().decode('utf-8').strip()
>   File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
>   File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u 
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and 
> args should be either supplied as array of terms or supplied as {{shell=True}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18203 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18203/
Java: 32bit/jdk-9-ea+140 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.response.JSONWriterTest.testArrnvpWriterOverridesAllWrites

Error Message:
class org.apache.solr.response.ArrayOfNamedValuePairJSONWriter needs to 
override 'public void 
org.apache.solr.response.JSONWriter.writeArray(java.lang.String,java.util.List) 
throws java.io.IOException'

Stack Trace:
java.lang.AssertionError: class 
org.apache.solr.response.ArrayOfNamedValuePairJSONWriter needs to override 
'public void 
org.apache.solr.response.JSONWriter.writeArray(java.lang.String,java.util.List) 
throws java.io.IOException'
at 
__randomizedtesting.SeedInfo.seed([AB97FD741DA0809C:213E63F9C5B3A4C7]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.response.JSONWriterTest.testArrnvpWriterOverridesAllWrites(JSONWriterTest.java:216)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 

[jira] [Commented] (SOLR-9712) Saner default for maxWarmingSearchers

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9712:


If we go this route (which I think we should) then we probably also should:
 - change the default maxWarmingSearchers to 1
 - remove maxWarmingSearchers from our starting configs (it becomes pretty 
advanced... most shouldn't need to worry about it)
 - remove maxWarmingSearchers from the majority of our test configs - we'll 
want the best test coverage on maxWarmingSearchers=1
 - add an upgrade note encouraging removal of maxWarmingSearchers from your 
config, unless you specifically know better
 - document the change in behavior of course...

> Saner default for maxWarmingSearchers
> -
>
> Key: SOLR-9712
> URL: https://issues.apache.org/jira/browse/SOLR-9712
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9712.patch
>
>
> As noted in SOLR-9710, the default for maxWarmingSearchers is 
> Integer.MAX_VALUE which is just crazy. Let's have a saner default. Today we 
> log a performance warning when the number of on deck searchers goes over 1. 
> What if we had the default as 1 that expert users can increase if needed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5344) SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5344: relax the test requirements for estimated hit counts


> SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to 
> time
> 
>
> Key: SOLR-5344
> URL: https://issues.apache.org/jira/browse/SOLR-5344
> Project: Solr
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: James Dyer
> Attachments: SOLR-5344.patch
>
>
> Doesn't happen very often, but maybe one I can fix. I'll look into it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-5344) SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time

[James Dyer (JIRA)]

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

James Dyer resolved SOLR-5344.
--
Resolution: Fixed

test fix only, no CHANGES.txt entry.

> SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to 
> time
> 
>
> Key: SOLR-5344
> URL: https://issues.apache.org/jira/browse/SOLR-5344
> Project: Solr
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: James Dyer
> Attachments: SOLR-5344.patch
>
>
> Doesn't happen very often, but maybe one I can fix. I'll look into it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-5344) SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to time

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5344: relax the test requirements for estimated hit counts


> SpellCheckCollatorTest.testEstimatedHitCounts fails in jenkins from time to 
> time
> 
>
> Key: SOLR-5344
> URL: https://issues.apache.org/jira/browse/SOLR-5344
> Project: Solr
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: James Dyer
> Attachments: SOLR-5344.patch
>
>
> Doesn't happen very often, but maybe one I can fix. I'll look into it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9712) Saner default for maxWarmingSearchers

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9712:


I often wondered if this was causing subtle bugs... other parts of the system 
rely on being able to reliably do a commit and not having it spuriously fail. 
Probably should have fixed it a long time ago!

> Saner default for maxWarmingSearchers
> -
>
> Key: SOLR-9712
> URL: https://issues.apache.org/jira/browse/SOLR-9712
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9712.patch
>
>
> As noted in SOLR-9710, the default for maxWarmingSearchers is 
> Integer.MAX_VALUE which is just crazy. Let's have a saner default. Today we 
> log a performance warning when the number of on deck searchers goes over 1. 
> What if we had the default as 1 that expert users can increase if needed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9712) Saner default for maxWarmingSearchers

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-9712:
---
Attachment: SOLR-9712.patch

Here's a completely untested patch.

It's much smaller than it looks (change in indentation obscures actual changes.)

This really just adds a loop around the open logic and then replaces the code 
that throws an exception when maxWarmingSearchers is exceeded with a wait.  
Seems like the lowest risk change since it doesn't change anything else.
{code}
} else if (onDeckSearchers > maxWarmingSearchers) {
  onDeckSearchers--;
  try {
searcherLock.wait();
  } catch (InterruptedException e) {
log.info(SolrException.toStr(e));
// TODO: should we throw an exception in this case?
  }
  continue;  // go back to the top of the loop and retry
{code}

That code just logs an InterruptedException, but perhaps we should throw an 
exception in that case (i.e. abort trying to open a reader)?  Things like this 
sometimes do have a real impact on our Chaos tests though...

> Saner default for maxWarmingSearchers
> -
>
> Key: SOLR-9712
> URL: https://issues.apache.org/jira/browse/SOLR-9712
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9712.patch
>
>
> As noted in SOLR-9710, the default for maxWarmingSearchers is 
> Integer.MAX_VALUE which is just crazy. Let's have a saner default. Today we 
> log a performance warning when the number of on deck searchers goes over 1. 
> What if we had the default as 1 that expert users can increase if needed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[JIRA]

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

Jan Høydahl reassigned SOLR-8440:
-

Assignee: Jan Høydahl

> 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: Jan Høydahl
>  Labels: authentication, security
>
> 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.4#6332)

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

[jira] [Updated] (LUCENE-7534) smokeTestRelease.py on cygwin [Errno 2] No such file or directory:

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7534:
-
Attachment: LUCENE-7534.patch

[^LUCENE-7534.patch] let me finally smore release on widows (cygwin). Please, 
confirm that it won't hurt -normal- other platforms.   

> smokeTestRelease.py on cygwin [Errno 2] No such file or directory: 
> ---
>
> Key: LUCENE-7534
> URL: https://issues.apache.org/jira/browse/LUCENE-7534
> Project: Lucene - Core
>  Issue Type: Bug
> Environment: Windows, Cygwin, Python
>Reporter: Mikhail Khludnev
> Attachments: LUCENE-7534.patch, LUCENE-7534.patch, LUCENE-7534.patch
>
>
> {quote}
> $ python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> Revision: 1fe1a54db32b8c27bfae81887cd4d75242090613
> Java 1.8 JAVA_HOME=C:\Program Files\Java\jdk1.8.0_102
> Traceback (most recent call last):
>   File "dev-tools/scripts/smokeTestRelease.py", line 1440, in 
> main()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1377, in main
> c = parse_config()
>   File "dev-tools/scripts/smokeTestRelease.py", line 1239, in parse_config
> c.java = make_java_config(parser, c.test_java8)
>   File "dev-tools/scripts/smokeTestRelease.py", line 1193, in make_java_config
> run_java8 = _make_runner(java8_home, '1.8')
>   File "dev-tools/scripts/smokeTestRelease.py", line 1179, in _make_runner
> java_home = subprocess.check_output('cygpath -u "%s"' % 
> java_home).read().decode('utf-8').strip()
>   File "/usr/lib/python3.4/subprocess.py", line 607, in check_output
> with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
>   File "/usr/lib/python3.4/subprocess.py", line 859, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.4/subprocess.py", line 1457, in _execute_child
> raise child_exception_type(errno_num, err_msg)
> FileNotFoundError: [Errno 2] No such file or directory: 'cygpath -u 
> "C:\\Program Files\\Java\\jdk1.8.0_102"'
> {quote}
> giving [the doc|https://docs.python.org/3.4/library/subprocess.html] path and 
> args should be either supplied as array of terms or supplied as {{shell=True}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9712) Saner default for maxWarmingSearchers

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9712:


bq. I thought the first part was the reason behind waitSearcher=true?

Right, unless maxWarningSearchers is exceeded, in which case I think an 
exception is thrown?

> Saner default for maxWarmingSearchers
> -
>
> Key: SOLR-9712
> URL: https://issues.apache.org/jira/browse/SOLR-9712
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.4
>
>
> As noted in SOLR-9710, the default for maxWarmingSearchers is 
> Integer.MAX_VALUE which is just crazy. Let's have a saner default. Today we 
> log a performance warning when the number of on deck searchers goes over 1. 
> What if we had the default as 1 that expert users can increase if needed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7498) More Like This to Use BM25

[Alessandro Benedetti (JIRA)]

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

Alessandro Benedetti commented on LUCENE-7498:
--

Started the implementation and tests.
The refactor will break down the big MoreLikeThis monolithic class in more 
cohesive classes with separate tests.
I will keep this ticket up to date.


> More Like This to Use BM25
> --
>
> Key: LUCENE-7498
> URL: https://issues.apache.org/jira/browse/LUCENE-7498
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/other
>Reporter: Alessandro Benedetti
>
> BM25 is now the default similarity, but the more like this is still using the 
> old TF/IDF .
>  
> This issue is to move to BM25 and refactor the MLT to be more organised, 
> extensible and maintainable.
> Few extensions will follow later, but the focus of this issue will be :
>  - BM25
> - code refactor + tests



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9720:
--

In general this looks really good. 

The one thing I would look into is the effect of the changes to the Explanation 
class and whether there is test coverage on this. [~dpgove] any thoughts on 
this?

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch, SOLR-9720.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.response.JSONWriterTest.testArrnvpWriterOverridesAllWrites

Error Message:
class org.apache.solr.response.ArrayOfNamedValuePairJSONWriter needs to 
override 'public void 
org.apache.solr.response.JSONWriter.writeArray(java.lang.String,java.util.List) 
throws java.io.IOException'

Stack Trace:
java.lang.AssertionError: class 
org.apache.solr.response.ArrayOfNamedValuePairJSONWriter needs to override 
'public void 
org.apache.solr.response.JSONWriter.writeArray(java.lang.String,java.util.List) 
throws java.io.IOException'
at 
__randomizedtesting.SeedInfo.seed([4D2B909C6F788C39:C7820E11B76BA862]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.response.JSONWriterTest.testArrnvpWriterOverridesAllWrites(JSONWriterTest.java:216)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 

[jira] [Commented] (SOLR-9710) SpellCheckComponentTest (still) occasionally fails

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9710:


bq.  We have a couple of fresh failures as our test harness fails if we go 
beyond the # of allowed on-deck searchers.

which failures do you have? 
bq. What we want instead is for it to wait for the searcher to be available and 
then continue. 
Presumably test can poll /mbeans until searcher is changed. 

> SpellCheckComponentTest (still) occasionally fails
> --
>
> Key: SOLR-9710
> URL: https://issues.apache.org/jira/browse/SOLR-9710
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.2.1
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Fix For: 6.3
>
> Attachments: SOLR-9710.patch
>
>
> In December 2015, I addressed occasional, non-reproducable failures with the 
> Spellcheck Component tests.  These were failing with this warning:
> bq. PERFORMANCE WARNING: Overlapping onDeckSearchers=2
> ...and the test itself would run before the test data was committed, 
> resulting in failure.
> This problem is re-occurring and needs a better fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_102) - Build # 2098 - Unstable!

[Michael McCandless]

This is a scary failure ... it means we wrote bytes into our
paged-bytes arrays, and later read them back, and they were different.

It does not repro for me on 64 bit JVM (1.8.0_101) w/ default GC ...
maybe G1GC (on 32 bit JVMs?) is still buggy?

Mike McCandless

http://blog.mikemccandless.com


On Wed, Nov 2, 2016 at 11:38 PM, Policeman Jenkins Server
 wrote:
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2098/
> Java: 32bit/jdk1.8.0_102 -server -XX:+UseG1GC
>
> 1 tests failed.
> FAILED:  org.apache.lucene.util.TestPagedBytes.testDataInputOutput2
>
> Error Message:
>
>
> Stack Trace:
> java.lang.AssertionError
> at 
> __randomizedtesting.SeedInfo.seed([31D9F38942A7A39D:BF18FD0F12366D5D]:0)
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertTrue(Assert.java:54)
> at 
> org.apache.lucene.util.TestPagedBytes.testDataInputOutput2(TestPagedBytes.java:136)
> 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:367)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
> 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 
> 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:367)
> at java.lang.Thread.run(Thread.java:745)
>
>
>
>
> Build Log:
> [...truncated 1065 lines...]
>[junit4] Suite: org.apache.lucene.util.TestPagedBytes
>[junit4]   2> NOTE: 

[jira] [Commented] (SOLR-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[ASF subversion and git services (JIRA)]

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

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

Commit 1f595a20a2c2a5b06586f637da5f5487f796c2e4 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1f595a2 ]

SOLR-9720: Refactor Responsewriters to remove dependencies on TupleStream, 
Tuple, Explanation


> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch, SOLR-9720.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9714) Ability to configure STOP_PORT

[JIRA]

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

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

Solr currently occupies three (four) ports on startup:
* SOLR_PORT
* STOP_PORT=SOLR_PORT-1000 (jetty stop port)
* RMI_PORT=SOLR_PORT+1 (jmx)
* zkRun port=SOLR_PORT+1000 (if started with -c without -z)

Today you can (not documented) customize STOP_PORT when starting Solr, but not 
when stopping.
RMI_PORT and STOP_KEY is already configurable in solr.in or env.vars, while 
zkRun port is not configurable.

I propose the addition of {{SOLR_STOP_PORT}} in solr.in scripts and document it.
At the same time the {{install_solr_service}} script could get options for {{-j 
}}, {{-t }}, {{-k }}, but perhaps instead of 
inventing a install-script option for every thinkable variable, we should let 
people supply a solr.in file {{-c }}?

Another related issue is that if you try to stop Solr with an incorrect 
STOP_PORT or an incorrect STOP_KEY, i.e. {{solr stop -k foo -p 8983}} then the 
controlled stop through stop port/key fails, but then the process is still 
forcefully killed after some seconds. Should we not instead exit with message 
"invalid stop port/key given". Is not the purpose of the secret stop key to 
prevent people from stopping the process without the proper key? Also, the {{-k 
}} parameter is only documented for {{stop}}, but it exists for {{start}} 
as well.



> Ability to configure STOP_PORT
> --
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: 胡晓东
>Priority: Minor
> Attachments: SOLR-9714.patch
>
>
> Our system just has port planning,we have the requirement to configure what 
> to use as stop port explicitly. but now I can configure the stop_port on the 
> starting script($SOLR_HOME/bin/solr), but can not use the port to stop solr 
> gracefully. I think the script has a little problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9714) Ability to configure STOP_PORT

[JIRA]

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

Jan Høydahl updated SOLR-9714:
--
Summary: Ability to configure STOP_PORT  (was: can not stop solr with 
$STOP_PORT)

> Ability to configure STOP_PORT
> --
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: 胡晓东
>Priority: Minor
> Attachments: SOLR-9714.patch
>
>
> Our system just has port planning,we have the requirement to configure what 
> to use as stop port explicitly. but now I can configure the stop_port on the 
> starting script($SOLR_HOME/bin/solr), but can not use the port to stop solr 
> gracefully. I think the script has a little problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9716) RecoveryStrategy send prep recovery cmd without setting request time out

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-9716:
---
Attachment: SOLR-9716.patch

Updated patch included a test. 

In this patch I introduced a new class called ChaosHttpSolrClient, in which 
randomly wait forever ( in case of PREPRECOVERY request ) if socketTimeOut is 
not set.

> RecoveryStrategy send prep recovery cmd without setting request time out
> 
>
> Key: SOLR-9716
> URL: https://issues.apache.org/jira/browse/SOLR-9716
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-9716.patch, SOLR-9716.patch
>
>
> Currently, RecoveryStrategy sends prep recovery cmd without setting request 
> time out. But this can be long running request, so if we have network 
> partition in the middle of the request. Recovering core will stay down 
> forever.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9722) Can not parse query contains space before forward slash

[JIRA]

Muḥammad T Jack created SOLR-9722:
-

 Summary: Can not parse query contains space before forward slash
 Key: SOLR-9722
 URL: https://issues.apache.org/jira/browse/SOLR-9722
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: query parsers, search, SolrCloud
Affects Versions: 5.5.2
Reporter: Muḥammad T Jack


Hi,

I got an error when do search on Solr 5.5.2, but works fine on Solr  1.4.

for q:
works fine:a/b
 a/ b
 a b
but not work: a / b
"msg": "org.apache.solr.search.SyntaxError: Cannot parse 'a / b': Lexical error 
at line 1, column 6.  Encountered:  after : \"/ b\"",

our data contains a company name called "Zuo Zuo / Zuozuo Dessert Nouyo"
It just related query parse.
So. what is the difference between 'a/ b' and 'a / b' ?
It's not work for us on Solr 5.5.2.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9720) Refactor responsewriter to remove dependencies on TupleStream etc

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9720:
-
Attachment: SOLR-9720.patch

> Refactor responsewriter to remove dependencies on TupleStream etc
> -
>
> Key: SOLR-9720
> URL: https://issues.apache.org/jira/browse/SOLR-9720
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9720.patch, SOLR-9720.patch, SOLR-9720.patch
>
>
> ResponseWriters are designed to be agnostic of components and they should 
> work with the well know set of types we already support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9717) "xsort" ResponseWriter should support javabin and other formats

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9717:
-
Summary: "xsort" ResponseWriter should support javabin and other formats  
(was: "xsort" ResponseWriter should support javabin)

> "xsort" ResponseWriter should support javabin and other formats
> ---
>
> Key: SOLR-9717
> URL: https://issues.apache.org/jira/browse/SOLR-9717
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> The Response JSON is written in an ad hoc way. Standardize the way the docs 
> are written and support javabin as well



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9712) Saner default for maxWarmingSearchers

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9712:
-

bq. One needs a reliable "update this document and make it visible, and don't 
return until it is visible" in conjunction with "let's not warm more than one 
searcher at a time".

I thought the first part was the reason behind waitSearcher=true? Agreed that 
we need to fix the second part. As David said, the commits should block by 
default instead of happening concurrently. Otherwise we cannot easily reason 
about memory consumption when multiple clients call commit.

> Saner default for maxWarmingSearchers
> -
>
> Key: SOLR-9712
> URL: https://issues.apache.org/jira/browse/SOLR-9712
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.4
>
>
> As noted in SOLR-9710, the default for maxWarmingSearchers is 
> Integer.MAX_VALUE which is just crazy. Let's have a saner default. Today we 
> log a performance warning when the number of on deck searchers goes over 1. 
> What if we had the default as 1 that expert users can increase if needed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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