[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_20) - Build # 4417 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4417/
Java: 64bit/jdk1.8.0_20 -XX:-UseCompressedOops -XX:+UseSerialGC (asserts: true)

1 tests failed.
FAILED:  
org.apache.lucene.facet.TestRandomSamplingFacetsCollector.testRandomSampling

Error Message:
69

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 69
at 
__randomizedtesting.SeedInfo.seed([E3991AAE34F3F583:98173B385A40234]:0)
at 
org.apache.lucene.facet.TestRandomSamplingFacetsCollector.testRandomSampling(TestRandomSamplingFacetsCollector.java:133)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 6331 lines...]
   [junit4] Suite: org.apache.lucene.facet.TestRandomSamplingFacetsCollector
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestRandomSamplingFacetsCollector -Dtests.method=testRandomSampling 
-Dtests.seed=E3991AAE34F3F583 -Dtests.slow=true -Dtests.locale=no_NO 
-Dtests.timezone=Asia/Tehran -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.61s | 
TestRandomSamplingFacetsCollector.testRandomSampling <<<
   [junit4]> Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 69
   [junit4]>

[jira] [Commented] (SOLR-5147) Support Block Join documents in DIH

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-5147:


[~elyograg] don't hesitate to attach the refreshed patch! You never know when a 
committer is attracted by this.

> Support Block Join documents in DIH
> ---
>
> Key: SOLR-5147
> URL: https://issues.apache.org/jira/browse/SOLR-5147
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Vadim Kirilchuk
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-5147.patch, SOLR-5147.patch
>
>
> DIH should be able to index hierarchical documents, i.e. it should be able to 
> work with SolrInputDocuments#addChildDocument.
> There was patch in SOLR-3076: 
> https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch
> But it is not uptodate and far from being complete.



--
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-5147) Support Block Join documents in DIH

[Shawn Heisey (JIRA)]

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

Shawn Heisey edited comment on SOLR-5147 at 12/31/14 7:25 AM:
--

Found the relevant change in Lucene.  It is LUCENE-3312.  Replacing 
StoredDocument with the old class (org.apache.lucene.document.Document) in the 
new test allows it to compile and pass on branch_5x.



was (Author: elyograg):
Found the relevant change in Lucene.  It is LUCENE-3312.  Replacing 
StoredDocument with org.apache.lucene.document.Document in the new test allows 
it to compile and pass on branch_5x.


> Support Block Join documents in DIH
> ---
>
> Key: SOLR-5147
> URL: https://issues.apache.org/jira/browse/SOLR-5147
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Vadim Kirilchuk
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-5147.patch, SOLR-5147.patch
>
>
> DIH should be able to index hierarchical documents, i.e. it should be able to 
> work with SolrInputDocuments#addChildDocument.
> There was patch in SOLR-3076: 
> https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch
> But it is not uptodate and far from being complete.



--
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-5147) Support Block Join documents in DIH

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5147:


Found the relevant change in Lucene.  It is LUCENE-3312.  Replacing 
StoredDocument with org.apache.lucene.document.Document in the new test allows 
it to compile and pass on branch_5x.


> Support Block Join documents in DIH
> ---
>
> Key: SOLR-5147
> URL: https://issues.apache.org/jira/browse/SOLR-5147
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Vadim Kirilchuk
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-5147.patch, SOLR-5147.patch
>
>
> DIH should be able to index hierarchical documents, i.e. it should be able to 
> work with SolrInputDocuments#addChildDocument.
> There was patch in SOLR-3076: 
> https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch
> But it is not uptodate and far from being complete.



--
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-5147) Support Block Join documents in DIH

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5147:


This code cannot be merged into branch_5x in its current state.  The new test 
tries to use a class that does not exist in branch_5x: 
org.apache.lucene.index.StoredDocument.


> Support Block Join documents in DIH
> ---
>
> Key: SOLR-5147
> URL: https://issues.apache.org/jira/browse/SOLR-5147
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Vadim Kirilchuk
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-5147.patch, SOLR-5147.patch
>
>
> DIH should be able to index hierarchical documents, i.e. it should be able to 
> work with SolrInputDocuments#addChildDocument.
> There was patch in SOLR-3076: 
> https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch
> But it is not uptodate and far from being complete.



--
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-4839) Jetty 9

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-4839:
--

Still digging into the HttpPartitionTest hangs, but for me, it looks like 
something related to deleting the collections using the collections admin API 
at the end of the sub-tests. If I comment out the delete collection request 
(several places in the code), HttpPartitionTest works fine:

{code}
try {
  CollectionAdminRequest.Delete req = new CollectionAdminRequest.Delete();
  req.setCollectionName(testCollectionName);
  //req.process(cloudClient);
} catch (Exception e) {
  // don't fail the test
  log.warn("Could not delete collection {} after test completed", 
testCollectionName);
}
{code}

> Jetty 9
> ---
>
> Key: SOLR-4839
> URL: https://issues.apache.org/jira/browse/SOLR-4839
> Project: Solr
>  Issue Type: Improvement
>Reporter: Bill Bell
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-4839.patch, SOLR-4839.patch, SOLR-4839.patch, 
> SOLR-4839.patch, SOLR-4839.patch
>
>
> Implement Jetty 9



--
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] (LUCENE-6147) Make the core Accountables.namedAccountable function public

[Ryan Ernst (JIRA)]

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

Ryan Ernst resolved LUCENE-6147.

   Resolution: Fixed
Fix Version/s: Trunk
   5.0
 Assignee: Ryan Ernst

> Make the core Accountables.namedAccountable function public
> ---
>
> Key: LUCENE-6147
> URL: https://issues.apache.org/jira/browse/LUCENE-6147
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
>Assignee: Ryan Ernst
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6147.patch
>
>
> {{Accountables}} has a number of methods named {{namedAccountable}}.  The 
> core one of these works by taking a snapshot with an anonymous 
> {{Accountable}}.  This method is currently private due to concerns over 
> safety.  However, I think we should make it public, and document the how 
> safety can be achieved (which is by only using that and the other 
> {{namedAccountable}} methods).



--
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-6147) Make the core Accountables.namedAccountable function public

[ASF subversion and git services (JIRA)]

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

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

Commit 1648658 from [~rjernst] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1648658 ]

LUCENE-6147: Make the core Accountables.namedAccountable function public 
(merged 1648657)

> Make the core Accountables.namedAccountable function public
> ---
>
> Key: LUCENE-6147
> URL: https://issues.apache.org/jira/browse/LUCENE-6147
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6147.patch
>
>
> {{Accountables}} has a number of methods named {{namedAccountable}}.  The 
> core one of these works by taking a snapshot with an anonymous 
> {{Accountable}}.  This method is currently private due to concerns over 
> safety.  However, I think we should make it public, and document the how 
> safety can be achieved (which is by only using that and the other 
> {{namedAccountable}} methods).



--
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-6147) Make the core Accountables.namedAccountable function public

[ASF subversion and git services (JIRA)]

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

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

Commit 1648657 from [~rjernst] in branch 'dev/trunk'
[ https://svn.apache.org/r1648657 ]

LUCENE-6147: Make the core Accountables.namedAccountable function public

> Make the core Accountables.namedAccountable function public
> ---
>
> Key: LUCENE-6147
> URL: https://issues.apache.org/jira/browse/LUCENE-6147
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
> Attachments: LUCENE-6147.patch
>
>
> {{Accountables}} has a number of methods named {{namedAccountable}}.  The 
> core one of these works by taking a snapshot with an anonymous 
> {{Accountable}}.  This method is currently private due to concerns over 
> safety.  However, I think we should make it public, and document the how 
> safety can be achieved (which is by only using that and the other 
> {{namedAccountable}} methods).



--
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-6147) Make the core Accountables.namedAccountable function public

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6147:
-

Looks great. Thanks for fixing the docs: they are currently buggy.

> Make the core Accountables.namedAccountable function public
> ---
>
> Key: LUCENE-6147
> URL: https://issues.apache.org/jira/browse/LUCENE-6147
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
> Attachments: LUCENE-6147.patch
>
>
> {{Accountables}} has a number of methods named {{namedAccountable}}.  The 
> core one of these works by taking a snapshot with an anonymous 
> {{Accountable}}.  This method is currently private due to concerns over 
> safety.  However, I think we should make it public, and document the how 
> safety can be achieved (which is by only using that and the other 
> {{namedAccountable}} methods).



--
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-6147) Make the core Accountables.namedAccountable function public

[Ryan Ernst (JIRA)]

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

Ryan Ernst updated LUCENE-6147:
---
Attachment: LUCENE-6147.patch

Patch.

> Make the core Accountables.namedAccountable function public
> ---
>
> Key: LUCENE-6147
> URL: https://issues.apache.org/jira/browse/LUCENE-6147
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
> Attachments: LUCENE-6147.patch
>
>
> {{Accountables}} has a number of methods named {{namedAccountable}}.  The 
> core one of these works by taking a snapshot with an anonymous 
> {{Accountable}}.  This method is currently private due to concerns over 
> safety.  However, I think we should make it public, and document the how 
> safety can be achieved (which is by only using that and the other 
> {{namedAccountable}} methods).



--
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-6147) Make the core Accountables.namedAccountable function public

[Ryan Ernst (JIRA)]

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

Ryan Ernst updated LUCENE-6147:
---
Summary: Make the core Accountables.namedAccountable function public  (was: 
Make the core {{Accountables.namedAccountable}} function public)

> Make the core Accountables.namedAccountable function public
> ---
>
> Key: LUCENE-6147
> URL: https://issues.apache.org/jira/browse/LUCENE-6147
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
>
> {{Accountables}} has a number of methods named {{namedAccountable}}.  The 
> core one of these works by taking a snapshot with an anonymous 
> {{Accountable}}.  This method is currently private due to concerns over 
> safety.  However, I think we should make it public, and document the how 
> safety can be achieved (which is by only using that and the other 
> {{namedAccountable}} methods).



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

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

[jira] [Created] (LUCENE-6147) Make the core {{Accountables.namedAccountable}} function public

[Ryan Ernst (JIRA)]

Ryan Ernst created LUCENE-6147:
--

 Summary: Make the core {{Accountables.namedAccountable}} function 
public
 Key: LUCENE-6147
 URL: https://issues.apache.org/jira/browse/LUCENE-6147
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Ryan Ernst


{{Accountables}} has a number of methods named {{namedAccountable}}.  The core 
one of these works by taking a snapshot with an anonymous {{Accountable}}.  
This method is currently private due to concerns over safety.  However, I think 
we should make it public, and document the how safety can be achieved (which is 
by only using that and the other {{namedAccountable}} methods).



--
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-Tests-5.x-Java7 - Build # 2404 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2404/

1 tests failed.
REGRESSION:  org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability

Error Message:
No live SolrServers available to handle this request

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request
at 
__randomizedtesting.SeedInfo.seed([9870DCC86EF17784:59B8018ECF97A62D]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:539)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301)
at 
org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability(TestLBHttpSolrServer.java:223)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:36

[jira] [Commented] (SOLR-6792) cleanup solrconfig.xml files by removing implicit plugins

[ASF subversion and git services (JIRA)]

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

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

Commit 1648654 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1648654 ]

SOLR-6792 added javadocs

> cleanup solrconfig.xml files by removing implicit plugins
> -
>
> Key: SOLR-6792
> URL: https://issues.apache.org/jira/browse/SOLR-6792
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6792.patch
>
>
>  /replication , /get , /update, /admin/ are registered implicitly for each 
> core. No need to specify them from solrconfig.xml if nothing custom needs to 
> be added



--
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-6792) cleanup solrconfig.xml files by removing implicit plugins

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-6792:
--

bq.And nuking the class entirely in trunk.

We shold give enough time to users to cleanup their solrconfig.xml files. TIll 
that point we will keep the class around

bq.I also wonder if it's worth going through and removing explicit definitions 
from the various test and example solrconfig.xml files we have?

I think I have removed most references 

> cleanup solrconfig.xml files by removing implicit plugins
> -
>
> Key: SOLR-6792
> URL: https://issues.apache.org/jira/browse/SOLR-6792
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6792.patch
>
>
>  /replication , /get , /update, /admin/ are registered implicitly for each 
> core. No need to specify them from solrconfig.xml if nothing custom needs to 
> be added



--
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-6792) cleanup solrconfig.xml files by removing implicit plugins

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-6792 at 12/31/14 4:48 AM:


bq.And nuking the class entirely in trunk.

We should give enough time to users to cleanup their solrconfig.xml files. TIll 
that point we will keep the class around

bq.I also wonder if it's worth going through and removing explicit definitions 
from the various test and example solrconfig.xml files we have?

I think I have removed most references 


was (Author: noble.paul):
bq.And nuking the class entirely in trunk.

We shold give enough time to users to cleanup their solrconfig.xml files. TIll 
that point we will keep the class around

bq.I also wonder if it's worth going through and removing explicit definitions 
from the various test and example solrconfig.xml files we have?

I think I have removed most references 

> cleanup solrconfig.xml files by removing implicit plugins
> -
>
> Key: SOLR-6792
> URL: https://issues.apache.org/jira/browse/SOLR-6792
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6792.patch
>
>
>  /replication , /get , /update, /admin/ are registered implicitly for each 
> core. No need to specify them from solrconfig.xml if nothing custom needs to 
> be added



--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions

[JIRA]

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

Tomás Fernández Löbbe reassigned SOLR-6648:
---

Assignee: Tomás Fernández Löbbe

> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>Assignee: Tomás Fernández Löbbe
>  Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6648.patch
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-6648:
-

I think this makes sense. It sounds like it would be more common for people to 
always want suggestions with/without highlight and with/without 
"allTermsRequired" than the need to specify it per request.
I think it would be better to split the Lucene part to a LUCENE jira.

> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>  Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6648.patch
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-6797) Add score=degrees|kilometers|miles for AbstractSpatialFieldType

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-6797:


RE test maxDistErr and/or distErr... you might trivially just see if 
strategy.getDistErrPct and/or SpatialPrefixTree.getMaxLevels() yields what you 
expect given some particular input.

> Add score=degrees|kilometers|miles for AbstractSpatialFieldType
> ---
>
> Key: SOLR-6797
> URL: https://issues.apache.org/jira/browse/SOLR-6797
> Project: Solr
>  Issue Type: Improvement
>  Components: spatial
>Reporter: David Smiley
> Attachments: SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, 
> SOLR-6797.patch, SOLR-6797.patch
>
>
> Annoyingly, the units="degrees" attribute is required for fields extending 
> AbstractSpatialFieldType (e.g. RPT, BBox).  And it doesn't really have any 
> effect.  I propose the following:
> * Simply drop the attribute; ignore it if someone sets it to "degrees" (for 
> back-compat).
> * When using score="distance", or score=area or area2D (as seen in BBoxField) 
> then use kilometers if geo=true, otherwise degrees.
> * Add support for score=degrees|kilometers|miles|degrees



--
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-6901) Rethink EmbeddedSolrServer CoreContainer use

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-6901:


Undeprecate, for the reasons you give.  

It may also allow for reduced lines of code when using EmbeddedSolrServer.  
There's quite a bit of setup... ESS ought to have a builder or based on all the 
possible ways you might want to create it; and creating these are a pain!  I 
created SOLR-1793 a long time ago with no comments but my comment here 
https://issues.apache.org/jira/browse/SOLR-4502?focusedCommentId=14011291  has 
more and limited feedback.

> Rethink EmbeddedSolrServer CoreContainer use
> 
>
> Key: SOLR-6901
> URL: https://issues.apache.org/jira/browse/SOLR-6901
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Priority: Minor
>
> This was originally going to be about removing the EmbeddedSolrServer 
> constructor that takes a SolrCore, which has been deprecated since at least 
> 2010 (!).  Digging around a bit, though, it seems that having a CoreContainer 
> reference in ESS isn't very useful, especially as we only allow querying a 
> single core from it.
> What it *does* allow you to do is to send CoreAdminRequests, but again most 
> of these are not useful for a single core.
> I don't really have a strong opinion here, other than that we shouldn't carry 
> a Deprecated annotation across a third (!) major release.  
> * Simplest option is to just nuke that constructor (it's currently used in a 
> single test, which can be re-written).
> * Another option would be to 'undeprecate' it, and simply disallow core admin 
> requests if coreContainer is null
> * Yet another possibility is to stop holding on to the CoreContainer 
> reference, and instead have a custom CoreAdminHandler that only works for 
> commands that 'make sense' for a single core (essentially, RELOAD and STATUS) 
> and returns the SolrJ equivalent of an UnsupportedOperationException for 
> everything else.
> I'm leaning mostly to option 2 at the moment, because I think an embedded 
> client that takes a single core is a very useful abstraction (could be a nice 
> way of short-circuiting local requests in ShardHandler, for example).



--
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-SmokeRelease-5.x - Build # 225 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/225/

No tests ran.

Build Log:
[...truncated 51695 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 446 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [smoker] NOTE: output encoding is US-ASCII
   [smoker] 
   [smoker] Load release URL 
"file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.02 sec (7.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.0.0-src.tgz...
   [smoker] 27.9 MB in 0.04 sec (673.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.0.0.tgz...
   [smoker] 64.0 MB in 0.09 sec (676.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.0.0.zip...
   [smoker] 73.5 MB in 0.08 sec (883.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5631 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5631 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.jettyConnector=Socket 
-Dtests.multiplier=1 -Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 209 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   4.10.3
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1527, in 
   [smoker] main()
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1472, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1510, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, svnRevision, version, testArgs, baseURL)
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 616, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 801, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1465, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/build.xml:414:
 exec returned: 1

Total time: 45 minutes 5 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Updated] (SOLR-6666) Dynamic copy fields are considering all dynamic fields, causing a significant performance impact on indexing documents

[Erick Erickson (JIRA)]

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

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

Hmmm, I like the way you've broken things out, it makes the code easier to 
follow. It gave me a headache looking the original code before either patch.

We have three other test failures, it's always best to run 'ant test' before 
putting up a patch. That said, I think the one I'm seeing (there are three, but 
they're all the same problem) is the following:

[~sar...@syr.edu] I'm particularly interested in what you think here.

The trunk code returns this fragment in TestCopyFieldCollectionResource.java
{
  "source":"src_sub_no_ast_i",
  "sourceDynamicBase":"*_i",
  "dest":"title"},

whereas the patched code returns:
{
  "source":"src_sub_no_ast_i",
  "dest":"title"},

The schema.xml file (if I've got the right one) has this line:
   

Like I said, the original code hurt my head, I suspect it was just wrong. 
Steve, do you have any comments here? Or am I mis-interpreting things?

The attached patch fixes these three problems, I'll run the whole test suite 
again too.


> Dynamic copy fields are considering all dynamic fields, causing a significant 
> performance impact on indexing documents
> --
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis, update
> Environment: Linux, Solr 4.8, Schema with 70 fields and more than 500 
> specific CopyFields for dynamic fields, but without wildcards (the fields are 
> dynamic, the copy directive is not)
>Reporter: Liram Vardi
>Assignee: Erick Erickson
> Attachments: SOLR-.patch, SOLR-.patch, SOLR-.patch
>
>
> Result:
> After applying a fix for this issue, tests which we conducted show more than 
> 40 percent improvement on our insertion performance.
> Explanation:
> Using JVM profiler, we found a CPU "bottleneck" during Solr indexing process. 
> This bottleneck can be found at org.apache.solr.schema.IndexSchema, in the 
> following method, "getCopyFieldsList()":
> {code:title=getCopyFieldsList() |borderStyle=solid}
> final List result = new ArrayList<>();
> for (DynamicCopy dynamicCopy : dynamicCopyFields) {
>   if (dynamicCopy.matches(sourceField)) {
> result.add(new CopyField(getField(sourceField), 
> dynamicCopy.getTargetField(sourceField), dynamicCopy.maxChars));
>   }
> }
> List fixedCopyFields = copyFieldsMap.get(sourceField);
> if (null != fixedCopyFields) {
>   result.addAll(fixedCopyFields);
> }
> {code}
> This function tries to find for an input source field all its copyFields (All 
> its destinations which Solr need to move this field). 
> As you can probably note, the first part of the procedure is the procedure 
> most “expensive” step (takes O( n ) time while N is the size of the 
> "dynamicCopyFields" group).
> The next part is just a simple "hash" extraction, which takes O(1) time. 
> Our schema contains over then 500 copyFields but only 70 of then are 
> "indexed" fields. 
> We also have one dynamic field with  a wildcard ( * ), which "catches" the 
> rest of the document fields. 
> As you can conclude, we have more than 400 copyFields that are based on this 
> dynamicField but all, except one, are fixed (i.e. does not contain any 
> wildcard).
> From some reason, the copyFields registration procedure defines those 400 
> fields as "DynamicCopyField " and then store them in the “dynamicCopyFields” 
> array, 
> This step makes getCopyFieldsList() very expensive (in CPU terms) without any 
> justification: All of those 400 copyFields are not glob and therefore do not 
> need any complex pattern matching to the input field. They all can be store 
> at the "fixedCopyFields".
> Only copyFields with asterisks need this "special" treatment and they are 
> (especially on our case) pretty rare.  
> Therefore, we created a patch which fix this problem by changing the 
> registerCopyField() procedure.
> Test which we conducted show that there is no change in the Indexing results. 
> Moreover, the fix still successfully passes the class unit tests (i.e. 
> IndexSchemaTest.java).
>



--
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-4746) Create a move method in Directory.

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4746:
-

I opened LUCENE-6146 to fix the api first.

I have more concerns about allowing hard links on os X 
(http://arstechnica.com/apple/2011/07/mac-os-x-10-7/12/) or even using them at 
all, because its not obvious and at least could be hellacious for tests (dir A 
calls crash() on a file its done with but dir B is still using, etc). 

Maybe as a first step, we should optimize this to use Files.copy? its a 
conservative and safer step and can be faster depending on the OS, on windows 
it calls a special method, on linux etc its a read-write loop in JNI.

> Create a move method in Directory.
> --
>
> Key: LUCENE-4746
> URL: https://issues.apache.org/jira/browse/LUCENE-4746
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, Trunk
>
> Attachments: LUCENE-4746.patch, LUCENE-4746.patch
>
>
> I'd like to make a move method for directory.
> We already have a move for Solr in DirectoryFactory, but it seems it belongs 
> at the directory level really.
> The default impl can do a copy and delete, but most implementations will be 
> able to optimize to a rename.
> Besides the move we do for Solr (to move a replicated index into place), it 
> would also be useful for another feature I'd like to add - the ability to 
> merge an index with moves rather than copies. In some cases, you don't 
> need/want to copy all the files and could just rename/move them. 



--
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-6146) Directory.copy -> Directory.copyFrom

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-6146:

Attachment: LUCENE-6146.patch

initial patch.

> Directory.copy -> Directory.copyFrom
> 
>
> Key: LUCENE-6146
> URL: https://issues.apache.org/jira/browse/LUCENE-6146
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-6146.patch
>
>
> Spinoff of LUCENE-4746.
> This method is currently:
> {code}
> copy(Directory to, String src, String dest, IOContext context)
> {code}
> But it would be better to restructure this so the destination directory is 
> the one actually being changed by the operation:
> {code}
> copyFrom(Directory from, String src, String dest, IOContext context)
> {code}
> Besides fixing the order to make sense, adding it to the name might help 
> prevent bugs like the current TrackingDirectoryWrapper impl (used by 
> IndexWriter to track what files are used):
> {code}
> public void copy(Directory to, String src, String dest, IOContext context) 
> throws IOException {
>   createdFileNames.add(dest); // BUG!
>   in.copy(to, src, dest, context);
> }
> {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] [Updated] (SOLR-6903) deletes with commitWithin are not reflected in all nodes

[Brendan Humphreys (JIRA)]

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

Brendan Humphreys updated SOLR-6903:

Attachment: SOLR-6903.patch

modified {{BasicDistributeZkTest}} to demonstrate the problem

> deletes with commitWithin are not reflected in all nodes
> 
>
> Key: SOLR-6903
> URL: https://issues.apache.org/jira/browse/SOLR-6903
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.10.3, 5.0
>Reporter: Brendan Humphreys
> Attachments: SOLR-6903.patch
>
>
> deletes with {{commitWithin}} are not reflected in all nodes in a solrcloud 
> cluster. 
> The deleted document is no longer visible in the leader node, but remains 
> present in the other nodes. 
> I've modified {{BasicDistributedZkTest}} to demonstrate the problem. 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] [Created] (SOLR-6903) deletes with commitWithin are not reflected in all nodes

[Brendan Humphreys (JIRA)]

Brendan Humphreys created SOLR-6903:
---

 Summary: deletes with commitWithin are not reflected in all nodes
 Key: SOLR-6903
 URL: https://issues.apache.org/jira/browse/SOLR-6903
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.10.3, 5.0
Reporter: Brendan Humphreys


deletes with {{commitWithin}} are not reflected in all nodes in a solrcloud 
cluster. 

The deleted document is no longer visible in the leader node, but remains 
present in the other nodes. 

I've modified {{BasicDistributedZkTest}} to demonstrate the problem. 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] [Created] (LUCENE-6146) Directory.copy -> Directory.copyFrom

[Robert Muir (JIRA)]

Robert Muir created LUCENE-6146:
---

 Summary: Directory.copy -> Directory.copyFrom
 Key: LUCENE-6146
 URL: https://issues.apache.org/jira/browse/LUCENE-6146
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


Spinoff of LUCENE-4746.

This method is currently:
{code}
copy(Directory to, String src, String dest, IOContext context)
{code}

But it would be better to restructure this so the destination directory is the 
one actually being changed by the operation:
{code}
copyFrom(Directory from, String src, String dest, IOContext context)
{code}

Besides fixing the order to make sense, adding it to the name might help 
prevent bugs like the current TrackingDirectoryWrapper impl (used by 
IndexWriter to track what files are used):

{code}
public void copy(Directory to, String src, String dest, IOContext context) 
throws IOException {
  createdFileNames.add(dest); // BUG!
  in.copy(to, src, dest, context);
}
{code}




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

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

[jira] [Commented] (SOLR-5810) State of external collections not displayed in cloud graph panel

[ASF subversion and git services (JIRA)]

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

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

Commit 1648630 from [~thelabdude] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1648630 ]

SOLR-5810: backport to branch 5x

> State of external collections not displayed in cloud graph panel
> 
>
> Key: SOLR-5810
> URL: https://issues.apache.org/jira/browse/SOLR-5810
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud, web gui
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-5810-prelim.patch, SOLR-5810.patch, 
> SOLR-5810.patch, SOLR-5810.patch, SOLR-5810.prelim2.patch
>
>
> External collections (SOLR-5473) are not displayed in the Cloud -> graph 
> panel, which makes it very hard to see which external collections have 
> problems, such as after a downed node comes back online.



--
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-5810) State of external collections not displayed in cloud graph panel

[Timothy Potter (JIRA)]

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

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

> State of external collections not displayed in cloud graph panel
> 
>
> Key: SOLR-5810
> URL: https://issues.apache.org/jira/browse/SOLR-5810
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud, web gui
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-5810-prelim.patch, SOLR-5810.patch, 
> SOLR-5810.patch, SOLR-5810.patch, SOLR-5810.prelim2.patch
>
>
> External collections (SOLR-5473) are not displayed in the Cloud -> graph 
> panel, which makes it very hard to see which external collections have 
> problems, such as after a downed node comes back online.



--
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-6581) Prepare CollapsingQParserPlugin and ExpandComponent for 5.0

[David Smiley (JIRA)]

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

David Smiley updated SOLR-6581:
---
Attachment: renames.diff

While you are improving CollapsingQParserPlugin, I suggest doing some variable 
renames.  In my work I needed something like this code so I forked it to be 
modified, but found my first task was to do a bunch of renames so that it was 
clear what variable was for what.  The attached patch is a redacted version 
from my code and includes a tad bit of other stuff to be ignored, but see the 
change in variable names, and a getter rename or two.  As a random example, 
"docId" is unclear; is this a global doc ID or is it segment local?  Likewise 
for ordinals.  Arguably most of Lucene/Solr is guilty of this but this one 
source file I found hard to penetrate until I did the renames to decipher 
what's going on.

> Prepare CollapsingQParserPlugin and ExpandComponent for 5.0
> ---
>
> Key: SOLR-6581
> URL: https://issues.apache.org/jira/browse/SOLR-6581
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.0
>
> Attachments: SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, 
> SOLR-6581.patch, renames.diff
>
>
> *Background*
> The 4x implementation of the CollapsingQParserPlugin and the ExpandComponent 
> are optimized to work with a top level FieldCache. Top level FieldCaches have 
> a very fast docID to top-level ordinal lookup. Fast access to the top-level 
> ordinals allows for very high performance field collapsing on high 
> cardinality fields. 
> LUCENE-5666 unified the DocValues and FieldCache api's so that the top level 
> FieldCache is no longer in regular use. Instead all top level caches are 
> accessed through MultiDocValues. 
> There are some major advantages of using the MultiDocValues rather then a top 
> level FieldCache. But there is one disadvantage, the lookup from docId to 
> top-level ordinals is slower using MultiDocValues.
> My testing has shown that *after optimizing* the CollapsingQParserPlugin code 
> to use MultiDocValues, the performance drop is around 100%.  For some use 
> cases this performance drop is a blocker.
> *What About Faceting?*
> String faceting also relies on the top level ordinals. Is faceting 
> performance affected also? My testing has shown that the faceting performance 
> is affected much less then collapsing. 
> One possible reason for this may be that field collapsing is memory bound and 
> faceting is not. So the additional memory accesses needed for MultiDocValues 
> affects field collapsing much more then faceting.
> *Proposed Solution*
> The proposed solution is to have the default Collapse and Expand algorithm 
> use MultiDocValues, but to provide an option to use a top level FieldCache if 
> the performance of MultiDocValues is a blocker.
> The proposed mechanism for switching to the FieldCache would be a new "hint" 
> parameter. If the hint parameter is set to "FAST_QUERY" then the top-level 
> FieldCache would be used for both Collapse and Expand.
> Example syntax:
> {code}
> fq={!collapse field=x hint=FAST_QUERY}
> {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] [Updated] (SOLR-5810) State of external collections not displayed in cloud graph panel

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-5810:
-
Attachment: SOLR-5810.patch

here's the updated patch (committed to trunk) which provides basic paged 
navigation controls for the cloud graph panel to support many collections. 
update includes re-establishing the watcher after a Zk session expiration using 
the OnReconnect interface

> State of external collections not displayed in cloud graph panel
> 
>
> Key: SOLR-5810
> URL: https://issues.apache.org/jira/browse/SOLR-5810
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud, web gui
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-5810-prelim.patch, SOLR-5810.patch, 
> SOLR-5810.patch, SOLR-5810.patch, SOLR-5810.prelim2.patch
>
>
> External collections (SOLR-5473) are not displayed in the Cloud -> graph 
> panel, which makes it very hard to see which external collections have 
> problems, such as after a downed node comes back online.



--
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-5810) State of external collections not displayed in cloud graph panel

[ASF subversion and git services (JIRA)]

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

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

Commit 1648621 from [~thelabdude] in branch 'dev/trunk'
[ https://svn.apache.org/r1648621 ]

SOLR-5810: basic paged nav support for cloud graph panel for many collections.

> State of external collections not displayed in cloud graph panel
> 
>
> Key: SOLR-5810
> URL: https://issues.apache.org/jira/browse/SOLR-5810
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud, web gui
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-5810-prelim.patch, SOLR-5810.patch, 
> SOLR-5810.patch, SOLR-5810.prelim2.patch
>
>
> External collections (SOLR-5473) are not displayed in the Cloud -> graph 
> panel, which makes it very hard to see which external collections have 
> problems, such as after a downed node comes back online.



--
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-6581) Prepare CollapsingQParserPlugin and ExpandComponent for 5.0

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-6581:
-
Attachment: SOLR-6581.patch

> Prepare CollapsingQParserPlugin and ExpandComponent for 5.0
> ---
>
> Key: SOLR-6581
> URL: https://issues.apache.org/jira/browse/SOLR-6581
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.0
>
> Attachments: SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, 
> SOLR-6581.patch
>
>
> *Background*
> The 4x implementation of the CollapsingQParserPlugin and the ExpandComponent 
> are optimized to work with a top level FieldCache. Top level FieldCaches have 
> a very fast docID to top-level ordinal lookup. Fast access to the top-level 
> ordinals allows for very high performance field collapsing on high 
> cardinality fields. 
> LUCENE-5666 unified the DocValues and FieldCache api's so that the top level 
> FieldCache is no longer in regular use. Instead all top level caches are 
> accessed through MultiDocValues. 
> There are some major advantages of using the MultiDocValues rather then a top 
> level FieldCache. But there is one disadvantage, the lookup from docId to 
> top-level ordinals is slower using MultiDocValues.
> My testing has shown that *after optimizing* the CollapsingQParserPlugin code 
> to use MultiDocValues, the performance drop is around 100%.  For some use 
> cases this performance drop is a blocker.
> *What About Faceting?*
> String faceting also relies on the top level ordinals. Is faceting 
> performance affected also? My testing has shown that the faceting performance 
> is affected much less then collapsing. 
> One possible reason for this may be that field collapsing is memory bound and 
> faceting is not. So the additional memory accesses needed for MultiDocValues 
> affects field collapsing much more then faceting.
> *Proposed Solution*
> The proposed solution is to have the default Collapse and Expand algorithm 
> use MultiDocValues, but to provide an option to use a top level FieldCache if 
> the performance of MultiDocValues is a blocker.
> The proposed mechanism for switching to the FieldCache would be a new "hint" 
> parameter. If the hint parameter is set to "FAST_QUERY" then the top-level 
> FieldCache would be used for both Collapse and Expand.
> Example syntax:
> {code}
> fq={!collapse field=x hint=FAST_QUERY}
> {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

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-5.x #803: POMs out of sync

[Uwe Schindler]

I think this started earlier, the builds in the meantime just disappeared, 
there is a gap in ids between the last successful one and the first failed one.

 

I just wonder why this only happens on Maven builds… Maybe it is related to 
FreeBSD blackole, but then it should also happen for other builds.

Trunk does not have an issue, because it does not run tests at the moment (bug 
in FreeBSD JDK that makes it crush).

 

Uwe

 

-

Uwe Schindler

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

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Erik Hatcher [mailto:erik.hatc...@gmail.com] 
Sent: Tuesday, December 30, 2014 8:21 PM
To: dev@lucene.apache.org
Subject: Re: [JENKINS-MAVEN] Lucene-Solr-Maven-5.x #803: POMs out of sync

 

How do we get this one fixed?   I see it seemed to start happening around 
https://builds.apache.org/job/Lucene-Solr-Maven-5.x/784/

 

  Erik

 

On Dec 30, 2014, at 10:54 AM, Apache Jenkins Server  
wrote:

 

Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/803/

2 tests failed.
FAILED:  org.apache.solr.hadoop.MorphlineBasicMiniMRTest.testPathParts

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
  at __randomizedtesting.SeedInfo.seed([B991C12C3C7B41B1]:0)


FAILED:  
org.apache.solr.hadoop.MorphlineBasicMiniMRTest.org.apache.solr.hadoop.MorphlineBasicMiniMRTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
  at __randomizedtesting.SeedInfo.seed([B991C12C3C7B41B1]:0)




Build Log:
[...truncated 54033 lines...]
BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:552: 
The following error occurred while executing this line:
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:204: 
The following error occurred while executing this line:
: Java returned: 1

Total time: 343 minutes 49 seconds
Build step 'Invoke Ant' marked build as failure
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

 

[jira] [Resolved] (LUCENE-6138) ItalianLightStemmer doesn't apply on words shorter then 6 chars in length

[Erick Erickson (JIRA)]

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

Erick Erickson resolved LUCENE-6138.

Resolution: Won't Fix

Massimo:

Appreciate your understanding here. It's always difficult to figure out what to 
be responsible for and what not...

Closing as per your comment...

> ItalianLightStemmer doesn't apply on words shorter then 6 chars in length
> -
>
> Key: LUCENE-6138
> URL: https://issues.apache.org/jira/browse/LUCENE-6138
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 4.10.2
>Reporter: Massimo Pasquini
>Priority: Minor
>
> I expect a stemmer to transform nouns in their singular and plural forms into 
> a shorter common form. The implementation of the ItalianLightStemmer doesn't 
> apply any stemming to words shorter then 6 characters in length. This leads 
> to some annoying results:
> singular form | plural form
> 4|5 chars in length (no stemming)
> alga -> alga | alghe -> alghe
> fuga -> fuga | fughe -> fughe
> lega -> lega | leghe -> leghe
> 5|6 chars in length (stemming only on plural form)
> vanga -> vanga | vanghe -> vang
> verga -> verga | verghe -> verg
> I suppose that such limitation on words length is to avoid other side effects 
> on shorter words not in the set above, but I think something must be reviewed 
> in the code for better results.



--
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-6897) Nuke non-NRT mode from code and configuration

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-6897:

Attachment: SOLR-6897.patch

Patch to remove nrtMode. This also removes TestNonNRTOpen, 
TestArbitraryIndexDir and TestReplicationHandler.testNoWriter.

TestNonNRTOpen is not needed anymore. We may need another test to replace 
TestArbitraryIndexDir. I am not yet sure about 
TestReplicationHandler.testNoWriter.

> Nuke non-NRT mode from code and configuration
> -
>
> Key: SOLR-6897
> URL: https://issues.apache.org/jira/browse/SOLR-6897
> Project: Solr
>  Issue Type: Task
>Reporter: Shalin Shekhar Mangar
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6897.patch
>
>
> We've had nrtMode as a configurable param in solrconfig.xml. This was maybe 
> necessary in the early days when were testing the waters for NRT searchers 
> but it is not necessary anymore. We should just nuke it and have only NRT 
> mode always.



--
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-Tests-5.x-Java7 - Build # 2402 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2402/

1 tests failed.
REGRESSION:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([6DE50EF442ABB761:F7117316DC312B5D]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:730)
at 
org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:237)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

01


request was:rows=20&qt=standard&q=id:529&start=0&version=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:723)
 

[jira] [Commented] (SOLR-5316) Solr 4.2.1 LotsOfCores new options

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-5316:
--

Olivier:

I'm really sorry it's taken me this long to look more closely, well the heck 
with the excuses...

Anyway, I think I'm going to pass on committing this one. It's not a problem 
with the code, I looked it over (although not in excruciating detail), and it 
looks quite good.

Rather, I think it introduces more complexity than I'm comfortable introducing 
at this point for a not-very-common use-case AFAIK. Especially as Zookeeper as 
"the one source of truth" is out there somewhere on the horizon.

So I'm making it unassigned, perhaps someone else might want to pick this up.



> Solr 4.2.1 LotsOfCores new options
> --
>
> Key: SOLR-5316
> URL: https://issues.apache.org/jira/browse/SOLR-5316
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore
>Affects Versions: 4.2.1, 4.7
>Reporter: olivier soyez
>Assignee: Erick Erickson
>Priority: Minor
>  Labels: patch
> Fix For: 4.2.1
>
> Attachments: SOLR-5316.patch, solr-4.2.1.patchLOTSOFCORES
>
>
> The SOLR-5316.patch is for the lotsofcores use case: a large number of 
> homogeneous cores with frequent loading/unloading. The new Cores options are:
> - defaultLoadOnStartup : true by default
> - defaultTransient : false by default
>   In this way, you can change the default attributes value for all cores.
>   The lotsofcores use case requires to have defaultLoadOnStartup = false and 
> defaultTransient = true
> - "numBuckets" to create a subdirectory based on a hash on the corename % 
> numBuckets in the core Datadir, because all cores cannot live in the same 
> directory
> - "auto" with 2 differents values :
> 1) createLoad: create, if not exist, and load the core on the fly on
> the first incoming request (update, select).
> 2) onlyLoad: load the core on the fly on the first incoming request
> (update, select), if exist on disk
> The auto option uses an additional cores option named baseDataDir to 
> automatically generate the dataDir of each core and uses the "numBucket" 
> option if exists. All the cores have the same solr config defined in the 
> solr_home/conf.
> - discoverOnDemand : false by default. If enabled, the discovery and loading 
> of cores at the solr startup are disabled and a new option named 
> coreDiscovery in the STATUS action is available to discover on demand all the 
> cores in the coreRootDirectory (only add the cores descriptions)
> - noCorePropertiesFile : false by default. If enabled, don't use anymore the 
> core.properties file, a core will be detected on disk based on the file 
> segments.gen
> The unload command was also modified in order to handle the non loaded 
> transient cores, to be able to apply for example the deleteIndex, 
> deleteDataDir options.
> I added some Junit tests.
> An example of solr.xml:
> 
>   schema.xml
>   5000
>   solr_home/data
>   solr_home/data
>   100
>   createLoad
>   false
>   true
>   true
>   true
> 
> The patch SOLR-5316.patch in attachment is for svn solr branch_4X (revision 
> number 1556554)
> ---
> The patch solr-4.2.1.patchLOTSOFCORES is for the lotsofcores use case, 
> including some modification : 
> - by default, all cores have loadOnStartup="false" and transient="true" 
> attributes
> - the create admin command can register a lazy core (to take into account the 
> transientCacheSize option)
> - add transient cores persistency
> - handle unload admin command for never launched transient cores (non active 
> cores)
> To improve performance, we use this Solr patched version with the persistence 
> disabled.
> In this way, Solr is working with a solr.xml file without any core entries, 
> because it's useless in our use case (with the new Auto option for the cores)
> The new Cores options :
> - "numBuckets" to create a subdirectory based on a hash on the corename 
> % numBuckets in the core Datadir, because all cores cannot live in the 
> same directory
> - "Auto" with 3 differents values :
> 1) false : default behaviour
> 2) createLoad : create, if not exist, and load the core on the fly on 
> the first incoming request (update, select).
> 3) onlyLoad : load the core on the fly on the first incoming request 
> (update, select), if exist on disk
> The Auto option uses an additional cores option named baseDataDir to 
> automatically generate the dataDir of each core and uses the "numBucket" 
> option if exists.



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

[jira] [Assigned] (SOLR-5316) Solr 4.2.1 LotsOfCores new options

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-5316:


Assignee: (was: Erick Erickson)

> Solr 4.2.1 LotsOfCores new options
> --
>
> Key: SOLR-5316
> URL: https://issues.apache.org/jira/browse/SOLR-5316
> Project: Solr
>  Issue Type: Improvement
>  Components: multicore
>Affects Versions: 4.2.1, 4.7
>Reporter: olivier soyez
>Priority: Minor
>  Labels: patch
> Fix For: 4.2.1
>
> Attachments: SOLR-5316.patch, solr-4.2.1.patchLOTSOFCORES
>
>
> The SOLR-5316.patch is for the lotsofcores use case: a large number of 
> homogeneous cores with frequent loading/unloading. The new Cores options are:
> - defaultLoadOnStartup : true by default
> - defaultTransient : false by default
>   In this way, you can change the default attributes value for all cores.
>   The lotsofcores use case requires to have defaultLoadOnStartup = false and 
> defaultTransient = true
> - "numBuckets" to create a subdirectory based on a hash on the corename % 
> numBuckets in the core Datadir, because all cores cannot live in the same 
> directory
> - "auto" with 2 differents values :
> 1) createLoad: create, if not exist, and load the core on the fly on
> the first incoming request (update, select).
> 2) onlyLoad: load the core on the fly on the first incoming request
> (update, select), if exist on disk
> The auto option uses an additional cores option named baseDataDir to 
> automatically generate the dataDir of each core and uses the "numBucket" 
> option if exists. All the cores have the same solr config defined in the 
> solr_home/conf.
> - discoverOnDemand : false by default. If enabled, the discovery and loading 
> of cores at the solr startup are disabled and a new option named 
> coreDiscovery in the STATUS action is available to discover on demand all the 
> cores in the coreRootDirectory (only add the cores descriptions)
> - noCorePropertiesFile : false by default. If enabled, don't use anymore the 
> core.properties file, a core will be detected on disk based on the file 
> segments.gen
> The unload command was also modified in order to handle the non loaded 
> transient cores, to be able to apply for example the deleteIndex, 
> deleteDataDir options.
> I added some Junit tests.
> An example of solr.xml:
> 
>   schema.xml
>   5000
>   solr_home/data
>   solr_home/data
>   100
>   createLoad
>   false
>   true
>   true
>   true
> 
> The patch SOLR-5316.patch in attachment is for svn solr branch_4X (revision 
> number 1556554)
> ---
> The patch solr-4.2.1.patchLOTSOFCORES is for the lotsofcores use case, 
> including some modification : 
> - by default, all cores have loadOnStartup="false" and transient="true" 
> attributes
> - the create admin command can register a lazy core (to take into account the 
> transientCacheSize option)
> - add transient cores persistency
> - handle unload admin command for never launched transient cores (non active 
> cores)
> To improve performance, we use this Solr patched version with the persistence 
> disabled.
> In this way, Solr is working with a solr.xml file without any core entries, 
> because it's useless in our use case (with the new Auto option for the cores)
> The new Cores options :
> - "numBuckets" to create a subdirectory based on a hash on the corename 
> % numBuckets in the core Datadir, because all cores cannot live in the 
> same directory
> - "Auto" with 3 differents values :
> 1) false : default behaviour
> 2) createLoad : create, if not exist, and load the core on the fly on 
> the first incoming request (update, select).
> 3) onlyLoad : load the core on the fly on the first incoming request 
> (update, select), if exist on disk
> The Auto option uses an additional cores option named baseDataDir to 
> automatically generate the dataDir of each core and uses the "numBucket" 
> option if exists.



--
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-6138) ItalianLightStemmer doesn't apply on words shorter then 6 chars in length

[Massimo Pasquini (JIRA)]

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

Massimo Pasquini commented on LUCENE-6138:
--

I got the point about "it's not your work", after all this is the good thing 
about open source software. I also definitely agree your second point "these 
kind of changes need real evaluation work too": that's exactly what I was 
thinking before opening this issue. 
I think I will try to fix the ItalianLightStemmer myself and see what the 
results will be, but considering the wide range of test necessary in this 
specific domain, it will take a while before I could find enough time to try to 
fix it.
About this issue, I suppose it may be closed as "won't fix" then.

> ItalianLightStemmer doesn't apply on words shorter then 6 chars in length
> -
>
> Key: LUCENE-6138
> URL: https://issues.apache.org/jira/browse/LUCENE-6138
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 4.10.2
>Reporter: Massimo Pasquini
>Priority: Minor
>
> I expect a stemmer to transform nouns in their singular and plural forms into 
> a shorter common form. The implementation of the ItalianLightStemmer doesn't 
> apply any stemming to words shorter then 6 characters in length. This leads 
> to some annoying results:
> singular form | plural form
> 4|5 chars in length (no stemming)
> alga -> alga | alghe -> alghe
> fuga -> fuga | fughe -> fughe
> lega -> lega | leghe -> leghe
> 5|6 chars in length (stemming only on plural form)
> vanga -> vanga | vanghe -> vang
> verga -> verga | verghe -> verg
> I suppose that such limitation on words length is to avoid other side effects 
> on shorter words not in the set above, but I think something must be reviewed 
> in the code for better results.



--
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-4746) Create a move method in Directory.

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4746:
-

A few more problems, it wont work with MDW correctly unless we deal with stale 
file maps (or MDW knows that linking is happening).

We also need to look into what this is about, maybe its solved in the JDK:

{noformat}
BUGS
   On NFS filesystems, the return code may be wrong in case the NFS server 
performs the link creation and dies before it can say so.  Use  stat(2)  to  
find
   out if the link got created.
{noformat}

> Create a move method in Directory.
> --
>
> Key: LUCENE-4746
> URL: https://issues.apache.org/jira/browse/LUCENE-4746
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, Trunk
>
> Attachments: LUCENE-4746.patch, LUCENE-4746.patch
>
>
> I'd like to make a move method for directory.
> We already have a move for Solr in DirectoryFactory, but it seems it belongs 
> at the directory level really.
> The default impl can do a copy and delete, but most implementations will be 
> able to optimize to a rename.
> Besides the move we do for Solr (to move a replicated index into place), it 
> would also be useful for another feature I'd like to add - the ability to 
> merge an index with moves rather than copies. In some cases, you don't 
> need/want to copy all the files and could just rename/move them. 



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

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

[GitHub] lucene-solr pull request: Use JUnit rules instead of inheritance w...

[madrob]

Github user madrob commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/121#discussion_r22362948
  
--- Diff: 
solr/test-framework/src/java/org/apache/solr/BaseDistributedSearchTestCase.java 
---
@@ -173,16 +179,25 @@ protected BaseDistributedSearchTestCase(final String 
context) {
  "[ff01::213]:2" + context};
   }
 
-  protected int shardCount = 4;  // the actual number of solr cores 
that will be created in the cluster
+  private final static int DEFAULT_MAX_SHARD_COUNT = 3;
+
+  private int shardCount = -1;  // the actual number of solr cores 
that will be created in the cluster
+  public int getShardCount() {
+return shardCount;
+  }
+
+  private boolean isShardCountFixed = false;
 
   /**
-   * Sub classes can set this flag in their constructor to true if they
-   * want to fix the number of shards to 'shardCount'
+   * Sub classes can call this in their constructor to fix the number of 
shards
*
-   * The default is false which means that test will be executed with
-   * 1, 2, 3, shardCount number of shards repeatedly
+   * By default, the test will be executed with
+   * 1, 2, ... DEFAULT_MAX_SHARD_COUNT number of shards repeatedly
*/
-  protected boolean fixShardCount = false;
+  public void fixShardCount(int count) {
--- End diff --

Maybe add a reference to the annotations and explain why one is preferred 
over the other for the benefit of future test writers.


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

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

[GitHub] lucene-solr pull request: Use JUnit rules instead of inheritance w...

[madrob]

Github user madrob commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/121#discussion_r22362862
  
--- Diff: 
solr/core/src/test/org/apache/solr/update/SolrCmdDistributorTest.java ---
@@ -506,14 +506,14 @@ public boolean checkRetry() {
   }
   
   @Override
-  public void setUp() throws Exception {
-super.setUp();
+  public void distribSetUp() throws Exception {
--- End diff --

There's a couple of these "no-op" distribSetup() calls too; if we remove 
the distribTearDown() ones, then these should go too. Leaving them in is 
probably fine though.


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

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

[GitHub] lucene-solr pull request: Use JUnit rules instead of inheritance w...

[madrob]

Github user madrob commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/121#discussion_r22362769
  
--- Diff: 
solr/test-framework/src/java/org/apache/solr/BaseDistributedSearchTestCase.java 
---
@@ -861,23 +869,107 @@ protected void compareResponses(QueryResponse a, 
QueryResponse b) {
 compareSolrResponses(a, b);
   }
 
-  @Test
-  public void testDistribSearch() throws Exception {
-if (fixShardCount) {
-  createServers(shardCount);
-  RandVal.uniqueValues = new HashSet(); //reset random values
-  doTest();
-  destroyServers();
-} else {
-  for (int nServers = 1; nServers < shardCount; nServers++) {
-createServers(nServers);
+  @Retention(RetentionPolicy.RUNTIME)
+  @Target(ElementType.METHOD)
+  public @interface ShardsRepeat {
+public abstract int min() default 1;
+public abstract int max() default DEFAULT_MAX_SHARD_COUNT;
+  }
+
+  @Retention(RetentionPolicy.RUNTIME)
+  @Target(ElementType.METHOD)
+  public @interface ShardsFixed {
+public abstract int num();
+  }
+
+  public class ShardsRepeatRule implements TestRule {
--- End diff --

+1 This is a really good idea.


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

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

[GitHub] lucene-solr pull request: Use JUnit rules instead of inheritance w...

[madrob]

Github user madrob commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/121#discussion_r22362512
  
--- Diff: 
solr/core/src/test/org/apache/solr/cloud/TestDistribDocBasedVersion.java ---
@@ -350,8 +348,8 @@ void doDBQ(String q, String... reqParams) throws 
Exception {
   }
 
   @Override
-  public void tearDown() throws Exception {
-super.tearDown();
+  public void distribTearDown() throws Exception {
--- End diff --

Is this override necessary? Without it, the call would just resolve to the 
super class anyway.


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

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

[GitHub] lucene-solr pull request: Use JUnit rules instead of inheritance w...

[madrob]

Github user madrob commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/121#discussion_r22362519
  
--- Diff: 
solr/core/src/test/org/apache/solr/cloud/TriLevelCompositeIdRoutingTest.java ---
@@ -155,8 +153,8 @@ private String getKey(String id) {
   }
 
   @Override
-  public void tearDown() throws Exception {
-super.tearDown();
+  public void distribTearDown() throws Exception {
--- End diff --

Is this override necessary? Without it, the call would just resolve to the 
super class anyway.


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

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

[GitHub] lucene-solr pull request: Use JUnit rules instead of inheritance w...

[madrob]

Github user madrob commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/121#discussion_r22362487
  
--- Diff: solr/core/src/test/org/apache/solr/cloud/ShardRoutingTest.java ---
@@ -351,8 +334,8 @@ void doDBQ(String q, String... reqParams) throws 
Exception {
   }
 
   @Override
-  public void tearDown() throws Exception {
-super.tearDown();
+  public void distribTearDown() throws Exception {
--- End diff --

Is this override necessary? Without it, the call would just resolve to the 
super class anyway.


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

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

[GitHub] lucene-solr pull request: Use JUnit rules instead of inheritance w...

[madrob]

Github user madrob commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/121#discussion_r22362427
  
--- Diff: solr/core/src/test/org/apache/solr/cloud/MigrateRouteKeyTest.java 
---
@@ -77,7 +75,7 @@ public void tearDown() throws Exception {
 if (controlClientCloud != null) {
   controlClientCloud.shutdown();
 }
-super.tearDown();
+super.distribTearDown();
--- End diff --

super.distribTearDown() is called twice in this method.


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

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

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 719 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/719/

1 tests failed.
REGRESSION:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch

Error Message:
Error from server at http://127.0.0.1:65196: java.lang.NullPointerException 

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Error 
from server at http://127.0.0.1:65196: java.lang.NullPointerException

at 
org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:566)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:213)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:209)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:448)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:200)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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.

[GitHub] lucene-solr pull request: Use JUnit rules instead of inheritance w...

[madrob]

Github user madrob commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/121#discussion_r22362409
  
--- Diff: solr/core/src/test/org/apache/solr/cloud/DeleteShardTest.java ---
@@ -71,7 +68,7 @@ public void tearDown() throws Exception {
 if (controlClientCloud != null) {
   controlClientCloud.shutdown();
 }
-super.tearDown();
+super.distribTearDown();
--- End diff --

super.distribTearDown() is called twice in this method.


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

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

[jira] [Commented] (SOLR-6902) Use JUnit rules instead of inheritance with distributed Solr tests to allow for multiple tests without the same class

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-6902:
-

There's a bit of a subtlety here btw with a re-implementation of the 
{{setUp}}/{{tearDown}} mechanism since I couldn't figure out a way to have 
rules run after they have (which are tagged @Before).

> Use JUnit rules instead of inheritance with distributed Solr tests to allow 
> for multiple tests without the same class
> -
>
> Key: SOLR-6902
> URL: https://issues.apache.org/jira/browse/SOLR-6902
> Project: Solr
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Ramkumar Aiyengar
>Priority: Minor
>
> Finally got annoyed enough with too many things being clubbed into one test 
> method in all distributed Solr tests (anything inheriting from 
> {{BaseDistributedSearchTestCase}} and currently implementing {{doTest}})..
> This just lays the groundwork really for allowing multiple test methods 
> within the same class, and doesn't split tests as yet or flatten the 
> inheritance hierarchy (when abused for doing multiple tests), as this touches 
> a lot of files by itself. For that reason, the sooner this is picked up the 
> better..



--
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-6902) Use JUnit rules instead of inheritance with distributed Solr tests to allow for multiple tests without the same class

[Ramkumar Aiyengar (JIRA)]

Ramkumar Aiyengar created SOLR-6902:
---

 Summary: Use JUnit rules instead of inheritance with distributed 
Solr tests to allow for multiple tests without the same class
 Key: SOLR-6902
 URL: https://issues.apache.org/jira/browse/SOLR-6902
 Project: Solr
  Issue Type: Improvement
  Components: Tests
Reporter: Ramkumar Aiyengar
Priority: Minor


Finally got annoyed enough with too many things being clubbed into one test 
method in all distributed Solr tests (anything inheriting from 
{{BaseDistributedSearchTestCase}} and currently implementing {{doTest}})..

This just lays the groundwork really for allowing multiple test methods within 
the same class, and doesn't split tests as yet or flatten the inheritance 
hierarchy (when abused for doing multiple tests), as this touches a lot of 
files by itself. For that reason, the sooner this is picked up the better..



--
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-6902) Use JUnit rules instead of inheritance with distributed Solr tests to allow for multiple tests without the same class

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-6902:
--

GitHub user andyetitmoves opened a pull request:

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

Use JUnit rules instead of inheritance with distributed Solr tests to allow 
for multiple tests without the same class

Patch for SOLR-6902

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

$ git pull https://github.com/bloomberg/lucene-solr trunk-shard-junit-rule

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

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

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

This closes #121


commit 02d678044a9f399a6bdf63e9a977d6e760a0a1bf
Author: Ramkumar Aiyengar 
Date:   2014-12-30T14:39:23Z

Use JUnit rules instead of inheritance with distributed tests to allow for 
multiple tests without the same class.




> Use JUnit rules instead of inheritance with distributed Solr tests to allow 
> for multiple tests without the same class
> -
>
> Key: SOLR-6902
> URL: https://issues.apache.org/jira/browse/SOLR-6902
> Project: Solr
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Ramkumar Aiyengar
>Priority: Minor
>
> Finally got annoyed enough with too many things being clubbed into one test 
> method in all distributed Solr tests (anything inheriting from 
> {{BaseDistributedSearchTestCase}} and currently implementing {{doTest}})..
> This just lays the groundwork really for allowing multiple test methods 
> within the same class, and doesn't split tests as yet or flatten the 
> inheritance hierarchy (when abused for doing multiple tests), as this touches 
> a lot of files by itself. For that reason, the sooner this is picked up the 
> better..



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

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

[GitHub] lucene-solr pull request: Use JUnit rules instead of inheritance w...

[andyetitmoves]

GitHub user andyetitmoves opened a pull request:

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

Use JUnit rules instead of inheritance with distributed Solr tests to allow 
for multiple tests without the same class

Patch for SOLR-6902

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

$ git pull https://github.com/bloomberg/lucene-solr trunk-shard-junit-rule

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

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

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

This closes #121


commit 02d678044a9f399a6bdf63e9a977d6e760a0a1bf
Author: Ramkumar Aiyengar 
Date:   2014-12-30T14:39:23Z

Use JUnit rules instead of inheritance with distributed tests to allow for 
multiple tests without the same class.




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

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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-5.x #803: POMs out of sync

[Erik Hatcher]

How do we get this one fixed?   I see it seemed to start happening around 
https://builds.apache.org/job/Lucene-Solr-Maven-5.x/784/ 


Erik

> On Dec 30, 2014, at 10:54 AM, Apache Jenkins Server 
>  wrote:
> 
> Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/803/
> 
> 2 tests failed.
> FAILED:  org.apache.solr.hadoop.MorphlineBasicMiniMRTest.testPathParts
> 
> Error Message:
> Test abandoned because suite timeout was reached.
> 
> Stack Trace:
> java.lang.Exception: Test abandoned because suite timeout was reached.
>   at __randomizedtesting.SeedInfo.seed([B991C12C3C7B41B1]:0)
> 
> 
> FAILED:  
> org.apache.solr.hadoop.MorphlineBasicMiniMRTest.org.apache.solr.hadoop.MorphlineBasicMiniMRTest
> 
> Error Message:
> Suite timeout exceeded (>= 720 msec).
> 
> Stack Trace:
> java.lang.Exception: Suite timeout exceeded (>= 720 msec).
>   at __randomizedtesting.SeedInfo.seed([B991C12C3C7B41B1]:0)
> 
> 
> 
> 
> Build Log:
> [...truncated 54033 lines...]
> BUILD FAILED
> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:552:
>  The following error occurred while executing this line:
> /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:204:
>  The following error occurred while executing this line:
> : Java returned: 1
> 
> Total time: 343 minutes 49 seconds
> Build step 'Invoke Ant' marked build as failure
> Recording test results
> Email was triggered for: Failure
> Sending email for trigger: Failure
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4746) Create a move method in Directory.

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4746:
-

By the way, first we need to fix Directory.copy. I really hate that the 
signature is: 

{noformat}
copy(Directory to, String src, String dest, IOContext context)
{noformat}

This makes such a thing ridiculous to test, because we don't call the method on 
the directory that will actually be modified.

Instead I think it should be copyFrom(Directory sourceDir, ...) ?

> Create a move method in Directory.
> --
>
> Key: LUCENE-4746
> URL: https://issues.apache.org/jira/browse/LUCENE-4746
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, Trunk
>
> Attachments: LUCENE-4746.patch, LUCENE-4746.patch
>
>
> I'd like to make a move method for directory.
> We already have a move for Solr in DirectoryFactory, but it seems it belongs 
> at the directory level really.
> The default impl can do a copy and delete, but most implementations will be 
> able to optimize to a rename.
> Besides the move we do for Solr (to move a replicated index into place), it 
> would also be useful for another feature I'd like to add - the ability to 
> merge an index with moves rather than copies. In some cases, you don't 
> need/want to copy all the files and could just rename/move them. 



--
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-4746) Create a move method in Directory.

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-4746:

Attachment: LUCENE-4746.patch

Here is a simpler patch that just optimizes FSDirectory.copy() to use hard 
links when possible. If its not supported, we just fall back to what we do 
today.


> Create a move method in Directory.
> --
>
> Key: LUCENE-4746
> URL: https://issues.apache.org/jira/browse/LUCENE-4746
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, Trunk
>
> Attachments: LUCENE-4746.patch, LUCENE-4746.patch
>
>
> I'd like to make a move method for directory.
> We already have a move for Solr in DirectoryFactory, but it seems it belongs 
> at the directory level really.
> The default impl can do a copy and delete, but most implementations will be 
> able to optimize to a rename.
> Besides the move we do for Solr (to move a replicated index into place), it 
> would also be useful for another feature I'd like to add - the ability to 
> merge an index with moves rather than copies. In some cases, you don't 
> need/want to copy all the files and could just rename/move them. 



--
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-6792) cleanup solrconfig.xml files by removing implicit plugins

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-6792:
-

Hi [~noble.paul], I think the CHANGES.txt entry for this has got a bit messed 
up?  

It would be helpful to have more deprecation information in the javadoc for the 
deprecated class as well - at the moment, it just tells you it's deprecated, it 
doesn't say what you should do instead.

I also wonder if it's worth going through and removing explicit definitions 
from the various test and example solrconfig.xml files we have?  And nuking the 
class entirely in trunk.

> cleanup solrconfig.xml files by removing implicit plugins
> -
>
> Key: SOLR-6792
> URL: https://issues.apache.org/jira/browse/SOLR-6792
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6792.patch
>
>
>  /replication , /get , /update, /admin/ are registered implicitly for each 
> core. No need to specify them from solrconfig.xml if nothing custom needs to 
> be added



--
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] [Closed] (LUCENE-6145) Make EarlyTerminatingSortingCollector smarter about when it can early terminate

[Adrien Grand (JIRA)]

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

Adrien Grand closed LUCENE-6145.

   Resolution: Fixed
Fix Version/s: Trunk
   5.0

> Make EarlyTerminatingSortingCollector smarter about when it can early 
> terminate
> ---
>
> Key: LUCENE-6145
> URL: https://issues.apache.org/jira/browse/LUCENE-6145
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6145.patch
>
>
> Today EarlyTerminatingSortingCollector only early-terminates if the sort 
> order matches exactly the index-time sort order. It should also 
> early-terminate when the sort order is a prefix of the index-time sort order.



--
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-6640) ChaosMonkeySafeLeaderTest failure with CorruptIndexException

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-6640:

Attachment: SOLR-6640_new_index_dir.patch

This patch uses the following approach - Download all missing files from leader 
into the tempIndexDir and then copy over the remaining files from the current 
index directory into the tempIndexDir. Now use the index.properties method to 
switch to the new index. 

Main changes are in moveIndexFiles() method.

Still very rough and needs refactoring, but wanted to share this approach and 
get some thoughts on it.

> ChaosMonkeySafeLeaderTest failure with CorruptIndexException
> 
>
> Key: SOLR-6640
> URL: https://issues.apache.org/jira/browse/SOLR-6640
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 5.0
>Reporter: Shalin Shekhar Mangar
> Fix For: 5.0
>
> Attachments: Lucene-Solr-5.x-Linux-64bit-jdk1.8.0_20-Build-11333.txt, 
> SOLR-6640.patch, SOLR-6640.patch, SOLR-6640_new_index_dir.patch
>
>
> Test failure found on jenkins:
> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11333/
> {code}
> 1 tests failed.
> REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch
> Error Message:
> shard2 is not consistent.  Got 62 from 
> http://127.0.0.1:57436/collection1lastClient and got 24 from 
> http://127.0.0.1:53065/collection1
> Stack Trace:
> java.lang.AssertionError: shard2 is not consistent.  Got 62 from 
> http://127.0.0.1:57436/collection1lastClient and got 24 from 
> http://127.0.0.1:53065/collection1
> at 
> __randomizedtesting.SeedInfo.seed([F4B371D421E391CD:7555FFCC56BCF1F1]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1255)
> at 
> org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1234)
> at 
> org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:162)
> at 
> org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
> {code}
> Cause of inconsistency is:
> {code}
> Caused by: org.apache.lucene.index.CorruptIndexException: file mismatch, 
> expected segment id=yhq3vokoe1den2av9jbd3yp8, got=yhq3vokoe1den2av9jbd3yp7 
> (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.ChaosMonkeySafeLeaderTest-F4B371D421E391CD-001/tempDir-001/jetty3/index/_1_2.liv")))
>[junit4]   2>  at 
> org.apache.lucene.codecs.CodecUtil.checkSegmentHeader(CodecUtil.java:259)
>[junit4]   2>  at 
> org.apache.lucene.codecs.lucene50.Lucene50LiveDocsFormat.readLiveDocs(Lucene50LiveDocsFormat.java:88)
>[junit4]   2>  at 
> org.apache.lucene.codecs.asserting.AssertingLiveDocsFormat.readLiveDocs(AssertingLiveDocsFormat.java:64)
>[junit4]   2>  at 
> org.apache.lucene.index.SegmentReader.(SegmentReader.java:102)
> {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-6145) Make EarlyTerminatingSortingCollector smarter about when it can early terminate

[ASF subversion and git services (JIRA)]

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

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

Commit 1648555 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1648555 ]

LUCENE-6145: Make EarlyTerminatingSortingCollector able to early-terminate when 
the sort order is a prefix of the index-time order.

> Make EarlyTerminatingSortingCollector smarter about when it can early 
> terminate
> ---
>
> Key: LUCENE-6145
> URL: https://issues.apache.org/jira/browse/LUCENE-6145
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6145.patch
>
>
> Today EarlyTerminatingSortingCollector only early-terminates if the sort 
> order matches exactly the index-time sort order. It should also 
> early-terminate when the sort order is a prefix of the index-time sort order.



--
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-6145) Make EarlyTerminatingSortingCollector smarter about when it can early terminate

[ASF subversion and git services (JIRA)]

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

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

Commit 1648547 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1648547 ]

LUCENE-6145: Make EarlyTerminatingSortingCollector able to early-terminate when 
the sort order is a prefix of the index-time order.

> Make EarlyTerminatingSortingCollector smarter about when it can early 
> terminate
> ---
>
> Key: LUCENE-6145
> URL: https://issues.apache.org/jira/browse/LUCENE-6145
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6145.patch
>
>
> Today EarlyTerminatingSortingCollector only early-terminates if the sort 
> order matches exactly the index-time sort order. It should also 
> early-terminate when the sort order is a prefix of the index-time sort order.



--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions

[Boon Low (JIRA)]

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

Boon Low edited comment on SOLR-6648 at 12/30/14 5:08 PM:
--

I have created a patche for this, in Lucene and Solr, so that highlighting and 
the Boolean matching clause can be configured in solrconfig.xml, for 
*BlendedInfixSuggester* and *AnalyzingInfixSuggester*:

{code:xml}
   
..
BlendedInfixLookupFactory
DocumentDictionaryFactory
 ...
false
true
 
{code}

If not configured, both 'highlighting' and 'allTermsRequired' default to *true.


was (Author: boonious):
I have created a patche for this, in Lucene and Solr, so that the suggester 
highlighting and the Boolean matching option can be configured in 
solrconfig.xml, for *BlendedInfixSuggester* and *AnalyzingInfixSuggester*:

{code:xml}
   
..
BlendedInfixLookupFactory
DocumentDictionaryFactory
 ...
false
true
 
{code}

If not configured, both 'highlighting' and 'allTermsRequired' default to *true.

> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>  Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6648.patch
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions

[Boon Low (JIRA)]

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

Boon Low commented on SOLR-6648:


Patch submitted. Also added a couple of unit tests for allTermsRequired=false.

Since the patch involves Lucene suggesters (AnalyzingInfixSuggester, 
BlendedInfixSuggester) and the corresponding factories in Solr, do we need to 
open a Lucene issue?

Please change the title of this issue to something cf. "Infix suggesters 
highlighting and allTermsRequired configuration"  to reflect to the scope of 
patch.

> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>  Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6648.patch
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-5209) last replica removal cascades to remove shard from clusterstate

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5209:
---

I think as part of making zk the truth we actually do want to prevent creation 
of cores that are not part of a zk collection. 

> last replica removal cascades to remove shard from clusterstate
> ---
>
> Key: SOLR-5209
> URL: https://issues.apache.org/jira/browse/SOLR-5209
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.4
>Reporter: Christine Poerschke
>Assignee: Mark Miller
> Attachments: SOLR-5209.patch
>
>
> The problem we saw was that unloading of an only replica of a shard deleted 
> that shard's info from the clusterstate. Once it was gone then there was no 
> easy way to re-create the shard (other than dropping and re-creating the 
> whole collection's state).
> This seems like a bug?
> Overseer.java around line 600 has a comment and commented out code:
> // TODO TODO TODO!!! if there are no replicas left for the slice, and the 
> slice has no hash range, remove it
> // if (newReplicas.size() == 0 && slice.getRange() == null) {
> // if there are no replicas left for the slice remove it



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

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

[jira] [Commented] (LUCENE-6138) ItalianLightStemmer doesn't apply on words shorter then 6 chars in length

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-6138:


Unfortunately I don't quite know, I've used the stemmers "as is".

Sorry I can't help... 

> ItalianLightStemmer doesn't apply on words shorter then 6 chars in length
> -
>
> Key: LUCENE-6138
> URL: https://issues.apache.org/jira/browse/LUCENE-6138
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 4.10.2
>Reporter: Massimo Pasquini
>Priority: Minor
>
> I expect a stemmer to transform nouns in their singular and plural forms into 
> a shorter common form. The implementation of the ItalianLightStemmer doesn't 
> apply any stemming to words shorter then 6 characters in length. This leads 
> to some annoying results:
> singular form | plural form
> 4|5 chars in length (no stemming)
> alga -> alga | alghe -> alghe
> fuga -> fuga | fughe -> fughe
> lega -> lega | leghe -> leghe
> 5|6 chars in length (stemming only on plural form)
> vanga -> vanga | vanghe -> vang
> verga -> verga | verghe -> verg
> I suppose that such limitation on words length is to avoid other side effects 
> on shorter words not in the set above, but I think something must be reviewed 
> in the code for better results.



--
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-5209) last replica removal cascades to remove shard from clusterstate

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-5209:
-

I think this might fail 
{{BasicDistributedZkTest.testFailedCoreCreateCleansUp}}.. If we call core 
create, it happens to be the first core of the collection, and the core 
creation fails (due to say, a config issue) -- the test currently verifies if 
the rollback happens by checking for the absence of the collection. We could 
obviously change the test, but in such a case, should we be removing the 
collection as well? (or disallow creation of a core for a non-existent 
collection -- though that might be a bigger, disruptive end user change and not 
necessarily good)..

> last replica removal cascades to remove shard from clusterstate
> ---
>
> Key: SOLR-5209
> URL: https://issues.apache.org/jira/browse/SOLR-5209
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.4
>Reporter: Christine Poerschke
>Assignee: Mark Miller
> Attachments: SOLR-5209.patch
>
>
> The problem we saw was that unloading of an only replica of a shard deleted 
> that shard's info from the clusterstate. Once it was gone then there was no 
> easy way to re-create the shard (other than dropping and re-creating the 
> whole collection's state).
> This seems like a bug?
> Overseer.java around line 600 has a comment and commented out code:
> // TODO TODO TODO!!! if there are no replicas left for the slice, and the 
> slice has no hash range, remove it
> // if (newReplicas.size() == 0 && slice.getRange() == null) {
> // if there are no replicas left for the slice remove it



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

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

[jira] [Comment Edited] (SOLR-6648) AnalyzingInfixLookupFactory always highlights suggestions

[Boon Low (JIRA)]

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

Boon Low edited comment on SOLR-6648 at 12/30/14 4:58 PM:
--

I have created a patche for this, in Lucene and Solr, so that the suggester 
highlighting and the Boolean matching option can be configured in 
solrconfig.xml, for *BlendedInfixSuggester* and *AnalyzingInfixSuggester*:

{code:xml}
   
..
BlendedInfixLookupFactory
DocumentDictionaryFactory
 ...
false
true
 
{code}

If not configured, both 'highlighting' and 'allTermsRequired' default to *true.


was (Author: boonious):
I have created a patche for this, in Lucene and Solr, so that the suggester 
highlighting and the Boolean matching option can be configured in 
solrconfig.xml, for *BlendedInfixSuggester* and *AnalyzingInfixSuggester*:

{code:xml}
   
..
BlendedInfixLookupFactory
DocumentDictionaryFactory
 ...
false
true
 
{code}


> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>  Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6648.patch
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions

[Boon Low (JIRA)]

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

Boon Low updated SOLR-6648:
---
Attachment: SOLR-6648.patch

> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>  Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6648.patch
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions

[Boon Low (JIRA)]

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

Boon Low updated SOLR-6648:
---
Attachment: (was: SOLR-6648)

> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>  Labels: suggester
> Fix For: 5.0, Trunk
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-6138) ItalianLightStemmer doesn't apply on words shorter then 6 chars in length

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6138:
-

One nice thing about the porter stemmer is that it does some basic syllable 
counting instead of using arbitrary limits of characters like the light 
stemmers do. This is more complicated than checking a limit, but probably the 
best solution for this problem. Its probably easier to implement this logic 
with the snowball language itself (for this language, the logic already exists 
there), but could be done in java too. However these kind of changes need real 
evaluation work too. Currently we don't invent these light stemmers, we just 
use other people's work.



> ItalianLightStemmer doesn't apply on words shorter then 6 chars in length
> -
>
> Key: LUCENE-6138
> URL: https://issues.apache.org/jira/browse/LUCENE-6138
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 4.10.2
>Reporter: Massimo Pasquini
>Priority: Minor
>
> I expect a stemmer to transform nouns in their singular and plural forms into 
> a shorter common form. The implementation of the ItalianLightStemmer doesn't 
> apply any stemming to words shorter then 6 characters in length. This leads 
> to some annoying results:
> singular form | plural form
> 4|5 chars in length (no stemming)
> alga -> alga | alghe -> alghe
> fuga -> fuga | fughe -> fughe
> lega -> lega | leghe -> leghe
> 5|6 chars in length (stemming only on plural form)
> vanga -> vanga | vanghe -> vang
> verga -> verga | verghe -> verg
> I suppose that such limitation on words length is to avoid other side effects 
> on shorter words not in the set above, but I think something must be reviewed 
> in the code for better results.



--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions

[Boon Low (JIRA)]

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

Boon Low updated SOLR-6648:
---
Attachment: SOLR-6648

> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>  Labels: suggester
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6648
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions

[Boon Low (JIRA)]

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

Boon Low commented on SOLR-6648:


I have created a patche for this, in Lucene and Solr, so that the suggester 
highlighting and the Boolean matching option can be configured in 
solrconfig.xml, for *BlendedInfixSuggester* and *AnalyzingInfixSuggester*:

{code:xml}
   
..
BlendedInfixLookupFactory
DocumentDictionaryFactory
 ...
false
true
 
{code}


> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>  Labels: suggester
> Fix For: 5.0, Trunk
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-6145) Make EarlyTerminatingSortingCollector smarter about when it can early terminate

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6145:
-

I am +1 to the patch, but not excited about permanently requiring the user to 
pass a MergePolicy to this collector.

One reason is that it makes it harder to integrate with other search code. E.G. 
somewhere i made a patch to allow inexact results/hit counts as flags to 
indexsearcher, which would make this collector much easier to use (and also 
allow other tricks). 

But this means somehow we have to serialize the "sort" better, which is 
complicated. So +1 to the patch for now :)

> Make EarlyTerminatingSortingCollector smarter about when it can early 
> terminate
> ---
>
> Key: LUCENE-6145
> URL: https://issues.apache.org/jira/browse/LUCENE-6145
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6145.patch
>
>
> Today EarlyTerminatingSortingCollector only early-terminates if the sort 
> order matches exactly the index-time sort order. It should also 
> early-terminate when the sort order is a prefix of the index-time sort order.



--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions

[Boon Low (JIRA)]

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

Boon Low commented on SOLR-6648:


Suggestion highlighting and "allTermsRequired" options are currently hardwired 
in Lucene - see *true*, *true* in the lookup method in 
*AnalyzingInfixSuggester.java* below:

{code}
public List lookup(CharSequence key, Set contexts, 
boolean onlyMorePopular, int num) throws IOException {
return lookup(key, contexts, num, true, true);
}

/** Lookup, without any context. */
public List lookup(CharSequence key, int num, boolean 
allTermsRequired, boolean doHighlight) throws IOException {
return lookup(key, null, num, allTermsRequired, doHighlight);
  }
{code}

The lookup method (proper) does support the options, e.g. creating the 
appropriate Boolean lookup clauses based on "allTermsRequired": 
BooleanClause.Occur.MUST vs. BooleanClause.Occur.SHOULD.



> AnalyzingInfixLookupFactory always highlights suggestions
> -
>
> Key: SOLR-6648
> URL: https://issues.apache.org/jira/browse/SOLR-6648
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
>Reporter: Varun Thacker
>  Labels: suggester
> Fix For: 5.0, Trunk
>
>
> When using AnalyzingInfixLookupFactory suggestions always return with the 
> match term as highlighted and 'allTermsRequired' is always set to true.
> We should be able to configure those.
> Steps to reproduce - 
> schema additions
> {code}
> 
> 
>   mySuggester
>   AnalyzingInfixLookupFactory
>   DocumentDictionaryFactory 
>   suggestField
>   weight
>   textSuggest
> 
>   
>   
> 
>   true
>   10
> 
> 
>   suggest
> 
>   
> {code}
> solrconfig changes -
> {code}
>  positionIncrementGap="100">
>
>   
>   
>   
>
>   
> stored="true"/>
> {code}
> Add 3 documents - 
> {code}
> curl http://localhost:8983/solr/update/json?commit=true -H 
> 'Content-type:application/json' -d '
> [ {"id" : "1", "suggestField" : "bass fishing"}, {"id" : "2", "suggestField" 
> : "sea bass"}, {"id" : "3", "suggestField" : "sea bass fishing"} ]
> '
> {code}
> Query -
> {code}
> http://localhost:8983/solr/collection1/suggest?suggest.build=true&suggest.dictionary=mySuggester&q=bass&wt=json&indent=on
> {code}
> Response 
> {code}
> {
>   "responseHeader":{
> "status":0,
> "QTime":25},
>   "command":"build",
>   "suggest":{"mySuggester":{
>   "bass":{
> "numFound":3,
> "suggestions":[{
> "term":"bass fishing",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass",
> "weight":0,
> "payload":""},
>   {
> "term":"sea bass fishing",
> "weight":0,
> "payload":""}]
> {code}
> The problem is in SolrSuggester Line 200 where we say lookup.lookup()
> This constructor does not take allTermsRequired and doHighlight since it's 
> only tuneable to AnalyzingInfixSuggester and not the other lookup 
> implementations.
> If different Lookup implementations have different params as their 
> constructors, these sort of issues will always keep happening. Maybe we 
> should not keep it generic and do instanceof checks and set params 
> accordingly?



--
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-6901) Rethink EmbeddedSolrServer CoreContainer use

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-6901:
---

 Summary: Rethink EmbeddedSolrServer CoreContainer use
 Key: SOLR-6901
 URL: https://issues.apache.org/jira/browse/SOLR-6901
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Priority: Minor


This was originally going to be about removing the EmbeddedSolrServer 
constructor that takes a SolrCore, which has been deprecated since at least 
2010 (!).  Digging around a bit, though, it seems that having a CoreContainer 
reference in ESS isn't very useful, especially as we only allow querying a 
single core from it.

What it *does* allow you to do is to send CoreAdminRequests, but again most of 
these are not useful for a single core.

I don't really have a strong opinion here, other than that we shouldn't carry a 
Deprecated annotation across a third (!) major release.  
* Simplest option is to just nuke that constructor (it's currently used in a 
single test, which can be re-written).
* Another option would be to 'undeprecate' it, and simply disallow core admin 
requests if coreContainer is null
* Yet another possibility is to stop holding on to the CoreContainer reference, 
and instead have a custom CoreAdminHandler that only works for commands that 
'make sense' for a single core (essentially, RELOAD and STATUS) and returns the 
SolrJ equivalent of an UnsupportedOperationException for everything else.

I'm leaning mostly to option 2 at the moment, because I think an embedded 
client that takes a single core is a very useful abstraction (could be a nice 
way of short-circuiting local requests in ShardHandler, for example).



--
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-6138) ItalianLightStemmer doesn't apply on words shorter then 6 chars in length

[Massimo Pasquini (JIRA)]

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

Massimo Pasquini commented on LUCENE-6138:
--

Could you please give me the link to the right place to post issues about the 
stemmers? I cannot find any link to the project. Thanks

> ItalianLightStemmer doesn't apply on words shorter then 6 chars in length
> -
>
> Key: LUCENE-6138
> URL: https://issues.apache.org/jira/browse/LUCENE-6138
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 4.10.2
>Reporter: Massimo Pasquini
>Priority: Minor
>
> I expect a stemmer to transform nouns in their singular and plural forms into 
> a shorter common form. The implementation of the ItalianLightStemmer doesn't 
> apply any stemming to words shorter then 6 characters in length. This leads 
> to some annoying results:
> singular form | plural form
> 4|5 chars in length (no stemming)
> alga -> alga | alghe -> alghe
> fuga -> fuga | fughe -> fughe
> lega -> lega | leghe -> leghe
> 5|6 chars in length (stemming only on plural form)
> vanga -> vanga | vanghe -> vang
> verga -> verga | verghe -> verg
> I suppose that such limitation on words length is to avoid other side effects 
> on shorter words not in the set above, but I think something must be reviewed 
> in the code for better results.



--
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-6145) Make EarlyTerminatingSortingCollector smarter about when it can early terminate

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6145:
-
Attachment: LUCENE-6145.patch

Here is a patch. EarlyTerminatingSortingCollector now also takes the merge 
policy as an argument to check if the sort order is a prefix of the index-time 
order and then early-terminates on every segment where the serialized index 
order matches the sort order that is wrapped by the merge policy.

> Make EarlyTerminatingSortingCollector smarter about when it can early 
> terminate
> ---
>
> Key: LUCENE-6145
> URL: https://issues.apache.org/jira/browse/LUCENE-6145
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6145.patch
>
>
> Today EarlyTerminatingSortingCollector only early-terminates if the sort 
> order matches exactly the index-time sort order. It should also 
> early-terminate when the sort order is a prefix of the index-time sort order.



--
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-6144) Upgrade ivy to 2.4.0

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on LUCENE-6144:
--

The precommit passed.  If there's no objection, I will commit later today (9:30 
AM for me currently).

> Upgrade ivy to 2.4.0
> 
>
> Key: LUCENE-6144
> URL: https://issues.apache.org/jira/browse/LUCENE-6144
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Affects Versions: 5.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6144.patch
>
>
> Ivy 2.4.0 is released.  IVY-1489 is likely to still be a problem.
> I'm not sure whether we have a minimum version check for ivy, or whether we 
> are using any features that *require* a minimum version check.



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

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

[jira] [Created] (LUCENE-6145) Make EarlyTerminatingSortingCollector smarter about when it can early terminate

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6145:


 Summary: Make EarlyTerminatingSortingCollector smarter about when 
it can early terminate
 Key: LUCENE-6145
 URL: https://issues.apache.org/jira/browse/LUCENE-6145
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


Today EarlyTerminatingSortingCollector only early-terminates if the sort order 
matches exactly the index-time sort order. It should also early-terminate when 
the sort order is a prefix of the index-time sort order.



--
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-6144) Upgrade ivy to 2.4.0

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on LUCENE-6144:
--

For that test run, and the precommit, I *did* erase the 2.3.0 jar from 
~/.ant/lib and re-do ivy-bootstrap.


> Upgrade ivy to 2.4.0
> 
>
> Key: LUCENE-6144
> URL: https://issues.apache.org/jira/browse/LUCENE-6144
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Affects Versions: 5.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6144.patch
>
>
> Ivy 2.4.0 is released.  IVY-1489 is likely to still be a problem.
> I'm not sure whether we have a minimum version check for ivy, or whether we 
> are using any features that *require* a minimum version check.



--
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-6144) Upgrade ivy to 2.4.0

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated LUCENE-6144:
-
Attachment: LUCENE-6144.patch

Patch to upgrade ivy.

One run of all normal tests passed.  Checking precommit now.

> Upgrade ivy to 2.4.0
> 
>
> Key: LUCENE-6144
> URL: https://issues.apache.org/jira/browse/LUCENE-6144
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Affects Versions: 5.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6144.patch
>
>
> Ivy 2.4.0 is released.  IVY-1489 is likely to still be a problem.
> I'm not sure whether we have a minimum version check for ivy, or whether we 
> are using any features that *require* a minimum version check.



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

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

[jira] [Created] (LUCENE-6144) Upgrade ivy to 2.4.0

[Shawn Heisey (JIRA)]

Shawn Heisey created LUCENE-6144:


 Summary: Upgrade ivy to 2.4.0
 Key: LUCENE-6144
 URL: https://issues.apache.org/jira/browse/LUCENE-6144
 Project: Lucene - Core
  Issue Type: Task
  Components: general/build
Affects Versions: 5.0
Reporter: Shawn Heisey
Assignee: Shawn Heisey
 Fix For: 5.0, Trunk


Ivy 2.4.0 is released.  IVY-1489 is likely to still be a problem.

I'm not sure whether we have a minimum version check for ivy, or whether we are 
using any features that *require* a minimum version check.




--
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-MAVEN] Lucene-Solr-Maven-5.x #803: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/803/

2 tests failed.
FAILED:  org.apache.solr.hadoop.MorphlineBasicMiniMRTest.testPathParts

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([B991C12C3C7B41B1]:0)


FAILED:  
org.apache.solr.hadoop.MorphlineBasicMiniMRTest.org.apache.solr.hadoop.MorphlineBasicMiniMRTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([B991C12C3C7B41B1]:0)




Build Log:
[...truncated 54033 lines...]
BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:552: 
The following error occurred while executing this line:
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:204: 
The following error occurred while executing this line:
: Java returned: 1

Total time: 343 minutes 49 seconds
Build step 'Invoke Ant' marked build as failure
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (SOLR-6895) Consider renaming SolrServer to SolrClient

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-6895:
-

It'll work if you recompile against the new jar.  Not sure if you just drop in 
the new jar to an existing indexer's classpath, I think that probably depends 
on the JVM and Classloader, but I don't think that's something we can guarantee 
anyway.

> Consider renaming SolrServer to SolrClient
> --
>
> Key: SOLR-6895
> URL: https://issues.apache.org/jira/browse/SOLR-6895
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 5.0, Trunk
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: SOLR-6895.patch, SOLR-6895.patch
>
>
> This has been niggling at me for a while.  Instantiating a new SolrServer 
> object doesn't create a server, it creates a client.



--
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-6895) Consider renaming SolrServer to SolrClient

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-6895:
---

bq. Consider renaming SolrServer to SolrClient

+1

> Consider renaming SolrServer to SolrClient
> --
>
> Key: SOLR-6895
> URL: https://issues.apache.org/jira/browse/SOLR-6895
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 5.0, Trunk
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: SOLR-6895.patch, SOLR-6895.patch
>
>
> This has been niggling at me for a while.  Instantiating a new SolrServer 
> object doesn't create a server, it creates a client.



--
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-6127) Improve Solr's exampledocs data

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-6127:


I moved it up as a first-class citizen under example (so we can have its own 
config/view as needed later maybe).

> Improve Solr's exampledocs data
> ---
>
> Key: SOLR-6127
> URL: https://issues.apache.org/jira/browse/SOLR-6127
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation, scripts and tools
>Reporter: Varun Thacker
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: LICENSE.txt, README.txt, README.txt, SOLR-6127.patch, 
> film.csv, film.json, film.xml, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py
>
>
> Currently 
> - The CSV example has 10 documents.
> - The JSON example has 4 documents.
> - The XML example has 32 documents.
> 1. We should have equal number of documents and the same documents in all the 
> example formats
> 2. A data set which is slightly more comprehensive.



--
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-6127) Improve Solr's exampledocs data

[ASF subversion and git services (JIRA)]

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

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

Commit 1648540 from [~ehatcher] in branch 'dev/trunk'
[ https://svn.apache.org/r1648540 ]

SOLR-6127: move films example (data) to its own subdirectory

> Improve Solr's exampledocs data
> ---
>
> Key: SOLR-6127
> URL: https://issues.apache.org/jira/browse/SOLR-6127
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation, scripts and tools
>Reporter: Varun Thacker
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
> Attachments: LICENSE.txt, README.txt, README.txt, SOLR-6127.patch, 
> film.csv, film.json, film.xml, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py, freebase_film_dump.py, 
> freebase_film_dump.py, freebase_film_dump.py
>
>
> Currently 
> - The CSV example has 10 documents.
> - The JSON example has 4 documents.
> - The XML example has 32 documents.
> 1. We should have equal number of documents and the same documents in all the 
> example formats
> 2. A data set which is slightly more comprehensive.



--
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-6797) Add score=degrees|kilometers|miles for AbstractSpatialFieldType

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-6797:


https://reviews.apache.org/r/29487/

> Add score=degrees|kilometers|miles for AbstractSpatialFieldType
> ---
>
> Key: SOLR-6797
> URL: https://issues.apache.org/jira/browse/SOLR-6797
> Project: Solr
>  Issue Type: Improvement
>  Components: spatial
>Reporter: David Smiley
> Attachments: SOLR-6797.patch, SOLR-6797.patch, SOLR-6797.patch, 
> SOLR-6797.patch, SOLR-6797.patch
>
>
> Annoyingly, the units="degrees" attribute is required for fields extending 
> AbstractSpatialFieldType (e.g. RPT, BBox).  And it doesn't really have any 
> effect.  I propose the following:
> * Simply drop the attribute; ignore it if someone sets it to "degrees" (for 
> back-compat).
> * When using score="distance", or score=area or area2D (as seen in BBoxField) 
> then use kilometers if geo=true, otherwise degrees.
> * Add support for score=degrees|kilometers|miles|degrees



--
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-5507) Admin UI - Refactoring using AngularJS

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-5507:
-

index and logging pages complete on the github branch. The only difference I 
can see is the fact that column widths are different on the logging page. 
Otherwise, it should be a feature-for-feature match.

> Admin UI - Refactoring using AngularJS
> --
>
> Key: SOLR-5507
> URL: https://issues.apache.org/jira/browse/SOLR-5507
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Attachments: SOLR-5507.patch
>
>
> On the LSR in Dublin, i've talked again to [~upayavira] and this time we 
> talked about Refactoring the existing UI - using AngularJS: providing (more, 
> internal) structure and what not ;>
> He already started working on the Refactoring, so this is more a 'tracking' 
> issue about the progress he/we do there.
> Will extend this issue with a bit more context & additional information, w/ 
> thoughts about the possible integration in the existing UI and more (:



--
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-6895) Consider renaming SolrServer to SolrClient

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-6895:


[~romseygeek] did you test that it works?   I wonder if somehow a test could be 
made that ensures that SolrServer stuff still works in a 4x indexer with the 
renamed stuff.   I have no objections, just want to be sure it's working in a 
backwards compatible way for 4x indexers.

> Consider renaming SolrServer to SolrClient
> --
>
> Key: SOLR-6895
> URL: https://issues.apache.org/jira/browse/SOLR-6895
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 5.0, Trunk
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: SOLR-6895.patch, SOLR-6895.patch
>
>
> This has been niggling at me for a while.  Instantiating a new SolrServer 
> object doesn't create a server, it creates a client.



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

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

[GitHub] lucene-solr pull request: Fixed a typo in various solrconfig.xml f...

[asfgit]

Github user asfgit closed the pull request at:

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


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

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

[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_40-ea-b09) - Build # 4415 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4415/
Java: 32bit/jdk1.8.0_40-ea-b09 -client -XX:+UseParallelGC (asserts: false)

1 tests failed.
FAILED:  org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT

Error Message:
SOLR-5815? : wrong maxDoc: core=org.apache.solr.core.SolrCore@179179a 
searcher=Searcher@d63cf2[collection1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_4(5.0.0):c1)
 Uninverting(_5(5.0.0):c1)))} expected:<3> but was:<2>

Stack Trace:
java.lang.AssertionError: SOLR-5815? : wrong maxDoc: 
core=org.apache.solr.core.SolrCore@179179a 
searcher=Searcher@d63cf2[collection1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_4(5.0.0):c1)
 Uninverting(_5(5.0.0):c1)))} expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([F8CD364450DA75D2:4D4B57C3EF1BC726]: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.core.TestNonNRTOpen.assertNotNRT(TestNonNRTOpen.java:142)
at 
org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT(TestNonNRTOpen.java:100)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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.

[jira] [Updated] (SOLR-6895) Consider renaming SolrServer to SolrClient

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-6895:

Attachment: SOLR-6895.patch

Updated patch, with deprecations after Erik's suggestion.

I'd like to commit this today, as it's pretty heavy and will likely get out of 
sync with trunk pretty quickly.

> Consider renaming SolrServer to SolrClient
> --
>
> Key: SOLR-6895
> URL: https://issues.apache.org/jira/browse/SOLR-6895
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 5.0, Trunk
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: SOLR-6895.patch, SOLR-6895.patch
>
>
> This has been niggling at me for a while.  Instantiating a new SolrServer 
> object doesn't create a server, it creates a client.



--
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-6895) Consider renaming SolrServer to SolrClient

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-6895:
-

Oh that would work, yes.  I'll amend the patch.  Thanks!

> Consider renaming SolrServer to SolrClient
> --
>
> Key: SOLR-6895
> URL: https://issues.apache.org/jira/browse/SOLR-6895
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 5.0, Trunk
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: SOLR-6895.patch
>
>
> This has been niggling at me for a while.  Instantiating a new SolrServer 
> object doesn't create a server, it creates a client.



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

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

Re: [JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2399 - Failure

[Erik Hatcher]

I wish!  It’s caught me a few times.


> On Dec 30, 2014, at 5:17 AM, Ramkumar R. Aiyengar  
> wrote:
> 
> Just curious since I see this come up once in a while. Doesn't Apache SVN 
> offer tweaking pre-commit hooks? Isn't this better checked there than failing 
> tests after the fact?
> 
> On 30 Dec 2014 08:35, "Erik Hatcher"  > wrote:
> I'll fix.  Geez!  :) sorry.
> 
> 
> > On Dec 30, 2014, at 00:59, Apache Jenkins Server  > > wrote:
> >
> > Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2399/ 
> > 
> >
> > All tests passed
> >
> > Build Log:
> > [...truncated 59402 lines...]
> > BUILD FAILED
> > /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:529:
> >  The following error occurred while executing this line:
> > /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:436:
> >  The following error occurred while executing this line:
> > /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/extra-targets.xml:105:
> >  The following error occurred while executing this line:
> > /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/extra-targets.xml:204:
> >  The following files are missing svn:eol-style (or binary svn:mime-type):
> > * ./solr/bin/post
> >
> > Total time: 96 minutes 28 seconds
> > Build step 'Invoke Ant' marked build as failure
> > Archiving artifacts
> > Sending artifact delta relative to Lucene-Solr-Tests-5.x-Java7 #2398
> > Archived 1 artifacts
> > Archive block size is 32768
> > Received 0 blocks and 464 bytes
> > Compression is 0.0%
> > Took 0.22 sec
> > Recording test results
> > Email was triggered for: Failure
> > Sending email for trigger: Failure
> >
> >
> >
> > -
> > 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] [Updated] (SOLR-6900) bin/post improvements needed

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-6900:
---
Description: 
* Fix glob patterns.  They don't work as expected: bin/post collection1 \*.xml 
expands \*.xml such that the script gets all the file names as parameters not 
just literally "\*.xml"
* Add error handling to check that the collection exists
* Create Windows version

  was:
* Fix glob patterns.  They don't work as expected: bin/post collection1 \*.xml 
expands \*.xml such that the script gets all the file names as parameters not 
just literally "\*.xml"
* Add error handling to check that the collection exists


> bin/post improvements needed
> 
>
> Key: SOLR-6900
> URL: https://issues.apache.org/jira/browse/SOLR-6900
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, Trunk
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
>
> * Fix glob patterns.  They don't work as expected: bin/post collection1 
> \*.xml expands \*.xml such that the script gets all the file names as 
> parameters not just literally "\*.xml"
> * Add error handling to check that the collection exists
> * Create Windows version



--
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-6900) bin/post improvements needed

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-6900:
---
Description: 
* Fix glob patterns.  They don't work as expected: bin/post collection1 \*.xml 
expands \*.xml such that the script gets all the file names as parameters not 
just literally "\*.xml"
* Add error handling to check that the collection exists

  was:
* Fix glob patterns.  They don't work as expected: bin/post collection1 *.xml 
expands *.xml such that the script gets all the file names as parameters not 
just literally "*.xml"
* Add error handling to check that the collection exists


> bin/post improvements needed
> 
>
> Key: SOLR-6900
> URL: https://issues.apache.org/jira/browse/SOLR-6900
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, Trunk
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.0, Trunk
>
>
> * Fix glob patterns.  They don't work as expected: bin/post collection1 
> \*.xml expands \*.xml such that the script gets all the file names as 
> parameters not just literally "\*.xml"
> * Add error handling to check that the collection exists



--
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-6900) bin/post improvements needed

[Erik Hatcher (JIRA)]

Erik Hatcher created SOLR-6900:
--

 Summary: bin/post improvements needed
 Key: SOLR-6900
 URL: https://issues.apache.org/jira/browse/SOLR-6900
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0, Trunk
Reporter: Erik Hatcher
Assignee: Erik Hatcher
 Fix For: 5.0, Trunk


* Fix glob patterns.  They don't work as expected: bin/post collection1 *.xml 
expands *.xml such that the script gets all the file names as parameters not 
just literally "*.xml"
* Add error handling to check that the collection exists



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