Re: Strangeness with MultiSpansWrapper duplication

[Alan Woodward]

Ugh, I think that's a merge error on my part.  You should be fine to nuke the 
lucene/core version.

Alan Woodward
www.flax.co.uk


On 1 Oct 2015, at 01:06, Shawn Heisey wrote:

> In branch_5x, the MultiSpansWrapper.java file exists in two places.  I
> only noticed this because of an error in eclipse.  The two files look
> identical.  This doesn't seem to cause any actual problems with the
> build, just the IDE error.
> 
> One copyishere:
> 
> lucene/test-framework/src/java/org/apache/lucene/search/spans/MultiSpansWrapper.java
> 
> The other is here:
> 
> lucene/core/src/test/org/apache/lucene/search/spans/MultiSpansWrapper.java
> 
> It appears that trunk doesn't have this problem, and only the copy in
> test-framework exists.
> 
> Here is a patch that removes the extra copy in 5.x:
> 
> https://www.dropbox.com/s/tij4ckt84l971hx/nuke-multispans.patch?dl=0
> 
> I can open an issue and remove the extra file, if everyone thinks that's
> a good idea.  The core tests passed with this patch applied, but the
> benchmark tests failed with an access denied problem that seems
> completely unrelated.  I will pound on it some more to be sure I don't
> see any problems.
> 
> Thanks,
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

[Alex Watson (JIRA)]

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

Alex Watson commented on LUCENE-2899:
-

I have tried this patch with the current trunk, it patches fine but when it 
goes to compile there are a lot of errors, some are easily fixed issues with 
java 8 being more strict but there are a few which are caused by method 
signatures being different.

Will there be an updated patch to fix these issues?

What is the status of this being fully integrated in to the trunk so a patch is 
not required?

> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 4.9, Trunk
>
> Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, 
> OpenNLPFilter.java, OpenNLPTokenizer.java
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice 
> to have a submodule (under analysis) that exposed capabilities for it. Drew 
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp



--
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-8101) Installation script permission issues and other scripts fixes

[Sergey Urushkin (JIRA)]

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

Sergey Urushkin updated SOLR-8101:
--
Attachment: solr-scripts-v3.patch

It seems that solr v.5.3.1 doesn't need rw permisstions to 
{{$SOLR_INSTALL_DIR/server/solr-webapp}} and  
{{$SOLR_INSTALL_DIR/server/logs}}, so whole {{$SOLR_INSTALL_DIR}} should only 
be readable by {{$SOLR_USER}}. Attached patch v3.

> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: solr-5.3.1.patch, solr-scripts-v2.patch, 
> solr-scripts-v3.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as 
> they may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
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-8101) Installation script permission issues and other scripts fixes

[Sergey Urushkin (JIRA)]

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

Sergey Urushkin updated SOLR-8101:
--
Description: 
Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest to 
improve current shell scripts. Provided patch:
  *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
will be run by root on start/shutdown.
  * changes permissions. {{$SOLR_USER}} should only be able to write to 
{{$SOLR_VAR_DIR}}. This directory should not be readable by other users as they 
may contain personal information.
  * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
there is no need in {{/home/solr}} directory.
  * adds quotes to unquoted variables
  * adds leading zero to chmod commands
  * removes group from chown commands (uses ":")
  * adds {{-f}} option to 

Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.

  was:
Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest to 
improve current shell scripts. Provided patch:
  *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
will be run by root on start/shutdown.
  * changes permissions. {{$SOLR_USER}} should only be able to write to 
{{$SOLR_VAR_DIR}}. This directory should not be readable by other users as they 
may contain personal information.
  * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
there is no need in {{/home/solr}} directory.
  * adds quotes to unquoted variables
  * adds leading zero to chmod commands
  * removes group from chown commands (uses ":")
  * adds {{-f}}

Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.


> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: solr-5.3.1.patch, solr-scripts-v2.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as 
> they may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
>   * adds {{-f}} option to 
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
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-8101) Installation script permission issues and other scripts fixes

[Sergey Urushkin (JIRA)]

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

Sergey Urushkin updated SOLR-8101:
--
Description: 
Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest to 
improve current shell scripts. Provided patch:
  *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
will be run by root on start/shutdown.
  * changes permissions. {{$SOLR_USER}} should only be able to write to 
{{$SOLR_VAR_DIR}}. This directory should not be readable by other users as it 
may contain personal information.
  * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
there is no need in {{/home/solr}} directory.
  * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
safely upgrade Solr.
  * adds quotes to unquoted variables
  * adds leading zero to chmod commands
  * removes group from chown commands (uses ":")

Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.

  was:
Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest to 
improve current shell scripts. Provided patch:
  *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
will be run by root on start/shutdown.
  * changes permissions. {{$SOLR_USER}} should only be able to write to 
{{$SOLR_VAR_DIR}}. This directory should not be readable by other users as they 
may contain personal information.
  * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
there is no need in {{/home/solr}} directory.
  * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
safely upgrade Solr.
  * adds quotes to unquoted variables
  * adds leading zero to chmod commands
  * removes group from chown commands (uses ":")

Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.


> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: solr-5.3.1.patch, solr-scripts-v2.patch, 
> solr-scripts-v3.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as it 
> may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
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-8111) Requests always pick the first shard when the collection is present locally

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-8111:
---

 Summary: Requests always pick the first shard when the collection 
is present locally
 Key: SOLR-8111
 URL: https://issues.apache.org/jira/browse/SOLR-8111
 Project: Solr
  Issue Type: Bug
Reporter: Varun Thacker
Priority: Minor


Currently we always pick the first shard present locally for a request against 
a collection preferring the leader.

Since we are doing this locally it doesn't even matter which replica we pick. 
Picking a leader will be slightly more efficient for updates.

We should refactor {{HttpSolrCall#getCoreByCollection}} to check for leaders of 
all shards before picking any other replica. Right now we just do it for the 
first shard.



--
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-8101) Installation script permission issues and other scripts fixes

[Sergey Urushkin (JIRA)]

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

Sergey Urushkin updated SOLR-8101:
--
Description: 
Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest to 
improve current shell scripts. Provided patch:
  *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
will be run by root on start/shutdown.
  * changes permissions. {{$SOLR_USER}} should only be able to write to 
{{$SOLR_VAR_DIR}}. This directory should not be readable by other users as they 
may contain personal information.
  * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
there is no need in {{/home/solr}} directory.
  * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
safely upgrade Solr.
  * adds quotes to unquoted variables
  * adds leading zero to chmod commands
  * removes group from chown commands (uses ":")

Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.

  was:
Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest to 
improve current shell scripts. Provided patch:
  *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
will be run by root on start/shutdown.
  * changes permissions. {{$SOLR_USER}} should only be able to write to 
{{$SOLR_VAR_DIR}}. This directory should not be readable by other users as they 
may contain personal information.
  * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
there is no need in {{/home/solr}} directory.
  * adds quotes to unquoted variables
  * adds leading zero to chmod commands
  * removes group from chown commands (uses ":")
  * adds {{-f}} option to 

Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.


> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: solr-5.3.1.patch, solr-scripts-v2.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as 
> they may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
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-5.x-MacOSX (64bit/jdk1.8.0) - Build # 2715 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2715/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([19E656938EF54EA7:91B269492009235F]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:485)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1505)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:211)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Resolved] (LUCENE-6650) Remove dependency of lucene/spatial on oal.search.Filter

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-6650.
--
   Resolution: Fixed
Fix Version/s: 5.4

(I didn't bother going with the Function)

> Remove dependency of lucene/spatial on oal.search.Filter
> 
>
> Key: LUCENE-6650
> URL: https://issues.apache.org/jira/browse/LUCENE-6650
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: David Smiley
> Fix For: 5.4
>
> Attachments: LUCENE-6650.patch, LUCENE-6650.patch
>
>
> We should try to remove usage of oal.search.Filter in lucene/spatial. I gave 
> it a try but this module makes non-trivial use of filters so I wouldn't mind 
> some help here.



--
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-trunk-Linux (64bit/jdk1.8.0_60) - Build # 14367 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14367/
Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestMiniSolrCloudClusterBase

Error Message:
91 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase: 1) Thread[id=2784, 
name=qtp1271173983-2784-selector-ServerConnectorManager@27a5e10a/0, 
state=RUNNABLE, group=TGRP-TestMiniSolrCloudClusterBase] at 
sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600)
 at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549)
 at 
org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52)  
   at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=2888, 
name=coreContainerWorkExecutor-1208-thread-1, state=TIMED_WAITING, 
group=TGRP-TestMiniSolrCloudClusterBase] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)3) Thread[id=2905, 
name=zkCallback-453-thread-3, state=TIMED_WAITING, 
group=TGRP-TestMiniSolrCloudClusterBase] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)4) Thread[id=2882, 
name=coreContainerWorkExecutor-1216-thread-1, state=TIMED_WAITING, 
group=TGRP-TestMiniSolrCloudClusterBase] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)5) Thread[id=2911, 
name=zkCallback-455-thread-3, state=TIMED_WAITING, 
group=TGRP-TestMiniSolrCloudClusterBase] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)6) Thread[id=2800, 

[jira] [Updated] (SOLR-8101) Installation script permission issues and other scripts fixes

[Sergey Urushkin (JIRA)]

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

Sergey Urushkin updated SOLR-8101:
--
Attachment: (was: solr-scripts-v3.patch)

> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: solr-5.3.1.patch, solr-scripts-v2.patch, 
> solr-scripts-v3.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as 
> they may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
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-8101) Installation script permission issues and other scripts fixes

[Sergey Urushkin (JIRA)]

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

Sergey Urushkin updated SOLR-8101:
--
Attachment: solr-scripts-v3.patch

> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: solr-5.3.1.patch, solr-scripts-v2.patch, 
> solr-scripts-v3.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as 
> they may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
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-6785) Consider merging Query.rewrite() into Query.createWeight()

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-6785:
---

The API isn't as tidy, but I think you're right that this gives us more 
flexibility when it comes to query optimization, etc.  I'll extend the patch to 
all modules.  Thanks!

> Consider merging Query.rewrite() into Query.createWeight()
> --
>
> Key: LUCENE-6785
> URL: https://issues.apache.org/jira/browse/LUCENE-6785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
> Attachments: LUCENE-6785-alt.patch, LUCENE-6785.patch, 
> LUCENE-6785.patch
>
>
> Prompted by the discussion on LUCENE-6590.
> Query.rewrite() is a bit of an oddity.  You call it to create a query for a 
> specific IndexSearcher, and to ensure that you get a query implementation 
> that has a working createWeight() method.  However, Weight itself already 
> encapsulates the notion of a per-searcher query.
> You also need to repeatedly call rewrite() until the query has stopped 
> rewriting itself, which is a bit trappy - there are a few places (in 
> highlighting code for example) that just call rewrite() once, rather than 
> looping round as IndexSearcher.rewrite() does.  Most queries don't need to be 
> called multiple times, however, so this seems a bit redundant.  And the ones 
> that do currently return un-rewritten queries can be changed simply enough to 
> rewrite them.
> Finally, in pretty much every case I can find in the codebase, rewrite() is 
> called purely as a prelude to createWeight().  This means, in the case of for 
> example large BooleanQueries, we end up cloning the whole query structure, 
> only to throw it away immediately.
> I'd like to try removing rewrite() entirely, and merging the logic into 
> createWeight(), simplifying the API and removing the trap where code only 
> calls rewrite once.  What do people think?



--
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-8101) Installation script permission issues and other scripts fixes

[Sergey Urushkin (JIRA)]

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

Sergey Urushkin edited comment on SOLR-8101 at 10/1/15 11:01 AM:
-

It seems that solr v.5.3.1 doesn't need rw permissions to 
{{$SOLR_INSTALL_DIR/server/solr-webapp}} and  
{{$SOLR_INSTALL_DIR/server/logs}}, so whole {{$SOLR_INSTALL_DIR}} should only 
be readable by {{$SOLR_USER}}. Attached patch v3.


was (Author: urusha):
It seems that solr v.5.3.1 doesn't need rw permisstions to 
{{$SOLR_INSTALL_DIR/server/solr-webapp}} and  
{{$SOLR_INSTALL_DIR/server/logs}}, so whole {{$SOLR_INSTALL_DIR}} should only 
be readable by {{$SOLR_USER}}. Attached patch v3.

> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: solr-5.3.1.patch, solr-scripts-v2.patch, 
> solr-scripts-v3.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as 
> they may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
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-8101) Installation script permission issues and other scripts fixes

[Sergey Urushkin (JIRA)]

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

Sergey Urushkin updated SOLR-8101:
--
Description: 
Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest to 
improve current shell scripts. Provided patch:
  *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
will be run by root on start/shutdown.
  * changes permissions. {{$SOLR_USER}} should only be able to write to 
{{$SOLR_VAR_DIR}}. This directory should not be readable by other users as they 
may contain personal information.
  * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
there is no need in {{/home/solr}} directory.
  * adds quotes to unquoted variables
  * adds leading zero to chmod commands
  * removes group from chown commands (uses ":")
  * adds {{-f}}

Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.

  was:
Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest to 
improve current shell scripts. Provided patch:
  *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
will be run by root on start/shutdown.
  * changes permissions. {{$SOLR_USER}} should only be able to write to 
{{$SOLR_VAR_DIR}} {{$SOLR_INSTALL_DIR/server/solr-webapp}} 
{{$SOLR_INSTALL_DIR/server/logs}} . {{solr-webapp}} directory might be 
inspected more. These directories should not be readable by other users as they 
may contain personal information.
  * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
there is no need in {{/home/solr}} directory.
  * adds quotes to unquoted variables
  * adds leading zero to chmod commands
  * removes group from chown commands (uses ":")

Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.


> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: solr-5.3.1.patch, solr-scripts-v2.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as 
> they may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
>   * adds {{-f}}
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
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-7227) Solr distribution archive should have the WAR file extracted already

[Timothy Potter (JIRA)]

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

Timothy Potter resolved SOLR-7227.
--
Resolution: Fixed

This was fixed in 5.3, just didn't get closed out. Thanks for the help on this 
Uwe

> Solr distribution archive should have the WAR file extracted already
> 
>
> Key: SOLR-7227
> URL: https://issues.apache.org/jira/browse/SOLR-7227
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.0
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: Trunk, 5.3
>
> Attachments: SOLR-7227-part2.patch, SOLR-7227-part2.patch, 
> SOLR-7227-part2.patch, SOLR-7227-part2.patch, SOLR-7227-part2.patch, 
> SOLR-7227-part2.patch, SOLR-7227.patch, SOLR-7227.patch
>
>
> Currently, there is still the solr.war file in the server/webapps directory, 
> which gets extracted upon first startup of Solr. It would be better to ship 
> Solr with the WAR already extracted, thus taking us one step closer to truly 
> not shipping a WAR file. Moreover, some users have reported not being able to 
> make /opt/solr truly read-only because of the need to extract the WAR 
> on-the-fly upon first startup.



--
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-8107) bin/solr -f should use exec

[Timothy Potter (JIRA)]

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

Timothy Potter reassigned SOLR-8107:


Assignee: Timothy Potter

> bin/solr -f should use exec
> ---
>
> Key: SOLR-8107
> URL: https://issues.apache.org/jira/browse/SOLR-8107
> Project: Solr
>  Issue Type: Bug
>Reporter: Martijn Koster
>Assignee: Timothy Potter
>Priority: Minor
>
> When you run {{bin/solr -f}}, bash invokes java as a sub-process.
> If you {{kill -TERM}} the script, java gets terminated uncleanly.
> The script should invoke java using {{exec}}: then, when you send a {{TERM}}, 
> it stops ServerConnector and shuts down the core. And you save yourself a 
> process in the process.
> See this patch https://gist.github.com/makuk66/5ba75e8d592bf5428611



--
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-7641) bin/solr script checks for the presence of the JAR command before resolving java (where it might also find jar)

[Timothy Potter (JIRA)]

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

Timothy Potter resolved SOLR-7641.
--
Resolution: Won't Fix

As of 5.3, the WAR is extracted so bin/solr doesn't need jar or unzip available 
anymore.

> bin/solr script checks for the presence of the JAR command before resolving 
> java (where it might also find jar)
> ---
>
> Key: SOLR-7641
> URL: https://issues.apache.org/jira/browse/SOLR-7641
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.3
>
>
> I have SOLR_JAVA_HOME set to point to a valid JDK in my bin/solr.in.sh
> {code}
> SOLR_JAVA_HOME="/home/ubuntu/jdk1.8.0_45"
> {code}
> Note: I do not have JAVA_HOME set in my environment nor is it in my PATH.
> And yet, when I run bin/solr, I get the following error:
> {code}
> $ bin/solr start -cloud -p 8984 -d cloud84 -f
> This script requires extracting a WAR file with either the jar or unzip 
> utility, please install these utilities or contact your administrator for 
> assistance.
> {code}
> I think this code in bin/solr should be after the script resolves the 
> location of "java" so it can check there for "jar" and use that rather than 
> failing the script as it's doing now.
> {code}
> if hash jar 2>/dev/null ; then  # hash returns true if jar is on the path
>   UNPACK_WAR_CMD=("$(command -v jar)" xf)
> elif hash unzip 2>/dev/null ; then  # hash returns true if unzip is on the 
> path
>   UNPACK_WAR_CMD=("$(command -v unzip)" -q)
> else
>   echo -e "This script requires extracting a WAR file with either the jar or 
> unzip utility, please install these utilities or contact your administrator 
> for assistance."
>   exit 1
> fi
> {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-6398) Usability and documentation issues found trying to build an RC using dev-tools/scripts/buildAndPushRelease.py

[Timothy Potter (JIRA)]

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

Timothy Potter commented on LUCENE-6398:


Hi Noble - since you did the last couple of releases, I'm assigning this to you 
to either close out if you think the docs are up-to-date and reflect the 
process or to make changes as you see fit.

> Usability and documentation issues found trying to build an RC using 
> dev-tools/scripts/buildAndPushRelease.py
> -
>
> Key: LUCENE-6398
> URL: https://issues.apache.org/jira/browse/LUCENE-6398
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: -tools
>Reporter: Timothy Potter
>Assignee: Noble Paul
>
> This ticket is to address usability and documentation problems found while 
> trying to do the 5.1 RC. Overall, it's a powerful process, but want to make 
> it a bit easier for newbies doing it the first time.
> Here's the start:
> 1) dev-tools/scripts/buildAndPushRelease.py
> Prompts you for the following:
> {code}
> Enter GPG keystore password: 
> {code}
> It's really asking for the passphrase the key you're using to sign the 
> release artifacts, so it seems like it should prompt for something like:
> {code}
> Enter secret passphrase for key:
> {code}
> 2. At the end of a release build, the scripts says:
> {code}
> Next set the PYTHON_EXEC env var and you can run the smoker tester:
>   $PYTHON_EXEC dev-tools/scripts/buildAndPushRelease.py URL
> {code}
> Running that command verbatim, you get an error:
> {code}
> usage: buildAndPushRelease.py [-h] [--no-prepare] [--push-remote USERNAME]
>   [--push-local PATH] [--sign KEYID]
>   [--rc-num NUM] [--smoke-test PATH]
>   checkout_path
> buildAndPushRelease.py: error: Root path is not a valid lucene-solr checkout
> [~/dev/lw/projects/lucene_solr_5_1]$ $PYTHON_EXEC 
> dev-tools/scripts/buildAndPushRelease.py --smoke-test 
> file:///Users/timpotter/dev/lw/releases/5.1rc1/lucene-solr-5.1.0-RC1-rev1671632
> usage: buildAndPushRelease.py [-h] [--no-prepare] [--push-remote USERNAME]
>   [--push-local PATH] [--sign KEYID]
>   [--rc-num NUM] [--smoke-test PATH]
>   checkout_path
> buildAndPushRelease.py: error: the following arguments are required: 
> checkout_path
> {code}
> So we need to fix the example to display what is actually needed to run.
> Will add more to the docs as I go thru the process, but wanted to get a 
> ticket in place for making improvements.



--
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-6398) Usability and documentation issues found trying to build an RC using dev-tools/scripts/buildAndPushRelease.py

[Timothy Potter (JIRA)]

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

Timothy Potter updated LUCENE-6398:
---
Assignee: Noble Paul  (was: Timothy Potter)

> Usability and documentation issues found trying to build an RC using 
> dev-tools/scripts/buildAndPushRelease.py
> -
>
> Key: LUCENE-6398
> URL: https://issues.apache.org/jira/browse/LUCENE-6398
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: -tools
>Reporter: Timothy Potter
>Assignee: Noble Paul
>
> This ticket is to address usability and documentation problems found while 
> trying to do the 5.1 RC. Overall, it's a powerful process, but want to make 
> it a bit easier for newbies doing it the first time.
> Here's the start:
> 1) dev-tools/scripts/buildAndPushRelease.py
> Prompts you for the following:
> {code}
> Enter GPG keystore password: 
> {code}
> It's really asking for the passphrase the key you're using to sign the 
> release artifacts, so it seems like it should prompt for something like:
> {code}
> Enter secret passphrase for key:
> {code}
> 2. At the end of a release build, the scripts says:
> {code}
> Next set the PYTHON_EXEC env var and you can run the smoker tester:
>   $PYTHON_EXEC dev-tools/scripts/buildAndPushRelease.py URL
> {code}
> Running that command verbatim, you get an error:
> {code}
> usage: buildAndPushRelease.py [-h] [--no-prepare] [--push-remote USERNAME]
>   [--push-local PATH] [--sign KEYID]
>   [--rc-num NUM] [--smoke-test PATH]
>   checkout_path
> buildAndPushRelease.py: error: Root path is not a valid lucene-solr checkout
> [~/dev/lw/projects/lucene_solr_5_1]$ $PYTHON_EXEC 
> dev-tools/scripts/buildAndPushRelease.py --smoke-test 
> file:///Users/timpotter/dev/lw/releases/5.1rc1/lucene-solr-5.1.0-RC1-rev1671632
> usage: buildAndPushRelease.py [-h] [--no-prepare] [--push-remote USERNAME]
>   [--push-local PATH] [--sign KEYID]
>   [--rc-num NUM] [--smoke-test PATH]
>   checkout_path
> buildAndPushRelease.py: error: the following arguments are required: 
> checkout_path
> {code}
> So we need to fix the example to display what is actually needed to run.
> Will add more to the docs as I go thru the process, but wanted to get a 
> ticket in place for making improvements.



--
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-5.x-Solaris (multiarch/jdk1.7.0) - Build # 91 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/91/
Java: multiarch/jdk1.7.0 -d64 -XX:-UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Didn't see replicas [core_node1, core_node3] come up within 9 ms! 
ClusterState: DocCollection(c8n_1x3_lf)={   "autoAddReplicas":"false",   
"router":{"name":"compositeId"},   "replicationFactor":"3",   
"maxShardsPerNode":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"c8n_1x3_lf_shard1_replica1",   
"node_name":"127.0.0.1:35231__w%2Fdr",   
"base_url":"http://127.0.0.1:35231/_w/dr;,   "state":"recovering"}, 
"core_node2":{   "core":"c8n_1x3_lf_shard1_replica3",   
"node_name":"127.0.0.1:61202__w%2Fdr",   
"base_url":"http://127.0.0.1:61202/_w/dr;,   "state":"down"}, 
"core_node3":{   "core":"c8n_1x3_lf_shard1_replica2",   
"node_name":"127.0.0.1:49167__w%2Fdr",   
"base_url":"http://127.0.0.1:49167/_w/dr;,   "state":"active",  
 "leader":"true"}

Stack Trace:
java.lang.AssertionError: Didn't see replicas [core_node1, core_node3] come up 
within 9 ms! ClusterState: DocCollection(c8n_1x3_lf)={
  "autoAddReplicas":"false",
  "router":{"name":"compositeId"},
  "replicationFactor":"3",
  "maxShardsPerNode":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "node_name":"127.0.0.1:35231__w%2Fdr",
  "base_url":"http://127.0.0.1:35231/_w/dr;,
  "state":"recovering"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "node_name":"127.0.0.1:61202__w%2Fdr",
  "base_url":"http://127.0.0.1:61202/_w/dr;,
  "state":"down"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:49167__w%2Fdr",
  "base_url":"http://127.0.0.1:49167/_w/dr;,
  "state":"active",
  "leader":"true"}
at 
__randomizedtesting.SeedInfo.seed([97B30B7C3114AA3:812F0F6D6DED275B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.HttpPartitionTest.waitToSeeReplicasActive(HttpPartitionTest.java:689)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:178)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_60) - Build # 5297 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5297/
Java: 64bit/jdk1.8.0_60 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
ERROR: SolrIndexSearcher opens=51 closes=50

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([AA0BABB900633613]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233)
at sun.reflect.GeneratedMethodAccessor46.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=12892, name=searcherExecutor-6751-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=12892, name=searcherExecutor-6751-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([AA0BABB900633613]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=12892, 

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b78) - Build # 14371 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14371/
Java: 32bit/jdk1.9.0-ea-b78 -client -XX:+UseG1GC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithKerberosAlt

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=2212, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)2) Thread[id=2211, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)3) Thread[id=2210, 
name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)4) Thread[id=2209, 
name=apacheds, state=WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] 
at java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)5) Thread[id=2213, 
name=groupCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 
   1) Thread[id=2212, name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-TestSolrCloudWithKerberosAlt]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 

[jira] [Created] (SOLR-8112) HdfsTransactionLog#rollback should throw a not supported exception.

[Mark Miller (JIRA)]

Mark Miller created SOLR-8112:
-

 Summary: HdfsTransactionLog#rollback should throw a not supported 
exception.
 Key: SOLR-8112
 URL: https://issues.apache.org/jira/browse/SOLR-8112
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor


This method currently won't work until we get hdfs truncate support in 2.8.

Nothing currently calls this, we work around lack of support in HdfsUpdateLog, 
but we should clean this up anyway.



--
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-8095) Allow disabling HDFS Locality Metrics

[ASF subversion and git services (JIRA)]

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

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

Commit 1706307 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1706307 ]

SOLR-8095: Allow disabling HDFS Locality Metrics and disable by default as it 
may have performance implications on rapidly changing indexes.

> Allow disabling HDFS Locality Metrics
> -
>
> Key: SOLR-8095
> URL: https://issues.apache.org/jira/browse/SOLR-8095
> Project: Solr
>  Issue Type: Bug
>  Components: hdfs
>Reporter: Mike Drob
>Assignee: Mark Miller
>  Labels: metrics
> Fix For: Trunk
>
> Attachments: SOLR-8095.patch
>
>
> We added metrics, but not a way to configure/turn them off.



--
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: Sanity checking in Solr

[Erick Erickson]

Yeah, this would be totally cool. Personally, if it fits into the
debug component
I'd advocate adding it in automatically if debug=all/true, assuming it wasn't
all that expensive at run time.


On Tue, Sep 29, 2015 at 11:26 PM, Toke Eskildsen  
wrote:
> On Tue, 2015-09-29 at 13:30 +0100, Upayavira wrote:
>> Could it be added to the debug component? That seems like a natural
>> place for it. It could, as you say, look for standard things that
>> might make a query perform badly, and report them in a new 
>> element, or such.
>
> Agreed. I'll take a closer look on how the debug mechanism ties into
> Solr. If sanity checking fits well, I'll try and make a proof of concept
> and a JIRA.
>
> - Toke Eskildsen, State and University Library, Denmark
>
>
>
>
> -
> 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] [Assigned] (SOLR-8095) Allow disabling HDFS Locality Metrics

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-8095:
-

Assignee: Mark Miller

> Allow disabling HDFS Locality Metrics
> -
>
> Key: SOLR-8095
> URL: https://issues.apache.org/jira/browse/SOLR-8095
> Project: Solr
>  Issue Type: Bug
>  Components: hdfs
>Reporter: Mike Drob
>Assignee: Mark Miller
>  Labels: metrics
> Fix For: Trunk
>
> Attachments: SOLR-8095.patch
>
>
> We added metrics, but not a way to configure/turn them off.



--
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-5.x-Linux (64bit/jdk1.9.0-ea-b78) - Build # 14082 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14082/
Java: 64bit/jdk1.9.0-ea-b78 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestConfigSetsAPIExclusivity.testAPIExclusivity

Error Message:
Unexpected exception: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54738/solr: delete the configset time out:300s 
expected:<0> but was:<1>

Stack Trace:
java.lang.AssertionError: Unexpected exception: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54738/solr: delete the configset time out:300s 
expected:<0> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([C73BD2CE723A10E0:BA4ECB352B9EA9A9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.TestConfigSetsAPIExclusivity.testAPIExclusivity(TestConfigSetsAPIExclusivity.java:95)
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:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 

[jira] [Commented] (SOLR-8095) Allow disabling HDFS Locality Metrics

[ASF subversion and git services (JIRA)]

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

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

Commit 1706302 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1706302 ]

SOLR-8095: Allow disabling HDFS Locality Metrics and disable by default as it 
may have performance implications on rapidly changing indexes.

> Allow disabling HDFS Locality Metrics
> -
>
> Key: SOLR-8095
> URL: https://issues.apache.org/jira/browse/SOLR-8095
> Project: Solr
>  Issue Type: Bug
>  Components: hdfs
>Reporter: Mike Drob
>Assignee: Mark Miller
>  Labels: metrics
> Fix For: Trunk
>
> Attachments: SOLR-8095.patch
>
>
> We added metrics, but not a way to configure/turn them off.



--
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-8025) QueryComponent: remove unnecessary getQueryCommand() calls

[ASF subversion and git services (JIRA)]

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

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

Commit 1706313 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1706313 ]

SOLR-8025: remove unnecessary ResponseBuilder.getQueryCommand() calls

> QueryComponent: remove unnecessary getQueryCommand() calls
> --
>
> Key: SOLR-8025
> URL: https://issues.apache.org/jira/browse/SOLR-8025
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8025.patch
>
>
> patch to follow



--
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-8113) Accept replacement strings in CloneFieldUpdateProcessorFactory

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-8113:
---
Attachment: SOLR-8113.patch

Patch vs 5x

> Accept replacement strings in CloneFieldUpdateProcessorFactory
> --
>
> Key: SOLR-8113
> URL: https://issues.apache.org/jira/browse/SOLR-8113
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 5.3
>Reporter: Gus Heck
> Attachments: SOLR-8113.patch
>
>
> Presently CloneFieldUpdateProcessorFactory accepts regular expressions to 
> select source fields, which mirrors wildcards in the source for copyField in 
> the schema. This patch adds a counterpart to copyField's wildcards in the 
> dest attribute by interpreting the dest parameter as a regex replacement 
> string.



--
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-8113) Accept replacement strings in CloneFieldUpdateProcessorFactory

[Gus Heck (JIRA)]

Gus Heck created SOLR-8113:
--

 Summary: Accept replacement strings in 
CloneFieldUpdateProcessorFactory
 Key: SOLR-8113
 URL: https://issues.apache.org/jira/browse/SOLR-8113
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 5.3
Reporter: Gus Heck


Presently CloneFieldUpdateProcessorFactory accepts regular expressions to 
select source fields, which mirrors wildcards in the source for copyField in 
the schema. This patch adds a counterpart to copyField's wildcards in the dest 
attribute by interpreting the dest parameter as a regex replacement string.




--
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-8113) Accept replacement strings in CloneFieldUpdateProcessorFactory

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-8113:


This was motivated by the response to SOLR-8109. This bridges the gap in the 
suggested alternate solution, but does look like it will likely be a lot less 
performant. I couldn't find a way to re-use the match done by the 
FieldNameSelector, so the regex matches have to execute twice. All attempts I 
made to do that resulted in major API changes.

This is however more flexible, will not interfere with atomic updates (as 
copyField apparently does) and Allows further movement away from the use of 
copyField.

My preference would be for both this and SOLR-8109 to become available since 
speed is one tradeoff, and atomic update support etc is another.

> Accept replacement strings in CloneFieldUpdateProcessorFactory
> --
>
> Key: SOLR-8113
> URL: https://issues.apache.org/jira/browse/SOLR-8113
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 5.3
>Reporter: Gus Heck
> Attachments: SOLR-8113.patch
>
>
> Presently CloneFieldUpdateProcessorFactory accepts regular expressions to 
> select source fields, which mirrors wildcards in the source for copyField in 
> the schema. This patch adds a counterpart to copyField's wildcards in the 
> dest attribute by interpreting the dest parameter as a regex replacement 
> string.



--
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-7766) support creation of a coreless collection

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-7766.
---
   Resolution: Fixed
Fix Version/s: (was: 5.4)
   5.3

Was actually included in 5.3 but i'd just forgotten to close out this ticket, 
apologies.

> support creation of a coreless collection
> -
>
> Key: SOLR-7766
> URL: https://issues.apache.org/jira/browse/SOLR-7766
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: Trunk, 5.3
>
> Attachments: SOLR-7766.patch, SOLR-7766.txt
>
>
> By supplying the special value of EMPTY for the createNodeSet parameter (via 
> {{.../solr/admin/collections?action=CREATE=EMPTY=myCollection&...}})
>  a collection can be created in the usual manner but it will just not yet 
> contain any cores for any of its shards. Later on 
> {{.../solr/admin/collections?wt=json=ADDREPLICA=myCollection&...}}
>  calls can create cores as and when and where required.
> github pull request with proposed changes to follow.



--
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-6780) GeoPointDistanceQuery doesn't work with a large radius?

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-6780:


bq. The failure is clearly a boundary case, so maybe we just need a better "is 
boundary case" check?

Definitely the situation with this failure. The new GeoUtils.compare method was 
returning null for these boundary points so the test was always setting 
expected = false. I've changed it to ignore those boundary test points that are 
within the accepted error tolerance.

> GeoPointDistanceQuery doesn't work with a large radius?
> ---
>
> Key: LUCENE-6780
> URL: https://issues.apache.org/jira/browse/LUCENE-6780
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: LUCENE-6780-heap-used-hack.patch, LUCENE-6780.patch, 
> LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch
>
>
> I'm working on LUCENE-6698 but struggling with test failures ...
> Then I noticed that TestGeoPointQuery's test never tests on large distances, 
> so I modified the test to sometimes do so (like TestBKDTree) and hit test 
> failures.



--
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-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 14372 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14372/
Java: 64bit/jdk1.9.0-ea-b78 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestAuthenticationFramework

Error Message:
71 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestAuthenticationFramework: 1) Thread[id=10481, 
name=Thread-3223, state=WAITING, group=TGRP-TestAuthenticationFramework]
 at java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
org.apache.solr.core.CloserThread.run(CoreContainer.java:1155)2) 
Thread[id=10388, 
name=qtp697101997-10388-selector-ServerConnectorManager@64e42212/2, 
state=RUNNABLE, group=TGRP-TestAuthenticationFramework] at 
sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:600)
 at 
org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:549)
 at 
org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52)  
   at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
at java.lang.Thread.run(Thread.java:746)3) Thread[id=10398, 
name=qtp697101997-10398-acceptor-0@22f017af-ServerConnector@79a87ba2{HTTP/1.1}{127.0.0.1:49445},
 state=RUNNABLE, group=TGRP-TestAuthenticationFramework] at 
sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) at 
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) 
at 
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) 
at 
org.eclipse.jetty.server.ServerConnector.accept(ServerConnector.java:377)   
  at 
org.eclipse.jetty.server.AbstractConnector$Acceptor.run(AbstractConnector.java:500)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
at java.lang.Thread.run(Thread.java:746)4) Thread[id=10403, 
name=qtp482822019-10403, state=TIMED_WAITING, 
group=TGRP-TestAuthenticationFramework] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:389) 
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:531)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.access$700(QueuedThreadPool.java:47)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:590) 
at java.lang.Thread.run(Thread.java:746)5) Thread[id=10417, 
name=Scheduler-956154601, state=TIMED_WAITING, 
group=TGRP-TestAuthenticationFramework] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)6) Thread[id=10411, 
name=qtp1496249653-10411, state=TIMED_WAITING, 
group=TGRP-TestAuthenticationFramework] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:389) 
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.idleJobPoll(QueuedThreadPool.java:531)
 at 
org.eclipse.jetty.util.thread.QueuedThreadPool.access$700(QueuedThreadPool.java:47)
 at 

[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 90 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/90/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.security.PKIAuthenticationIntegrationTest.testPkiAuth

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 10 
seconds
at 
__randomizedtesting.SeedInfo.seed([5D88118CA4532CC:356618492AF3B56D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:836)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1393)
at 
org.apache.solr.security.PKIAuthenticationIntegrationTest.testPkiAuth(PKIAuthenticationIntegrationTest.java:52)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 

[jira] [Resolved] (SOLR-8025) QueryComponent: remove unnecessary getQueryCommand() calls

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-8025.
---
   Resolution: Fixed
Fix Version/s: 5.4
   Trunk

> QueryComponent: remove unnecessary getQueryCommand() calls
> --
>
> Key: SOLR-8025
> URL: https://issues.apache.org/jira/browse/SOLR-8025
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-8025.patch
>
>
> patch to follow



--
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-8025) QueryComponent: remove unnecessary getQueryCommand() calls

[ASF subversion and git services (JIRA)]

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

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

Commit 1706322 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1706322 ]

SOLR-8025: remove unnecessary ResponseBuilder.getQueryCommand() calls (merge in 
revision 1706313 from trunk)

> QueryComponent: remove unnecessary getQueryCommand() calls
> --
>
> Key: SOLR-8025
> URL: https://issues.apache.org/jira/browse/SOLR-8025
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8025.patch
>
>
> patch to follow



--
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-6435) java.util.ConcurrentModificationException: Removal from the cache failed error in SimpleNaiveBayesClassifier

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili commented on LUCENE-6435:
-

thanks Adrien for following up LUCENE-6821, I'll mark this as resolved as the 
classification specific issue has been fixed.

> java.util.ConcurrentModificationException: Removal from the cache failed 
> error in SimpleNaiveBayesClassifier
> 
>
> Key: LUCENE-6435
> URL: https://issues.apache.org/jira/browse/LUCENE-6435
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/classification
>Affects Versions: 5.1
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk
>
> Attachments: LUCENE-6435.patch, patch.rtf
>
>
> While using {{SimpleNaiveBayesClassifier}} on a very large index (all Italian 
> Wikipedia articles) I see the following code triggering a 
> {{ConcurrentModificationException}} when evicting the {{Query}} from the 
> {{LRUCache}}.
> {code}
> BooleanQuery booleanQuery = new BooleanQuery();
> BooleanQuery subQuery = new BooleanQuery();
> for (String textFieldName : textFieldNames) {
>   subQuery.add(new BooleanClause(new TermQuery(new Term(textFieldName, 
> word)), BooleanClause.Occur.SHOULD));
> }
> booleanQuery.add(new BooleanClause(subQuery, BooleanClause.Occur.MUST));
> booleanQuery.add(new BooleanClause(new TermQuery(new Term(classFieldName, 
> c)), BooleanClause.Occur.MUST));
> //...
> TotalHitCountCollector totalHitCountCollector = new 
> TotalHitCountCollector();
> indexSearcher.search(booleanQuery, totalHitCountCollector);
> return totalHitCountCollector.getTotalHits();
> {code}
> this is the complete stacktrace:
> {code}
> java.util.ConcurrentModificationException: Removal from the cache failed! 
> This is probably due to a query which has been modified after having been put 
> into  the cache or a badly implemented clone(). Query class: [class 
> org.apache.lucene.search.BooleanQuery], query: [#text:panoram #cat:1356]
>   at 
> __randomizedtesting.SeedInfo.seed([B6513DEC3681FEF5:138235BE33532634]:0)
>   at 
> org.apache.lucene.search.LRUQueryCache.evictIfNecessary(LRUQueryCache.java:285)
>   at 
> org.apache.lucene.search.LRUQueryCache.putIfAbsent(LRUQueryCache.java:268)
>   at 
> org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.scorer(LRUQueryCache.java:569)
>   at 
> org.apache.lucene.search.ConstantScoreWeight.scorer(ConstantScoreWeight.java:82)
>   at org.apache.lucene.search.Weight.bulkScorer(Weight.java:137)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:560)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:367)
>   at 
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.getWordFreqForClass(SimpleNaiveBayesClassifier.java:288)
>   at 
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.calculateLogLikelihood(SimpleNaiveBayesClassifier.java:248)
>   at 
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.assignClassNormalizedList(SimpleNaiveBayesClassifier.java:169)
>   at 
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.assignClass(SimpleNaiveBayesClassifier.java:125)
>   at 
> org.apache.lucene.classification.WikipediaTest.testItalianWikipedia(WikipediaTest.java:126)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> 

[jira] [Resolved] (LUCENE-6435) java.util.ConcurrentModificationException: Removal from the cache failed error in SimpleNaiveBayesClassifier

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved LUCENE-6435.
-
   Resolution: Fixed
Fix Version/s: 6.0

> java.util.ConcurrentModificationException: Removal from the cache failed 
> error in SimpleNaiveBayesClassifier
> 
>
> Key: LUCENE-6435
> URL: https://issues.apache.org/jira/browse/LUCENE-6435
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/classification
>Affects Versions: 5.1
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk, 6.0
>
> Attachments: LUCENE-6435.patch, patch.rtf
>
>
> While using {{SimpleNaiveBayesClassifier}} on a very large index (all Italian 
> Wikipedia articles) I see the following code triggering a 
> {{ConcurrentModificationException}} when evicting the {{Query}} from the 
> {{LRUCache}}.
> {code}
> BooleanQuery booleanQuery = new BooleanQuery();
> BooleanQuery subQuery = new BooleanQuery();
> for (String textFieldName : textFieldNames) {
>   subQuery.add(new BooleanClause(new TermQuery(new Term(textFieldName, 
> word)), BooleanClause.Occur.SHOULD));
> }
> booleanQuery.add(new BooleanClause(subQuery, BooleanClause.Occur.MUST));
> booleanQuery.add(new BooleanClause(new TermQuery(new Term(classFieldName, 
> c)), BooleanClause.Occur.MUST));
> //...
> TotalHitCountCollector totalHitCountCollector = new 
> TotalHitCountCollector();
> indexSearcher.search(booleanQuery, totalHitCountCollector);
> return totalHitCountCollector.getTotalHits();
> {code}
> this is the complete stacktrace:
> {code}
> java.util.ConcurrentModificationException: Removal from the cache failed! 
> This is probably due to a query which has been modified after having been put 
> into  the cache or a badly implemented clone(). Query class: [class 
> org.apache.lucene.search.BooleanQuery], query: [#text:panoram #cat:1356]
>   at 
> __randomizedtesting.SeedInfo.seed([B6513DEC3681FEF5:138235BE33532634]:0)
>   at 
> org.apache.lucene.search.LRUQueryCache.evictIfNecessary(LRUQueryCache.java:285)
>   at 
> org.apache.lucene.search.LRUQueryCache.putIfAbsent(LRUQueryCache.java:268)
>   at 
> org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.scorer(LRUQueryCache.java:569)
>   at 
> org.apache.lucene.search.ConstantScoreWeight.scorer(ConstantScoreWeight.java:82)
>   at org.apache.lucene.search.Weight.bulkScorer(Weight.java:137)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:560)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:367)
>   at 
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.getWordFreqForClass(SimpleNaiveBayesClassifier.java:288)
>   at 
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.calculateLogLikelihood(SimpleNaiveBayesClassifier.java:248)
>   at 
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.assignClassNormalizedList(SimpleNaiveBayesClassifier.java:169)
>   at 
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.assignClass(SimpleNaiveBayesClassifier.java:125)
>   at 
> org.apache.lucene.classification.WikipediaTest.testItalianWikipedia(WikipediaTest.java:126)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
>   at 
> 

Re: Solr search

[Upayavira]

There are some dependencies that are dual licensed, e.g GPL and MIT. we
are accepting them under the terms of the MIT license NOT the GPL. Thus,
you can be sure that the software included in Lucene or Solr will not
include any code for which you must follow the obligations of the GPL.

upayavira


On Thu, Oct 1, 2015, at 06:56 AM, Uwe Schindler wrote:
> Hi,


>


> The licenses of those files are all explained and listed in the
> licenses/ subdirectory of the Solr distribution (same for Lucene). All
> those 3 files are Apache 2.0 license, see corresponding files:


> -ant-LICENSE-ASL.txt, but I think you are talking about junit4-ant-LICENSE-
> ASL.txt


> -commons-fileupload-LICENSE-ASL.txt


> -xercesImpl-LICENSE-ASL.txt


>


> If you have any doubt about the used licenses, please clearly state
> the lines of code that you think are GPL.


>


> There is lots of other code under MIT license (“ls
> licenses/**MIT**.txt”), which is perfectly valid for Apache products.


> But there is no GPL code listed in our official license records, which
> would violate Apache’s license restrictions.


>


> The files of xerces or fileupload that you mention cannot be
> removed, only ant/junit4-ant can be removed – because it is a test
> dependency only.


>


> Uwe


>


> -


> Uwe Schindler


> H.-H.-Meier-Allee 63, D-28213 Bremen


> http://www.thetaphi.de[1]


> eMail: u...@thetaphi.de


>


> *From:* vetrik kumaran murugesan [mailto:vetri...@gmail.com] *Sent:*
> Thursday, October 01, 2015 3:11 AM *To:* dev@lucene.apache.org
> *Subject:* Re: Solr search

>


> Hi Upayavira,


>


> Thanks for your quick reply.


>


> Files above use GPL and MIT license , like junit4-ant 2.1.13 has  GPL
> and MIT.


>


> Regards,


>


> Vetrik


>


>


>


> 2015-09-30 17:27 GMT-05:00 Upayavira :


> On Wed, Sep 30, 2015, at 10:55 PM, vetrik kumaran murugesan wrote:


>> Dear Team,


>>


>> I am wondering can we use Solr 5.3 search  server  without the
>> following jar files,


>>


>> commonsfileupload: 1.2.1


>> xerces : xercesImpl : 2.9.1


>> org.apache.ant : ant : 1.8.2


>>


>>


>> If yes , how can I do it. I am trying to evaluate Solr 5.3 , you
>> input is valuable and appreciated.


>


> Why would you want to do that?


>


> xerces is an XML parser. It wouldn't surprise me if Solr couldn't load
> its configs without it. Seems kinda important.


>


> All the files you mention above are (as far as I understand) Apache
> code, therefore Apache licensed. Why is their use a factor in your
> evaluation?


>


> Upayavira


>





Links:

  1. http://www.thetaphi.de/

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60) - Build # 14076 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14076/
Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([F0FF9B7E7707AE4D:2B8E7BB440726B2B]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1084)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:953)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:485)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464)
at 
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:443)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (LUCENE-6823) Remove use of System.currentTimeMillis() from LocalReplicator

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated LUCENE-6823:
-
Attachment: LUCENE-6823.patch

Patch to replace it with System.nanoTime()/100.

> Remove use of System.currentTimeMillis() from LocalReplicator
> -
>
> Key: LUCENE-6823
> URL: https://issues.apache.org/jira/browse/LUCENE-6823
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: LUCENE-6823.patch
>
>
> LocalReplicator uses System.currentTimeMillis() for session expiry, which is 
> not guaranteed monotonic.



--
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-trunk-Windows (64bit/jdk1.8.0_60) - Build # 5298 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5298/
Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseSerialGC

4 tests failed.
FAILED:  org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([2B97F889CBD6F9C4:164F56A5F338A7B4]:0)
at java.util.LinkedList$ListItr.next(LinkedList.java:893)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.shutdown(MiniSolrCloudCluster.java:380)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:202)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestMiniSolrCloudClusterBase

Error Message:
91 threads leaked from SUITE scope at 

[jira] [Created] (LUCENE-6823) Remove use of System.currentTimeMillis() from LocalReplicator

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created LUCENE-6823:


 Summary: Remove use of System.currentTimeMillis() from 
LocalReplicator
 Key: LUCENE-6823
 URL: https://issues.apache.org/jira/browse/LUCENE-6823
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Ishan Chattopadhyaya
Priority: Minor


LocalReplicator uses System.currentTimeMillis() for session expiry, which is 
not guaranteed monotonic.



--
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-7282) Cache config or index schema objects by configset and share them across cores

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7282:


Something to think about, and this might affect the existing non-cloud feature 
"shareSchema" too:

If the actual Java object is shared, we need to be careful about behavior on 
reload.  Users expect that updating the config in zookeeper will not cause 
immediate usage of that config, that they will have to do a reload before it 
will take effect.  Say that one machine, updated with a Solr version that has a 
fix for this issue, hosts ten cores that are replicas for various shards from 
Collection A.  Those ten cores are all sharing Java objects for config and 
schema.

When the user updates the config in zookeeper that for collection A, here's how 
I think everything should play out:

 * The objects that those ten cores are sharing will NOT be updated by the 
change to zookeeper -- they will still contain info from the config before 
modification.
 * When one of those cores is reloaded, it should create new objects holding 
the new information in zookeeper, but the other cores for that collection will 
still have the old objects with the old config.
 * When a second and subsequent cores are reloaded, they should share the 
objects created during the first core reload.

The coding challenge will be to figure out when the existing set of config 
objects (probably at the CoreContainer level) need to be thrown away (but still 
held by existing cores) and replaced with a new set of objects.  I'm guessing 
that the config znode in zookeeper contains some info that will only change 
when the config is updated, that info could probably be used.

> Cache config or index schema objects by configset and share them across cores
> -
>
> Key: SOLR-7282
> URL: https://issues.apache.org/jira/browse/SOLR-7282
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-7282.patch
>
>
> Sharing schema and config objects has been known to improve startup 
> performance when a large number of cores are on the same box (See 
> http://wiki.apache.org/solr/LotsOfCores).Damien also saw improvements to 
> cluster startup speed upon caching the index schema in SOLR-7191.
> Now that SolrCloud configuration is based on config sets in ZK, we should 
> explore how we can minimize config/schema parsing for each core in a way that 
> is compatible with the recent/planned changes in the config and schema APIs.



--
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-NightlyTests-trunk - Build # 809 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/809/

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=29478, name=collection1, 
state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=29478, name=collection1, state=RUNNABLE, 
group=TGRP-HdfsCollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:38328/s/f: Could not find collection : 
awholynewstresscollection_collection1_0
at __randomizedtesting.SeedInfo.seed([241AE4706039BEC7]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1099)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:895)




Build Log:
[...truncated 6 lines...]
   [junit4] Suite: 
org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J2/temp/solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest_241AE4706039BEC7-001/init-core-data-001
   [junit4]   2> 4149138 WARN  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 4149138 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false)
   [junit4]   2> 4149138 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /s/f
   [junit4]   1> Formatting using clusterid: testClusterID
   [junit4]   2> 4149289 WARN  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.a.h.m.i.MetricsConfig Cannot locate configuration: tried 
hadoop-metrics2-namenode.properties,hadoop-metrics2.properties
   [junit4]   2> 4149320 WARN  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.a.h.h.HttpRequestLog Jetty request log can only be enabled using Log4j
   [junit4]   2> 4149323 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.m.log jetty-6.1.26
   [junit4]   2> 4149361 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.m.log Extract 
jar:file:/x1/jenkins/.ivy2/cache/org.apache.hadoop/hadoop-hdfs/tests/hadoop-hdfs-2.6.0-tests.jar!/webapps/hdfs
 to ./temp/Jetty_localhost_40802_hdfsv5bduw/webapp
   [junit4]   2> 4149628 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.m.log NO JSP Support for /, did not find 
org.apache.jasper.servlet.JspServlet
   [junit4]   2> 4150146 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.m.log Started 
HttpServer2$SelectChannelConnectorWithSafeStartup@localhost:40802
   [junit4]   2> 4150404 WARN  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.a.h.h.HttpRequestLog Jetty request log can only be enabled using Log4j
   [junit4]   2> 4150405 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.m.log jetty-6.1.26
   [junit4]   2> 4150418 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.m.log Extract 
jar:file:/x1/jenkins/.ivy2/cache/org.apache.hadoop/hadoop-hdfs/tests/hadoop-hdfs-2.6.0-tests.jar!/webapps/datanode
 to ./temp/Jetty_localhost_43012_datanode.u97rmv/webapp
   [junit4]   2> 4150521 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.m.log NO JSP Support for /, did not find 
org.apache.jasper.servlet.JspServlet
   [junit4]   2> 4150898 INFO  
(SUITE-HdfsCollectionsAPIDistributedZkTest-seed#[241AE4706039BEC7]-worker) [
] o.m.log 

[jira] [Comment Edited] (SOLR-8113) Accept replacement strings in CloneFieldUpdateProcessorFactory

[Gus Heck (JIRA)]

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

Gus Heck edited comment on SOLR-8113 at 10/2/15 2:58 AM:
-

This was motivated by the response to SOLR-8109. This bridges the gap in the 
suggested alternate solution, but does look like it will likely be a lot less 
performant. I couldn't find a way to re-use the match done by the 
FieldNameSelector, so the regex matches have to execute twice. All attempts I 
made to do that resulted in major API changes.

This is however more flexible, will not interfere with atomic updates (as 
copyField apparently does) and Allows further movement away from the use of 
copyField.

It would be nice if both this and SOLR-8109 to become available since speed is 
one tradeoff, and atomic update support etc is another.


was (Author: gus_heck):
This was motivated by the response to SOLR-8109. This bridges the gap in the 
suggested alternate solution, but does look like it will likely be a lot less 
performant. I couldn't find a way to re-use the match done by the 
FieldNameSelector, so the regex matches have to execute twice. All attempts I 
made to do that resulted in major API changes.

This is however more flexible, will not interfere with atomic updates (as 
copyField apparently does) and Allows further movement away from the use of 
copyField.

My preference would be for both this and SOLR-8109 to become available since 
speed is one tradeoff, and atomic update support etc is another.

> Accept replacement strings in CloneFieldUpdateProcessorFactory
> --
>
> Key: SOLR-8113
> URL: https://issues.apache.org/jira/browse/SOLR-8113
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 5.3
>Reporter: Gus Heck
> Attachments: SOLR-8113.patch
>
>
> Presently CloneFieldUpdateProcessorFactory accepts regular expressions to 
> select source fields, which mirrors wildcards in the source for copyField in 
> the schema. This patch adds a counterpart to copyField's wildcards in the 
> dest attribute by interpreting the dest parameter as a regex replacement 
> string.



--
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

SolrCloud overseer queue, zookeeper, and jute.maxbuffer

[Shawn Heisey]

In a message I just sent to the solr-user list, I mentioned problems
with the overseer queue getting significantly larger than jute.maxbuffer.

How much pain would it cause if zookeeper were were to refuse to accept
new entries in the overseer queue when the new entry would push the
znode size above jute.maxbuffer?  Presumably it would cause a specific
exception that we could catch.  If that feature existed, could the
situation be handled gracefully in SolrCloud, possibly waiting until the
overseer has processed some of the existing entries and made some room?

I sent a query about such a feature to the zookeeper mailing list:

http://mail-archives.apache.org/mod_mbox/zookeeper-user/201510.mbox/%3C560DCB9E.4090307%40elyograg.org%3E

There are more messages in the thread, which you can follow with the
navigation links.  ZOOKEEPER-2260 was mentioned, which looks
interesting, but ultimately the root of the huge queue problem is the
fact that entries are generated VERY fast, and the size of the queue
znode is not restricted to zookeeper's own built-in limitations.

A few months ago, on SOLR-7191, I mentioned an idea for creating single
entries in the queue that can do large-scale state updates instead of
updating one little piece in each entry.  It's the second to last
paragraph in this comment:

https://issues.apache.org/jira/browse/SOLR-7191?focusedCommentId=14348836

Any thoughts?

Thanks,
Shawn


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

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-8110:
-

+1

We should log a warning for each dodgy fieldname in 'lenient' mode, so that 
users are aware that they're running the risk of some functionality not working.

> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



--
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-trunk-Linux (32bit/jdk1.9.0-ea-b78) - Build # 14366 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14366/
Java: 32bit/jdk1.9.0-ea-b78 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([57A369F25242EA0A:F0E7D1563FF9F9B3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationWithTruncatedTlog(CdcrReplicationHandlerTest.java:121)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:52)
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:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at