[JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 686 - Failure!

[jenkins]

Build: 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/686/

3 tests failed.
REGRESSION:  
org.apache.solr.handler.dataimport.TestSqlEntityProcessorDelta3.testCompositePk_DeltaImport_nodelta

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([C9DA3ED8D4A0A074:1A23CA2AB7ED56E8]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:459)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:426)
at 
org.apache.solr.handler.dataimport.TestSqlEntityProcessorDelta3.add1document(TestSqlEntityProcessorDelta3.java:83)
at 
org.apache.solr.handler.dataimport.TestSqlEntityProcessorDelta3.testCompositePk_DeltaImport_nodelta(TestSqlEntityProcessorDelta3.java:219)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:814)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:889)
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.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:821)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='1']
xml response was: 

010*:* OR add1documentstandard202.2


request 
was:start=0&q=*:*+OR+add1document&qt=standard&rows=20&version=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:45

[JENKINS] Lucene-Solr-trunk-Linux-Java7-64 - Build # 159 - Failure!

[jenkins]

Build: 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/159/

1 tests failed.
REGRESSION:  
org.apache.solr.handler.dataimport.TestSqlEntityProcessorDelta3.testCompositePk_DeltaImport_nodelta

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([623BF152C2FBB98D:B1C205A0A1B64F11]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:459)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:426)
at 
org.apache.solr.handler.dataimport.TestSqlEntityProcessorDelta3.add1document(TestSqlEntityProcessorDelta3.java:83)
at 
org.apache.solr.handler.dataimport.TestSqlEntityProcessorDelta3.testCompositePk_DeltaImport_nodelta(TestSqlEntityProcessorDelta3.java:219)
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:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:814)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:889)
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.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:821)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='1']
xml response was: 

010*:* OR add1documentstandard202.2


request 
was:start=0&q=*:*+OR+add1document&qt=standard&rows=20&version=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:45

[JENKINS] Lucene-Solr-trunk-Windows-Java6-64 - Build # 398 - Failure!

[jenkins]

Build: 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/398/

1 tests failed.
REGRESSION:  org.apache.solr.search.TestSort.testRandomFieldNameSorts

Error Message:
Over 0.2% oddities in test: 13/6395 have func/query parsing semenatics gotten 
broader?

Stack Trace:
java.lang.AssertionError: Over 0.2% oddities in test: 13/6395 have func/query 
parsing semenatics gotten broader?
at 
__randomizedtesting.SeedInfo.seed([E2CDF7FE0FBC0715:F6F3B575B5CC7983]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.search.TestSort.testRandomFieldNameSorts(TestSort.java:151)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:814)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:889)
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.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:821)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)




Build Log:
[...truncated 9831 lines...]
   [junit4]   2> 189 T2006 oasc.RequestHandlers.initHandlersFromConfig adding 
lazy requestHandler: solr.ReplicationHandler
   [junit4]   2> 189 T2006 oasc.RequestHandlers.initHandlersFromConfig created 
/replication: solr.ReplicationHandler
   [junit4]   2> 189 T2006 oasc.RequestHandlers.initHandlersFromConfig created 
standard: solr.StandardRequestHandler
   [junit4]   2> 190 T2006 oasc.RequestHandlers

[jira] [Commented] (SOLR-3505) Detect and report when the limit for maximum number of documents in a single index is exceeded

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-3505:
--

Similar to LUCENE-4105, it would greatly simplify testing to have a mechanism 
for arbitrarily bumping the next document number to a value like 
Integer.MAX_VALUE - k so that the limit can be hit by adding only a small 
number of documents.

Although it might be necessary to add a handler-level request query parameter 
to set the document number, it may be sufficient for to have unit tests that 
reach in directly to the IndexWriter that Solr is using to set the document 
number.

But since it might be nice to be able to manually test (okay, scripted test) 
this feature with a full-blown multi-machine cloud cluster, an explicit request 
parameter might be more desirable. Maybe something like 
&__docNumber__=2147483630.



> Detect and report when the limit for maximum number of documents in a single 
> index is exceeded
> --
>
> Key: SOLR-3505
> URL: https://issues.apache.org/jira/browse/SOLR-3505
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 3.6
>Reporter: Jack Krupansky
>Priority: Minor
>
> SOLR-3504 documents the limit for maximum number of documents in a single 
> index, but it is highly desirable to have Solr detect when this limit is 
> reached and provide a sensible response for the user.
> I am not sure of the implementation details, but generally each of the 
> "update" handlers would return an HTTP 400 status code. The reason phrase 
> should be something like "Exceeded maximum number of documents in a single 
> index - 2,147,483,647".
> It is not clear whether Solr itself should check the limit defensively, or 
> simply let Lucene throw the proposed MaxDocumentException and then catch it 
> and return the desired 400 response. It is also not clear if that processing 
> can be centralized or if calls to some new utility method would need to be 
> sprinkled in various places in Solr. Add also it may or may not be necessary 
> for update processors to either ignore or watch for this exception.
> There may be implications for SolrCloud, so that a reasonably useful response 
> gets back to both the original poster code as well as the Solr admin.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-4105) Detect and report when the limit for maximum number of documents in a single index is exceeded

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on LUCENE-4105:


To facilitate testing, I would propose an expert/testing method that would bump 
the internal document number for a segment arbitrarily so that it could be set 
to say Integer.MAX_VALUE - k so that the limit could be hit by adding only a 
relatively small number of documents.

I am not sure of the ramifications to existing code of such a gap, but since 
document numbers within a segment are per-segment anyway, I suspect it should 
be feasible, at least if it is done before any docs are added to the segment.


> Detect and report when the limit for maximum number of documents in a single 
> index is exceeded
> --
>
> Key: LUCENE-4105
> URL: https://issues.apache.org/jira/browse/LUCENE-4105
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: 3.6
>Reporter: Jack Krupansky
>Priority: Minor
>
> LUCENE-4104 documents the limit for maximum number of documents in a single 
> index, but it is highly desirable to have Lucene detect when this limit is 
> reached and throw a sensible exception for the user.
> I am not sure of the implementation details, but it seems as if 
> IndexWriter.addDocument, addDocuments, addIndexes, and updateDocuments would 
> be the APIs from which a new exception, call is MaxDocumentException would be 
> thrown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (SOLR-3505) Detect and report when the limit for maximum number of documents in a single index is exceeded

[Jack Krupansky (JIRA)]

Jack Krupansky created SOLR-3505:


 Summary: Detect and report when the limit for maximum number of 
documents in a single index is exceeded
 Key: SOLR-3505
 URL: https://issues.apache.org/jira/browse/SOLR-3505
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 3.6
Reporter: Jack Krupansky
Priority: Minor


SOLR-3504 documents the limit for maximum number of documents in a single 
index, but it is highly desirable to have Solr detect when this limit is 
reached and provide a sensible response for the user.

I am not sure of the implementation details, but generally each of the "update" 
handlers would return an HTTP 400 status code. The reason phrase should be 
something like "Exceeded maximum number of documents in a single index - 
2,147,483,647".

It is not clear whether Solr itself should check the limit defensively, or 
simply let Lucene throw the proposed MaxDocumentException and then catch it and 
return the desired 400 response. It is also not clear if that processing can be 
centralized or if calls to some new utility method would need to be sprinkled 
in various places in Solr. Add also it may or may not be necessary for update 
processors to either ignore or watch for this exception.

There may be implications for SolrCloud, so that a reasonably useful response 
gets back to both the original poster code as well as the Solr admin.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (LUCENE-4105) Detect and report when the limit for maximum number of documents in a single index is exceeded

[Jack Krupansky (JIRA)]

Jack Krupansky created LUCENE-4105:
--

 Summary: Detect and report when the limit for maximum number of 
documents in a single index is exceeded
 Key: LUCENE-4105
 URL: https://issues.apache.org/jira/browse/LUCENE-4105
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/index
Affects Versions: 3.6
Reporter: Jack Krupansky
Priority: Minor


LUCENE-4104 documents the limit for maximum number of documents in a single 
index, but it is highly desirable to have Lucene detect when this limit is 
reached and throw a sensible exception for the user.

I am not sure of the implementation details, but it seems as if 
IndexWriter.addDocument, addDocuments, addIndexes, and updateDocuments would be 
the APIs from which a new exception, call is MaxDocumentException would be 
thrown.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3504) Clearly document the limit for the maximum number of documents in a single index

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-3504:
--

Solr has a number of interfaces for adding documents, such as Update XML, 
Update CSV, SolrCell, Data Import Handler, SolrCloud, etc. Generally, each has 
a wiki page, to which the following section should be added:

"Limitations

Although a Solr implementation can scale into the billions of documents by 
using a number of shards, each individual shard or Solr core is limited by the 
Lucene limit for an index which is approximately 2.14 billion documents 
(2,147,483,647 to be exact) in the current implementation of Lucene. In 
practice, it is unlikely that such a large number of documents would fit and 
perform well in a single index. In extreme cases it may be possible, but in no 
case can the number of documents in a single index exceed that number."

This limitation could also be added to the Solr tutorial page.

There are probably a few other locations in the Solr docs when this limitation 
should be noted.


> Clearly document the limit for the maximum number of documents in a single 
> index
> 
>
> Key: SOLR-3504
> URL: https://issues.apache.org/jira/browse/SOLR-3504
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 3.6
>Reporter: Jack Krupansky
>Priority: Minor
>
> Although the actual limit to the number of documents supported by a Solr 
> implementation depends on the number of shards, unless the user is intimately 
> familiar with the implementation of Lucene, they may not realize that a 
> single Solr index (single shard, single core) is limited to approximately 
> 2.14 billion documents regardless of their processing power or memory. This 
> limit should be clearly documented for the Solr user.
> Granted, users should be strongly discouraged from attempting to create a 
> single, unsharded index of that size, but they certainly should have to find 
> out about the Lucene limit by accident.
> A subsequent issue will recommend that Solr detect and appropriately report 
> to the user when and if this limit is hit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: What is the maximum document number?

[Jack Krupansky]

Double oops... it is Integer.MAX_VALUE, not Integer.MAX_INT.

-- Jack Krupansky

From: Jack Krupansky 
Sent: Sunday, June 03, 2012 5:11 PM
To: dev@lucene.apache.org 
Subject: Re: What is the maximum document number?

Oops, I indicated that Integer.MAX_INT was 2^30-1, but it is 2^31-1 or 
2,147,483,647. So the largest document number in Lucene would be 2,147,483,646 
and the largest number (count) of documents would be 2,147,483,647.

-- Jack Krupansky

From: Jack Krupansky 
Sent: Sunday, June 03, 2012 4:09 PM
To: dev@lucene.apache.org 
Subject: Re: What is the maximum document number?

The javadoc for IR.maxDoc refers to “largest possible document number”, but the 
word “possible” is confusing. Superficially it sounds like the largest document 
number that Lucene can ever assign, but really it is simply the “largest 
document number in the index at the moment, including deleted documents.”

The javadoc should probably simply say: numDocs = maxDocs - numDeletedDocs


-- Jack Krupansky

From: Uwe Schindler 
Sent: Sunday, June 03, 2012 3:47 PM
To: dev@lucene.apache.org 
Subject: Re: What is the maximum document number?

Hi,

In fact maxDoc is not the maximum, it is also a count. If no deletions are in 
an index, maxDoc==numDocs. That's unfortunately how it is, maybe we should 
rename that in 4.0.

Uwe
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de




Jack Krupansky  schrieb: 
  Doing a little more research on document numbers, I had thought that the 
maximum document number was 2^30-1 or Integer.MAX_INT, but... I see that 
IndexReader.numDocs, maxDoc, and the corresponding IndexWriter methods return 
the number of documents as an int, so since document numbers start at zero, the 
number of documents is actually limited to 2^30-1, so the highest document 
number is limited to 2^30-1 minus another 1 or 2^30-2.

  -- Jack Krupansky

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java6-64 #392

[jenkins]

See 



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

[jira] [Created] (SOLR-3504) Clearly document the limit for the maximum number of documents in a single index

[Jack Krupansky (JIRA)]

Jack Krupansky created SOLR-3504:


 Summary: Clearly document the limit for the maximum number of 
documents in a single index
 Key: SOLR-3504
 URL: https://issues.apache.org/jira/browse/SOLR-3504
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 3.6
Reporter: Jack Krupansky
Priority: Minor


Although the actual limit to the number of documents supported by a Solr 
implementation depends on the number of shards, unless the user is intimately 
familiar with the implementation of Lucene, they may not realize that a single 
Solr index (single shard, single core) is limited to approximately 2.14 billion 
documents regardless of their processing power or memory. This limit should be 
clearly documented for the Solr user.

Granted, users should be strongly discouraged from attempting to create a 
single, unsharded index of that size, but they certainly should have to find 
out about the Lucene limit by accident.

A subsequent issue will recommend that Solr detect and appropriately report to 
the user when and if this limit is hit.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (LUCENE-4104) Clearly document the limit for maximum number of documents in a single index

[Jack Krupansky (JIRA)]

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

Jack Krupansky updated LUCENE-4104:
---

Description: 
Although the "int" in a number of APIs strongly suggests the approximate limit 
to the number of documents than can exist in a single Lucene index, it would be 
useful to have the specific number more clearly documented.

My reading suggests that the limit is 2^31-2 so that the count of documents, 0 
to 2^31-2, will fit in an int as Integer.MAX_VALUE or 2^31-1 or 2,147,483,647.

Symbolic definitions of the maximum document number and maximum number of 
documents, as well as the first document number should also be provided.

A subsequent issue will be to detect and throw an exception when that limit is 
exceeded.


  was:
Although the "int" in a number of APIs strongly suggests the approximate limit 
to the number of documents than can exist in a single Lucene index, it would be 
useful to have the specific number more clearly documented.

My reading suggests that the limit is 2^31-2 so that the count of documents, 0 
to 2^31-2, will fit in an int as Integer.MAX_INT or 2^31-1 or 2,147,483,647.

Symbolic definitions of the maximum document number and maximum number of 
documents, as well as the first document number should also be provided.

A subsequent issue will be to detect and throw an exception when that limit is 
exceeded.



> Clearly document the limit for maximum number of documents in a single index
> 
>
> Key: LUCENE-4104
> URL: https://issues.apache.org/jira/browse/LUCENE-4104
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: 3.6
>Reporter: Jack Krupansky
>Priority: Minor
>
> Although the "int" in a number of APIs strongly suggests the approximate 
> limit to the number of documents than can exist in a single Lucene index, it 
> would be useful to have the specific number more clearly documented.
> My reading suggests that the limit is 2^31-2 so that the count of documents, 
> 0 to 2^31-2, will fit in an int as Integer.MAX_VALUE or 2^31-1 or 
> 2,147,483,647.
> Symbolic definitions of the maximum document number and maximum number of 
> documents, as well as the first document number should also be provided.
> A subsequent issue will be to detect and throw an exception when that limit 
> is exceeded.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-4104) Clearly document the limit for maximum number of documents in a single index

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on LUCENE-4104:


I propose to add these constants to IndexWriter:

static final int MAX_DOCUMENT_NUMBER = Integer.MAX_VALUE - 1;
static final int MIN_DOCUMENT_NUMBER = 0;
static final int MAX_DOCUMENT_COUNT = MAX_DOCUMENT_NUMBER - MIN_DOCUMENT_NUMBER 
+ 1;

And add these to IndexReader for convenience:

static final int MAX_DOCUMENT_NUMBER = IndexWriter.MAX_DOCUMENT_NUMBER;
static final int MIN_DOCUMENT_NUMBER = IndexWriter.MIN_DOCUMENT_NUMBER;
static final int MAX_DOCUMENT_COUNT = IndexWriter.MAX_DOCUMENT_COUNT;

Add to the IndexWriter class javadoc at the class level and in the addDocument, 
addDocuments, and maybe updateDocuments methods:

"NOTE: the maximum number of documents in a single Lucene index is defined by 
MAX_DOCUMENT_COUNT which is 2,147,483,647 in the current implementation, but in 
practice that number will be reduced by deleted documents and may not be 
achievable with available memory in the JVM."


> Clearly document the limit for maximum number of documents in a single index
> 
>
> Key: LUCENE-4104
> URL: https://issues.apache.org/jira/browse/LUCENE-4104
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: 3.6
>Reporter: Jack Krupansky
>Priority: Minor
>
> Although the "int" in a number of APIs strongly suggests the approximate 
> limit to the number of documents than can exist in a single Lucene index, it 
> would be useful to have the specific number more clearly documented.
> My reading suggests that the limit is 2^31-2 so that the count of documents, 
> 0 to 2^31-2, will fit in an int as Integer.MAX_INT or 2^31-1 or 2,147,483,647.
> Symbolic definitions of the maximum document number and maximum number of 
> documents, as well as the first document number should also be provided.
> A subsequent issue will be to detect and throw an exception when that limit 
> is exceeded.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (LUCENE-4104) Clearly document the limit for maximum number of documents in a single index

[Jack Krupansky (JIRA)]

Jack Krupansky created LUCENE-4104:
--

 Summary: Clearly document the limit for maximum number of 
documents in a single index
 Key: LUCENE-4104
 URL: https://issues.apache.org/jira/browse/LUCENE-4104
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/index
Affects Versions: 3.6
Reporter: Jack Krupansky
Priority: Minor


Although the "int" in a number of APIs strongly suggests the approximate limit 
to the number of documents than can exist in a single Lucene index, it would be 
useful to have the specific number more clearly documented.

My reading suggests that the limit is 2^31-2 so that the count of documents, 0 
to 2^31-2, will fit in an int as Integer.MAX_INT or 2^31-1 or 2,147,483,647.

Symbolic definitions of the maximum document number and maximum number of 
documents, as well as the first document number should also be provided.

A subsequent issue will be to detect and throw an exception when that limit is 
exceeded.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: What is the maximum document number?

[Jack Krupansky]

Oops, I indicated that Integer.MAX_INT was 2^30-1, but it is 2^31-1 or 
2,147,483,647. So the largest document number in Lucene would be 2,147,483,646 
and the largest number (count) of documents would be 2,147,483,647.

-- Jack Krupansky

From: Jack Krupansky 
Sent: Sunday, June 03, 2012 4:09 PM
To: dev@lucene.apache.org 
Subject: Re: What is the maximum document number?

The javadoc for IR.maxDoc refers to “largest possible document number”, but the 
word “possible” is confusing. Superficially it sounds like the largest document 
number that Lucene can ever assign, but really it is simply the “largest 
document number in the index at the moment, including deleted documents.”

The javadoc should probably simply say: numDocs = maxDocs - numDeletedDocs


-- Jack Krupansky

From: Uwe Schindler 
Sent: Sunday, June 03, 2012 3:47 PM
To: dev@lucene.apache.org 
Subject: Re: What is the maximum document number?

Hi,

In fact maxDoc is not the maximum, it is also a count. If no deletions are in 
an index, maxDoc==numDocs. That's unfortunately how it is, maybe we should 
rename that in 4.0.

Uwe
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de




Jack Krupansky  schrieb: 
  Doing a little more research on document numbers, I had thought that the 
maximum document number was 2^30-1 or Integer.MAX_INT, but... I see that 
IndexReader.numDocs, maxDoc, and the corresponding IndexWriter methods return 
the number of documents as an int, so since document numbers start at zero, the 
number of documents is actually limited to 2^30-1, so the highest document 
number is limited to 2^30-1 minus another 1 or 2^30-2.

  -- Jack Krupansky

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #391

[jenkins]

See 


--
[...truncated 16582 lines...]
   [junit4]   2>at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
   [junit4]   2>at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
   [junit4]   2>at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   [junit4]   2>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   [junit4]   2>at java.lang.Thread.run(Thread.java:662)
   [junit4]   2> 
   [junit4]   2> 59487 T2988 C177 REQ [collection1] webapp=/solr path=/select 
params={wt=javabin&q=*:*&version=2} hits=0 status=0 QTime=0 
   [junit4]   2> 59597 T2988 C177 REQ [collection1] webapp=/solr path=/select 
params={wt=javabin&q=*:*&version=2} hits=0 status=0 QTime=0 
   [junit4]   2> 59708 T2988 C177 REQ [collection1] webapp=/solr path=/select 
params={wt=javabin&q=*:*&version=2} hits=0 status=0 QTime=0 
   [junit4]   2> 59817 T2815 oas.SolrTestCaseJ4.tearDown ###Ending test
   [junit4]   1> replicate slave to master
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestReplicationHandler -Dtests.method=test 
-Dtests.seed=2444E543B7648ECD -Dtests.locale=de -Dtests.timezone=AET 
-Dargs="-Dfile.encoding=Cp1252"
   [junit4]   1> 
   [junit4]   2>
   [junit4]> (@AfterClass output)
   [junit4]   2> 59838 T2815 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=425593729
   [junit4]   2> 59839 T2815 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@5d1972ea
   [junit4]   2> 59840 T2815 oasc.SolrCore.closeSearcher [collection1] Closing 
main searcher on request.
   [junit4]   2> 59840 T2815 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=2,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=494,cumulative_deletesById=0,cumulative_deletesByQuery=1,cumulative_errors=0}
   [junit4]   2> 59844 T2815 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
   [junit4]   2> 59898 T2815 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=160450151
   [junit4]   2> 59899 T2815 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@2d38f79d
   [junit4]   2> 59899 T2815 oasc.SolrCore.closeSearcher [collection1] Closing 
main searcher on request.
   [junit4]   2> 59900 T2815 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=1,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
   [junit4]   2> 59903 T2815 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
   [junit4]   2> 59970 T2815 oas.SolrTestCaseJ4.deleteCore ###deleteCore
   [junit4]   2> NOTE: test params are: codec=Lucene40: {}, 
sim=DefaultSimilarity, locale=de, timezone=AET
   [junit4]   2> NOTE: Windows 7 6.1 amd64/Sun Microsystems Inc. 1.6.0_32 
(64-bit)/cpus=2,threads=1,free=121913872,total=277938176
   [junit4]   2> NOTE: All tests run in this JVM: [TestStopFilterFactory, 
TestGermanStemFilterFactory, TestQuerySenderListener, 
TestWordDelimiterFilterFactory, TestValueSourceCache, IndexSchemaTest, 
SignatureUpdateProcessorFactoryTest, UUIDFieldTest, TestIndexingPerformance, 
TestIrishLowerCaseFilterFactory, TestCollationField, TestLuceneMatchVersion, 
StandardRequestHandlerTest, TestGalicianMinimalStemFilterFactory, 
TestRealTimeGet, TestIndonesianStemFilterFactory, NoCacheHeaderTest, 
FieldAnalysisRequestHandlerTest, TestSuggestSpellingConverter, 
TestBeiderMorseFilterFactory, TestMergePolicyConfig, 
TestPatternReplaceCharFilterFactory, TestHindiFilters, 
TestThaiWordFilterFactory, DoubleMetaphoneFilterFactoryTest, 
TestElisionFilterFactory, PrimitiveFieldTypeTest, LeaderElectionTest, 
SpellCheckComponentTest, QueryElevationComponentTest, TestFaceting, 
TestTrimFilterFactory, TestCapitalizationFilterFactory, TestFiltering, 
TestPhoneticFilterFactory, StatsComponentTest, TestPatternTokenizerFactory, 
TestLFUCache, JsonLoaderTest, BadIndexSchemaTest, 
TestPHPSerializedResponseWriter, TestRecovery, MoreLikeThisHandlerTest, 
DocumentBuilderTest, TestWikipediaTokenizerFactory, TestUtils, 
NotRequiredUniqueKeyTest, ZkSolrClientTest, LukeRequestHandlerTest, 
TestPatternReplaceFilterFactory, FullSolrCloudDistribCmdsTest, 
TestStemmerOverrideFilterFactory, TestRussianLightStemFilterFactory, 
TestRandomFaceting, TestShingleFilterFactory, SoftAutoCommitTest, 
PluginInfoTest, DateFieldTest, TestJmxMonitoredMap, TestRemoteStreaming, 
TestReversedWildcardFilterFact

Re: What is the maximum document number?

[Jack Krupansky]

The javadoc for IR.maxDoc refers to “largest possible document number”, but the 
word “possible” is confusing. Superficially it sounds like the largest document 
number that Lucene can ever assign, but really it is simply the “largest 
document number in the index at the moment, including deleted documents.”

The javadoc should probably simply say: numDocs = maxDocs - numDeletedDocs


-- Jack Krupansky

From: Uwe Schindler 
Sent: Sunday, June 03, 2012 3:47 PM
To: dev@lucene.apache.org 
Subject: Re: What is the maximum document number?

Hi,

In fact maxDoc is not the maximum, it is also a count. If no deletions are in 
an index, maxDoc==numDocs. That's unfortunately how it is, maybe we should 
rename that in 4.0.

Uwe
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de




Jack Krupansky  schrieb: 
  Doing a little more research on document numbers, I had thought that the 
maximum document number was 2^30-1 or Integer.MAX_INT, but... I see that 
IndexReader.numDocs, maxDoc, and the corresponding IndexWriter methods return 
the number of documents as an int, so since document numbers start at zero, the 
number of documents is actually limited to 2^30-1, so the highest document 
number is limited to 2^30-1 minus another 1 or 2^30-2.

  -- Jack Krupansky

Re: What is the maximum document number?

[Uwe Schindler]

Hi,

In fact maxDoc is not the maximum, it is also a count. If no deletions are in 
an index, maxDoc==numDocs. That's unfortunately how it is, maybe we should 
rename that in 4.0.

Uwe
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de



Jack Krupansky  schrieb:

Doing a little more research on document numbers, I had thought that the 
maximum document number was 2^30-1 or Integer.MAX_INT, but... I see that 
IndexReader.numDocs, maxDoc, and the corresponding IndexWriter methods return 
the number of documents as an int, so since document numbers start at zero, the 
number of documents is actually limited to 2^30-1, so the highest document 
number is limited to 2^30-1 minus another 1 or 2^30-2.


-- Jack Krupansky

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java6-64 #390

[jenkins]

See 



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

[jira] [Comment Edited] (LUCENE-4092) Check what's Jenkins pattern for e-mailing log fragments (so that it includes failures).

[Steven Rowe (JIRA)]

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

Steven Rowe edited comment on LUCENE-4092 at 6/3/12 7:07 PM:
-

{quote}
Spreading the BUILD_LOG_REGEX regex value over multiple lines is not supported 
by Jenkins's email templating functionality 
[...]
This could be fixed by allowing line terminators to be escaped:
[...]
I submitted a Jenkins JIRA issue for this: 
[https://issues.jenkins-ci.org/browse/JENKINS-13976].
{quote}

I forked the email-ext project on github and made a pull request, which has now 
been incorporated into the upstream project.


  was (Author: steve_rowe):
{quote}
Spreading the BUILD_LOG_REGEX regex value over multiple lines is not supported 
by Jenkins's email templating functionality 
[...]
This could be fixed by allowing line terminators to be escaped:
[...]
I submitted a Jenkins JIRA issue for this: 
[https://issues.jenkins-ci.org/browse/JENKINS-13976].
{quote}

I forked the email-ext project on github and made a pull request, which has now 
been incorporated into the master.

  
> Check what's Jenkins pattern for e-mailing log fragments (so that it includes 
> failures).
> 
>
> Key: LUCENE-4092
> URL: https://issues.apache.org/jira/browse/LUCENE-4092
> Project: Lucene - Java
>  Issue Type: Sub-task
>  Components: general/test
>Reporter: Dawid Weiss
>Priority: Trivial
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (LUCENE-3892) Add a useful intblock postings format (eg, FOR, PFOR, PFORDelta, Simple9/16/64, etc.)

[Han Jiang (JIRA)]

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

Han Jiang updated LUCENE-3892:
--

Attachment: LUCENE-3892_pfor.patch

Ah, just cannot wait for a performance optimization!

This version should now pass all tests below: 

ant test-core -Dtests.postingsformat=PFor

It fixes: 1) trailing forced exceptions will be ignored and encoded as normal 
value; 2) IntBuffer is maintained at IndexInput/Output level; 3) Former 
nocommit issues such as BlockTreeTerms* and code licence.

The patch also contains a minimal change with the help of Robert's patch: 
https://issues.apache.org/jira/secure/attachment/12530685/LUCENE-4102.patch. 
Hope Dawid will commit the complete version into trunk soon!

I'll try to optimize these codes later.

> Add a useful intblock postings format (eg, FOR, PFOR, PFORDelta, 
> Simple9/16/64, etc.)
> -
>
> Key: LUCENE-3892
> URL: https://issues.apache.org/jira/browse/LUCENE-3892
> Project: Lucene - Java
>  Issue Type: Improvement
>Reporter: Michael McCandless
>  Labels: gsoc2012, lucene-gsoc-12
> Fix For: 4.1
>
> Attachments: LUCENE-3892_pfor.patch, LUCENE-3892_pfor.patch, 
> LUCENE-3892_settings.patch, LUCENE-3892_settings.patch
>
>
> On the flex branch we explored a number of possible intblock
> encodings, but for whatever reason never brought them to completion.
> There are still a number of issues opened with patches in different
> states.
> Initial results (based on prototype) were excellent (see
> http://blog.mikemccandless.com/2010/08/lucene-performance-with-pfordelta-codec.html
> ).
> I think this would make a good GSoC project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (LUCENE-4103) AnalyzerQueryNodeProcessor throws a class cast exception with the RegexpQueryNode

[Daniel Truemper (JIRA)]

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

Daniel Truemper updated LUCENE-4103:


Attachment: 0001-Fix-for-the-flexible-regexp-parsing.patch

A patch in GIT format that can be applied to SVN via `patch -p1 -i 0001-F...`

> AnalyzerQueryNodeProcessor throws a class cast exception with the 
> RegexpQueryNode
> -
>
> Key: LUCENE-4103
> URL: https://issues.apache.org/jira/browse/LUCENE-4103
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.0
>Reporter: Daniel Truemper
>Priority: Minor
> Fix For: 4.0
>
> Attachments: 0001-Fix-for-the-flexible-regexp-parsing.patch
>
>
> When using the flexible query parser with the regular expression syntax the 
> processing pipeline fails with the following class cast exception:
> {noformat}
> java.lang.ClassCastException: 
> org.apache.lucene.queryparser.flexible.standard.nodes.RegexpQueryNode cannot 
> be cast to org.apache.lucene.queryparser.flexible.core.nodes.FieldQueryNode
>   at 
> __randomizedtesting.SeedInfo.seed([34AF003D9388DF45:CB5F8BB4EE483FEE]:0)
>   at 
> org.apache.lucene.queryparser.flexible.standard.processors.AnalyzerQueryNodeProcessor.postProcessNode(AnalyzerQueryNodeProcessor.java:114)
> {noformat}
> A very simple patch is attached that will simply add the RegexpQueryNode to 
> the nodes that should not get processed by the AnalyzerQueryNodeProcessor. I 
> think this means that the regular expression is not analyzed, which should be 
> ok!?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

What is the maximum document number?

[Jack Krupansky]

Doing a little more research on document numbers, I had thought that the 
maximum document number was 2^30-1 or Integer.MAX_INT, but... I see that 
IndexReader.numDocs, maxDoc, and the corresponding IndexWriter methods return 
the number of documents as an int, so since document numbers start at zero, the 
number of documents is actually limited to 2^30-1, so the highest document 
number is limited to 2^30-1 minus another 1 or 2^30-2.

-- Jack Krupansky

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #389

[jenkins]

See 


--
[...truncated 16408 lines...]
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestConfig
   [junit4] Completed in 0.43s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestReversedWildcardFilterFactory
   [junit4] Completed in 1.05s, 4 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedSpellCheckComponentTest
   [junit4] Completed in 21.02s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.BinaryUpdateRequestHandlerTest
   [junit4] Completed in 1.50s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestSynonymFilterFactory
   [junit4] Completed in 0.02s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.util.DateMathParserTest
   [junit4] Completed in 0.07s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest
   [junit4] Completed in 37.53s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.SpellPossibilityIteratorTest
   [junit4] Completed in 0.09s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestQueryUtils
   [junit4] Completed in 1.24s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.RecoveryZkTest
   [junit4] Completed in 29.69s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.NodeStateWatcherTest
   [junit4] Completed in 29.80s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestPhoneticFilterFactory
   [junit4] Completed in 12.68s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestJoin
   [junit4] Completed in 11.46s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.SpellCheckComponentTest
   [junit4] Completed in 5.65s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.TestMultiCoreConfBootstrap
   [junit4] Completed in 4.61s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.request.SimpleFacetsTest
   [junit4] Completed in 7.46s, 29 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.TestFunctionQuery
   [junit4] Completed in 3.28s, 14 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSort
   [junit4] Completed in 3.26s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.ConvertedLegacyTest
   [junit4] Completed in 3.22s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.TestTrie
   [junit4] Completed in 1.66s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.StatsComponentTest
   [junit4] Completed in 5.32s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.SolrInfoMBeanTest
   [junit4] Completed in 0.81s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.update.SolrCmdDistributorTest
   [junit4] Completed in 1.78s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.admin.LukeRequestHandlerTest
   [junit4] Completed in 2.35s, 3 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest
   [junit4] Completed in 1.22s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy2
   [junit4] Completed in 0.76s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.update.TestIndexingPerformance
   [junit4] Completed in 0.65s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestPseudoReturnFields
   [junit4] Completed in 1.08s, 13 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSurroundQueryParser
   [junit4] Completed in 0.76s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.DirectSolrSpellCheckerTest
   [junit4] Completed in 0.83s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.distance.DistanceFunctionTest
   [junit4] Completed in 0.87s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.XsltUpdateRequestHandlerTest
   [junit4] Completed in 0.81s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestRemoteStreaming
   [junit4] Completed in 0.98s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.SpatialFilterTest
   [junit4] Completed in 1.51s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.PolyFieldTest
   [junit4] Completed in 1.23s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.DocumentAnalysisRequestHandlerTest
   [junit4] Completed in 0.81s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestFoldingMultitermQuery
   [junit4] Completed in 1.30s, 18 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.FileBasedSpellCheckerTest
   [junit4] Completed in 1.04s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestValueSourceCache
   [junit4] Completed in 0.93s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.BadComponentTest
   [junit4] Completed in 0.70s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.

[jira] [Updated] (LUCENE-4103) AnalyzerQueryNodeProcessor throws a class cast exception with the RegexpQueryNode

[Daniel Truemper (JIRA)]

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

Daniel Truemper updated LUCENE-4103:


Fix Version/s: 4.0
Affects Version/s: 4.0

> AnalyzerQueryNodeProcessor throws a class cast exception with the 
> RegexpQueryNode
> -
>
> Key: LUCENE-4103
> URL: https://issues.apache.org/jira/browse/LUCENE-4103
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.0
>Reporter: Daniel Truemper
>Priority: Minor
> Fix For: 4.0
>
>
> When using the flexible query parser with the regular expression syntax the 
> processing pipeline fails with the following class cast exception:
> {noformat}
> java.lang.ClassCastException: 
> org.apache.lucene.queryparser.flexible.standard.nodes.RegexpQueryNode cannot 
> be cast to org.apache.lucene.queryparser.flexible.core.nodes.FieldQueryNode
>   at 
> __randomizedtesting.SeedInfo.seed([34AF003D9388DF45:CB5F8BB4EE483FEE]:0)
>   at 
> org.apache.lucene.queryparser.flexible.standard.processors.AnalyzerQueryNodeProcessor.postProcessNode(AnalyzerQueryNodeProcessor.java:114)
> {noformat}
> A very simple patch is attached that will simply add the RegexpQueryNode to 
> the nodes that should not get processed by the AnalyzerQueryNodeProcessor. I 
> think this means that the regular expression is not analyzed, which should be 
> ok!?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (LUCENE-4103) AnalyzerQueryNodeProcessor throws a class cast exception with the RegexpQueryNode

[Daniel Truemper (JIRA)]

Daniel Truemper created LUCENE-4103:
---

 Summary: AnalyzerQueryNodeProcessor throws a class cast exception 
with the RegexpQueryNode
 Key: LUCENE-4103
 URL: https://issues.apache.org/jira/browse/LUCENE-4103
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/queryparser
Reporter: Daniel Truemper
Priority: Minor


When using the flexible query parser with the regular expression syntax the 
processing pipeline fails with the following class cast exception:

{noformat}
java.lang.ClassCastException: 
org.apache.lucene.queryparser.flexible.standard.nodes.RegexpQueryNode cannot be 
cast to org.apache.lucene.queryparser.flexible.core.nodes.FieldQueryNode
at 
__randomizedtesting.SeedInfo.seed([34AF003D9388DF45:CB5F8BB4EE483FEE]:0)
at 
org.apache.lucene.queryparser.flexible.standard.processors.AnalyzerQueryNodeProcessor.postProcessNode(AnalyzerQueryNodeProcessor.java:114)
{noformat}

A very simple patch is attached that will simply add the RegexpQueryNode to the 
nodes that should not get processed by the AnalyzerQueryNodeProcessor. I think 
this means that the regular expression is not analyzed, which should be ok!?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Missing javadoc for IndexWriter.hasDeletions

[Jack Krupansky]

There is no javadoc for IndexWriter.hasDeletions. I would have expected it to 
be the same as for IndexReader:

/** Returns true if any documents have been deleted */

Although, I think both should also say “since the most recent merge”.

-- Jack Krupansky

[jira] [Commented] (SOLR-3503) Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-3503:
--

Ultimately it may simply come down to doing better documentation for the 
interactions between stemming and wildcards. After all, the stemmer does do its 
thing at index time, so even if the stemmer is not called at all at query time, 
the user who wants to use wildcards needs to know what rules the stemmer used 
at index time.

In any case, I'll think about this a little more before proceeding. And as I 
said, the restriction is that the results can't be worse than they are today.


> Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware
> -
>
> Key: SOLR-3503
> URL: https://issues.apache.org/jira/browse/SOLR-3503
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.0, 5.0
>
>
> It seems to me that all the stemmers could be MultiTermAware, anyone know of 
> a reason not?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (SOLR-3503) Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-3503.
--

Resolution: Won't Fix

Jack:

Go ahead and have a whack at it if you want, but given that if one really 
_wants_ to, one can just define a "multiterm" section of in the schema and put 
whatever one wants in there, I'm not inclined to spend time on this. The intent 
of the whole MultiTermAware bit was to do the safe, easily-explainable stuff. I 
suspect that this would just be a lot of effort for, arguably, no net benefit 
(by the time we had to explain all the caveats, whether it worked for 
language/stemmer X, Y or Z, etc). But I'll be happy for you to prove me 
wrong

> Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware
> -
>
> Key: SOLR-3503
> URL: https://issues.apache.org/jira/browse/SOLR-3503
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.0, 5.0
>
>
> It seems to me that all the stemmers could be MultiTermAware, anyone know of 
> a reason not?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Reopened] (SOLR-3503) Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware

[Erick Erickson (JIRA)]

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

Erick Erickson reopened SOLR-3503:
--


Changing to "won't fix"

> Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware
> -
>
> Key: SOLR-3503
> URL: https://issues.apache.org/jira/browse/SOLR-3503
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.0, 5.0
>
>
> It seems to me that all the stemmers could be MultiTermAware, anyone know of 
> a reason not?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3503) Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-3503:
--

Or are you just trying to trick me into doing it?! (I may.)

I'm at least half-convinced that it would not be harmful, at least for some 
stemmers and the changes would be stemmer-specific anyway, so it would give 
incremental improvement even if not 100% solving all issues for all stemmbers.

How about changing the status to "Won't Fix" rather than "Invalid"?


> Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware
> -
>
> Key: SOLR-3503
> URL: https://issues.apache.org/jira/browse/SOLR-3503
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.0, 5.0
>
>
> It seems to me that all the stemmers could be MultiTermAware, anyone know of 
> a reason not?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Resolved] (SOLR-3503) Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-3503.
--

Resolution: Invalid

Gaaah! That'll teach me to put up a JIRA when I haven't had enough coffee. I 
was just thinking about it in terms of the stemmer producing a single token, 
which would be fine.

The notion that _what_ the stem wound up being and the impossibility of "doing 
the right thing" given that transformation completely escaped my not-yet-awake 
brain. Or what remains of it.

Especially when you consider embedded wildcards (e.g. bil*et) as you pointed 
out.

So I'm closing this as "invalid". I don't think it's worth the effort. If 
someone _really_ wants to do this, they can try it with the "multiterm" 
analysis chain definition and suffer the consequences...

> Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware
> -
>
> Key: SOLR-3503
> URL: https://issues.apache.org/jira/browse/SOLR-3503
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.0, 5.0
>
>
> It seems to me that all the stemmers could be MultiTermAware, anyone know of 
> a reason not?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3503) Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-3503:
--

It could be tricky, but it could work, but users would have to be made aware of 
how wildcards could interfere or interact with stemming. And testing is 
essential, as well as good user documentation of how to navigate the stemming 
vs. wildcards minefield.

Unless the user actually knows what the stemmed term will be, even simple 
trailing wildcards can be tricky since the stem could be much shorter than the 
user expects. For example "investment*" where the actual stemmed and indexed 
term might be "invest" for a particular stemmer.

Leading wildcards can sometimes be okay, but completely dependent on the 
particular stemmer. For example, "*ment".

And simple embedded wildcards can be a real wildcard, once again depending on 
the specific stemmer. For example, "inve*ment".

But, I don't think any or all of those concerns are any worse than the 
situation we have today.

But, some robust tests would be needed to persuade me that this improvement is 
actually okay.

Right now, I say go for it, including the test examples for various stemmers 
and documentation for issues that users must be aware of (call it "safe 
wildcards in the presence of stemming.") I think the only restriction is that 
query results should not be worse than without this improvement.

Unfortunately, the doc may be stemmer-dependent. And separate tests needed for 
each stemmer.

The bottom line is to reduce the surprise factor for the user.

As a side note, it would be nice if Solr had a mechanism to return "informative 
notes and warnings" with a query response. For example, "Wildcard term 
inves*ment matches no indexed terms".


> Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware
> -
>
> Key: SOLR-3503
> URL: https://issues.apache.org/jira/browse/SOLR-3503
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.0, 5.0
>
>
> It seems to me that all the stemmers could be MultiTermAware, anyone know of 
> a reason not?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

RE: svn commit: r820071 - in /websites: production/lucene/content/ production/lucene/content/core/ production/lucene/content/solr/ staging/lucene/trunk/content/ staging/lucene/trunk/content/core/ stag

[Uwe Schindler]

I programmed my imap server filters to redirect them to trash :-)

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Jack Krupansky [mailto:j...@basetechnology.com]
> Sent: Sunday, June 03, 2012 3:18 PM
> To: dev@lucene.apache.org
> Subject: Re: svn commit: r820071 - in /websites: production/lucene/content/
> production/lucene/content/core/ production/lucene/content/solr/
> staging/lucene/trunk/content/ staging/lucene/trunk/content/core/
> staging/lucene/trunk/content/solr/
> 
> I see many of these messages every day and they are all virtually identical -
> indicating "(empty)" modifications - but with new revision numbers for web
> pages on staging and production. Sometimes the modifications are not
> "(empty)", suggesting that the empties are for failed builds and only on a
> successful build are revisions listed in the HTML. Is this actually normal or 
> is
> this a step that should be skipped if there are no changes? Just curious.
> 
> -- Jack Krupansky
> 
> -Original Message-
> From: build...@apache.org
> Sent: Sunday, June 03, 2012 4:21 AM
> To: comm...@lucene.apache.org
> Subject: svn commit: r820071 - in /websites: production/lucene/content/
> production/lucene/content/core/ production/lucene/content/solr/
> staging/lucene/trunk/content/ staging/lucene/trunk/content/core/
> staging/lucene/trunk/content/solr/
> 
> Author: buildbot
> Date: Sun Jun  3 08:21:23 2012
> New Revision: 820071
> 
> Log:
> Dynamic update by buildbot for lucene
> 
> Modified:
> websites/production/lucene/content/core/index.html
> websites/production/lucene/content/index.html
> websites/production/lucene/content/solr/index.html
> websites/staging/lucene/trunk/content/core/index.html
> websites/staging/lucene/trunk/content/index.html
> websites/staging/lucene/trunk/content/solr/index.html
> 
> Modified: websites/production/lucene/content/core/index.html
> 
> ==
> (empty)
> 
> Modified: websites/production/lucene/content/index.html
> 
> ==
> (empty)
> 
> Modified: websites/production/lucene/content/solr/index.html
> 
> ==
> (empty)
> 
> Modified: websites/staging/lucene/trunk/content/core/index.html
> 
> ==
> (empty)
> 
> Modified: websites/staging/lucene/trunk/content/index.html
> 
> ==
> (empty)
> 
> Modified: websites/staging/lucene/trunk/content/solr/index.html
> 
> ==
> (empty)
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org


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

[jira] [Commented] (LUCENE-4101) Remove XXXField.TYPE_STORED

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on LUCENE-4101:


Superficially, the new concept of a field  that is stored and indexed being two 
fields - both with the same name - sounds confusing, but it all depends on how 
this will be presented to users. What "model" of the relationship between 
"index", "field", and "document" are users expected to understand with respect 
to how fields are "stored" vs. "indexed"? Show me the model, and then I could 
judge whether it is truly confusing.

Users generally need to be concerned about storage capacity and performance, so 
a model that clarifies (and separates) the impact that a stored field has on 
index vs. query result performance would be helpful.

Finally, maybe down the road it would be advantageous to have a stronger 
separation of indexed and stored fields, even to the point of using separate 
JVMs or even machines (e.g., one to identiy results and one or more separate 
JVMs/machines to retrieve stored fields for query response) so that index 
lookup throughput can be faster and index size can be larger without reducing 
the ability to have large numbers of large stored fields. I only mention this 
in the context of how it might make sense to migrate users away from the 
concept that the "indexed" and "stored" aspects (maybe that's a better word 
than just "field") are forever tightly rather than loosely linked.


> Remove XXXField.TYPE_STORED
> ---
>
> Key: LUCENE-4101
> URL: https://issues.apache.org/jira/browse/LUCENE-4101
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4101.patch
>
>
> Spinoff from LUCENE-3312.
> For 4.0 I think we should simplify the sugar field APIs by requiring
> that you add a StoredField if you want to store the field.  Expert users
> can still make a custom FieldType that both stores and indexes...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-4101) Remove XXXField.TYPE_STORED

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-4101:
-

{quote}
I set it to blocker because I think the 4.0 API for creating stored
fields is confusing now (separate from the changes being explored in
LUCENE-3312).
This (XXXField/FieldType) is one of the major changed APIs in 4.0 so
it's worth spending effort reviewing/fixing it before we ship it. The
same goes for all our other new AIPs in 4.0: we should scrutinize them.
{quote}

OK: I totally agree with scrutinizing the API. I also feel bad about
making the comment here because I know its really a ton of work to make
patches like this... and delays can cause lots of merging grief.

{quote}
personally i dont like the fact you have to add the field twice.
Expert users don't have to (they can make a custom field type, at least
until 5.0). This API is just for basic usage, and I think it's
important that API be really easy to use.
{quote}

I think this is where my concern lies? I think its the wrong way around:
basic users should be able to add the field once and just say its indexed & 
stored :)

I agree that TYPE_STORED is confusing, and I also agree that StoredXXX is not 
great.
I guess i just want to know that we've had a little time to think about the 
different
options here, maybe there is a better solution.

> Remove XXXField.TYPE_STORED
> ---
>
> Key: LUCENE-4101
> URL: https://issues.apache.org/jira/browse/LUCENE-4101
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4101.patch
>
>
> Spinoff from LUCENE-3312.
> For 4.0 I think we should simplify the sugar field APIs by requiring
> that you add a StoredField if you want to store the field.  Expert users
> can still make a custom FieldType that both stores and indexes...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: svn commit: r820071 - in /websites: production/lucene/content/ production/lucene/content/core/ production/lucene/content/solr/ staging/lucene/trunk/content/ staging/lucene/trunk/content/core/ stag

[Jack Krupansky]

I see many of these messages every day and they are all virtually 
identical - indicating "(empty)" modifications - but with new revision 
numbers for web pages on staging and production. Sometimes the modifications 
are not "(empty)", suggesting that the empties are for failed builds and 
only on a successful build are revisions listed in the HTML. Is this 
actually normal or is this a step that should be skipped if there are no 
changes? Just curious.


-- Jack Krupansky

-Original Message- 
From: build...@apache.org

Sent: Sunday, June 03, 2012 4:21 AM
To: comm...@lucene.apache.org
Subject: svn commit: r820071 - in /websites: production/lucene/content/ 
production/lucene/content/core/ production/lucene/content/solr/ 
staging/lucene/trunk/content/ staging/lucene/trunk/content/core/ 
staging/lucene/trunk/content/solr/


Author: buildbot
Date: Sun Jun  3 08:21:23 2012
New Revision: 820071

Log:
Dynamic update by buildbot for lucene

Modified:
   websites/production/lucene/content/core/index.html
   websites/production/lucene/content/index.html
   websites/production/lucene/content/solr/index.html
   websites/staging/lucene/trunk/content/core/index.html
   websites/staging/lucene/trunk/content/index.html
   websites/staging/lucene/trunk/content/solr/index.html

Modified: websites/production/lucene/content/core/index.html
==
   (empty)

Modified: websites/production/lucene/content/index.html
==
   (empty)

Modified: websites/production/lucene/content/solr/index.html
==
   (empty)

Modified: websites/staging/lucene/trunk/content/core/index.html
==
   (empty)

Modified: websites/staging/lucene/trunk/content/index.html
==
   (empty)

Modified: websites/staging/lucene/trunk/content/solr/index.html
==
   (empty)


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

[jira] [Commented] (SOLR-3503) Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware

[Robert Muir (JIRA)]

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

Robert Muir commented on SOLR-3503:
---

most stemmers use length of the string / syllable count. In general this won't 
work... I don't think we should do it.

> Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware
> -
>
> Key: SOLR-3503
> URL: https://issues.apache.org/jira/browse/SOLR-3503
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.0, 5.0
>
>
> It seems to me that all the stemmers could be MultiTermAware, anyone know of 
> a reason not?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (SOLR-3503) Make SnowballPorterFilterFactory (and other stemmers?) MultiTermAware

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-3503:


 Summary: Make SnowballPorterFilterFactory (and other stemmers?) 
MultiTermAware
 Key: SOLR-3503
 URL: https://issues.apache.org/jira/browse/SOLR-3503
 Project: Solr
  Issue Type: Improvement
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Fix For: 4.0, 5.0


It seems to me that all the stemmers could be MultiTermAware, anyone know of a 
reason not?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (SOLR-3441) Make ElisionFilterFactory MultiTermAware

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-3441:


Assignee: Erick Erickson

> Make ElisionFilterFactory MultiTermAware
> 
>
> Key: SOLR-3441
> URL: https://issues.apache.org/jira/browse/SOLR-3441
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Affects Versions: 3.6
>Reporter: Jack Krupansky
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-3441.patch
>
>
> The ElisionFilterFactory (which removes l' from l'avion) is not 
> MultiTermAware - which includes release 3.6. I wanted to use a wildcard such 
> as: (l'aub*).
> Seems simple enough to address. I'll attach a patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java6-64 #382

[jenkins]

See 



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

[jira] [Commented] (LUCENE-4102) SuppressCodecs doesnt work with -Dtests.postingsformat

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-4102:
-

Per-method cause from suite-level assumption failures is not reported at the 
moment (this is JUnit shortcoming that needs a workaround):
{noformat}
   [junit4] Suite: org.apache.lucene.index.TestPostingsOffsets
   [junit4] IGNORED 0.00s J3 | TestPostingsOffsets.testPayloads
   [junit4]> Cause: Unknown reason for ignore status.
   [junit4] IGNORED 0.00s J3 | TestPostingsOffsets.testRandom
   [junit4]> Cause: Unknown reason for ignore status.
   [junit4] IGNORED 0.00s J3 | TestPostingsOffsets.testBasic
   [junit4]> Cause: Unknown reason for ignore status.
   [junit4] IGNORED 0.00s J3 | TestPostingsOffsets.testSkipping
   [junit4]> Cause: Unknown reason for ignore status.
   [junit4] IGNORED 0.00s J3 | TestPostingsOffsets.testWithUnindexedFields
   [junit4]> Cause: Unknown reason for ignore status.
   [junit4]> Assumption #1: Class not allowed to use postings format: 
MockFixedIntBlock.
   [junit4] Completed on J3 in 0.06s, 5 tests, 5 skipped
{noformat}

I will try to fix this in the next tests' framework upgrade (needs a patch at 
the runner level).

> SuppressCodecs doesnt work with -Dtests.postingsformat
> --
>
> Key: LUCENE-4102
> URL: https://issues.apache.org/jira/browse/LUCENE-4102
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/test
>Reporter: Robert Muir
> Attachments: LUCENE-4102.patch, LUCENE-4102.patch
>
>
> As reported by Han on the mailing list: if you are running all tests with 
> your postingsformat, but a test specifically ignores it, it doesnt work 
> correctly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (LUCENE-4102) SuppressCodecs doesnt work with -Dtests.postingsformat

[Dawid Weiss (JIRA)]

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

Dawid Weiss updated LUCENE-4102:


Attachment: LUCENE-4102.patch

I'd just move all the suppression checks to the class rule -- it is fired once 
per suite and the annotation works at the suite level anyway.

> SuppressCodecs doesnt work with -Dtests.postingsformat
> --
>
> Key: LUCENE-4102
> URL: https://issues.apache.org/jira/browse/LUCENE-4102
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/test
>Reporter: Robert Muir
> Attachments: LUCENE-4102.patch, LUCENE-4102.patch
>
>
> As reported by Han on the mailing list: if you are running all tests with 
> your postingsformat, but a test specifically ignores it, it doesnt work 
> correctly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-2858) Separate SegmentReaders (and other atomic readers) from composite IndexReaders

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-2858:


bq. This explains the change back after 4055, I thought un-compressed oops 
responsible for the speedup.

That's what I thought too (and I was very confused that uncompressed oops would 
improve things)!  But LUCENE-4055 landed on the same day I turned off 
uncompressed oops... so I think all mysteries are now explained.

> Separate SegmentReaders (and other atomic readers) from composite IndexReaders
> --
>
> Key: LUCENE-2858
> URL: https://issues.apache.org/jira/browse/LUCENE-2858
> Project: Lucene - Java
>  Issue Type: Task
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.0
>
> Attachments: LUCENE-2858-FCinsanity.patch, 
> LUCENE-2858-FixSlowEnsureOpen.patch, LUCENE-2858.patch, LUCENE-2858.patch
>
>
> With current trunk, whenever you open an IndexReader on a directory you get 
> back a DirectoryReader which is a composite reader. The interface of 
> IndexReader has now lots of methods that simply throw UOE (in fact more than 
> 50% of all methods that are commonly used ones are unuseable now). This 
> confuses users and makes the API hard to understand.
> This issue should split "atomic readers" from "reader collections" with a 
> separate API. After that, you are no longer able, to get TermsEnum without 
> wrapping from those composite readers. We currently have helper classes for 
> wrapping (SlowMultiReaderWrapper - please rename, the name is really ugly; or 
> Multi*), those should be retrofitted to implement the correct classes 
> (SlowMultiReaderWrapper would be an atomic reader but takes a composite 
> reader as ctor param, maybe it could also simply take a List). 
> In my opinion, maybe composite readers could implement some collection APIs 
> and also have the ReaderUtil method directly built in (possibly as a "view" 
> in the util.Collection sense). In general composite readers do not really 
> need to look like the previous IndexReaders, they could simply be a 
> "collection" of SegmentReaders with some functionality like reopen.
> On the other side, atomic readers do not need reopen logic anymore? When a 
> segment changes, you need a new atomic reader? - maybe because of deletions 
> thats not the best idea, but we should investigate. Maybe make the whole 
> reopen logic simplier to use (ast least on the collection reader level).
> We should decide about good names, i have no preference at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #381

[jenkins]

See 


--
[...truncated 10458 lines...]
   [junit4] Completed in 1.25s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.XmlUpdateRequestHandlerTest
   [junit4] Completed in 1.05s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DocumentBuilderTest
   [junit4] Completed in 1.11s, 11 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.DisMaxRequestHandlerTest
   [junit4] Completed in 1.19s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSort
   [junit4] Completed in 4.57s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.servlet.CacheHeaderTest
   [junit4] Completed in 1.42s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestJapaneseTokenizerFactory
   [junit4] Completed in 0.04s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.FieldAnalysisRequestHandlerTest
   [junit4] Completed in 1.40s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestMappingCharFilterFactory
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.LeaderElectionTest
   [junit4] Completed in 42.62s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.NodeStateWatcherTest
   [junit4] Completed in 22.28s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedSpellCheckComponentTest
   [junit4] Completed in 19.62s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.TestJoin
   [junit4] Completed in 10.58s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestGroupingSearch
   [junit4] Completed in 7.32s, 12 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.ConvertedLegacyTest
   [junit4] Completed in 3.65s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestFiltering
   [junit4] Completed in 3.87s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.StatsComponentTest
   [junit4] Completed in 5.93s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.servlet.SolrRequestParserTest
   [junit4] Completed in 1.18s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestPseudoReturnFields
   [junit4] Completed in 1.59s, 13 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.HighlighterTest
   [junit4] Completed in 2.76s, 27 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.admin.CoreAdminHandlerTest
   [junit4] Completed in 2.60s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.PolyFieldTest
   [junit4] Completed in 1.73s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestBinaryResponseWriter
   [junit4] Completed in 2.39s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.SolrCoreCheckLockOnStartupTest
   [junit4] Completed in 2.21s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.DocumentAnalysisRequestHandlerTest
   [junit4] Completed in 1.39s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.CopyFieldTest
   [junit4] Completed in 0.94s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestFoldingMultitermQuery
   [junit4] Completed in 1.83s, 18 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.CurrencyFieldTest
   [junit4] IGNORED 0.00s | CurrencyFieldTest.testPerformance
   [junit4]> Cause: Annotated @Ignore()
   [junit4] Completed in 1.64s, 8 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.TestOmitPositions
   [junit4] Completed in 1.19s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.RequestHandlersTest
   [junit4] Completed in 1.11s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.internal.csv.CSVPrinterTest
   [junit4] Completed in 0.53s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestDocSet
   [junit4] Completed in 0.70s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestCSVLoader
   [junit4] Completed in 1.35s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.DebugComponentTest
   [junit4] Completed in 1.13s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestIndexSearcher
   [junit4] Completed in 2.40s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestQueryUtils
   [junit4] Completed in 1.26s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestValueSourceCache
   [junit4] Completed in 1.19s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.response.TestPHPSerializedResponseWriter
   [junit4] Completed in 1.01s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.JsonLoaderTest
   [junit4] Completed in 0.98s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.HighlighterConfigTest
   [junit4] Completed in 0.87s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSolrQueryParser
   [junit4] Complet

[jira] [Commented] (LUCENE-2858) Separate SegmentReaders (and other atomic readers) from composite IndexReaders

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-2858:
---

Thanks Mike for taking care. For me this looked crazy, because refactoring like 
this should not change perf.

This explains the change back  after 4055, I thought un-compressed oops 
responsible for the speedup.

> Separate SegmentReaders (and other atomic readers) from composite IndexReaders
> --
>
> Key: LUCENE-2858
> URL: https://issues.apache.org/jira/browse/LUCENE-2858
> Project: Lucene - Java
>  Issue Type: Task
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.0
>
> Attachments: LUCENE-2858-FCinsanity.patch, 
> LUCENE-2858-FixSlowEnsureOpen.patch, LUCENE-2858.patch, LUCENE-2858.patch
>
>
> With current trunk, whenever you open an IndexReader on a directory you get 
> back a DirectoryReader which is a composite reader. The interface of 
> IndexReader has now lots of methods that simply throw UOE (in fact more than 
> 50% of all methods that are commonly used ones are unuseable now). This 
> confuses users and makes the API hard to understand.
> This issue should split "atomic readers" from "reader collections" with a 
> separate API. After that, you are no longer able, to get TermsEnum without 
> wrapping from those composite readers. We currently have helper classes for 
> wrapping (SlowMultiReaderWrapper - please rename, the name is really ugly; or 
> Multi*), those should be retrofitted to implement the correct classes 
> (SlowMultiReaderWrapper would be an atomic reader but takes a composite 
> reader as ctor param, maybe it could also simply take a List). 
> In my opinion, maybe composite readers could implement some collection APIs 
> and also have the ReaderUtil method directly built in (possibly as a "view" 
> in the util.Collection sense). In general composite readers do not really 
> need to look like the previous IndexReaders, they could simply be a 
> "collection" of SegmentReaders with some functionality like reopen.
> On the other side, atomic readers do not need reopen logic anymore? When a 
> segment changes, you need a new atomic reader? - maybe because of deletions 
> thats not the best idea, but we should investigate. Maybe make the whole 
> reopen logic simplier to use (ast least on the collection reader level).
> We should decide about good names, i have no preference at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-2858) Separate SegmentReaders (and other atomic readers) from composite IndexReaders

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-2858:


bq. Not entirely sure why but it looks like the commits here slowed down our 
NRT reopen latency.

OK, sorry, I was wrong about this!

I went back and re-ran the NRTPerfTest and isolated the slowdown to LUCENE-3728 
(also committed on the same day)... it was because we lost the 
SegmentInfo.sizeInBytes caching... but then in LUCENE-4055 we got it back and 
we got the performance back ... so all's well that ends well :)

> Separate SegmentReaders (and other atomic readers) from composite IndexReaders
> --
>
> Key: LUCENE-2858
> URL: https://issues.apache.org/jira/browse/LUCENE-2858
> Project: Lucene - Java
>  Issue Type: Task
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 4.0
>
> Attachments: LUCENE-2858-FCinsanity.patch, 
> LUCENE-2858-FixSlowEnsureOpen.patch, LUCENE-2858.patch, LUCENE-2858.patch
>
>
> With current trunk, whenever you open an IndexReader on a directory you get 
> back a DirectoryReader which is a composite reader. The interface of 
> IndexReader has now lots of methods that simply throw UOE (in fact more than 
> 50% of all methods that are commonly used ones are unuseable now). This 
> confuses users and makes the API hard to understand.
> This issue should split "atomic readers" from "reader collections" with a 
> separate API. After that, you are no longer able, to get TermsEnum without 
> wrapping from those composite readers. We currently have helper classes for 
> wrapping (SlowMultiReaderWrapper - please rename, the name is really ugly; or 
> Multi*), those should be retrofitted to implement the correct classes 
> (SlowMultiReaderWrapper would be an atomic reader but takes a composite 
> reader as ctor param, maybe it could also simply take a List). 
> In my opinion, maybe composite readers could implement some collection APIs 
> and also have the ReaderUtil method directly built in (possibly as a "view" 
> in the util.Collection sense). In general composite readers do not really 
> need to look like the previous IndexReaders, they could simply be a 
> "collection" of SegmentReaders with some functionality like reopen.
> On the other side, atomic readers do not need reopen logic anymore? When a 
> segment changes, you need a new atomic reader? - maybe because of deletions 
> thats not the best idea, but we should investigate. Maybe make the whole 
> reopen logic simplier to use (ast least on the collection reader level).
> We should decide about good names, i have no preference at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (LUCENE-4100) Maxscore - Efficient Scoring

[Stefan Pohl (JIRA)]

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

Stefan Pohl updated LUCENE-4100:


Description: 
At Berlin Buzzwords 2012, I will be presenting 'maxscore', an efficient 
algorithm first published in the IR domain in 1995 by H. Turtle & J. Flood, 
that I find deserves more attention among Lucene users (and developers).
I implemented a proof of concept and did some performance measurements with 
example queries and lucenebench, the package of Mike McCandless, resulting in 
very significant speedups.

This ticket is to get started the discussion on including the implementation 
into Lucene's codebase. Because the technique requires awareness about it from 
the Lucene user/developer, it seems best to become a contrib/module package so 
that it consciously can be chosen to be used.

  was:
At Berlin Buzzwords 2012, I will be presenting 'maxscore', an efficient 
algorithm firstly published in the IR domain in 1995 by H. Turtle & J. Flood, 
that I find deserves more attention among Lucene users (and developers).
I implemented a proof of concept and did some performance measurements with 
example queries and lucenebench, the package of Mike McCandless, resulting in 
very significant speedups.

This ticket is to get started the discussion on including the implementation 
into Lucene's codebase. Because the technique requires awareness about it from 
the Lucene user/developer, it seems best to become a contrib/module package so 
that it consciously can be chosen to be used.


> Maxscore - Efficient Scoring
> 
>
> Key: LUCENE-4100
> URL: https://issues.apache.org/jira/browse/LUCENE-4100
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: core/codecs, core/query/scoring, core/search
>Affects Versions: 4.0
>Reporter: Stefan Pohl
>  Labels: api-change, patch, performance
> Fix For: 4.0
>
> Attachments: contrib_maxscore.tgz, maxscore.patch
>
>
> At Berlin Buzzwords 2012, I will be presenting 'maxscore', an efficient 
> algorithm first published in the IR domain in 1995 by H. Turtle & J. Flood, 
> that I find deserves more attention among Lucene users (and developers).
> I implemented a proof of concept and did some performance measurements with 
> example queries and lucenebench, the package of Mike McCandless, resulting in 
> very significant speedups.
> This ticket is to get started the discussion on including the implementation 
> into Lucene's codebase. Because the technique requires awareness about it 
> from the Lucene user/developer, it seems best to become a contrib/module 
> package so that it consciously can be chosen to be used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Suppressing list doesn't take effect when -Dtests.postingsformat is used

[Dawid Weiss]

Robert's patch looks good to me. Perhaps we could just move the entire
assumption to that rule (I don't have the code open so I don't know
where this is called, but I think it should be determined as soon as
possible and once).

Dawid

On Sun, Jun 3, 2012 at 9:54 AM, Uwe Schindler  wrote:
>> The actual source of the problem is that suppression applies to codec.getName
>> and enforcing a TEST_POSTINGSFORMAT means  Lucene40Codec is created
>> which always returns Lucene40 from getName(). A simple fix would be to allow
>> changing the returned name for Lucene40.
>
> I don't think we should do this! Making it un-final destroys the whole 
> concept behind it. SPI relies on a constant name and this enforces the codec 
> API to behave correctly. If it can suddenly return a different name the 
> consistency between codec file format and loaded codec is no longer preserved.
>
> Uwe
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: seeing stdout when running "ant test"?

[Michael McCandless]

On Sat, Jun 2, 2012 at 11:37 AM, Dawid Weiss
 wrote:
>> Thanks Dawid!  -Dtests.showSuccess=true is what I was looking for ...
>> I'll add it to the wiki.
>
> Thanks, I'm wiki-challenged. There is also command-line help readily
> available if you type:
>
> ant test-help
>
>     [echo] # Include additional information like what is printed to
>     [echo] # sysout/syserr, even if the test passes.
>     [echo] # Enabled automatically when running for a single test case.
>     [echo] ant -Dtests.showSuccess=true test

Thanks Dawid.  ant test-help is very useful; one of these days I'll
remember to run it when I'm confused :)

Mike McCandless

http://blog.mikemccandless.com

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

[jira] [Commented] (LUCENE-4101) Remove XXXField.TYPE_STORED

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-4101:


Sorry, I don't intend to rush this.

I set it to blocker because I think the 4.0 API for creating stored
fields is confusing now (separate from the changes being explored in
LUCENE-3312).

This (XXXField/FieldType) is one of the major changed APIs in 4.0 so
it's worth spending effort reviewing/fixing it before we ship it.  The
same goes for all our other new AIPs in 4.0: we should scrutinize them.

bq. personally i dont like the fact you have to add the field twice.

Expert users don't have to (they can make a custom field type, at least
until 5.0).  This API is just for basic usage, and I think it's
important that API be really easy to use.

Today in 4.0 you do this for an un-stored field:
{noformat}
new StringField("title", "...");
{noformat}

and this for a stored field:

{noformat}
new Field("title", "...", StringField.TYPE_STORED);
{noformat}

I think that's a confusing API.  EG, you don't know whether StringField,
IntField, etc., are stored by default.  When you do want to store a
field you suddenly must use the expert API (Field directly) and specify
this custom FieldType.  So I think we should improve this... we already
have StoredField and I think a strong decoupling of "it's stored" from
"all the other neat ways the field can be indexed" is clean.

I guess another option would be to splinter out StoredXXXField?  Ie:
{noformat}
new StoredStringField("title", "...");
{noformat}

But that's gonna double all the XXXFields we have.


> Remove XXXField.TYPE_STORED
> ---
>
> Key: LUCENE-4101
> URL: https://issues.apache.org/jira/browse/LUCENE-4101
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4101.patch
>
>
> Spinoff from LUCENE-3312.
> For 4.0 I think we should simplify the sugar field APIs by requiring
> that you add a StoredField if you want to store the field.  Expert users
> can still make a custom FieldType that both stores and indexes...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java7-64 #213

[jenkins]

See 



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

[jira] [Commented] (LUCENE-4101) Remove XXXField.TYPE_STORED

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-4101:
---

Hi,
I am strong +1 for adding the field twice! But it's a little bit too late for 
Lucene 4.0.

We should do this together with the other changes of Nikola in a separate 
branch!

> Remove XXXField.TYPE_STORED
> ---
>
> Key: LUCENE-4101
> URL: https://issues.apache.org/jira/browse/LUCENE-4101
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4101.patch
>
>
> Spinoff from LUCENE-3312.
> For 4.0 I think we should simplify the sugar field APIs by requiring
> that you add a StoredField if you want to store the field.  Expert users
> can still make a custom FieldType that both stores and indexes...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

RE: Suppressing list doesn't take effect when -Dtests.postingsformat is used

[Uwe Schindler]

> The actual source of the problem is that suppression applies to codec.getName
> and enforcing a TEST_POSTINGSFORMAT means  Lucene40Codec is created
> which always returns Lucene40 from getName(). A simple fix would be to allow
> changing the returned name for Lucene40.

I don't think we should do this! Making it un-final destroys the whole concept 
behind it. SPI relies on a constant name and this enforces the codec API to 
behave correctly. If it can suddenly return a different name the consistency 
between codec file format and loaded codec is no longer preserved.

Uwe


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

[jira] [Commented] (LUCENE-4101) Remove XXXField.TYPE_STORED

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-4101:
-

bq. I'm not sure we should rush it in: personally i dont like the fact you have 
to
add the field twice.

I have the same feeling though. Can't we branch and do development there and 
see how it goes API wise before we make those things blockers? Maybe two fields 
are overengineering?


> Remove XXXField.TYPE_STORED
> ---
>
> Key: LUCENE-4101
> URL: https://issues.apache.org/jira/browse/LUCENE-4101
> Project: Lucene - Java
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Blocker
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4101.patch
>
>
> Spinoff from LUCENE-3312.
> For 4.0 I think we should simplify the sugar field APIs by requiring
> that you add a StoredField if you want to store the field.  Expert users
> can still make a custom FieldType that both stores and indexes...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Suppressing list doesn't take effect when -Dtests.postingsformat is used

[Robert Muir]

On Sat, Jun 2, 2012 at 11:16 PM, Dawid Weiss
 wrote:
> The actual source of the problem is that suppression applies to
> codec.getName and enforcing a TEST_POSTINGSFORMAT means  Lucene40Codec
> is created which always returns Lucene40 from getName(). A simple fix
> would be to allow changing the returned name for Lucene40.
> Alternatively, we can do suppression checks more intelligent...
> Suggestions welcome.
>

I don't think we should do that, because getName() is for the SPI.

I have an alternate patch: https://issues.apache.org/jira/browse/LUCENE-4102

Thanks for reporting this!


-- 
lucidimagination.com

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

[jira] [Created] (LUCENE-4102) SuppressCodecs doesnt work with -Dtests.postingsformat

[Robert Muir (JIRA)]

Robert Muir created LUCENE-4102:
---

 Summary: SuppressCodecs doesnt work with -Dtests.postingsformat
 Key: LUCENE-4102
 URL: https://issues.apache.org/jira/browse/LUCENE-4102
 Project: Lucene - Java
  Issue Type: Bug
  Components: general/test
Reporter: Robert Muir
 Attachments: LUCENE-4102.patch

As reported by Han on the mailing list: if you are running all tests with your 
postingsformat, but a test specifically ignores it, it doesnt work correctly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (LUCENE-4102) SuppressCodecs doesnt work with -Dtests.postingsformat

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-4102:


Attachment: LUCENE-4102.patch

simple patch

> SuppressCodecs doesnt work with -Dtests.postingsformat
> --
>
> Key: LUCENE-4102
> URL: https://issues.apache.org/jira/browse/LUCENE-4102
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: general/test
>Reporter: Robert Muir
> Attachments: LUCENE-4102.patch
>
>
> As reported by Han on the mailing list: if you are running all tests with 
> your postingsformat, but a test specifically ignores it, it doesnt work 
> correctly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #212

[jenkins]

See 


--
[...truncated 14406 lines...]
   [junit4] Suite: org.apache.solr.core.TestXIncludeConfig
   [junit4] Completed in 0.67s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSolrQueryParser
   [junit4] Completed in 0.84s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestJapaneseBaseFormFilterFactory
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestItalianLightStemFilterFactory
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestJmxIntegration
   [junit4] IGNORED 0.00s | TestJmxIntegration.testJmxOnCoreReload
   [junit4]> Cause: Annotated @Ignore(timing problem? 
https://issues.apache.org/jira/browse/SOLR-2715)
   [junit4] Completed in 2.19s, 3 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTSTTest
   [junit4] Completed in 1.17s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestConfig
   [junit4] Completed in 0.33s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRealTimeGet
   [junit4] IGNOR/A 0.01s | TestRealTimeGet.testStressRecovery
   [junit4]> Assumption #1: FIXME: This test is horribly slow sometimes on 
Windows!
   [junit4]   2> 22119 T2799 oas.SolrTestCaseJ4.setUp ###Starting 
testStressRecovery
   [junit4]   2> 22119 T2799 oas.SolrTestCaseJ4.tearDown ###Ending 
testStressRecovery
   [junit4]   2>
   [junit4] Completed in 29.46s, 8 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.ZkControllerTest
   [junit4] Completed in 16.72s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestGroupingSearch
   [junit4] Completed in 7.39s, 12 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.TestMultiCoreConfBootstrap
   [junit4] Completed in 4.46s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRangeQuery
   [junit4] Completed in 8.08s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.PeerSyncTest
   [junit4] Completed in 5.08s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.TestFunctionQuery
   [junit4] Completed in 3.48s, 14 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSort
   [junit4] Completed in 4.04s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.MoreLikeThisHandlerTest
   [junit4] Completed in 1.12s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.ConvertedLegacyTest
   [junit4] Completed in 3.98s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestFiltering
   [junit4] Completed in 4.13s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.BadIndexSchemaTest
   [junit4] Completed in 2.02s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.StatsComponentTest
   [junit4] Completed in 7.74s, 6 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest
   [junit4] Completed in 1.52s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestCoreContainer
   [junit4] Completed in 3.41s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestWriterPerf
   [junit4] Completed in 1.38s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.TermsComponentTest
   [junit4] Completed in 1.35s, 13 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.HighlighterTest
   [junit4] Completed in 2.62s, 27 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.admin.CoreAdminHandlerTest
   [junit4] Completed in 1.99s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.SpellCheckCollatorTest
   [junit4] Completed in 2.07s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.DocumentAnalysisRequestHandlerTest
   [junit4] Completed in 1.00s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterWFSTTest
   [junit4] Completed in 1.58s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestPropInject
   [junit4] Completed in 1.66s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestFoldingMultitermQuery
   [junit4] Completed in 1.51s, 18 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.FieldMutatingUpdateProcessorTest
   [junit4] Completed in 0.74s, 20 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestDocSet
   [junit4] Completed in 0.57s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestIndexSearcher
   [junit4] Completed in 1.92s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.BadComponentTest
   [junit4] Completed in 0.70s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.JsonLoaderTest
   [junit4] Completed in 0.96s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.IndexReade