[jira] [Commented] (SOLR-2760) Cannot "ant dist or ant example"
[
https://issues.apache.org/jira/browse/SOLR-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104304#comment-13104304
]
Simon Willnauer commented on SOLR-2760:
---
try run ant clean from the top level directory and then try the dist again
> Cannot "ant dist or ant example"
>
>
> Key: SOLR-2760
> URL: https://issues.apache.org/jira/browse/SOLR-2760
> Project: Solr
> Issue Type: Bug
>Reporter: Bill Bell
>
> Path: .
> URL: http://svn.apache.org/repos/asf/lucene/dev/trunk/solr
> Repository Root: http://svn.apache.org/repos/asf
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 1170435
> Node Kind: directory
> Schedule: normal
> Last Changed Author: chrism
> Last Changed Rev: 1170425
> Last Changed Date: 2011-09-13 21:36:56 -0600 (Tue, 13 Sep 2011)
> Then
> > ant dist or ant example
> compile-core:
> [javac] Compiling 23 source files to
> /Users/bill/solr/trunk/modules/queries/build/classes/java
> [javac]
> /Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/NormValueSource.java:48:
> warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
> java.util.Map
> [javac] context.put("searcher",searcher);
> [javac]^
> [javac]
> /Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/NormValueSource.java:61:
> cannot find symbol
> [javac] symbol : class ConstDoubleDocValues
> [javac] location: class
> org.apache.lucene.queries.function.valuesource.NormValueSource
> [javac] return new ConstDoubleDocValues(0.0, this);
> [javac] ^
> [javac]
> /Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/NumDocsValueSource.java:40:
> cannot find symbol
> [javac] symbol : class ConstIntDocValues
> [javac] location: class
> org.apache.lucene.queries.function.valuesource.NumDocsValueSource
> [javac] return new
> ConstIntDocValues(ReaderUtil.getTopLevelContext(readerContext).reader.numDocs(),
> this);
> [javac]^
> [javac]
> /Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/QueryValueSource.java:73:
> warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
> java.util.Map
> [javac] context.put(this, w);
> [javac]^
> [javac]
> /Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/ScaleFloatFunction.java:96:
> warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
> java.util.Map
> [javac] context.put(this.source, scaleInfo);
> [javac]^
> [javac]
> /Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/SumTotalTermFreqValueSource.java:68:
> warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
> java.util.Map
> [javac] context.put(this, new LongDocValues(this) {
> [javac]^
> [javac]
> /Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/TotalTermFreqValueSource.java:68:
> warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
> java.util.Map
> [javac] context.put(this, new LongDocValues(this) {
> [javac]^
> [javac] 2 errors
> [javac] 5 warnings
--
This message is automatically generated by JIRA.
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-3434) Make ShingleAnalyzerWrapper and PerFieldAnalyzerWrapper immutable
[ https://issues.apache.org/jira/browse/LUCENE-3434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Male updated LUCENE-3434: --- Attachment: LUCENE-3434-trunk.patch LUCENE-3434-3x.patch Patches for trunk and 3x. > Make ShingleAnalyzerWrapper and PerFieldAnalyzerWrapper immutable > - > > Key: LUCENE-3434 > URL: https://issues.apache.org/jira/browse/LUCENE-3434 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/analysis >Reporter: Chris Male > Attachments: LUCENE-3434-3x.patch, LUCENE-3434-trunk.patch > > > Both ShingleAnalyzerWrapper and PerFieldAnalyzerWrapper have setters which > change some state which impacts their analysis stack. If these are going to > become reusable, then the state must be immutable as changing it will have no > effect. > Process will be similar to QueryAutoStopWordAnalyzer, I will remove in trunk > and deprecate in 3x. -- This message is automatically generated by JIRA. 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-2757) Switch min(a,b) function to min(a,b,...)
[ https://issues.apache.org/jira/browse/SOLR-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104284#comment-13104284 ] Bill Bell commented on SOLR-2757: - This is ready to be committed to 4.0 > Switch min(a,b) function to min(a,b,...) > > > Key: SOLR-2757 > URL: https://issues.apache.org/jira/browse/SOLR-2757 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.4 >Reporter: Bill Bell >Priority: Minor > Attachments: SOLR-2757.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > Would like the ability to use min(1,5,10,11) to return 1. To do that today it > is parenthesis nightmare: > min(min(min(1,5),10),11) > Should extend max() as well. -- This message is automatically generated by JIRA. 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] (SOLR-2757) Switch min(a,b) function to min(a,b,...)
[ https://issues.apache.org/jira/browse/SOLR-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Bell updated SOLR-2757: Attachment: SOLR-2757.patch > Switch min(a,b) function to min(a,b,...) > > > Key: SOLR-2757 > URL: https://issues.apache.org/jira/browse/SOLR-2757 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.4 >Reporter: Bill Bell >Priority: Minor > Attachments: SOLR-2757.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > Would like the ability to use min(1,5,10,11) to return 1. To do that today it > is parenthesis nightmare: > min(min(min(1,5),10),11) > Should extend max() as well. -- This message is automatically generated by JIRA. 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-2757) Switch min(a,b) function to min(a,b,...)
[
https://issues.apache.org/jira/browse/SOLR-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104283#comment-13104283
]
Bill Bell commented on SOLR-2757:
-
You can test with:
http://localhost:8983/solr/select?q={!func}max%2810,3,8,7,5,4%29&fl=score
http://localhost:8983/solr/select?q={!func}min%2810,3,8,7,5,4%29&fl=score
> Switch min(a,b) function to min(a,b,...)
>
>
> Key: SOLR-2757
> URL: https://issues.apache.org/jira/browse/SOLR-2757
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 3.4
>Reporter: Bill Bell
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Would like the ability to use min(1,5,10,11) to return 1. To do that today it
> is parenthesis nightmare:
> min(min(min(1,5),10),11)
> Should extend max() as well.
--
This message is automatically generated by JIRA.
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-2762) FSTLookup returns one less suggestion than it should when onlyMorePopular=true
FSTLookup returns one less suggestion than it should when onlyMorePopular=true -- Key: SOLR-2762 URL: https://issues.apache.org/jira/browse/SOLR-2762 Project: Solr Issue Type: Bug Components: spellchecker Affects Versions: 3.3 Reporter: David Smiley Priority: Minor I'm using the Suggester. When I switched from TSTLookup to FSTLookup, I noticed that it returned one fewer suggestion than what I asked for. I have spellcheck.onlyMorePopular=true; when I set it to false, I see the correct count. Another aspect of the bug is that this off-by-one bug only seems to occur when my suggestion has an exact match. -- This message is automatically generated by JIRA. 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: [jira] [Created] (SOLR-2760) Cannot "ant dist or ant example"
Thoughts on this?
I did an "svn up"
On 9/13/11 11:00 PM, "Bill Bell (JIRA)" wrote:
>Cannot "ant dist or ant example"
>
>
> Key: SOLR-2760
> URL: https://issues.apache.org/jira/browse/SOLR-2760
> Project: Solr
> Issue Type: Bug
>Reporter: Bill Bell
>
>
>Path: .
>URL: http://svn.apache.org/repos/asf/lucene/dev/trunk/solr
>Repository Root: http://svn.apache.org/repos/asf
>Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
>Revision: 1170435
>Node Kind: directory
>Schedule: normal
>Last Changed Author: chrism
>Last Changed Rev: 1170425
>Last Changed Date: 2011-09-13 21:36:56 -0600 (Tue, 13 Sep 2011)
>
>
>Then
>
>> ant dist or ant example
>
>compile-core:
>[javac] Compiling 23 source files to
>/Users/bill/solr/trunk/modules/queries/build/classes/java
>[javac]
>/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/
>function/valuesource/NormValueSource.java:48: warning: [unchecked]
>unchecked call to put(K,V) as a member of the raw type java.util.Map
>[javac] context.put("searcher",searcher);
>[javac]^
>[javac]
>/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/
>function/valuesource/NormValueSource.java:61: cannot find symbol
>[javac] symbol : class ConstDoubleDocValues
>[javac] location: class
>org.apache.lucene.queries.function.valuesource.NormValueSource
>[javac] return new ConstDoubleDocValues(0.0, this);
>[javac] ^
>[javac]
>/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/
>function/valuesource/NumDocsValueSource.java:40: cannot find symbol
>[javac] symbol : class ConstIntDocValues
>[javac] location: class
>org.apache.lucene.queries.function.valuesource.NumDocsValueSource
>[javac] return new
>ConstIntDocValues(ReaderUtil.getTopLevelContext(readerContext).reader.numD
>ocs(), this);
>[javac]^
>[javac]
>/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/
>function/valuesource/QueryValueSource.java:73: warning: [unchecked]
>unchecked call to put(K,V) as a member of the raw type java.util.Map
>[javac] context.put(this, w);
>[javac]^
>[javac]
>/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/
>function/valuesource/ScaleFloatFunction.java:96: warning: [unchecked]
>unchecked call to put(K,V) as a member of the raw type java.util.Map
>[javac] context.put(this.source, scaleInfo);
>[javac]^
>[javac]
>/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/
>function/valuesource/SumTotalTermFreqValueSource.java:68: warning:
>[unchecked] unchecked call to put(K,V) as a member of the raw type
>java.util.Map
>[javac] context.put(this, new LongDocValues(this) {
>[javac]^
>[javac]
>/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/
>function/valuesource/TotalTermFreqValueSource.java:68: warning:
>[unchecked] unchecked call to put(K,V) as a member of the raw type
>java.util.Map
>[javac] context.put(this, new LongDocValues(this) {
>[javac]^
>[javac] 2 errors
>[javac] 5 warnings
>
>
>--
>This message is automatically generated by JIRA.
>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
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2761) FSTLookup should use long-tail like discretization instead of proportional (linear)
FSTLookup should use long-tail like discretization instead of proportional (linear) --- Key: SOLR-2761 URL: https://issues.apache.org/jira/browse/SOLR-2761 Project: Solr Issue Type: Improvement Components: spellchecker Affects Versions: 3.4 Reporter: David Smiley Priority: Minor The Suggester's FSTLookup implementation discretizes the term frequencies into a configurable number of buckets (configurable as "weightBuckets") in order to deal with FST limitations. The mapping of a source frequency into a bucket is a proportional (i.e. linear) mapping from the minimum and maximum value. I don't think this makes sense at all given the well-known long-tail like distribution of term frequencies. As a result of this problem, I've found it necessary to increase weightBuckets substantially, like >100, to get quality suggestions. -- This message is automatically generated by JIRA. 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-2760) Cannot "ant dist or ant example"
Cannot "ant dist or ant example"
Key: SOLR-2760
URL: https://issues.apache.org/jira/browse/SOLR-2760
Project: Solr
Issue Type: Bug
Reporter: Bill Bell
Path: .
URL: http://svn.apache.org/repos/asf/lucene/dev/trunk/solr
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1170435
Node Kind: directory
Schedule: normal
Last Changed Author: chrism
Last Changed Rev: 1170425
Last Changed Date: 2011-09-13 21:36:56 -0600 (Tue, 13 Sep 2011)
Then
> ant dist or ant example
compile-core:
[javac] Compiling 23 source files to
/Users/bill/solr/trunk/modules/queries/build/classes/java
[javac]
/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/NormValueSource.java:48:
warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
java.util.Map
[javac] context.put("searcher",searcher);
[javac]^
[javac]
/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/NormValueSource.java:61:
cannot find symbol
[javac] symbol : class ConstDoubleDocValues
[javac] location: class
org.apache.lucene.queries.function.valuesource.NormValueSource
[javac] return new ConstDoubleDocValues(0.0, this);
[javac] ^
[javac]
/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/NumDocsValueSource.java:40:
cannot find symbol
[javac] symbol : class ConstIntDocValues
[javac] location: class
org.apache.lucene.queries.function.valuesource.NumDocsValueSource
[javac] return new
ConstIntDocValues(ReaderUtil.getTopLevelContext(readerContext).reader.numDocs(),
this);
[javac]^
[javac]
/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/QueryValueSource.java:73:
warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
java.util.Map
[javac] context.put(this, w);
[javac]^
[javac]
/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/ScaleFloatFunction.java:96:
warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
java.util.Map
[javac] context.put(this.source, scaleInfo);
[javac]^
[javac]
/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/SumTotalTermFreqValueSource.java:68:
warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
java.util.Map
[javac] context.put(this, new LongDocValues(this) {
[javac]^
[javac]
/Users/bill/solr/trunk/modules/queries/src/java/org/apache/lucene/queries/function/valuesource/TotalTermFreqValueSource.java:68:
warning: [unchecked] unchecked call to put(K,V) as a member of the raw type
java.util.Map
[javac] context.put(this, new LongDocValues(this) {
[javac]^
[javac] 2 errors
[javac] 5 warnings
--
This message is automatically generated by JIRA.
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] Lucene-trunk - Build # 1676 - Still Failing
Build: https://builds.apache.org/job/Lucene-trunk/1676/ 2 tests failed. FAILED: org.apache.lucene.index.TestTermsEnum.testIntersectRandom Error Message: Java heap space Stack Trace: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:128) at org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:28) at org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:134) at org.apache.lucene.index.TestTermsEnum.testIntersectRandom(TestTermsEnum.java:266) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:148) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) FAILED: org.apache.lucene.util.automaton.TestCompiledAutomaton.testRandom Error Message: Java heap space Stack Trace: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:128) at org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:28) at org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:134) at org.apache.lucene.util.automaton.TestCompiledAutomaton.build(TestCompiledAutomaton.java:39) at org.apache.lucene.util.automaton.TestCompiledAutomaton.testTerms(TestCompiledAutomaton.java:55) at org.apache.lucene.util.automaton.TestCompiledAutomaton.testRandom(TestCompiledAutomaton.java:101) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:148) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) Build Log (for compile errors): [...truncated 12800 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3434) Make ShingleAnalyzerWrapper and PerFieldAnalyzerWrapper immutable
Make ShingleAnalyzerWrapper and PerFieldAnalyzerWrapper immutable - Key: LUCENE-3434 URL: https://issues.apache.org/jira/browse/LUCENE-3434 Project: Lucene - Java Issue Type: Improvement Components: modules/analysis Reporter: Chris Male Both ShingleAnalyzerWrapper and PerFieldAnalyzerWrapper have setters which change some state which impacts their analysis stack. If these are going to become reusable, then the state must be immutable as changing it will have no effect. Process will be similar to QueryAutoStopWordAnalyzer, I will remove in trunk and deprecate in 3x. -- This message is automatically generated by JIRA. 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-2759) Remove the need for EDismax's ExtendedAnalyzer
[ https://issues.apache.org/jira/browse/SOLR-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Male resolved SOLR-2759. -- Resolution: Fixed Fix Version/s: 4.0 Assignee: Chris Male Committed revision 1170425. > Remove the need for EDismax's ExtendedAnalyzer > -- > > Key: SOLR-2759 > URL: https://issues.apache.org/jira/browse/SOLR-2759 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Chris Male >Assignee: Chris Male > Fix For: 4.0 > > Attachments: SOLR-2759.patch > > > ExtendedDisMaxQParserPlugin.ExtendedAnalyzer cannot be ported over to being > reusable due to its support for deciding at runtime whether stopwords should > be filtered or not. > One way to resolve this is to maintain 2 lazy-initialized Map Analyzer> in the ExtendedSolrQueryParser, one with the stopword filtering > Analyzers for fields, the other with no-stopword filtering Analyzers. Then > ExtendedSolrQueryParser can override the > QueryParserBase.newFieldQuery(Analyzer, String, String, boolean) and > substitute in the appropriate Analyzer based on the runtime behavior desired > at that time. > This will mean an ever so slight increase in memory consumption due to the 2 > maps, but will allow for reusability which will reduce memory consumption and > increase query throughput. -- This message is automatically generated by JIRA. 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] (LUCENE-3431) Make QueryAutoStopWordAnalyzer immutable and reusable
[ https://issues.apache.org/jira/browse/LUCENE-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Male resolved LUCENE-3431. Resolution: Fixed Fix Version/s: 4.0 3.5 Assignee: Chris Male 3x: Committed revision 1170423. Trunk: Committed revision 1170424. I will tackle proper reusability along with the other remaining Analyzers. > Make QueryAutoStopWordAnalyzer immutable and reusable > - > > Key: LUCENE-3431 > URL: https://issues.apache.org/jira/browse/LUCENE-3431 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/analysis >Reporter: Chris Male >Assignee: Chris Male > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3431-3x.patch, LUCENE-3431-trunk.patch > > > Currently QueryAutoStopWordAnalyzer allows its list of stop words to be > changed after instantiation through its addStopWords() methods. This stops > the Analyzer from being reusable since it must instantiate its StopFilters > every time. > Having these methods means that although the Analyzer can be instantiated > once and reused between IndexReaders, the actual analysis stack is not > reusable (which is probably the more expensive part). > So lets change the Analyzer so that its stop words are set at instantiation > time, facilitating reuse. -- This message is automatically generated by JIRA. 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-2594) Make Replication Handler cloud aware
[ https://issues.apache.org/jira/browse/SOLR-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104187#comment-13104187 ] Noble Paul commented on SOLR-2594: -- This issue needs to be 'won't fix'. > Make Replication Handler cloud aware > > > Key: SOLR-2594 > URL: https://issues.apache.org/jira/browse/SOLR-2594 > Project: Solr > Issue Type: Improvement > Components: replication (java), SolrCloud >Reporter: Shalin Shekhar Mangar > Fix For: 4.0 > > > Replication handler should be cloud aware. It should be possible to switch > roles from slave to master as well as switch masterUrls based on the cluster > topology and state. -- This message is automatically generated by JIRA. 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-3433) Random access non RAM resident IndexDocValues (CSF)
[ https://issues.apache.org/jira/browse/LUCENE-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104184#comment-13104184 ] Robert Muir commented on LUCENE-3433: - this isn't the field cache. > Random access non RAM resident IndexDocValues (CSF) > --- > > Key: LUCENE-3433 > URL: https://issues.apache.org/jira/browse/LUCENE-3433 > Project: Lucene - Java > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Yonik Seeley > Fix For: 4.0 > > > There should be a way to get specific IndexDocValues by going through the > Directory rather than loading all of the values into memory. -- This message is automatically generated by JIRA. 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-3433) Random access non RAM resident IndexDocValues (CSF)
[ https://issues.apache.org/jira/browse/LUCENE-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104165#comment-13104165 ] Jason Rutherglen commented on LUCENE-3433: -- Here's another thread discussing MMap'ing and field caches, where the consensus is against it: http://www.lucidimagination.com/search/document/70623ef5879bca38/fst_and_fieldcache#45006a7fe2847c09 posted in "1969-12-31 19:00" :) > Random access non RAM resident IndexDocValues (CSF) > --- > > Key: LUCENE-3433 > URL: https://issues.apache.org/jira/browse/LUCENE-3433 > Project: Lucene - Java > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Yonik Seeley > Fix For: 4.0 > > > There should be a way to get specific IndexDocValues by going through the > Directory rather than loading all of the values into memory. -- This message is automatically generated by JIRA. 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] [Issue Comment Edited] (SOLR-2594) Make Replication Handler cloud aware
[ https://issues.apache.org/jira/browse/SOLR-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104160#comment-13104160 ] Otis Gospodnetic edited comment on SOLR-2594 at 9/14/11 1:59 AM: - Shalin - do you see the existing replication handler mechanism becoming cloud aware or do you see replication changing all together, for example from periodically polling a master for index changes (which ain't real-time), to being implemented as real-time synchronous or asynchronous per-document, push-based replication a la ElasticSearch? If we look towards the bottom of http://wiki.apache.org/solr/NewSolrCloudDesign there is even a mention of replication functionality (in its today's form) not being needed any more once Solr Cloud functionality is all in place. If that is correct, what is the plan for this issue? was (Author: otis): Shalin - do you see the existing replication handler mechanism becoming cloud aware or do you see replication changing all together, for example from periodically polling a master for index changes (which ain't real-time), to being implemented as real-time synchronous or asynchronous per-document, push-based replication a la ElasticSearch? > Make Replication Handler cloud aware > > > Key: SOLR-2594 > URL: https://issues.apache.org/jira/browse/SOLR-2594 > Project: Solr > Issue Type: Improvement > Components: replication (java), SolrCloud >Reporter: Shalin Shekhar Mangar > Fix For: 4.0 > > > Replication handler should be cloud aware. It should be possible to switch > roles from slave to master as well as switch masterUrls based on the cluster > topology and state. -- This message is automatically generated by JIRA. 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-2594) Make Replication Handler cloud aware
[ https://issues.apache.org/jira/browse/SOLR-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104160#comment-13104160 ] Otis Gospodnetic commented on SOLR-2594: Shalin - do you see the existing replication handler mechanism becoming cloud aware or do you see replication changing all together, for example from periodically polling a master for index changes (which ain't real-time), to being implemented as real-time synchronous or asynchronous per-document, push-based replication a la ElasticSearch? > Make Replication Handler cloud aware > > > Key: SOLR-2594 > URL: https://issues.apache.org/jira/browse/SOLR-2594 > Project: Solr > Issue Type: Improvement > Components: replication (java), SolrCloud >Reporter: Shalin Shekhar Mangar > Fix For: 4.0 > > > Replication handler should be cloud aware. It should be possible to switch > roles from slave to master as well as switch masterUrls based on the cluster > topology and state. -- This message is automatically generated by JIRA. 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] (SOLR-2749) use BoundaryScanner in Solr FVH
[ https://issues.apache.org/jira/browse/SOLR-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-2749: - Affects Version/s: 4.0 3.4 3.1 3.2 3.3 Fix Version/s: 4.0 3.5 Assignee: Koji Sekiguchi > use BoundaryScanner in Solr FVH > --- > > Key: SOLR-2749 > URL: https://issues.apache.org/jira/browse/SOLR-2749 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 3.1, 3.2, 3.3, 3.4, 4.0 >Reporter: Koji Sekiguchi >Assignee: Koji Sekiguchi >Priority: Minor > Fix For: 3.5, 4.0 > > Attachments: SOLR-2749.patch, SOLR-2749.patch, SOLR-2749.patch > > > After LUCENE-1824 committed, Solr FragmentsBuilder can snip off at the > "natural" boundary by nature. But to bring out the full feature, Solr should > take care of arbitrary BoundaryScanner in solrconfig.xml. -- This message is automatically generated by JIRA. 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] (SOLR-2749) use BoundaryScanner in Solr FVH
[ https://issues.apache.org/jira/browse/SOLR-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-2749: - Attachment: SOLR-2749.patch New patch. I added test case. Will commit tonight. > use BoundaryScanner in Solr FVH > --- > > Key: SOLR-2749 > URL: https://issues.apache.org/jira/browse/SOLR-2749 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 3.1, 3.2, 3.3, 3.4, 4.0 >Reporter: Koji Sekiguchi >Priority: Minor > Fix For: 3.5, 4.0 > > Attachments: SOLR-2749.patch, SOLR-2749.patch, SOLR-2749.patch > > > After LUCENE-1824 committed, Solr FragmentsBuilder can snip off at the > "natural" boundary by nature. But to bring out the full feature, Solr should > take care of arbitrary BoundaryScanner in solrconfig.xml. -- This message is automatically generated by JIRA. 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-3433) Random access non RAM resident IndexDocValues (CSF)
[ https://issues.apache.org/jira/browse/LUCENE-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104091#comment-13104091 ] Robert Muir commented on LUCENE-3433: - no opinion has changed: traversing on disk automata in the way you describe is inefficient. here I describe accessing a fixed long value: 1 seek per access. how many seeks will an fst lookup take? hint: its more than 1! > Random access non RAM resident IndexDocValues (CSF) > --- > > Key: LUCENE-3433 > URL: https://issues.apache.org/jira/browse/LUCENE-3433 > Project: Lucene - Java > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Yonik Seeley > Fix For: 4.0 > > > There should be a way to get specific IndexDocValues by going through the > Directory rather than loading all of the values into memory. -- This message is automatically generated by JIRA. 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-3433) Random access non RAM resident IndexDocValues (CSF)
[ https://issues.apache.org/jira/browse/LUCENE-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104079#comment-13104079 ] Jason Rutherglen commented on LUCENE-3433: -- This is somewhat funny, as it seems the opinion has changed on MMap'ing and the potential for page faults: http://www.lucidimagination.com/search/document/8951a336dffa9535/storing_and_loading_the_fst_directly_from_disk#8951a336dffa9535 > Random access non RAM resident IndexDocValues (CSF) > --- > > Key: LUCENE-3433 > URL: https://issues.apache.org/jira/browse/LUCENE-3433 > Project: Lucene - Java > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Yonik Seeley > Fix For: 4.0 > > > There should be a way to get specific IndexDocValues by going through the > Directory rather than loading all of the values into memory. -- This message is automatically generated by JIRA. 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: [Lucene.Net] Test case for: possible infinite loop bug in portuguese snowball stemmer?
Hi Digy,
On 13.09.2011 22:12, Digy wrote:
I created a working portuguese stemmer (
http://people.apache.org/~digy/PortugueseStemmerNew.cs ) from
http://snowball.tartarus.org/archives/snowball-discuss/0943.html
http://snowball.tartarus.org/archives/snowball-discuss/att-0943/01-SnowballC
Sharp.zip
Since it has a BSD license (http://snowball.tartarus.org/license.php), I
don't think I can update the PortugueseStemmer.cs under contrib.
Snowball from Tartarus seems to be in Lucene Core:
http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_3_3/lucene/contrib/analyzers/common/src/java/org/tartarus/snowball/ext/
under the old BSD license:
http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_3_3/lucene/contrib/analyzers/common/src/java/org/tartarus/snowball/Among.java?revision=1141402&view=markup
Robert
DIGY
-Original Message-
From: Robert Stewart [mailto:robert_stew...@epam.com]
Sent: Tuesday, September 13, 2011 5:55 PM
To:
Subject: Re: [Lucene.Net] Test case for: possible infinite loop bug in
portuguese snowball stemmer?
Here is a test case:
string text = @"Califórnia";
Lucene.Net.Analysis.KeywordTokenizer tokenizer = new KeywordTokenizer(new
StringReader(text));
Lucene.Net.Analysis.Snowball.SnowballFilter stemmer=
new Lucene.Net.Analysis.Snowball.SnowballFilter(tokenizer,
"Portuguese");
Lucene.Net.Analysis.Token token;
while ((token = stemmer.Next()) != null)
{
System.Console.WriteLine(tokenText);
}
Seems to go into infinite loop. Call to stemmer.Next() never returns. Not
sure if this is the only stemmer I am having trouble with. And it does
happen to us on a near daily basis.
Thanks,
Bob
On Sep 13, 2011, at 9:37 AM, Robert Stewart wrote:
Are there any known issues with snowball stemmers (portuguese in
particular) going into some infinite loop? I have a problem that happens on
a recurring basis where IndexWriter locks up on AddDocument and never
returns (it has taken up to 3 days before we realize it), requiring manual
killing of the process. It seems to happen only on portuguese documents
from what I can tell so far, and the stack trace when thread is aborted is
always as follows:
System.Threading.ThreadAbortException: Thread was being aborted.
at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, SignatureStruct& sig,
MethodAttributes methodAttributes, RuntimeType typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, Signature sig, MethodAttributes
methodAttributes, RuntimeType typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
System.SystemException: System.Threading.ThreadAbortException: Thread was
being aborted.
at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, SignatureStruct& sig,
MethodAttributes methodAttributes, RuntimeType typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, Signature sig, MethodAttributes
methodAttributes, RuntimeType typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
at Lucene.Net.Analysis.TokenStream.IncrementToken()
at Lucene.Net.Index.DocInverterPerField.ProcessFields(Fieldable[]
fields, Int32 count)
at Lucene.Net.Index.DocFieldProcessorPerThread.ProcessDocument()
at Lucene.Net.Index.DocumentsWriter.UpdateDocument(Document doc,
Analyzer analyzer, Term delTerm)
at Lucene.Net.Index.IndexWriter.AddDocument(Document doc, Analyzer
analyzer)
Is there another list of contrib/snowball issues? I have not been able to
reproduce a small test case yet however. Have there been any such issues
with stemmers in the past?
Thanks,
Bob
-
Checked by AVG - www.avg.com
Version: 2012.0.1796 / Virus Database: 2082/4494 - Release Date: 09/13/11
[jira] [Updated] (LUCENE-3426) optimizer for n-gram PhraseQuery
[
https://issues.apache.org/jira/browse/LUCENE-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated LUCENE-3426:
---
Affects Version/s: 4.0
3.4
2.9.4
3.0.3
3.1
3.2
3.3
Fix Version/s: 4.0
3.5
Assignee: Koji Sekiguchi
> optimizer for n-gram PhraseQuery
>
>
> Key: LUCENE-3426
> URL: https://issues.apache.org/jira/browse/LUCENE-3426
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
>Affects Versions: 2.9.4, 3.0.3, 3.1, 3.2, 3.3, 3.4, 4.0
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Trivial
> Fix For: 3.5, 4.0
>
> Attachments: LUCENE-3426.patch, LUCENE-3426.patch, LUCENE-3426.patch,
> LUCENE-3426.patch, LUCENE-3426.patch, LUCENE-3426.patch, PerfTest.java,
> PerfTest.java
>
>
> If 2-gram is used and the length of query string is 4, for example q="ABCD",
> QueryParser generates (when autoGeneratePhraseQueries is true)
> PhraseQuery("AB BC CD") with slop 0. But it can be optimized PhraseQuery("AB
> CD") with appropriate positions.
> The idea came from the Japanese paper "N.M-gram: Implementation of Inverted
> Index Using N-gram with Hash Values" by Mikio Hirabayashi, et al. (The main
> theme of the paper is different from the idea that I'm using here, though)
--
This message is automatically generated by JIRA.
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-3426) optimizer for n-gram PhraseQuery
[
https://issues.apache.org/jira/browse/LUCENE-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated LUCENE-3426:
---
Attachment: LUCENE-3426.patch
Thank you for your continuous review the patch, Robert! Here is the new patch.
Now I don't touch the existing PhraseQuery as I use getter methods.
I think this is ready to commit.
> optimizer for n-gram PhraseQuery
>
>
> Key: LUCENE-3426
> URL: https://issues.apache.org/jira/browse/LUCENE-3426
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
>Reporter: Koji Sekiguchi
>Priority: Trivial
> Attachments: LUCENE-3426.patch, LUCENE-3426.patch, LUCENE-3426.patch,
> LUCENE-3426.patch, LUCENE-3426.patch, LUCENE-3426.patch, PerfTest.java,
> PerfTest.java
>
>
> If 2-gram is used and the length of query string is 4, for example q="ABCD",
> QueryParser generates (when autoGeneratePhraseQueries is true)
> PhraseQuery("AB BC CD") with slop 0. But it can be optimized PhraseQuery("AB
> CD") with appropriate positions.
> The idea came from the Japanese paper "N.M-gram: Implementation of Inverted
> Index Using N-gram with Hash Values" by Mikio Hirabayashi, et al. (The main
> theme of the paper is different from the idea that I'm using here, though)
--
This message is automatically generated by JIRA.
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-3433) Random access non RAM resident IndexDocValues (CSF)
[ https://issues.apache.org/jira/browse/LUCENE-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104049#comment-13104049 ] Robert Muir commented on LUCENE-3433: - Simon: I think it would be a really nice feature. Imagine someone that has a large collection and maybe quite a few docvalues fields: it would be nice if you have a fixed int64 docvalues for it to just be a mmap'ed readLong() for example. I think in a lot of cases the memory resident random-access that we have now is going to be great, e.g. if someone wants to use it for a scoring factor and its going to be super-hot. but in other more advanced cases (especially if you have many of them or access is relatively infrequent) it would be a nice option to have available where currently you have to deal with the downsides of 'fake terms' with a payload or stored fields. > Random access non RAM resident IndexDocValues (CSF) > --- > > Key: LUCENE-3433 > URL: https://issues.apache.org/jira/browse/LUCENE-3433 > Project: Lucene - Java > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Yonik Seeley > Fix For: 4.0 > > > There should be a way to get specific IndexDocValues by going through the > Directory rather than loading all of the values into memory. -- This message is automatically generated by JIRA. 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-3429) improve build system when tests hang
[ https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103997#comment-13103997 ] Mark Miller commented on LUCENE-3429: - bq. interrupt() is not a solution if you have busy code loops that never do any I/O or waiting/sleeping Indeed - the correct statement is that stop would not stop a thread *that is waiting* if interrupt would also not stop it. But stop is certainly a step beyond interrupt in ending a threads life. > improve build system when tests hang > > > Key: LUCENE-3429 > URL: https://issues.apache.org/jira/browse/LUCENE-3429 > Project: Lucene - Java > Issue Type: Test >Reporter: Robert Muir > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3429.patch, LUCENE-3429.patch > > > Currently, if tests hang in hudson it can go hung for days until we manually > kill it. > The problem is that when a hang happens its probably serious, what we want to > do (I think), is: > # time out the build. > # ensure we have enough debugging information to hopefully fix any hang. > So I think the ideal solution would be: > # add a sysprop "-D" that LuceneTestCase respects, it could default to no > timeout at all (some value like zero). > # when a timeout is set, LuceneTestCase spawns an additional timer thread for > the test class? method? > # if the timeout is exceeded, LuceneTestCase dumps all thread/stack > information, random seed information to hopefully reproduce the hang, and > fails the test. > # nightly builds would pass some reasonable -D for each test. > separately, I think we should have an "ant-level" timeout for the whole > build, in case it goes completely crazy (e.g. jvm completely hangs or > something else), just as an additional safety. -- This message is automatically generated by JIRA. 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-3433) Random access non RAM resident IndexDocValues (CSF)
[ https://issues.apache.org/jira/browse/LUCENE-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103988#comment-13103988 ] Simon Willnauer commented on LUCENE-3433: - yonik, do we really need random access? we already have an enum for on disk lookups which is essentially a DocIDSetIterator. > Random access non RAM resident IndexDocValues (CSF) > --- > > Key: LUCENE-3433 > URL: https://issues.apache.org/jira/browse/LUCENE-3433 > Project: Lucene - Java > Issue Type: New Feature >Affects Versions: 4.0 >Reporter: Yonik Seeley > Fix For: 4.0 > > > There should be a way to get specific IndexDocValues by going through the > Directory rather than loading all of the values into memory. -- This message is automatically generated by JIRA. 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-3429) improve build system when tests hang
[
https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103982#comment-13103982
]
Dawid Weiss commented on LUCENE-3429:
-
Ehm. So... I figured out at least the reason for the fact the tests hang on
mac/linux if the patch is applied. The reason is this in
TestConcurrentMergeScheduler):
{code}
@Override
public void eval(MockDirectoryWrapper dir) throws IOException {
if (doFail && (Thread.currentThread().getName().equals("main")
|| Thread.currentThread().getName().equals("Main Thread"))) {
{code}
because we're spawning threads named differently this test never finishes
(because this condition never occurs). Is this supposed to check if the code
runs a test case? If so then I suggest a different way of checking this: create
a field on LuceneTestCase with
{code}
volatile Thread current;
{code}
this would be set by the runner (or a rule, whatever) and then test cases could
verify they are running inside a test case by comparing Thread.currentThread()
== current.
Sounds good?
> improve build system when tests hang
>
>
> Key: LUCENE-3429
> URL: https://issues.apache.org/jira/browse/LUCENE-3429
> Project: Lucene - Java
> Issue Type: Test
>Reporter: Robert Muir
> Fix For: 3.5, 4.0
>
> Attachments: LUCENE-3429.patch, LUCENE-3429.patch
>
>
> Currently, if tests hang in hudson it can go hung for days until we manually
> kill it.
> The problem is that when a hang happens its probably serious, what we want to
> do (I think), is:
> # time out the build.
> # ensure we have enough debugging information to hopefully fix any hang.
> So I think the ideal solution would be:
> # add a sysprop "-D" that LuceneTestCase respects, it could default to no
> timeout at all (some value like zero).
> # when a timeout is set, LuceneTestCase spawns an additional timer thread for
> the test class? method?
> # if the timeout is exceeded, LuceneTestCase dumps all thread/stack
> information, random seed information to hopefully reproduce the hang, and
> fails the test.
> # nightly builds would pass some reasonable -D for each test.
> separately, I think we should have an "ant-level" timeout for the whole
> build, in case it goes completely crazy (e.g. jvm completely hangs or
> something else), just as an additional safety.
--
This message is automatically generated by JIRA.
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-3433) Random access non RAM resident IndexDocValues (CSF)
Random access non RAM resident IndexDocValues (CSF) --- Key: LUCENE-3433 URL: https://issues.apache.org/jira/browse/LUCENE-3433 Project: Lucene - Java Issue Type: New Feature Affects Versions: 4.0 Reporter: Yonik Seeley Fix For: 4.0 There should be a way to get specific IndexDocValues by going through the Directory rather than loading all of the values into memory. -- This message is automatically generated by JIRA. 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] (SOLR-2066) Search Grouping: support distributed search
[ https://issues.apache.org/jira/browse/SOLR-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated SOLR-2066: Attachment: SOLR-2066.patch NPE and empty results! Thanks for noticing this. Better now then when distributed grouping is released! > Search Grouping: support distributed search > --- > > Key: SOLR-2066 > URL: https://issues.apache.org/jira/browse/SOLR-2066 > Project: Solr > Issue Type: Sub-task >Reporter: Yonik Seeley > Fix For: 3.5, 4.0 > > Attachments: SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, > SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, > SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, > SOLR-2066.patch, SOLR-2066.patch > > > Support distributed field collapsing / search grouping. -- This message is automatically generated by JIRA. 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-3429) improve build system when tests hang
[ https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103958#comment-13103958 ] Dawid Weiss commented on LUCENE-3429: - Not really. Thread.stop is deprecated and I know the reasons it is deprecated, but this doesn't mean it doesn't work. interrupt() is not a solution if you have busy code loops that never do any I/O or waiting/sleeping -- try interrupting while(true); and you'll see what I mean. The code I posted is correct. Thread.stop() is not even called because no methods do timeout at the moment. The problem with hangs and jre crashes is something else, but I didn't have the time to peek at it yet. > improve build system when tests hang > > > Key: LUCENE-3429 > URL: https://issues.apache.org/jira/browse/LUCENE-3429 > Project: Lucene - Java > Issue Type: Test >Reporter: Robert Muir > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3429.patch, LUCENE-3429.patch > > > Currently, if tests hang in hudson it can go hung for days until we manually > kill it. > The problem is that when a hang happens its probably serious, what we want to > do (I think), is: > # time out the build. > # ensure we have enough debugging information to hopefully fix any hang. > So I think the ideal solution would be: > # add a sysprop "-D" that LuceneTestCase respects, it could default to no > timeout at all (some value like zero). > # when a timeout is set, LuceneTestCase spawns an additional timer thread for > the test class? method? > # if the timeout is exceeded, LuceneTestCase dumps all thread/stack > information, random seed information to hopefully reproduce the hang, and > fails the test. > # nightly builds would pass some reasonable -D for each test. > separately, I think we should have an "ant-level" timeout for the whole > build, in case it goes completely crazy (e.g. jvm completely hangs or > something else), just as an additional safety. -- This message is automatically generated by JIRA. 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: [Lucene.Net] Test case for: possible infinite loop bug in portuguese snowball stemmer?
I created a working portuguese stemmer (
http://people.apache.org/~digy/PortugueseStemmerNew.cs ) from
http://snowball.tartarus.org/archives/snowball-discuss/0943.html
http://snowball.tartarus.org/archives/snowball-discuss/att-0943/01-SnowballC
Sharp.zip
Since it has a BSD license (http://snowball.tartarus.org/license.php), I
don't think I can update the PortugueseStemmer.cs under contrib.
DIGY
-Original Message-
From: Robert Stewart [mailto:robert_stew...@epam.com]
Sent: Tuesday, September 13, 2011 5:55 PM
To:
Subject: Re: [Lucene.Net] Test case for: possible infinite loop bug in
portuguese snowball stemmer?
Here is a test case:
string text = @"Califórnia";
Lucene.Net.Analysis.KeywordTokenizer tokenizer = new KeywordTokenizer(new
StringReader(text));
Lucene.Net.Analysis.Snowball.SnowballFilter stemmer=
new Lucene.Net.Analysis.Snowball.SnowballFilter(tokenizer,
"Portuguese");
Lucene.Net.Analysis.Token token;
while ((token = stemmer.Next()) != null)
{
System.Console.WriteLine(tokenText);
}
Seems to go into infinite loop. Call to stemmer.Next() never returns. Not
sure if this is the only stemmer I am having trouble with. And it does
happen to us on a near daily basis.
Thanks,
Bob
On Sep 13, 2011, at 9:37 AM, Robert Stewart wrote:
> Are there any known issues with snowball stemmers (portuguese in
particular) going into some infinite loop? I have a problem that happens on
a recurring basis where IndexWriter locks up on AddDocument and never
returns (it has taken up to 3 days before we realize it), requiring manual
killing of the process. It seems to happen only on portuguese documents
from what I can tell so far, and the stack trace when thread is aborted is
always as follows:
>
> System.Threading.ThreadAbortException: Thread was being aborted.
> at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, SignatureStruct& sig,
MethodAttributes methodAttributes, RuntimeType typeOwner)
> at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, Signature sig, MethodAttributes
methodAttributes, RuntimeType typeOwner)
> at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
> at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
> at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
> System.SystemException: System.Threading.ThreadAbortException: Thread was
being aborted.
> at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, SignatureStruct& sig,
MethodAttributes methodAttributes, RuntimeType typeOwner)
> at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo
method, Object target, Object[] arguments, Signature sig, MethodAttributes
methodAttributes, RuntimeType typeOwner)
> at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean
skipVisibilityChecks)
> at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
> at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
> at Lucene.Net.Analysis.Snowball.SnowballFilter.Next()
> at Lucene.Net.Analysis.TokenStream.IncrementToken()
> at Lucene.Net.Index.DocInverterPerField.ProcessFields(Fieldable[]
fields, Int32 count)
> at Lucene.Net.Index.DocFieldProcessorPerThread.ProcessDocument()
> at Lucene.Net.Index.DocumentsWriter.UpdateDocument(Document doc,
Analyzer analyzer, Term delTerm)
> at Lucene.Net.Index.IndexWriter.AddDocument(Document doc, Analyzer
analyzer)
>
>
> Is there another list of contrib/snowball issues? I have not been able to
reproduce a small test case yet however. Have there been any such issues
with stemmers in the past?
>
> Thanks,
> Bob
-
Checked by AVG - www.avg.com
Version: 2012.0.1796 / Virus Database: 2082/4494 - Release Date: 09/13/11
[jira] [Commented] (LUCENE-3429) improve build system when tests hang
[ https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103947#comment-13103947 ] Simon Willnauer commented on LUCENE-3429: - david, I looked at your patch briefly and I think what you are trying to do is unfortunately not possible with java and its thread implementation. And actually I think it should not be possible too. Calling Thread.stop() is deprecated for a very good reason since it can put your Thread into an undefined state. I think what we should do instead is get all threads stack traces (Thread#getAllStackTraces()) and then interrupt the threads we obtained. if a thread doesn't react to interrupt() it won't react to stop() either afaik. > improve build system when tests hang > > > Key: LUCENE-3429 > URL: https://issues.apache.org/jira/browse/LUCENE-3429 > Project: Lucene - Java > Issue Type: Test >Reporter: Robert Muir > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3429.patch, LUCENE-3429.patch > > > Currently, if tests hang in hudson it can go hung for days until we manually > kill it. > The problem is that when a hang happens its probably serious, what we want to > do (I think), is: > # time out the build. > # ensure we have enough debugging information to hopefully fix any hang. > So I think the ideal solution would be: > # add a sysprop "-D" that LuceneTestCase respects, it could default to no > timeout at all (some value like zero). > # when a timeout is set, LuceneTestCase spawns an additional timer thread for > the test class? method? > # if the timeout is exceeded, LuceneTestCase dumps all thread/stack > information, random seed information to hopefully reproduce the hang, and > fails the test. > # nightly builds would pass some reasonable -D for each test. > separately, I think we should have an "ant-level" timeout for the whole > build, in case it goes completely crazy (e.g. jvm completely hangs or > something else), just as an additional safety. -- This message is automatically generated by JIRA. 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: 3.4.0 draft release notes
On Tue, Sep 13, 2011 at 2:53 PM, Bernd Fehling wrote: > Hmm, it may be not an blocker issue but still has a NPE which isn't > good publicity for solr/lucene. > This is already fixed with a patch attached to SOLR-2726. > And yes, it is fixed with its init(). > So where is the problem? As i explained both in this thread and on the jira issue, the proper fix is for the logic to be in *SolrSpellChecker*, since its the one that has this 'analyzer' variable. then the logic doesnt need to be duplicated across n implementing classes (AbstractLuceneSpellChecker, DirectSpellChecker, Suggester, ...) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: where is the SOLR_HOME
https://people.apache.org/~hossman/#solr-user Please Use "solr-user@lucene" Not "dev@lucene" Your question is better suited for the solr-user@lucene mailing list ... not the dev@lucene list. The dev list is for discussing development of the internals of Solr and the Lucene Java library ... it is *not* the appropriate place to ask questions about how to use Solr or the Lucene Java library when developing your own applications. Please resend your message to the solr-user mailing list, where you are likely to get more/betterresponses since that list also has a larger number of subscribers. (sorry i didn't mention this in my last reply, didn't notice the list until i hit send) -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: where is the SOLR_HOME
: http://wiki.apache.org/nutch/NutchTutorial#A6._Integrate_Solr_with_Nutch) I : should copy schema.xml of Nutch to conf directory of Solr. : So I added all of my required Analyzer like "*ICUNormalizer2FilterFactory" *to : this new shema.xml . Maybe all of my problems are deriving from this file! : but still i can't solve it. specifics matter... * what exactly does your schema.xml look like? * what exactly is the error you are getting? * Solr logs info on startup about every plugin jar it loads, what log messages are you seeing there? is it finding the specific jars you want? -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 3.4.0 draft release notes
Hmm, it may be not an blocker issue but still has a NPE which isn't good publicity for solr/lucene. This is already fixed with a patch attached to SOLR-2726. And yes, it is fixed with its init(). So where is the problem? - Ursprüngliche Nachricht - Von: Robert Muir Datum: Montag, 12. September 2011, 1:13 Betreff: Re: 3.4.0 draft release notes An: dev@lucene.apache.org > On Sun, Sep 11, 2011 at 7:04 PM, Michael McCandless > wrote: > > On Sat, Sep 10, 2011 at 10:21 AM, Bernd Fehling > > wrote: > > > >> Will the fix/patch for issue SOLR-2726 included in SOLR 3.4.0? > > > > Sorry, no. > > > > This isn't a release blocker issue. > > > > But, separately, I think we should fix it, but on quick glance it > > doesn't look like there's consensus on how to fix it? > > > > I had this same bug when implementing a spellchecker too. > Its something the spellcheck framework expects, but doesn't provide. > > I think its broken that SolrSpellChecker has both field name and > analyzer,but only sets up field name in its init()... if > SolrSpellChecker is > going to own the 'analyzer' variable then > I think its init() should take care of the logic, currently its either > duplicated across spellchecker implementations, > or its missing entirely, causing bugs like SOLR-2726. > > > -- > lucidimagination.com > > - > > 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: where is the SOLR_HOME
I tested your guidance but still have errors. let me to explain more about my problem. I use Nutch to crawling the web and fetching web pages. I send data of Nutch to Solr for Indexing. according to Nutch tutorial ( http://wiki.apache.org/nutch/NutchTutorial#A6._Integrate_Solr_with_Nutch) I should copy schema.xml of Nutch to conf directory of Solr. So I added all of my required Analyzer like "*ICUNormalizer2FilterFactory" *to this new shema.xml . Maybe all of my problems are deriving from this file! but still i can't solve it. On Tue, Sep 13, 2011 at 2:28 PM, mohit soni wrote: > Did you try following: > > > I think the path you specify here is relative to your SOLR_HOME directory, > which in example's case would be "example/solr " directory. Also, the "lib" > directory created by you exists at "example/solr/lib/", so using above lib > directive should solve the problem. > > Hope that helps! > ~Mohit > > > On Tue, Sep 13, 2011 at 11:14 AM, ahmad ajiloo wrote: > >> I created "example/solr/lib" directory and copied jar files to it and >> added this expressions in solrconfig.xml : >> >> >> (for assurance!!!) >> >> but it doesn't work and still has those errors ! >> >> >> >> On Mon, Sep 12, 2011 at 4:31 PM, Erik Hatcher wrote: >> >>> Yes, SOLR_HOME in this case, if you're running the example application, >>> in example/solr. There's no lib/ directory there by default, just create it >>> yourself. >>> >>> You can also add directives in your solrconfig.xml (you'll see this >>> documented in comments in the example config). >>> >>>Erik >>> >>> >>> >>> On Sep 12, 2011, at 07:51 , ahmad ajiloo wrote: >>> >>> > Hi >>> > In this page said: >>> > "Note: to use this filter, see solr/contrib/analysis-extras/README.txt >>> for instructions on which jars you need to add to your SOLR_HOME/lib " >>> > I can't find "SOLR_HOME/lib" ! >>> > Is there: "apache-solr-3.3.0\example\solr" ? there is no directory >>> which name is lib >>> > or: "apache-solr-3.3.0\" ? there is no directory which name is lib >>> > >>> > or : "apache-solr-3.3.0\example" ? there is a "lib" directory. I copied >>> 4 libraries exist in "solr/contrib/analysis-extras/" to >>> "apache-solr-3.3.0\example\lib" but some errors exist in loading page " >>> http://localhost:8983/solr/admin"; like: >>> > "org.apache.solr.common.SolrException: Error loading class >>> 'solr.ICUNormalizer2FilterFactory' " >>> > >>> > thanks a lot >>> > >>> > >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> >
Trunk test failure: ExtractingRequestHandlerTest.testCommitWithin() [was: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #239: POMs out of sync]
This is 100% reproducible on my local machine (run from solr/contrib/extraction/): ant test -Dtestcase=ExtractingRequestHandlerTest -Dtestmethod=testCommitWithin -Dtests.seed=-2b35f16e02bddd0d:5c36eb67e44fc16d:-54d0d485d6a45315 Steve > -Original Message- > From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] > Sent: Tuesday, September 13, 2011 12:09 PM > To: dev@lucene.apache.org > Subject: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #239: POMs out of sync > > Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/239/ > > 1 tests failed. > FAILED: > org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testCommi > tWithin > > Error Message: > Exception during query > > Stack Trace: > java.lang.RuntimeException: Exception during query > at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:396) > at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:363) > at > org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testCommi > tWithin(ExtractingRequestHandlerTest.java:306) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java > :57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI > mpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMeth > od.java:44) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallabl > e.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod > .java:41) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod. > java:20) > at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java > :28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:3 > 1) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner. > java:76) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner > .java:148) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner > .java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java > :28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:3 > 1) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java > :35) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Prov > ider.java:146) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.jav > a:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java > :57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI > mpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke( > ProviderFactory.java:103) > at $Proxy0.invoke(Unknown Source) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireS > tarter.java:145) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(Suref > ireStarter.java:87) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: java.lang.RuntimeException: REQUEST FAILED: > xpath=//*[@numFound='1'] > xml response was: > > 0 name="QTime">0 start="0"> > > > request was:start=0&q=id:one&qt=standard&rows=20&version=2.2 > at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:389) > ... 36 more > > > > > Build Log (for compile errors): > [...truncated 24297 lines...] > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3420) assertion derived class modifier from parent class silently breaks backward compatibility
[ https://issues.apache.org/jira/browse/LUCENE-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103800#comment-13103800 ] Uwe Schindler commented on LUCENE-3420: --- Hi, any comments? I would like to commit the "change" (it's not a fix as nothing is borken!) to trunk and 3.x, > assertion derived class modifier from parent class silently breaks backward > compatibility > - > > Key: LUCENE-3420 > URL: https://issues.apache.org/jira/browse/LUCENE-3420 > Project: Lucene - Java > Issue Type: Bug > Components: core/index >Affects Versions: 3.3 >Reporter: John Wang > Attachments: LUCENE-3420.patch > > > after upgrading to lucene 3.1+, I see this in my log: > java.lang.AssertionError: TokenStream implementation classes or at least > their incrementToken() implementation must be final > at > org.apache.lucene.analysis.TokenStream.assertFinal(TokenStream.java:117) > at org.apache.lucene.analysis.TokenStream.(TokenStream.java:92) > Turns out I derived TokenStream and my class was not declared final. > This silently breaks backward compatibility via reflection, scary... > I think doing this sort of check is fine, but throwing an > java.lang.AssertionError in this case is too stringent. > This is a style check against lucene clients, a error log would be fine, but > throwing an Error is too much. > See constructor implementation for: > http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/analysis/TokenStream.java?view=markup -- This message is automatically generated by JIRA. 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] (LUCENE-3420) assertion derived class modifier from parent class silently breaks backward compatibility
[ https://issues.apache.org/jira/browse/LUCENE-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-3420: - Assignee: Uwe Schindler > assertion derived class modifier from parent class silently breaks backward > compatibility > - > > Key: LUCENE-3420 > URL: https://issues.apache.org/jira/browse/LUCENE-3420 > Project: Lucene - Java > Issue Type: Bug > Components: core/index >Affects Versions: 3.3 >Reporter: John Wang >Assignee: Uwe Schindler > Attachments: LUCENE-3420.patch > > > after upgrading to lucene 3.1+, I see this in my log: > java.lang.AssertionError: TokenStream implementation classes or at least > their incrementToken() implementation must be final > at > org.apache.lucene.analysis.TokenStream.assertFinal(TokenStream.java:117) > at org.apache.lucene.analysis.TokenStream.(TokenStream.java:92) > Turns out I derived TokenStream and my class was not declared final. > This silently breaks backward compatibility via reflection, scary... > I think doing this sort of check is fine, but throwing an > java.lang.AssertionError in this case is too stringent. > This is a style check against lucene clients, a error log would be fine, but > throwing an Error is too much. > See constructor implementation for: > http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/src/java/org/apache/lucene/analysis/TokenStream.java?view=markup -- This message is automatically generated by JIRA. 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-3426) optimizer for n-gram PhraseQuery
[
https://issues.apache.org/jira/browse/LUCENE-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103775#comment-13103775
]
Michael McCandless commented on LUCENE-3426:
Patch looks great! What a nice opto :)
> optimizer for n-gram PhraseQuery
>
>
> Key: LUCENE-3426
> URL: https://issues.apache.org/jira/browse/LUCENE-3426
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
>Reporter: Koji Sekiguchi
>Priority: Trivial
> Attachments: LUCENE-3426.patch, LUCENE-3426.patch, LUCENE-3426.patch,
> LUCENE-3426.patch, LUCENE-3426.patch, PerfTest.java, PerfTest.java
>
>
> If 2-gram is used and the length of query string is 4, for example q="ABCD",
> QueryParser generates (when autoGeneratePhraseQueries is true)
> PhraseQuery("AB BC CD") with slop 0. But it can be optimized PhraseQuery("AB
> CD") with appropriate positions.
> The idea came from the Japanese paper "N.M-gram: Implementation of Inverted
> Index Using N-gram with Hash Values" by Mikio Hirabayashi, et al. (The main
> theme of the paper is different from the idea that I'm using here, though)
--
This message is automatically generated by JIRA.
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-2755) StreamingUpdateSolrServer is hard-coded to write XML data. It should integrate the RequestWriter API so that it can be used to send binary update payloads.
[ https://issues.apache.org/jira/browse/SOLR-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103770#comment-13103770 ] Patrick Sauts commented on SOLR-2755: - It is more a buffered asynchronous updater than a real streaming updater. > StreamingUpdateSolrServer is hard-coded to write XML data. It should > integrate the RequestWriter API so that it can be used to send binary update > payloads. > --- > > Key: SOLR-2755 > URL: https://issues.apache.org/jira/browse/SOLR-2755 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 3.3 >Reporter: Patrick Sauts > Labels: patch > Fix For: 3.4 > > Attachments: patch-StreamingUpdateSolrServer.txt > > > The aim of this patch is to use the RequestWriter API with > StreamingUpdateSolrServer. -- This message is automatically generated by JIRA. 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-3426) optimizer for n-gram PhraseQuery
[
https://issues.apache.org/jira/browse/LUCENE-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103750#comment-13103750
]
Robert Muir commented on LUCENE-3426:
-
I think I agree Koji, the patch looks good.
Though we should be able to keep PhraseQuery's internal members 'private' since
NGramPhraseQuery now uses getter methods to access positions, terms, slop ?
> optimizer for n-gram PhraseQuery
>
>
> Key: LUCENE-3426
> URL: https://issues.apache.org/jira/browse/LUCENE-3426
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
>Reporter: Koji Sekiguchi
>Priority: Trivial
> Attachments: LUCENE-3426.patch, LUCENE-3426.patch, LUCENE-3426.patch,
> LUCENE-3426.patch, LUCENE-3426.patch, PerfTest.java, PerfTest.java
>
>
> If 2-gram is used and the length of query string is 4, for example q="ABCD",
> QueryParser generates (when autoGeneratePhraseQueries is true)
> PhraseQuery("AB BC CD") with slop 0. But it can be optimized PhraseQuery("AB
> CD") with appropriate positions.
> The idea came from the Japanese paper "N.M-gram: Implementation of Inverted
> Index Using N-gram with Hash Values" by Mikio Hirabayashi, et al. (The main
> theme of the paper is different from the idea that I'm using here, though)
--
This message is automatically generated by JIRA.
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-3426) optimizer for n-gram PhraseQuery
[
https://issues.apache.org/jira/browse/LUCENE-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated LUCENE-3426:
---
Attachment: LUCENE-3426.patch
New patch. I added equals/hashCode in the patch.
I think it is too complex to apply optimization to MultiPhraseQuery, so I'd
like to stick with PhraseQuery in the patch.
> optimizer for n-gram PhraseQuery
>
>
> Key: LUCENE-3426
> URL: https://issues.apache.org/jira/browse/LUCENE-3426
> Project: Lucene - Java
> Issue Type: Improvement
> Components: core/search
>Reporter: Koji Sekiguchi
>Priority: Trivial
> Attachments: LUCENE-3426.patch, LUCENE-3426.patch, LUCENE-3426.patch,
> LUCENE-3426.patch, LUCENE-3426.patch, PerfTest.java, PerfTest.java
>
>
> If 2-gram is used and the length of query string is 4, for example q="ABCD",
> QueryParser generates (when autoGeneratePhraseQueries is true)
> PhraseQuery("AB BC CD") with slop 0. But it can be optimized PhraseQuery("AB
> CD") with appropriate positions.
> The idea came from the Japanese paper "N.M-gram: Implementation of Inverted
> Index Using N-gram with Hash Values" by Mikio Hirabayashi, et al. (The main
> theme of the paper is different from the idea that I'm using here, though)
--
This message is automatically generated by JIRA.
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-3425) NRT Caching Dir to allow for exact memory usage, better buffer allocation and "global" cross indices control
[ https://issues.apache.org/jira/browse/LUCENE-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103723#comment-13103723 ] Michael McCandless commented on LUCENE-3425: Actually, NRTCachingDir does explicitly control the RAM usage in that if its cache is using too much RAM then the next createOutput will go straight to disk. The one thing it does not do is evict the created files after they close. So, if you flush a big segment in IW, then NRTCachingDir will keep those files in RAM even though its now over-budget. (But the next segment to flush will go straight to disk). I think this isn't that big a problem in practice; ie, as long as you set your IW RAM buffer to something not too large, or you ensure you are opening a new NRT reader often enough that the accumulated docs won't create a very large segment, then the excess RAM used by NRTCachingDir will be bounded. Still it would be nice to fix it so it evicts the files that set it over, such that it's always below the budget once the outputs is closed. And I agree we should make it possible to have a single pool for accounting purposes, so you can share this pool across multiple NRTCachingDirs (and other things that use RAM). > NRT Caching Dir to allow for exact memory usage, better buffer allocation and > "global" cross indices control > > > Key: LUCENE-3425 > URL: https://issues.apache.org/jira/browse/LUCENE-3425 > Project: Lucene - Java > Issue Type: Improvement > Components: core/index >Reporter: Shay Banon > > A discussion on IRC raised several improvements that can be made to NRT > caching dir. Some of the problems it currently has are: > 1. Not explicitly controlling the memory usage, which can result in overusing > memory (for example, large new segments being committed because refreshing is > too far behind). > 2. Heap fragmentation because of constant allocation of (probably promoted to > old gen) byte buffers. > 3. Not being able to control the memory usage across indices for multi index > usage within a single JVM. > A suggested solution (which still needs to be ironed out) is to have a > BufferAllocator that controls allocation of byte[], and allow to return > unused byte[] to it. It will have a cap on the size of memory it allows to be > allocated. > The NRT caching dir will use the allocator, which can either be provided (for > usage across several indices) or created internally. The caching dir will > also create a wrapped IndexOutput, that will flush to the main dir if the > allocator can no longer provide byte[] (exhausted). > When a file is "flushed" from the cache to the main directory, it will return > all the currently allocated byte[] to the BufferAllocator to be reused by > other "files". -- This message is automatically generated by JIRA. 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-MAVEN] Lucene-Solr-Maven-trunk #239: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/239/ 1 tests failed. FAILED: org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testCommitWithin Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:396) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:363) at org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testCommitWithin(ExtractingRequestHandlerTest.java:306) 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:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:148) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) 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:616) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at $Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='1'] xml response was: 00 request was:start=0&q=id:one&qt=standard&rows=20&version=2.2 at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:389) ... 36 more Build Log (for compile errors): [...truncated 24297 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3167) Make lucene/solr a OSGI bundle through Ant
[ https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103709#comment-13103709 ] Luca Stancapiano commented on LUCENE-3167: -- it takes time because the bndlib is tied to the compilation of the sources. bndlib navigates recursively in the classpath of each module. More the dependencies are lot, more time is used. It is important to create the list of all the dependent classes > Make lucene/solr a OSGI bundle through Ant > -- > > Key: LUCENE-3167 > URL: https://issues.apache.org/jira/browse/LUCENE-3167 > Project: Lucene - Java > Issue Type: New Feature > Environment: bndtools >Reporter: Luca Stancapiano > Attachments: LUCENE-3167.patch, LUCENE-3167.patch, > lucene_trunk.patch, lucene_trunk.patch > > > We need to make a bundle thriugh Ant, so the binary can be published and no > more need the download of the sources. Actually to get a OSGI bundle we need > to use maven tools and build the sources. Here the reference for the creation > of the OSGI bundle through Maven: > https://issues.apache.org/jira/browse/LUCENE-1344 > Bndtools could be used inside Ant -- This message is automatically generated by JIRA. 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-3167) Make lucene/solr a OSGI bundle through Ant
[ https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103682#comment-13103682 ] Robert Muir commented on LUCENE-3167: - Steven and I got to the bottom of this: the issue was the ant license files in lucene/lib. These have a ® sign encoded in ISO-8859-1. > Make lucene/solr a OSGI bundle through Ant > -- > > Key: LUCENE-3167 > URL: https://issues.apache.org/jira/browse/LUCENE-3167 > Project: Lucene - Java > Issue Type: New Feature > Environment: bndtools >Reporter: Luca Stancapiano > Attachments: LUCENE-3167.patch, LUCENE-3167.patch, > lucene_trunk.patch, lucene_trunk.patch > > > We need to make a bundle thriugh Ant, so the binary can be published and no > more need the download of the sources. Actually to get a OSGI bundle we need > to use maven tools and build the sources. Here the reference for the creation > of the OSGI bundle through Maven: > https://issues.apache.org/jira/browse/LUCENE-1344 > Bndtools could be used inside Ant -- This message is automatically generated by JIRA. 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] Lucene-Solr-tests-only-3.x-java7 - Build # 437 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/437/ 1 tests failed. REGRESSION: org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest.testMultiThreaded Error Message: java.lang.AssertionError: Some threads threw uncaught exceptions! Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:540) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:96) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) at org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:568) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:512) Build Log (for compile errors): [...truncated 14601 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3167) Make lucene/solr a OSGI bundle through Ant
[ https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103671#comment-13103671 ] Steven Rowe commented on LUCENE-3167: - bq. Ouch: any idea why it takes so long? I think adding 153 seconds to the compilation time is very painful for developers. AFAICT, the bnd tool visits everything in the classpath and records everything it finds in the manifest. Luca, maybe you can add some more info here? bq. FYI: I had encoding problems with the patch (its ISO-8859-1 not UTF-8?) How did you experience these problems? I generated it using (Cygwin's) svn diff on Windows 7. I skimmed the patch and didn't see any above-ASCII chars. The patch applies without complaint using Cygwin's patch. > Make lucene/solr a OSGI bundle through Ant > -- > > Key: LUCENE-3167 > URL: https://issues.apache.org/jira/browse/LUCENE-3167 > Project: Lucene - Java > Issue Type: New Feature > Environment: bndtools >Reporter: Luca Stancapiano > Attachments: LUCENE-3167.patch, LUCENE-3167.patch, > lucene_trunk.patch, lucene_trunk.patch > > > We need to make a bundle thriugh Ant, so the binary can be published and no > more need the download of the sources. Actually to get a OSGI bundle we need > to use maven tools and build the sources. Here the reference for the creation > of the OSGI bundle through Maven: > https://issues.apache.org/jira/browse/LUCENE-1344 > Bndtools could be used inside Ant -- This message is automatically generated by JIRA. 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-3167) Make lucene/solr a OSGI bundle through Ant
[
https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103666#comment-13103666
]
Robert Muir commented on LUCENE-3167:
-
{quote}
I measured OSGI-compliant manifest creation time for all 38 non-example jars
(and the Solr war), and the total cost was 153.5 seconds, which is about 4
seconds per bundle on average.
{quote}
Ouch: any idea why it takes so long? I think adding 153 seconds to the
compilation time is very painful for developers.
FYI: I had encoding problems with the patch (its ISO-8859-1 not UTF-8?)
> Make lucene/solr a OSGI bundle through Ant
> --
>
> Key: LUCENE-3167
> URL: https://issues.apache.org/jira/browse/LUCENE-3167
> Project: Lucene - Java
> Issue Type: New Feature
> Environment: bndtools
>Reporter: Luca Stancapiano
> Attachments: LUCENE-3167.patch, LUCENE-3167.patch,
> lucene_trunk.patch, lucene_trunk.patch
>
>
> We need to make a bundle thriugh Ant, so the binary can be published and no
> more need the download of the sources. Actually to get a OSGI bundle we need
> to use maven tools and build the sources. Here the reference for the creation
> of the OSGI bundle through Maven:
> https://issues.apache.org/jira/browse/LUCENE-1344
> Bndtools could be used inside Ant
--
This message is automatically generated by JIRA.
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-3167) Make lucene/solr a OSGI bundle through Ant
[ https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3167: Attachment: LUCENE-3167.patch Here's the correct patch. > Make lucene/solr a OSGI bundle through Ant > -- > > Key: LUCENE-3167 > URL: https://issues.apache.org/jira/browse/LUCENE-3167 > Project: Lucene - Java > Issue Type: New Feature > Environment: bndtools >Reporter: Luca Stancapiano > Attachments: LUCENE-3167.patch, LUCENE-3167.patch, > lucene_trunk.patch, lucene_trunk.patch > > > We need to make a bundle thriugh Ant, so the binary can be published and no > more need the download of the sources. Actually to get a OSGI bundle we need > to use maven tools and build the sources. Here the reference for the creation > of the OSGI bundle through Maven: > https://issues.apache.org/jira/browse/LUCENE-1344 > Bndtools could be used inside Ant -- This message is automatically generated by JIRA. 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-3167) Make lucene/solr a OSGI bundle through Ant
[ https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3167: Attachment: (was: LUCENE-3406.patch) > Make lucene/solr a OSGI bundle through Ant > -- > > Key: LUCENE-3167 > URL: https://issues.apache.org/jira/browse/LUCENE-3167 > Project: Lucene - Java > Issue Type: New Feature > Environment: bndtools >Reporter: Luca Stancapiano > Attachments: LUCENE-3167.patch, LUCENE-3167.patch, > lucene_trunk.patch, lucene_trunk.patch > > > We need to make a bundle thriugh Ant, so the binary can be published and no > more need the download of the sources. Actually to get a OSGI bundle we need > to use maven tools and build the sources. Here the reference for the creation > of the OSGI bundle through Maven: > https://issues.apache.org/jira/browse/LUCENE-1344 > Bndtools could be used inside Ant -- This message is automatically generated by JIRA. 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-3167) Make lucene/solr a OSGI bundle through Ant
[ https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3167: Attachment: LUCENE-3406.patch This patch fixes various problems with the created manifests. I measured OSGI-compliant manifest creation time for all 38 non-example jars (and the Solr war), and the total cost was 153.5 seconds, which is about 4 seconds per bundle on average. I also measured manifest creation time without the OSGI stuff, and it's basically instantaneous: single-digit milliseconds on average per jar/war. Maybe 4 seconds per jar/war is okay? I'll wait a day or two before I commit so people can object or suggest alternatives. One alternative to always building the OSGI manifests would be to only build them when preparing a release. > Make lucene/solr a OSGI bundle through Ant > -- > > Key: LUCENE-3167 > URL: https://issues.apache.org/jira/browse/LUCENE-3167 > Project: Lucene - Java > Issue Type: New Feature > Environment: bndtools >Reporter: Luca Stancapiano > Attachments: LUCENE-3167.patch, LUCENE-3406.patch, > lucene_trunk.patch, lucene_trunk.patch > > > We need to make a bundle thriugh Ant, so the binary can be published and no > more need the download of the sources. Actually to get a OSGI bundle we need > to use maven tools and build the sources. Here the reference for the creation > of the OSGI bundle through Maven: > https://issues.apache.org/jira/browse/LUCENE-1344 > Bndtools could be used inside Ant -- This message is automatically generated by JIRA. 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] (SOLR-2759) Remove the need for EDismax's ExtendedAnalyzer
[ https://issues.apache.org/jira/browse/SOLR-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Male updated SOLR-2759: - Attachment: SOLR-2759.patch Simple patch which does what is described above. > Remove the need for EDismax's ExtendedAnalyzer > -- > > Key: SOLR-2759 > URL: https://issues.apache.org/jira/browse/SOLR-2759 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Chris Male > Attachments: SOLR-2759.patch > > > ExtendedDisMaxQParserPlugin.ExtendedAnalyzer cannot be ported over to being > reusable due to its support for deciding at runtime whether stopwords should > be filtered or not. > One way to resolve this is to maintain 2 lazy-initialized Map Analyzer> in the ExtendedSolrQueryParser, one with the stopword filtering > Analyzers for fields, the other with no-stopword filtering Analyzers. Then > ExtendedSolrQueryParser can override the > QueryParserBase.newFieldQuery(Analyzer, String, String, boolean) and > substitute in the appropriate Analyzer based on the runtime behavior desired > at that time. > This will mean an ever so slight increase in memory consumption due to the 2 > maps, but will allow for reusability which will reduce memory consumption and > increase query throughput. -- This message is automatically generated by JIRA. 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-3429) improve build system when tests hang
[ https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103652#comment-13103652 ] Dawid Weiss commented on LUCENE-3429: - The tests with this patch hang on my mac and on linux box. On windows they crash the jvm... oh boy, what a joy. > improve build system when tests hang > > > Key: LUCENE-3429 > URL: https://issues.apache.org/jira/browse/LUCENE-3429 > Project: Lucene - Java > Issue Type: Test >Reporter: Robert Muir > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3429.patch, LUCENE-3429.patch > > > Currently, if tests hang in hudson it can go hung for days until we manually > kill it. > The problem is that when a hang happens its probably serious, what we want to > do (I think), is: > # time out the build. > # ensure we have enough debugging information to hopefully fix any hang. > So I think the ideal solution would be: > # add a sysprop "-D" that LuceneTestCase respects, it could default to no > timeout at all (some value like zero). > # when a timeout is set, LuceneTestCase spawns an additional timer thread for > the test class? method? > # if the timeout is exceeded, LuceneTestCase dumps all thread/stack > information, random seed information to hopefully reproduce the hang, and > fails the test. > # nightly builds would pass some reasonable -D for each test. > separately, I think we should have an "ant-level" timeout for the whole > build, in case it goes completely crazy (e.g. jvm completely hangs or > something else), just as an additional safety. -- This message is automatically generated by JIRA. 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-2759) Remove the need for EDismax's ExtendedAnalyzer
[ https://issues.apache.org/jira/browse/SOLR-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103650#comment-13103650 ] Chris Male commented on SOLR-2759: -- Actually, we only need the 1 Map which will contain the no-stopword filtering Analyzers, since we can just retrieve the other directly from the Schema (since it doesn't need to be altered). > Remove the need for EDismax's ExtendedAnalyzer > -- > > Key: SOLR-2759 > URL: https://issues.apache.org/jira/browse/SOLR-2759 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Chris Male > > ExtendedDisMaxQParserPlugin.ExtendedAnalyzer cannot be ported over to being > reusable due to its support for deciding at runtime whether stopwords should > be filtered or not. > One way to resolve this is to maintain 2 lazy-initialized Map Analyzer> in the ExtendedSolrQueryParser, one with the stopword filtering > Analyzers for fields, the other with no-stopword filtering Analyzers. Then > ExtendedSolrQueryParser can override the > QueryParserBase.newFieldQuery(Analyzer, String, String, boolean) and > substitute in the appropriate Analyzer based on the runtime behavior desired > at that time. > This will mean an ever so slight increase in memory consumption due to the 2 > maps, but will allow for reusability which will reduce memory consumption and > increase query throughput. -- This message is automatically generated by JIRA. 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-2758) ConcurrentLRUCache should move from common/util to solr/util
[ https://issues.apache.org/jira/browse/SOLR-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103628#comment-13103628 ] David Smiley commented on SOLR-2758: I think both caches should go in the same package. These seem like a utility in nature so I think a util package is more appropriate. Sorry about the patch formatting. This patch is trivial enough that someone could do it manually. > ConcurrentLRUCache should move from common/util to solr/util > > > Key: SOLR-2758 > URL: https://issues.apache.org/jira/browse/SOLR-2758 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 3.3 >Reporter: David Smiley >Priority: Minor > Attachments: SOLR-2758_move_ConcurrentLRUCache.patch > > > There is exactly one small dependency that the SolrJ jar has to lucene-core > and that is indirectly via ConcurrentLRUCache which is in common/util. SolrJ > doesn't even use this cache but it's there any way. Attached is a patch for > the move. It also removes the lucene-core dependency that the SolrJ maven > pom.xml has on lucene-core. > Steve Rowe agrees: > https://issues.apache.org/jira/browse/SOLR-2756?focusedCommentId=13103103&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13103103 -- This message is automatically generated by JIRA. 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-2759) Remove the need for EDismax's ExtendedAnalyzer
Remove the need for EDismax's ExtendedAnalyzer -- Key: SOLR-2759 URL: https://issues.apache.org/jira/browse/SOLR-2759 Project: Solr Issue Type: Improvement Components: search Reporter: Chris Male ExtendedDisMaxQParserPlugin.ExtendedAnalyzer cannot be ported over to being reusable due to its support for deciding at runtime whether stopwords should be filtered or not. One way to resolve this is to maintain 2 lazy-initialized Map in the ExtendedSolrQueryParser, one with the stopword filtering Analyzers for fields, the other with no-stopword filtering Analyzers. Then ExtendedSolrQueryParser can override the QueryParserBase.newFieldQuery(Analyzer, String, String, boolean) and substitute in the appropriate Analyzer based on the runtime behavior desired at that time. This will mean an ever so slight increase in memory consumption due to the 2 maps, but will allow for reusability which will reduce memory consumption and increase query throughput. -- This message is automatically generated by JIRA. 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
[Lucene.Net] possible infinite loop bug in portuguese snowball stemmer?
Are there any known issues with snowball stemmers (portuguese in particular) going into some infinite loop? I have a problem that happens on a recurring basis where IndexWriter locks up on AddDocument and never returns (it has taken up to 3 days before we realize it), requiring manual killing of the process. It seems to happen only on portuguese documents from what I can tell so far, and the stack trace when thread is aborted is always as follows: System.Threading.ThreadAbortException: Thread was being aborted. at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeType typeOwner) at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at Lucene.Net.Analysis.Snowball.SnowballFilter.Next() System.SystemException: System.Threading.ThreadAbortException: Thread was being aborted. at System.RuntimeMethodHandle._InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeType typeOwner) at System.RuntimeMethodHandle.InvokeMethodFast(IRuntimeMethodInfo method, Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeType typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at Lucene.Net.Analysis.Snowball.SnowballFilter.Next() at Lucene.Net.Analysis.Snowball.SnowballFilter.Next() at Lucene.Net.Analysis.TokenStream.IncrementToken() at Lucene.Net.Index.DocInverterPerField.ProcessFields(Fieldable[] fields, Int32 count) at Lucene.Net.Index.DocFieldProcessorPerThread.ProcessDocument() at Lucene.Net.Index.DocumentsWriter.UpdateDocument(Document doc, Analyzer analyzer, Term delTerm) at Lucene.Net.Index.IndexWriter.AddDocument(Document doc, Analyzer analyzer) Is there another list of contrib/snowball issues? I have not been able to reproduce a small test case yet however. Have there been any such issues with stemmers in the past? Thanks, Bob
[jira] [Commented] (SOLR-2722) If hostPort is not specified, we should just look for jetty.port - and if that is not found, fall back to the default of 8983.
[
https://issues.apache.org/jira/browse/SOLR-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103621#comment-13103621
]
Mark Miller commented on SOLR-2722:
---
After discussing again with Hossman some time back, I'm going to just put
${jetty.port} as the default value in Solr.xml I think.
> If hostPort is not specified, we should just look for jetty.port - and if
> that is not found, fall back to the default of 8983.
> --
>
> Key: SOLR-2722
> URL: https://issues.apache.org/jira/browse/SOLR-2722
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Trivial
> Fix For: 4.0
>
>
> Originally we didn't rely on jetty.port as it's container specific - but
> rather than require you specify the port twice in this case, we should simply
> use jetty.port when it's there.
> The example from the SolrCloud wiki:
> java -Djetty.port=7574 -DhostPort=7574 -DzkHost=localhost:9983 -jar start.jar
> instead becomes:
> java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar
> We should also look at simply specifying the shard name in this example case
> (see the solrwiki examples) by system property rather than asking the user to
> edit solr.xml.
--
This message is automatically generated by JIRA.
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-1897) The data dir from the core descriptor should override the data dir from the solrconfig.xml rather than the other way round
[ https://issues.apache.org/jira/browse/SOLR-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1897. --- Resolution: Fixed I've added the changes entry. > The data dir from the core descriptor should override the data dir from the > solrconfig.xml rather than the other way round > -- > > Key: SOLR-1897 > URL: https://issues.apache.org/jira/browse/SOLR-1897 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-1897.patch > > -- This message is automatically generated by JIRA. 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-3431) Make QueryAutoStopWordAnalyzer immutable and reusable
[ https://issues.apache.org/jira/browse/LUCENE-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Male updated LUCENE-3431: --- Attachment: LUCENE-3431-3x.patch Patch for 3x with deprecations. > Make QueryAutoStopWordAnalyzer immutable and reusable > - > > Key: LUCENE-3431 > URL: https://issues.apache.org/jira/browse/LUCENE-3431 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/analysis >Reporter: Chris Male > Attachments: LUCENE-3431-3x.patch, LUCENE-3431-trunk.patch > > > Currently QueryAutoStopWordAnalyzer allows its list of stop words to be > changed after instantiation through its addStopWords() methods. This stops > the Analyzer from being reusable since it must instantiate its StopFilters > every time. > Having these methods means that although the Analyzer can be instantiated > once and reused between IndexReaders, the actual analysis stack is not > reusable (which is probably the more expensive part). > So lets change the Analyzer so that its stop words are set at instantiation > time, facilitating reuse. -- This message is automatically generated by JIRA. 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: update solr.xml error after create a new core
When is your build from? There was a bug fixed a couple weeks ago that sounds like this issue. On Sep 13, 2011, at 4:04 AM, kelong wrote: > Hi > I create a new core dynamically with > > http://localhost:8983/solr/admin/cores?action=CREATE&name=mycore&collection=collection1&shard=shard2&instanceDir=.&dataDir=example2\solr\data > > Before creating the solr.xml is > > > > > > > After creating, the solr.xml becomes > > >zkClientTimeout="1" hostPort="8983" hostContext="solr"> > dataDir="\example2\solr\data" collection="collection1"/> > dataDir="\example2\solr\data" collection="collection1"/> > > > > the new core is added twice and the old one information is missed. Can any > one exmplain why this happens? Is there any error in my operation? > > Thanks! - Mark Miller lucidimagination.com 2011.lucene-eurocon.org | Oct 17-20 | Barcelona - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3432) TieredMergePolicy expungeDeletes should not enforce maxMergedSegmentMB
[ https://issues.apache.org/jira/browse/LUCENE-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-3432. Resolution: Fixed Thanks v.sevel! > TieredMergePolicy expungeDeletes should not enforce maxMergedSegmentMB > -- > > Key: LUCENE-3432 > URL: https://issues.apache.org/jira/browse/LUCENE-3432 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3432.patch > > -- This message is automatically generated by JIRA. 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-3432) TieredMergePolicy expungeDeletes should not enforce maxMergedSegmentMB
[ https://issues.apache.org/jira/browse/LUCENE-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-3432: --- Attachment: LUCENE-3432.patch > TieredMergePolicy expungeDeletes should not enforce maxMergedSegmentMB > -- > > Key: LUCENE-3432 > URL: https://issues.apache.org/jira/browse/LUCENE-3432 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3432.patch > > -- This message is automatically generated by JIRA. 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] Lucene-trunk - Build # 1675 - Still Failing
Build: https://builds.apache.org/job/Lucene-trunk/1675/ 4 tests failed. REGRESSION: org.apache.lucene.index.TestNRTThreads.testNRTThreads Error Message: this writer hit an OutOfMemoryError; cannot commit Stack Trace: java.lang.IllegalStateException: this writer hit an OutOfMemoryError; cannot commit at org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:2746) at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2896) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2878) at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2862) at org.apache.lucene.index.TestNRTThreads.testNRTThreads(TestNRTThreads.java:357) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:148) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) REGRESSION: org.apache.lucene.util.packed.TestPackedInts.testIntOverflow Error Message: Java heap space Stack Trace: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.util.packed.Packed32.(Packed32.java:120) at org.apache.lucene.util.packed.TestPackedInts.testIntOverflow(TestPackedInts.java:265) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:148) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) FAILED: org.apache.lucene.index.TestTermsEnum.testIntersectRandom Error Message: Java heap space Stack Trace: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:128) at org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:28) at org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:134) at org.apache.lucene.index.TestTermsEnum.testIntersectRandom(TestTermsEnum.java:266) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:148) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) FAILED: org.apache.lucene.util.automaton.TestCompiledAutomaton.testRandom Error Message: Java heap space Stack Trace: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:128) at org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:28) at org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:134) at org.apache.lucene.util.automaton.TestCompiledAutomaton.build(TestCompiledAutomaton.java:39) at org.apache.lucene.util.automaton.TestCompiledAutomaton.testTerms(TestCompiledAutomaton.java:55) at org.apache.lucene.util.automaton.TestCompiledAutomaton.testRandom(TestCompiledAutomaton.java:101) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:148) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) Build Log (for compile errors): [...truncated 13186 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3432) TieredMergePolicy expungeDeletes should not enforce maxMergedSegmentMB
TieredMergePolicy expungeDeletes should not enforce maxMergedSegmentMB -- Key: LUCENE-3432 URL: https://issues.apache.org/jira/browse/LUCENE-3432 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.5, 4.0 -- This message is automatically generated by JIRA. 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: where is the SOLR_HOME
You only specify the JARs from one place or the other... either in solrconfig.xml's directives, or (not and!) the /lib directory. Erik On Sep 13, 2011, at 01:44 , ahmad ajiloo wrote: > I created "example/solr/lib" directory and copied jar files to it and added > this expressions in solrconfig.xml : > > > (for assurance!!!) > > but it doesn't work and still has those errors ! > > > On Mon, Sep 12, 2011 at 4:31 PM, Erik Hatcher wrote: > Yes, SOLR_HOME in this case, if you're running the example application, in > example/solr. There's no lib/ directory there by default, just create it > yourself. > > You can also add directives in your solrconfig.xml (you'll see this > documented in comments in the example config). > >Erik > > > > On Sep 12, 2011, at 07:51 , ahmad ajiloo wrote: > > > Hi > > In this page said: > > "Note: to use this filter, see solr/contrib/analysis-extras/README.txt for > > instructions on which jars you need to add to your SOLR_HOME/lib " > > I can't find "SOLR_HOME/lib" ! > > Is there: "apache-solr-3.3.0\example\solr" ? there is no directory which > > name is lib > > or: "apache-solr-3.3.0\" ? there is no directory which name is lib > > > > or : "apache-solr-3.3.0\example" ? there is a "lib" directory. I copied 4 > > libraries exist in "solr/contrib/analysis-extras/" to > > "apache-solr-3.3.0\example\lib" but some errors exist in loading page > > "http://localhost:8983/solr/admin"; like: > > "org.apache.solr.common.SolrException: Error loading class > > 'solr.ICUNormalizer2FilterFactory' " > > > > thanks a lot > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2066) Search Grouping: support distributed search
[
https://issues.apache.org/jira/browse/SOLR-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103573#comment-13103573
]
Jasper van Veghel commented on SOLR-2066:
-
Apologies for continuing to bring up issues ;-) but it seems that facets also
cause problems with empty result sets. Modify the TestDistributedGrouping test
as follows and you'll see:
{code}// Test distributed grouping with empty indices
query("q", "*:*", "rows", 100, "fl", "id," + i1, "group", "true",
"group.field", i1, "group.limit", 10, "sort", i1 + " asc, id asc");
query("q", "*:*", "rows", 100, "fl", "id," + i1, "group", "true",
"group.field", i1, "group.limit", 10, "sort", i1 + " asc, id asc",
"hl","true","hl.fl",t1);
query("q", "*:*", "rows", 100, "fl", "id," + i1, "group", "true",
"group.field", i1, "group.limit", 10, "sort", i1 + " asc, id asc", "facet",
"true", "facet.field", t1);{code}
Stacktrace:
{code}[junit] Caused by: org.apache.solr.common.SolrException: null
java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:409)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1407)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:248)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
null java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:409)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1407)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.{code}
> Search Grouping: support distributed search
> ---
>
> Key: SOLR-2066
> URL: https://issues.apache.org/jira/browse/SOLR-2066
> Project: Solr
> Issue Type: Sub-task
>Reporter: Yonik Seeley
> Fix For: 3.5, 4.0
>
> Attachments: SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch,
> SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch,
> SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch, SOLR-2066.patch,
> SOLR-2066.patch
>
>
> Support distributed field collapsing / search grouping.
--
This message is automatically generated by JIRA.
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-944) Solr EmbeddedSolrServer Client
[ https://issues.apache.org/jira/browse/SOLR-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103536#comment-13103536 ] Goutham commented on SOLR-944: -- "is it possible to handle the read/search by webinterface, and all write from java-client(with out http)EmbeddedSolrServer " for solr multicore support? How ti issue commit to jetty web app also ? whether i need to modify inside source? i am using solr3.1.0. > Solr EmbeddedSolrServer Client > -- > > Key: SOLR-944 > URL: https://issues.apache.org/jira/browse/SOLR-944 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.3 > Environment: Java 1,5, Solr 1.3 >Reporter: doss > Original Estimate: 24h > Remaining Estimate: 24h > > We have created a Java EmbeddedSolrServer Client Code, I can able to add, > delete, update the Solr content - At the same time i cant able to search the > updated conente from the Running Solr client(jetty) web interface. > My requirement is, All search need to happen from/by running web Solr(jetty, > 8983) and all write should happened from Java client code. > Both(jeety and javaclient) are using 'Core0' as core name, and both data > directory, schema, solrconfig are same. - is there any fix available?? > is it possible to handle the read/search by webinterface, and all write from > java-client(with out http) -- This message is automatically generated by JIRA. 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: where is the SOLR_HOME
Did you try following: I think the path you specify here is relative to your SOLR_HOME directory, which in example's case would be "example/solr " directory. Also, the "lib" directory created by you exists at "example/solr/lib/", so using above lib directive should solve the problem. Hope that helps! ~Mohit On Tue, Sep 13, 2011 at 11:14 AM, ahmad ajiloo wrote: > I created "example/solr/lib" directory and copied jar files to it and added > this expressions in solrconfig.xml : > > > (for assurance!!!) > > but it doesn't work and still has those errors ! > > > > On Mon, Sep 12, 2011 at 4:31 PM, Erik Hatcher wrote: > >> Yes, SOLR_HOME in this case, if you're running the example application, in >> example/solr. There's no lib/ directory there by default, just create it >> yourself. >> >> You can also add directives in your solrconfig.xml (you'll see this >> documented in comments in the example config). >> >>Erik >> >> >> >> On Sep 12, 2011, at 07:51 , ahmad ajiloo wrote: >> >> > Hi >> > In this page said: >> > "Note: to use this filter, see solr/contrib/analysis-extras/README.txt >> for instructions on which jars you need to add to your SOLR_HOME/lib " >> > I can't find "SOLR_HOME/lib" ! >> > Is there: "apache-solr-3.3.0\example\solr" ? there is no directory which >> name is lib >> > or: "apache-solr-3.3.0\" ? there is no directory which name is lib >> > >> > or : "apache-solr-3.3.0\example" ? there is a "lib" directory. I copied >> 4 libraries exist in "solr/contrib/analysis-extras/" to >> "apache-solr-3.3.0\example\lib" but some errors exist in loading page " >> http://localhost:8983/solr/admin"; like: >> > "org.apache.solr.common.SolrException: Error loading class >> 'solr.ICUNormalizer2FilterFactory' " >> > >> > thanks a lot >> > >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >
[jira] [Updated] (LUCENE-3431) Make QueryAutoStopWordAnalyzer immutable and reusable
[ https://issues.apache.org/jira/browse/LUCENE-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Male updated LUCENE-3431: --- Attachment: LUCENE-3431-trunk.patch Patch against trunk (no deprecations). All functionality is moved to constructors. Tests are cleaned up and renamed. Will make a 3x patch with deprecations. > Make QueryAutoStopWordAnalyzer immutable and reusable > - > > Key: LUCENE-3431 > URL: https://issues.apache.org/jira/browse/LUCENE-3431 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/analysis >Reporter: Chris Male > Attachments: LUCENE-3431-trunk.patch > > > Currently QueryAutoStopWordAnalyzer allows its list of stop words to be > changed after instantiation through its addStopWords() methods. This stops > the Analyzer from being reusable since it must instantiate its StopFilters > every time. > Having these methods means that although the Analyzer can be instantiated > once and reused between IndexReaders, the actual analysis stack is not > reusable (which is probably the more expensive part). > So lets change the Analyzer so that its stop words are set at instantiation > time, facilitating reuse. -- This message is automatically generated by JIRA. 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: [VOTE] Release Lucene/Solr 3.4.0, RC1
This VOTE has passed! I'll announce/publish. Mike McCandless http://blog.mikemccandless.com On Mon, Sep 12, 2011 at 5:11 PM, Yonik Seeley wrote: > On Fri, Sep 9, 2011 at 12:06 PM, Michael McCandless > wrote: >> Please vote to release the RC1 artifacts at: >> >> https://people.apache.org/~mikemccand/staging_area/lucene-solr-3.4.0-RC1-rev1167142 >> >> as Lucene 3.4.0 and Solr 3.4.0. > > +1 > > -Yonik > http://www.lucene-eurocon.com - The Lucene/Solr User Conference > > - > 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
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 10518 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/10518/ No tests ran. Build Log (for compile errors): [...truncated 1183 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3431) Make QueryAutoStopWordAnalyzer immutable and reusable
Make QueryAutoStopWordAnalyzer immutable and reusable - Key: LUCENE-3431 URL: https://issues.apache.org/jira/browse/LUCENE-3431 Project: Lucene - Java Issue Type: Improvement Components: modules/analysis Reporter: Chris Male Currently QueryAutoStopWordAnalyzer allows its list of stop words to be changed after instantiation through its addStopWords() methods. This stops the Analyzer from being reusable since it must instantiate its StopFilters every time. Having these methods means that although the Analyzer can be instantiated once and reused between IndexReaders, the actual analysis stack is not reusable (which is probably the more expensive part). So lets change the Analyzer so that its stop words are set at instantiation time, facilitating reuse. -- This message is automatically generated by JIRA. 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
update solr.xml error after create a new core
Hi I create a new core dynamically with http://localhost:8983/solr/admin/cores?action=CREATE&name=mycore&collection=collection1&shard=shard2&instanceDir=.&dataDir=example2\solr\data Before creating the solr.xml is * * ** ** * * After creating, the solr.xml becomes the new core is added twice and the old one information is missed. Can any one exmplain why this happens? Is there any error in my operation? Thanks!
[jira] [Commented] (LUCENE-3429) improve build system when tests hang
[ https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103428#comment-13103428 ] Dawid Weiss commented on LUCENE-3429: - Right Interesting. Ok, I'll dig later on. > improve build system when tests hang > > > Key: LUCENE-3429 > URL: https://issues.apache.org/jira/browse/LUCENE-3429 > Project: Lucene - Java > Issue Type: Test >Reporter: Robert Muir > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3429.patch, LUCENE-3429.patch > > > Currently, if tests hang in hudson it can go hung for days until we manually > kill it. > The problem is that when a hang happens its probably serious, what we want to > do (I think), is: > # time out the build. > # ensure we have enough debugging information to hopefully fix any hang. > So I think the ideal solution would be: > # add a sysprop "-D" that LuceneTestCase respects, it could default to no > timeout at all (some value like zero). > # when a timeout is set, LuceneTestCase spawns an additional timer thread for > the test class? method? > # if the timeout is exceeded, LuceneTestCase dumps all thread/stack > information, random seed information to hopefully reproduce the hang, and > fails the test. > # nightly builds would pass some reasonable -D for each test. > separately, I think we should have an "ant-level" timeout for the whole > build, in case it goes completely crazy (e.g. jvm completely hangs or > something else), just as an additional safety. -- This message is automatically generated by JIRA. 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-3429) improve build system when tests hang
[ https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103417#comment-13103417 ] Robert Muir commented on LUCENE-3429: - I only mention it because interrupting threads in our tests caused jre crashes before, LuceneTestCase:784 :) > improve build system when tests hang > > > Key: LUCENE-3429 > URL: https://issues.apache.org/jira/browse/LUCENE-3429 > Project: Lucene - Java > Issue Type: Test >Reporter: Robert Muir > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3429.patch, LUCENE-3429.patch > > > Currently, if tests hang in hudson it can go hung for days until we manually > kill it. > The problem is that when a hang happens its probably serious, what we want to > do (I think), is: > # time out the build. > # ensure we have enough debugging information to hopefully fix any hang. > So I think the ideal solution would be: > # add a sysprop "-D" that LuceneTestCase respects, it could default to no > timeout at all (some value like zero). > # when a timeout is set, LuceneTestCase spawns an additional timer thread for > the test class? method? > # if the timeout is exceeded, LuceneTestCase dumps all thread/stack > information, random seed information to hopefully reproduce the hang, and > fails the test. > # nightly builds would pass some reasonable -D for each test. > separately, I think we should have an "ant-level" timeout for the whole > build, in case it goes completely crazy (e.g. jvm completely hangs or > something else), just as an additional safety. -- This message is automatically generated by JIRA. 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-3429) improve build system when tests hang
[ https://issues.apache.org/jira/browse/LUCENE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103413#comment-13103413 ] Dawid Weiss commented on LUCENE-3429: - I didn't check and this should be a no-issue, even when you call stop() because stop() is supposed to throw a ThreadDeathError at the current execution point. interrupt() doesn't do anything other than setting a thread flag (it does interrupt i/o and monitors, but not busy loops). I don't think it's what we want. I didn't check on linux/ macos yet, didn't have time. > improve build system when tests hang > > > Key: LUCENE-3429 > URL: https://issues.apache.org/jira/browse/LUCENE-3429 > Project: Lucene - Java > Issue Type: Test >Reporter: Robert Muir > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3429.patch, LUCENE-3429.patch > > > Currently, if tests hang in hudson it can go hung for days until we manually > kill it. > The problem is that when a hang happens its probably serious, what we want to > do (I think), is: > # time out the build. > # ensure we have enough debugging information to hopefully fix any hang. > So I think the ideal solution would be: > # add a sysprop "-D" that LuceneTestCase respects, it could default to no > timeout at all (some value like zero). > # when a timeout is set, LuceneTestCase spawns an additional timer thread for > the test class? method? > # if the timeout is exceeded, LuceneTestCase dumps all thread/stack > information, random seed information to hopefully reproduce the hang, and > fails the test. > # nightly builds would pass some reasonable -D for each test. > separately, I think we should have an "ant-level" timeout for the whole > build, in case it goes completely crazy (e.g. jvm completely hangs or > something else), just as an additional safety. -- This message is automatically generated by JIRA. 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
