Re: [JENKINS] Lucene-Solr-Tests-trunk-java7 - Build # 3705 - Still Failing
Very weird. On Mon, Feb 4, 2013 at 12:46 AM, Mark Miller wrote: > It looks like this thing hung doing a security check…. > > [junit4:junit4] 2> 21) Thread[id=499, > name=TEST-BasicDistributedZkTest.testDistribSearch-seed#[437C1ACFB7351B0A], > state=RUNNABLE, group=TGRP-BasicDistributedZkTest] > [junit4:junit4] 2>at > java.security.AccessController.getStackAccessControlContext(Native Method) > [junit4:junit4] 2>at > java.security.AccessController.checkPermission(AccessController.java:534) > [junit4:junit4] 2>at > java.lang.SecurityManager.checkPermission(SecurityManager.java:549) > [junit4:junit4] 2>at > java.util.concurrent.ThreadPoolExecutor.checkShutdownAccess(ThreadPoolExecutor.java:711) > [junit4:junit4] 2>at > java.util.concurrent.ThreadPoolExecutor.shutdownNow(ThreadPoolExecutor.java:1387) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4743) ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader)
[ https://issues.apache.org/jira/browse/LUCENE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Nacional updated LUCENE-4743: --- Affects Version/s: (was: 3.6.2) 3.6 > ComplexPhraseQuery highlight problem after rewriting using > ComplexPhraseQuery.rewrite(IndexReader) > -- > > Key: LUCENE-4743 > URL: https://issues.apache.org/jira/browse/LUCENE-4743 > Project: Lucene - Core > Issue Type: Bug > Components: core/search, modules/queryparser >Affects Versions: 3.6 >Reporter: Jason Nacional > Labels: complexqueryparser, newbie, queryparser > > Just want to ask an assistance using ComplexPhraseQuery. I mean, when it > comes to highlighting the hits are not correct. I also started using > ComplexPhraseQueryParser to support complex proximity searches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4743) ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader)
[ https://issues.apache.org/jira/browse/LUCENE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570020#comment-13570020 ] Jason Nacional commented on LUCENE-4743: I also have a question about rewriting ComplexPhraseQuery. Do I really need to always open an IndexReader? I mean, in our system, searching and viewing the hit document is a separate page. So what I'm doing to highlight terms (since I used ComplexPhraseQuery and it needs to be "rewritten") is to open an IndexReader. I hope you understand my concerns. And I apologize for so many questions. Thanks. > ComplexPhraseQuery highlight problem after rewriting using > ComplexPhraseQuery.rewrite(IndexReader) > -- > > Key: LUCENE-4743 > URL: https://issues.apache.org/jira/browse/LUCENE-4743 > Project: Lucene - Core > Issue Type: Bug > Components: core/search, modules/queryparser >Affects Versions: 3.6.2 >Reporter: Jason Nacional > Labels: complexqueryparser, newbie, queryparser > > Just want to ask an assistance using ComplexPhraseQuery. I mean, when it > comes to highlighting the hits are not correct. I also started using > ComplexPhraseQueryParser to support complex proximity searches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4393) 'Execute Query' in the dashboard does not build the url correctly
[ https://issues.apache.org/jira/browse/SOLR-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-4393: --- Assignee: Stefan Matheis (steffkes) > 'Execute Query' in the dashboard does not build the url correctly > - > > Key: SOLR-4393 > URL: https://issues.apache.org/jira/browse/SOLR-4393 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 >Reporter: Anand >Assignee: Stefan Matheis (steffkes) > > Recently upgraded to 4.1 and started seeing this issue since the upgrade. We > also went from single core to multiple core at the same time. > > Steps to reproduce > 1. Select a core from the dashboard. > 2. Select 'Query' > 3. Without changing anything, click 'Execture Query'. > Expected: 10 hits (or less depending on data indexed) displayed on the screen. > Observed: See response below. > http://localhost:8080/solr/coreName/select? > > > 0 name="QTime">0 numFound="0" start="0"> > > Issue: "http://localhost:8080/solr/coreName/select?"; is incomplete and > "q=*:*" is not appended to the url. > Tested on Firefox and Chrome and both suffer from this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4349) Admin UI - Query Interface does not work in IE
[ https://issues.apache.org/jira/browse/SOLR-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570001#comment-13570001 ] David Smiley commented on SOLR-4349: For the record, the symptom is seen in Safari too :-( (I haven't tested the patch but someone on SOLR-4393 says that this patch fixes it). > Admin UI - Query Interface does not work in IE > -- > > Key: SOLR-4349 > URL: https://issues.apache.org/jira/browse/SOLR-4349 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) > Labels: IE, IE10, InternetExplorer > Fix For: 4.2, 5.0 > > Attachments: IE10-Query-Interface.png, SOLR-4349.patch > > > While fiddeling with SOLR-4345, i realized that the Query-Interface does not > really work in IE (at least IE10, i guess that's also valid for IE9 and maybe > others) > The Interface itself (including the Form on the left side, including various > options) is there, but if you submit the Form, the result is always empty (as > in 0 Documents returned) because of the used url: > bq. http://host:port/solr/collection1/select? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4743) ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader)
[ https://issues.apache.org/jira/browse/LUCENE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569947#comment-13569947 ] Jason Nacional commented on LUCENE-4743: Just an addition, I also used ComplexPhraseQueryParser as a default parser. > ComplexPhraseQuery highlight problem after rewriting using > ComplexPhraseQuery.rewrite(IndexReader) > -- > > Key: LUCENE-4743 > URL: https://issues.apache.org/jira/browse/LUCENE-4743 > Project: Lucene - Core > Issue Type: Bug > Components: core/search, modules/queryparser >Affects Versions: 3.6.2 >Reporter: Jason Nacional > Labels: complexqueryparser, newbie, queryparser > > Just want to ask an assistance using ComplexPhraseQuery. I mean, when it > comes to highlighting the hits are not correct. I also started using > ComplexPhraseQueryParser to support complex proximity searches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4401) Move the stress test in SOLR-4196 into a junit test
[ https://issues.apache.org/jira/browse/SOLR-4401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4401: - Fix Version/s: 5.0 4.2 Affects Version/s: 5.0 4.2 > Move the stress test in SOLR-4196 into a junit test > --- > > Key: SOLR-4401 > URL: https://issues.apache.org/jira/browse/SOLR-4401 > Project: Solr > Issue Type: Test >Affects Versions: 4.2, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.2, 5.0 > > > As part of SOLR-4196, I created a stress test proces for rapidly opening and > closing cores. It'd probably be useful to make this into a junit test that > ran nightly (it needs some time in order to show anything, as in minutes). > Typical failures are 20 minutes into the run, but occasionally they're faster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4401) Move the stress test in SOLR-4196 into a junit test
Erick Erickson created SOLR-4401: Summary: Move the stress test in SOLR-4196 into a junit test Key: SOLR-4401 URL: https://issues.apache.org/jira/browse/SOLR-4401 Project: Solr Issue Type: Test Reporter: Erick Erickson Assignee: Erick Erickson Priority: Minor As part of SOLR-4196, I created a stress test proces for rapidly opening and closing cores. It'd probably be useful to make this into a junit test that ran nightly (it needs some time in order to show anything, as in minutes). Typical failures are 20 minutes into the run, but occasionally they're faster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4743) ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader)
[
https://issues.apache.org/jira/browse/LUCENE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569935#comment-13569935
]
Jason Nacional commented on LUCENE-4743:
Thanks all for the quick response. I can provide you some sample queries:
Let's say we have the following line: Make Sure Our Emails Reach Your Inbox
the query is: "(Make Sur*) Inbox"~10
after searching, the hits are correct. but somehow "Make" is not being
highlighted. Am I missing something here? here is my code.
{code:title=DocHighlighter.java|borderStyle=solid}
...
Query rewrite_result = phrase.rewrite(IndexReader.open(INDEX_DIR));
QueryScorer qs_phrases = new QueryScorer(rewrite_result);
qs_phrases.setExpandMultiTermQuery(true);
highlighter = new Highlighter(htmlFormatter, qs_phrases);
highlighter.setTextFragmenter(new NullFragmenter());
highlighter.setMaxDocCharsToAnalyze(Integer.MAX_VALUE);
//get the temp text
if(text == null){
text = highlighter.getBestFragment(analyzer, "", pText);
}else{
text_temp = highlighter.getBestFragment(analyzer, "", text);
text = text_temp;
}
...
{code}
I'll start to create a test case for more info.
> ComplexPhraseQuery highlight problem after rewriting using
> ComplexPhraseQuery.rewrite(IndexReader)
> --
>
> Key: LUCENE-4743
> URL: https://issues.apache.org/jira/browse/LUCENE-4743
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search, modules/queryparser
>Affects Versions: 3.6.2
>Reporter: Jason Nacional
> Labels: complexqueryparser, newbie, queryparser
>
> Just want to ask an assistance using ComplexPhraseQuery. I mean, when it
> comes to highlighting the hits are not correct. I also started using
> ComplexPhraseQueryParser to support complex proximity searches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Comment Edited] (LUCENE-4743) ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader)
[
https://issues.apache.org/jira/browse/LUCENE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569935#comment-13569935
]
Jason Nacional edited comment on LUCENE-4743 at 2/4/13 12:14 AM:
-
Thanks all for the quick response. I can provide you some sample query:
Let's say we have the following line: Make Sure Our Emails Reach Your Inbox
the query is: "(Make Sur*) Inbox"~10
after searching, the hits are correct. but somehow "Make" is not being
highlighted. Am I missing something here? here is my code.
{code:title=DocHighlighter.java|borderStyle=solid}
...
Query rewrite_result = phrase.rewrite(IndexReader.open(INDEX_DIR));
QueryScorer qs_phrases = new QueryScorer(rewrite_result);
qs_phrases.setExpandMultiTermQuery(true);
highlighter = new Highlighter(htmlFormatter, qs_phrases);
highlighter.setTextFragmenter(new NullFragmenter());
highlighter.setMaxDocCharsToAnalyze(Integer.MAX_VALUE);
//get the temp text
if(text == null){
text = highlighter.getBestFragment(analyzer, "", pText);
}else{
text_temp = highlighter.getBestFragment(analyzer, "", text);
text = text_temp;
}
...
{code}
I'll start to create a test case for more info.
was (Author: jason.nacional):
Thanks all for the quick response. I can provide you some sample queries:
Let's say we have the following line: Make Sure Our Emails Reach Your Inbox
the query is: "(Make Sur*) Inbox"~10
after searching, the hits are correct. but somehow "Make" is not being
highlighted. Am I missing something here? here is my code.
{code:title=DocHighlighter.java|borderStyle=solid}
...
Query rewrite_result = phrase.rewrite(IndexReader.open(INDEX_DIR));
QueryScorer qs_phrases = new QueryScorer(rewrite_result);
qs_phrases.setExpandMultiTermQuery(true);
highlighter = new Highlighter(htmlFormatter, qs_phrases);
highlighter.setTextFragmenter(new NullFragmenter());
highlighter.setMaxDocCharsToAnalyze(Integer.MAX_VALUE);
//get the temp text
if(text == null){
text = highlighter.getBestFragment(analyzer, "", pText);
}else{
text_temp = highlighter.getBestFragment(analyzer, "", text);
text = text_temp;
}
...
{code}
I'll start to create a test case for more info.
> ComplexPhraseQuery highlight problem after rewriting using
> ComplexPhraseQuery.rewrite(IndexReader)
> --
>
> Key: LUCENE-4743
> URL: https://issues.apache.org/jira/browse/LUCENE-4743
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search, modules/queryparser
>Affects Versions: 3.6.2
>Reporter: Jason Nacional
> Labels: complexqueryparser, newbie, queryparser
>
> Just want to ask an assistance using ComplexPhraseQuery. I mean, when it
> comes to highlighting the hits are not correct. I also started using
> ComplexPhraseQueryParser to support complex proximity searches.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4393) 'Execute Query' in the dashboard does not build the url correctly
[ https://issues.apache.org/jira/browse/SOLR-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569931#comment-13569931 ] Anand commented on SOLR-4393: - Applied the patch and verified that it now works on both Firefox and Chrome. > 'Execute Query' in the dashboard does not build the url correctly > - > > Key: SOLR-4393 > URL: https://issues.apache.org/jira/browse/SOLR-4393 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 >Reporter: Anand > > Recently upgraded to 4.1 and started seeing this issue since the upgrade. We > also went from single core to multiple core at the same time. > > Steps to reproduce > 1. Select a core from the dashboard. > 2. Select 'Query' > 3. Without changing anything, click 'Execture Query'. > Expected: 10 hits (or less depending on data indexed) displayed on the screen. > Observed: See response below. > http://localhost:8080/solr/coreName/select? > > > 0 name="QTime">0 numFound="0" start="0"> > > Issue: "http://localhost:8080/solr/coreName/select?"; is incomplete and > "q=*:*" is not appended to the url. > Tested on Firefox and Chrome and both suffer from this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4748) Add DrillSideways helper class to Lucene facets module
[ https://issues.apache.org/jira/browse/LUCENE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569924#comment-13569924 ] Michael McCandless commented on LUCENE-4748: bq. Whether DrillDown (and sideways) should have .search(), or .getCollector() (something I've been thinking about before looking at your 2nd patch) ... I think that .search() looks good. If needed, we can always add a getCollector() later. I think we should somehow do a .getCollector(). For example, if you want to do grouping (using GroupingSearch) and faceting (using DrillSideways) ... you're kind of stuck because each of these classes does the "search" for you. It's also a hassle having to make the N search methods (I still have a nocommit to add searchAfter...). So a .getCollector would be nice so the app could use MultiCollector to run everything (maybe they need to do joins too!). But the challenge is ... we'd also need .getQuery, because DrillSideways runs a different Query from what the user provided (and a different collector). And then we'd need to expose the collector, and add methods to get the drill-down and drill-sideways results ... > Add DrillSideways helper class to Lucene facets module > -- > > Key: LUCENE-4748 > URL: https://issues.apache.org/jira/browse/LUCENE-4748 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.2, 5.0 > > Attachments: LUCENE-4748.patch, LUCENE-4748.patch, LUCENE-4748.patch > > > This came out of a discussion on the java-user list with subject > "Faceted search in OR": http://markmail.org/thread/jmnq6z2x7ayzci5k > The basic idea is to count "near misses" during collection, ie > documents that matched the main query and also all except one of the > drill down filters. > Drill sideways makes for a very nice faceted search UI because you > don't "lose" the facet counts after drilling in. Eg maybe you do a > search for "cameras", and you see facets for the manufacturer, so you > drill into "Nikon". > With drill sideways, even after drilling down, you'll still get the > counts for all the other brands, where each count tells you how many > hits you'd get if you changed to a different manufacturer. > This becomes more fun if you add further drill-downs, eg maybe I next drill > down into Resolution=10 megapixels", and then I can see how many 10 > megapixel cameras all other manufacturers, and what other resolutions > Nikon cameras offer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4743) ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader)
[ https://issues.apache.org/jira/browse/LUCENE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569919#comment-13569919 ] Mark Miller commented on LUCENE-4743: - The std Highlighter can highlight span querys when in postion aware mode. It uses a memory index and decomposes the original query to find the matches. > ComplexPhraseQuery highlight problem after rewriting using > ComplexPhraseQuery.rewrite(IndexReader) > -- > > Key: LUCENE-4743 > URL: https://issues.apache.org/jira/browse/LUCENE-4743 > Project: Lucene - Core > Issue Type: Bug > Components: core/search, modules/queryparser >Affects Versions: 3.6.2 >Reporter: Jason Nacional > Labels: complexqueryparser, newbie, queryparser > > Just want to ask an assistance using ComplexPhraseQuery. I mean, when it > comes to highlighting the hits are not correct. I also started using > ComplexPhraseQueryParser to support complex proximity searches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4743) ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader)
[ https://issues.apache.org/jira/browse/LUCENE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569903#comment-13569903 ] Ryan Lauck commented on LUCENE-4743: ComplexPhraseQuery rewrites complex proximity searches into SpanQuerys. FastVectorHighlighter currently just ignores SpanQuery, I'm not sure how Highlighter behaves. I use ComplexPhraseQuery in production so I'd be happy to help trace this issue if you can provide some sample queries or some test cases. > ComplexPhraseQuery highlight problem after rewriting using > ComplexPhraseQuery.rewrite(IndexReader) > -- > > Key: LUCENE-4743 > URL: https://issues.apache.org/jira/browse/LUCENE-4743 > Project: Lucene - Core > Issue Type: Bug > Components: core/search, modules/queryparser >Affects Versions: 3.6.2 >Reporter: Jason Nacional > Labels: complexqueryparser, newbie, queryparser > > Just want to ask an assistance using ComplexPhraseQuery. I mean, when it > comes to highlighting the hits are not correct. I also started using > ComplexPhraseQueryParser to support complex proximity searches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 178 - Still Failing!
On 2/3/2013 2:01 PM, Uwe Schindler wrote: Could this maybe related to number of open files? I have no idea how to configure that on MacOS. If this is the case, we should really drill down this test to not open so many file descriptors. Current setting: I located this: http://ghickman.co.uk/2012/02/25/osx-max-files-limit-neo4j.html Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4642) TokenizerFactory should provide a create method with a given AttributeSource
[ https://issues.apache.org/jira/browse/LUCENE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569883#comment-13569883 ] Renaud Delbru commented on LUCENE-4642: --- Hi, I have submitted a patch which integrates: - the patch from Uwe - the removal of the Tokenizer(AttributeSource) constructor - the addition of a TokenizerFactory.create(AttributeFactory) method - some of the changes from the previous patch from Steve (e.g., TokenizerFactory.create method throw UOE by default) All test suites are passing. > TokenizerFactory should provide a create method with a given AttributeSource > > > Key: LUCENE-4642 > URL: https://issues.apache.org/jira/browse/LUCENE-4642 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 4.1 >Reporter: Renaud Delbru >Assignee: Steve Rowe > Labels: analysis, attribute, tokenizer > Fix For: 4.2, 5.0 > > Attachments: LUCENE-4642.patch, LUCENE-4642.patch, LUCENE-4642.patch, > TrieTokenizerFactory.java.patch > > > All tokenizer implementations have a constructor that takes a given > AttributeSource as parameter (LUCENE-1826). However, the TokenizerFactory > does not provide an API to create tokenizers with a given AttributeSource. > Side note: There are still a lot of tokenizers that do not provide > constructors that take AttributeSource and AttributeFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4642) TokenizerFactory should provide a create method with a given AttributeSource
[ https://issues.apache.org/jira/browse/LUCENE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Renaud Delbru updated LUCENE-4642: -- Attachment: LUCENE-4642.patch > TokenizerFactory should provide a create method with a given AttributeSource > > > Key: LUCENE-4642 > URL: https://issues.apache.org/jira/browse/LUCENE-4642 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Affects Versions: 4.1 >Reporter: Renaud Delbru >Assignee: Steve Rowe > Labels: analysis, attribute, tokenizer > Fix For: 4.2, 5.0 > > Attachments: LUCENE-4642.patch, LUCENE-4642.patch, LUCENE-4642.patch, > TrieTokenizerFactory.java.patch > > > All tokenizer implementations have a constructor that takes a given > AttributeSource as parameter (LUCENE-1826). However, the TokenizerFactory > does not provide an API to create tokenizers with a given AttributeSource. > Side note: There are still a lot of tokenizers that do not provide > constructors that take AttributeSource and AttributeFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4748) Add DrillSideways helper class to Lucene facets module
[ https://issues.apache.org/jira/browse/LUCENE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-4748: --- Component/s: modules/facet > Add DrillSideways helper class to Lucene facets module > -- > > Key: LUCENE-4748 > URL: https://issues.apache.org/jira/browse/LUCENE-4748 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/facet >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.2, 5.0 > > Attachments: LUCENE-4748.patch, LUCENE-4748.patch, LUCENE-4748.patch > > > This came out of a discussion on the java-user list with subject > "Faceted search in OR": http://markmail.org/thread/jmnq6z2x7ayzci5k > The basic idea is to count "near misses" during collection, ie > documents that matched the main query and also all except one of the > drill down filters. > Drill sideways makes for a very nice faceted search UI because you > don't "lose" the facet counts after drilling in. Eg maybe you do a > search for "cameras", and you see facets for the manufacturer, so you > drill into "Nikon". > With drill sideways, even after drilling down, you'll still get the > counts for all the other brands, where each count tells you how many > hits you'd get if you changed to a different manufacturer. > This becomes more fun if you add further drill-downs, eg maybe I next drill > down into Resolution=10 megapixels", and then I can see how many 10 > megapixel cameras all other manufacturers, and what other resolutions > Nikon cameras offer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4748) Add DrillSideways helper class to Lucene facets module
[ https://issues.apache.org/jira/browse/LUCENE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569852#comment-13569852 ] Shai Erera commented on LUCENE-4748: bq. Now you instantiate DrillSideways, calls .addDrillDown one or more times, then call one of the search methods. That's actually very cool! bq. I think DrillDown ought to have a similar API I agree! Today DrillDown API is kinda confusing (you even have a nocommit regarding that). E.g. how should one use DrillDown to construct and AND of ORs. Having DrillDown.add() will be a great simplification! Whether DrillDown (and sideways) should have .search(), or .getCollector() (something I've been thinking about before looking at your 2nd patch) ... I think that .search() looks good. If needed, we can always add a getCollector() later. I think it would be good if we can merge DrillDown and Sideways, though not sure how the API would look like at the moment. So maybe for now we keep them separated. I.e., Sideways requires heavy jdocs, explaining exactly what it does, and e.g. the multiple FacetArrays allocation, so if all that we get by merging is the joint .add() logic ... I'd rather keep them separated. I plan to do a more thorough review tomorrow, but briefly scanning the new patch, this looks awesome! > Add DrillSideways helper class to Lucene facets module > -- > > Key: LUCENE-4748 > URL: https://issues.apache.org/jira/browse/LUCENE-4748 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.2, 5.0 > > Attachments: LUCENE-4748.patch, LUCENE-4748.patch, LUCENE-4748.patch > > > This came out of a discussion on the java-user list with subject > "Faceted search in OR": http://markmail.org/thread/jmnq6z2x7ayzci5k > The basic idea is to count "near misses" during collection, ie > documents that matched the main query and also all except one of the > drill down filters. > Drill sideways makes for a very nice faceted search UI because you > don't "lose" the facet counts after drilling in. Eg maybe you do a > search for "cameras", and you see facets for the manufacturer, so you > drill into "Nikon". > With drill sideways, even after drilling down, you'll still get the > counts for all the other brands, where each count tells you how many > hits you'd get if you changed to a different manufacturer. > This becomes more fun if you add further drill-downs, eg maybe I next drill > down into Resolution=10 megapixels", and then I can see how many 10 > megapixel cameras all other manufacturers, and what other resolutions > Nikon cameras offer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4193) A ZooKeeper RequestHandler that allows you to post config files to a collections linked config set or a specific config set.
[ https://issues.apache.org/jira/browse/SOLR-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569830#comment-13569830 ] Mark Miller commented on SOLR-4193: --- Hey Shawn, you can do this with the zkcli tool by the way - just change the config set link for the collection and reload. Will make sure it's supported through an http api as well though. > A ZooKeeper RequestHandler that allows you to post config files to a > collections linked config set or a specific config set. > > > Key: SOLR-4193 > URL: https://issues.apache.org/jira/browse/SOLR-4193 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: SOLR-4193.patch, SOLR-4193.patch > > > Could have an admin zk handler and one per core? > An admin zk handler would allow you to access it without specifying an > existing core if done right. > One per core lets you do things like: > post solrconfig.xml to localhost:8983:/solr/collection1/zkhandler > Then we look up what config set we linked to and overwrite the solrconfig.xml. > You can already GET config files through another handler, so at the moment > I'd avoid duplicating that. > Could imagine adding commands over time though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4193) A ZooKeeper RequestHandler that allows you to post config files to a collections linked config set or a specific config set.
[ https://issues.apache.org/jira/browse/SOLR-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569820#comment-13569820 ] Shawn Heisey commented on SOLR-4193: I'd like the ability to tell a collection to use a different config set. I brought this up on the mailing list, where Mark Miller directed me to this issue. Consider this situation, which is essentially where I am right now: I have a config set named 'mbbasecfg' which for the immediate future will be used by all collections that I add to my SolrCloud (4.1). Each collection will get used by a SolrJ servlet, which serves content from one specific customer. The 'mb' prefix is something specific to our software. Let's say customer X decides they want things to work very differently for their application, and they are willing to pay us development costs to make it happen. Their requested changes will require a different Solr config and maybe a different schema. Customer X already has a collection in SolrCloud. What I'd like to be able to do is upload a new config set called mbcustxcfg, then ask SolrCloud to change the customerx collection to use that new config set. If the changes don't require a reindex, we'd be done after reloading the collection. If they do require a reindex, then we'll do that. Currently we would have to delete their collection and build it again with a new config set. If renaming a collection is possible (not sure whether it is), we could do that before making a new collection with the original name. This is not the end of the world, of course. > A ZooKeeper RequestHandler that allows you to post config files to a > collections linked config set or a specific config set. > > > Key: SOLR-4193 > URL: https://issues.apache.org/jira/browse/SOLR-4193 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: SOLR-4193.patch, SOLR-4193.patch > > > Could have an admin zk handler and one per core? > An admin zk handler would allow you to access it without specifying an > existing core if done right. > One per core lets you do things like: > post solrconfig.xml to localhost:8983:/solr/collection1/zkhandler > Then we look up what config set we linked to and overwrite the solrconfig.xml. > You can already GET config files through another handler, so at the moment > I'd avoid duplicating that. > Could imagine adding commands over time though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4196) Untangle XML-specific nature of Config and Container classes
[ https://issues.apache.org/jira/browse/SOLR-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569811#comment-13569811 ] Mark Miller commented on SOLR-4196: --- bq. Hmmm, I have no idea why Eclipse didn't like the patch, I mention it because previous patches applied no problem, so I wasn't sure if something was done differently. I almost never find a patch eclipse won't apply for me. > Untangle XML-specific nature of Config and Container classes > > > Key: SOLR-4196 > URL: https://issues.apache.org/jira/browse/SOLR-4196 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, > SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, > SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, StressTest.zip, > StressTest.zip, StressTest.zip > > > sub-task for SOLR-4083. If we're going to try to obsolete solr.xml, we need > to pull all of the specific XML processing out of Config and Container. > Currently, we refer to xpaths all over the place. This JIRA is about > providing a thunking layer to isolate the XML-esque nature of solr.xml and > allow a simple properties file to be used instead which will lead, > eventually, to solr.xml going away. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4400) Rapidly opening and closing cores can lead to deadlock
[ https://issues.apache.org/jira/browse/SOLR-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569810#comment-13569810 ] Mark Miller commented on SOLR-4400: --- Yup, the attached is the commit lock issue. > Rapidly opening and closing cores can lead to deadlock > -- > > Key: SOLR-4400 > URL: https://issues.apache.org/jira/browse/SOLR-4400 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1 >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: 4.2, 5.0 > > Attachments: 4x_stack.txt > > > See the discussion at SOLR-4196. Under ridiculous loads (i.e. every request > causes a core to close and another one to open) Solr can lock up. This is > _only_ a problem if you are using transient cores (see SOLR-1028) with a > limited cache size. Simply lazily loading cores that are NOT transient > shouldn't have this problem, you need to be closing cores to get here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4400) Rapidly opening and closing cores can lead to deadlock
[ https://issues.apache.org/jira/browse/SOLR-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4400: - Attachment: 4x_stack.txt Attaching jstack output for a fresh (3-Feb) run against 4x, on a _very_ quick look it has the same issue, so I think we can be confident that the same fix needs to go in both places. Won't have time to look at this in detail until later today. > Rapidly opening and closing cores can lead to deadlock > -- > > Key: SOLR-4400 > URL: https://issues.apache.org/jira/browse/SOLR-4400 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1 >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: 4.2, 5.0 > > Attachments: 4x_stack.txt > > > See the discussion at SOLR-4196. Under ridiculous loads (i.e. every request > causes a core to close and another one to open) Solr can lock up. This is > _only_ a problem if you are using transient cores (see SOLR-1028) with a > limited cache size. Simply lazily loading cores that are NOT transient > shouldn't have this problem, you need to be closing cores to get here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4748) Add DrillSideways helper class to Lucene facets module
[ https://issues.apache.org/jira/browse/LUCENE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4748: --- Attachment: LUCENE-4748.patch New patch, addressing some nocommits. Now you instantiate DrillSideways, calls .addDrillDown one or more times, then call one of the search methods. I think DrillDown ought to have a similar API, so that you can build up some dims with OR and others without ... and maybe we should merge DrillDown and DrillSideways ... > Add DrillSideways helper class to Lucene facets module > -- > > Key: LUCENE-4748 > URL: https://issues.apache.org/jira/browse/LUCENE-4748 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.2, 5.0 > > Attachments: LUCENE-4748.patch, LUCENE-4748.patch, LUCENE-4748.patch > > > This came out of a discussion on the java-user list with subject > "Faceted search in OR": http://markmail.org/thread/jmnq6z2x7ayzci5k > The basic idea is to count "near misses" during collection, ie > documents that matched the main query and also all except one of the > drill down filters. > Drill sideways makes for a very nice faceted search UI because you > don't "lose" the facet counts after drilling in. Eg maybe you do a > search for "cameras", and you see facets for the manufacturer, so you > drill into "Nikon". > With drill sideways, even after drilling down, you'll still get the > counts for all the other brands, where each count tells you how many > hits you'd get if you changed to a different manufacturer. > This becomes more fun if you add further drill-downs, eg maybe I next drill > down into Resolution=10 megapixels", and then I can see how many 10 > megapixel cameras all other manufacturers, and what other resolutions > Nikon cameras offer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: Stress test deadlocks
On Feb 2, 2013, at 10:29 AM, Erick Erickson wrote: > My stray thought was I wonder if it'd make sense to add this to some kind of > regular test process just for yucks I really think this should be converted into a junit test - it's very useful and could be cranked up on nightly runs. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4748) Add DrillSideways helper class to Lucene facets module
[
https://issues.apache.org/jira/browse/LUCENE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569804#comment-13569804
]
Michael McCandless commented on LUCENE-4748:
{quote}
Since drill-down followed by drill-sideways is a sort of (re)filtering over the
original result set, perhaps the query result (say ScoredDocIds) could be
passed through rather than re-evaluating the Query?
IIRC the scores should not change during drill-down (and sideways as well), so
without re-evaluating this could perhaps save some juice?
{quote}
Yes, this would work correctly: the drill-sideways counts for dim X will be the
same as the drill-down counts for dim X on the query just before you drilled
into dim X. So we could save counting the sideways counts for dim X (but,
other dimensions previously drilled-down will still need new counting).
We'd need to run a different query, basically moving dim X up to the top
BooleanQuery as a MUST, and of course the app would have to save & return the
previous queries drill-down counts for dim X (which is a hassle in a stateless
server app)...
> Add DrillSideways helper class to Lucene facets module
> --
>
> Key: LUCENE-4748
> URL: https://issues.apache.org/jira/browse/LUCENE-4748
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4748.patch, LUCENE-4748.patch
>
>
> This came out of a discussion on the java-user list with subject
> "Faceted search in OR": http://markmail.org/thread/jmnq6z2x7ayzci5k
> The basic idea is to count "near misses" during collection, ie
> documents that matched the main query and also all except one of the
> drill down filters.
> Drill sideways makes for a very nice faceted search UI because you
> don't "lose" the facet counts after drilling in. Eg maybe you do a
> search for "cameras", and you see facets for the manufacturer, so you
> drill into "Nikon".
> With drill sideways, even after drilling down, you'll still get the
> counts for all the other brands, where each count tells you how many
> hits you'd get if you changed to a different manufacturer.
> This becomes more fun if you add further drill-downs, eg maybe I next drill
> down into Resolution=10 megapixels", and then I can see how many 10
> megapixel cameras all other manufacturers, and what other resolutions
> Nikon cameras offer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4400) Rapidly opening and closing cores can lead to deadlock
[ https://issues.apache.org/jira/browse/SOLR-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4400: -- Fix Version/s: 5.0 4.2 Affects Version/s: (was: 5.0) > Rapidly opening and closing cores can lead to deadlock > -- > > Key: SOLR-4400 > URL: https://issues.apache.org/jira/browse/SOLR-4400 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1 >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: 4.2, 5.0 > > > See the discussion at SOLR-4196. Under ridiculous loads (i.e. every request > causes a core to close and another one to open) Solr can lock up. This is > _only_ a problem if you are using transient cores (see SOLR-1028) with a > limited cache size. Simply lazily loading cores that are NOT transient > shouldn't have this problem, you need to be closing cores to get here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4196) Untangle XML-specific nature of Config and Container classes
[ https://issues.apache.org/jira/browse/SOLR-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569790#comment-13569790 ] Erick Erickson commented on SOLR-4196: -- Hmmm, I have no idea why Eclipse didn't like the patch, I just generated it with svn diff. But it I'm guessing you have it applied anyway. Sounds like we should raise a new JIRA about the deadlock issue, so I raised SOLR-4400 since it doesn't look like it's related to this particular patch... Certainly SOLR-1028 made the stress test possible so we're seeing it. NOTE: I'm pretty sure this applies to 4x too, I'm running that test now, will record it in SOLR-4400 > Untangle XML-specific nature of Config and Container classes > > > Key: SOLR-4196 > URL: https://issues.apache.org/jira/browse/SOLR-4196 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, > SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, > SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, StressTest.zip, > StressTest.zip, StressTest.zip > > > sub-task for SOLR-4083. If we're going to try to obsolete solr.xml, we need > to pull all of the specific XML processing out of Config and Container. > Currently, we refer to xpaths all over the place. This JIRA is about > providing a thunking layer to isolate the XML-esque nature of solr.xml and > allow a simple properties file to be used instead which will lead, > eventually, to solr.xml going away. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4400) Rapidly opening and closing cores can lead to deadlock
Erick Erickson created SOLR-4400: Summary: Rapidly opening and closing cores can lead to deadlock Key: SOLR-4400 URL: https://issues.apache.org/jira/browse/SOLR-4400 Project: Solr Issue Type: Bug Affects Versions: 4.1, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson See the discussion at SOLR-4196. Under ridiculous loads (i.e. every request causes a core to close and another one to open) Solr can lock up. This is _only_ a problem if you are using transient cores (see SOLR-1028) with a limited cache size. Simply lazily loading cores that are NOT transient shouldn't have this problem, you need to be closing cores to get here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4748) Add DrillSideways helper class to Lucene facets module
[ https://issues.apache.org/jira/browse/LUCENE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569780#comment-13569780 ] Gilad Barkai commented on LUCENE-4748: -- Great idea! Since drill-down followed by drill-sideways is a sort of (re)filtering over the original result set, perhaps the query result (say ScoredDocIds) could be passed through rather than re-evaluating the Query? IIRC the scores should not change during drill-down (and sideways as well), so without re-evaluating this could perhaps save some juice? > Add DrillSideways helper class to Lucene facets module > -- > > Key: LUCENE-4748 > URL: https://issues.apache.org/jira/browse/LUCENE-4748 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.2, 5.0 > > Attachments: LUCENE-4748.patch, LUCENE-4748.patch > > > This came out of a discussion on the java-user list with subject > "Faceted search in OR": http://markmail.org/thread/jmnq6z2x7ayzci5k > The basic idea is to count "near misses" during collection, ie > documents that matched the main query and also all except one of the > drill down filters. > Drill sideways makes for a very nice faceted search UI because you > don't "lose" the facet counts after drilling in. Eg maybe you do a > search for "cameras", and you see facets for the manufacturer, so you > drill into "Nikon". > With drill sideways, even after drilling down, you'll still get the > counts for all the other brands, where each count tells you how many > hits you'd get if you changed to a different manufacturer. > This becomes more fun if you add further drill-downs, eg maybe I next drill > down into Resolution=10 megapixels", and then I can see how many 10 > megapixel cameras all other manufacturers, and what other resolutions > Nikon cameras offer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3967) Mapping error: langid.enforceSchema option checks source field instead of target field
[
https://issues.apache.org/jira/browse/SOLR-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569777#comment-13569777
]
Mateusz Matela commented on SOLR-3967:
--
Yes, the fix looks good. Thanks!
> Mapping error: langid.enforceSchema option checks source field instead of
> target field
> --
>
> Key: SOLR-3967
> URL: https://issues.apache.org/jira/browse/SOLR-3967
> Project: Solr
> Issue Type: Bug
> Components: contrib - LangId
>Affects Versions: 4.0
>Reporter: Mateusz Matela
>Assignee: Jan Høydahl
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-3967.patch
>
>
> I use LangDetect update processor with a document that has "body" field.
> LangDetect should map this field to "body_pl", "body_en" or "body_nolang". My
> schema defines fields with language suffixes, but not "body" field. When the
> processor runs, I get error:
> {quote}Unsuccessful field name mapping to body_nolang, field does not exist,
> skipping mapping.{quote}
> I looked up source code and it seems there's an error in
> {{org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(SolrInputDocument)}}:
> {noformat}
> String mappedOutputField = getMappedField(fieldName, fieldLang);
> if(enforceSchema && schema.getFieldOrNull(fieldName) == null) {
> log.warn("Unsuccessful field name mapping to {}, field does not
> exist, skipping mapping.", mappedOutputField, fieldName);
> mappedOutputField = fieldName;
> }
> {noformat}
> I think it should check for {{schema.getFieldOrNull(mappedOutputField)}}
> instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] [Closed] (SOLR-3967) Mapping error: langid.enforceSchema option checks source field instead of target field
[
https://issues.apache.org/jira/browse/SOLR-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mateusz Matela closed SOLR-3967.
> Mapping error: langid.enforceSchema option checks source field instead of
> target field
> --
>
> Key: SOLR-3967
> URL: https://issues.apache.org/jira/browse/SOLR-3967
> Project: Solr
> Issue Type: Bug
> Components: contrib - LangId
>Affects Versions: 4.0
>Reporter: Mateusz Matela
>Assignee: Jan Høydahl
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-3967.patch
>
>
> I use LangDetect update processor with a document that has "body" field.
> LangDetect should map this field to "body_pl", "body_en" or "body_nolang". My
> schema defines fields with language suffixes, but not "body" field. When the
> processor runs, I get error:
> {quote}Unsuccessful field name mapping to body_nolang, field does not exist,
> skipping mapping.{quote}
> I looked up source code and it seems there's an error in
> {{org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(SolrInputDocument)}}:
> {noformat}
> String mappedOutputField = getMappedField(fieldName, fieldLang);
> if(enforceSchema && schema.getFieldOrNull(fieldName) == null) {
> log.warn("Unsuccessful field name mapping to {}, field does not
> exist, skipping mapping.", mappedOutputField, fieldName);
> mappedOutputField = fieldName;
> }
> {noformat}
> I think it should check for {{schema.getFieldOrNull(mappedOutputField)}}
> instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4748) Add DrillSideways helper class to Lucene facets module
[ https://issues.apache.org/jira/browse/LUCENE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4748: --- Attachment: LUCENE-4748.patch New patch, just using IS.search instead of walking the leaves myself... > Add DrillSideways helper class to Lucene facets module > -- > > Key: LUCENE-4748 > URL: https://issues.apache.org/jira/browse/LUCENE-4748 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.2, 5.0 > > Attachments: LUCENE-4748.patch, LUCENE-4748.patch > > > This came out of a discussion on the java-user list with subject > "Faceted search in OR": http://markmail.org/thread/jmnq6z2x7ayzci5k > The basic idea is to count "near misses" during collection, ie > documents that matched the main query and also all except one of the > drill down filters. > Drill sideways makes for a very nice faceted search UI because you > don't "lose" the facet counts after drilling in. Eg maybe you do a > search for "cameras", and you see facets for the manufacturer, so you > drill into "Nikon". > With drill sideways, even after drilling down, you'll still get the > counts for all the other brands, where each count tells you how many > hits you'd get if you changed to a different manufacturer. > This becomes more fun if you add further drill-downs, eg maybe I next drill > down into Resolution=10 megapixels", and then I can see how many 10 > megapixel cameras all other manufacturers, and what other resolutions > Nikon cameras offer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4747) java7 as a minimum requirement for lucene 5
[ https://issues.apache.org/jira/browse/LUCENE-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569761#comment-13569761 ] Michael McCandless commented on LUCENE-4747: +1 > java7 as a minimum requirement for lucene 5 > --- > > Key: LUCENE-4747 > URL: https://issues.apache.org/jira/browse/LUCENE-4747 > Project: Lucene - Core > Issue Type: Task >Affects Versions: 5.0 >Reporter: Robert Muir > Fix For: 5.0 > > > Spinoff from LUCENE-4746. > I propose we make this change on trunk only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4747) java7 as a minimum requirement for lucene 5
[ https://issues.apache.org/jira/browse/LUCENE-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569743#comment-13569743 ] Adrien Grand commented on LUCENE-4747: -- +1 > java7 as a minimum requirement for lucene 5 > --- > > Key: LUCENE-4747 > URL: https://issues.apache.org/jira/browse/LUCENE-4747 > Project: Lucene - Core > Issue Type: Task >Affects Versions: 5.0 >Reporter: Robert Muir > Fix For: 5.0 > > > Spinoff from LUCENE-4746. > I propose we make this change on trunk only. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
