Re: Unresolved external symbol errors when linking example native c++ code that uses jcc
Hi Andi, Sorry, I do not get your point. There was no error for jcc generating the code that wraps Native2Java.class. The problem occurs during linking some client code which uses this generated wrapper. Do I miss something here? Any tips where these symbols may emerge from? I really could not track or see them referenced in JCCEnv.cpp, really. Thanks, András Andi Vajda va...@apache.org írta: On Oct 21, 2010, at 4:39, Imre András ia...@freemail.hu wrote: Hi list, I intend to use jcc to ease calling Java code from native code. I managed to build and install it. Now I try to build my first test code from within MS VS 2010 Win32 console app project. Despite setting up the libs and includes I still get linker errors: I'm not sure this link line makes sense. To get an idea of what the correct link line looks like, get jcc to build a python extension and take a close look at the link line it generates as an example for your C++ only case. Andi.. -- Link: C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\link.exe / ERRORREPORT:PROMPT /OUT:C:\out\app\PeldaProgram\ZipBe\bin\test\src \Debug\jcc.exe /INCREMENTAL /NOLOGO python27.lib _jcc.lib jvm.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /ManifestFile:Debug \jcc.exe.intermediate.manifest /MANIFESTUAC:level='asInvoker' uiAccess='false' /DEBUG /PDB:C:\out\app\PeldaProgram\ZipBe\bin\test \src\Debug\jcc.pdb /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE / NXCOMPAT /IMPLIB:C:\out\app\PeldaProgram\ZipBe\bin\test\src\Debug \jcc.lib /MACHINE:X86 Debug\jcc.exe.embed.manifest.res Debug\jcc.obj Debug\stdafx.obj Debug\__wrap__.obj Creating library C:\out\app\PeldaProgram\ZipBe\bin\test\src\Debug \jcc.lib and object C:\out\app\PeldaProgram\ZipBe\bin\test\src\Debug \jcc.exp 1jcc.obj : error LNK2001: unresolved external symbol unsigned long VM_ENV (?VM_ENV@@3KA) 1stdafx.obj : error LNK2001: unresolved external symbol unsigned long VM_ENV (?VM_ENV@@3KA) 1__wrap__.obj : error LNK2001: unresolved external symbol unsigned long VM_ENV (?VM_ENV@@3KA) 1jcc.obj : error LNK2001: unresolved external symbol class JCCEnv * env (?env@@3PAVJCCEnv@@A) 1stdafx.obj : error LNK2001: unresolved external symbol class JCCEnv * env (?env@@3PAVJCCEnv@@A) 1__wrap__.obj : error LNK2001: unresolved external symbol class JCCEnv * env (?env@@3PAVJCCEnv@@A) 1C:\out\app\PeldaProgram\ZipBe\bin\test\src\Debug\jcc.exe : fatal error LNK1120: 2 unresolved externals 1Done Building Project C:\out\app\PeldaProgram\ZipBe\bin\test\jcc \jcc.vcxproj (rebuild target(s)) -- FAILED. Build FAILED. Time Elapsed 00:00:12.60 -- jni.h and Native2Java.h (jcc generated from the java class I intend to use in native c++ code) is added to stdafx.h. Now I have no idea where the above symbols come from, and how should I resolve them. Regards, András
Lucene-Solr-tests-only-trunk - Build # 500 - Failure
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/500/ 1 tests failed. REGRESSION: org.apache.solr.TestDistributedSearch.testDistribSearch Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:441) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:78) at org.apache.solr.BaseDistributedSearchTestCase.tearDown(BaseDistributedSearchTestCase.java:144) Build Log (for compile errors): [...truncated 8705 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-3.x - Build # 487 - Failure
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/487/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestThreadedOptimize.testThreadedOptimize Error Message: null Stack Trace: junit.framework.AssertionFailedError: at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:779) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:745) at org.apache.lucene.index.TestThreadedOptimize.runTest(TestThreadedOptimize.java:126) at org.apache.lucene.index.TestThreadedOptimize.testThreadedOptimize(TestThreadedOptimize.java:140) Build Log (for compile errors): [...truncated 4289 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Solr-trunk - Build # 1291 - Still Failing
Build: http://hudson.zones.apache.org/hudson/job/Solr-trunk/1291/ All tests passed Build Log (for compile errors): [...truncated 16261 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2618) Intermittent failure in 3.x's backwards TestThreadedOptimize
[
https://issues.apache.org/jira/browse/LUCENE-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924298#action_12924298
]
Michael McCandless commented on LUCENE-2618:
Ugh -- last night's 3.x build just failed again! So this was not the [only]
cause. Hmm. I'll leave this reopened
Intermittent failure in 3.x's backwards TestThreadedOptimize
Key: LUCENE-2618
URL: https://issues.apache.org/jira/browse/LUCENE-2618
Project: Lucene - Java
Issue Type: Bug
Components: Index
Reporter: Michael McCandless
Fix For: 3.1, 4.0
Attachments: LUCENE-2618.patch, LUCENE-2618.patch
Failure looks like this:
{noformat}
[junit] Testsuite: org.apache.lucene.index.TestThreadedOptimize
[junit] Testcase:
testThreadedOptimize(org.apache.lucene.index.TestThreadedOptimize): FAILED
[junit] null
[junit] junit.framework.AssertionFailedError: null
[junit] at
org.apache.lucene.index.TestThreadedOptimize.runTest(TestThreadedOptimize.java:125)
[junit] at
org.apache.lucene.index.TestThreadedOptimize.testThreadedOptimize(TestThreadedOptimize.java:149)
[junit] at
org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:253)
{noformat}
I just committed some verbosity so next time it strikes we'll have more
details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Using filters to speed up queries
Unfortunately, Lucene's performance with filters isn't great. This is because we now always apply filters up high, using a leapfrog approach, where we alternate asking the filter and then the scorer to skip to each other's docID. But if the filter accepts enough (~1% in my testing) of the documents in the index, it's often better to apply the filter down low like we do deleted docs (which really is its own filter), ie where we quickly eliminate docs as we enumerate them from the postings. I did a blog post about this too: http://chbits.blogspot.com/2010/09/fast-search-filters-using-flex.html That post shows some of the perf gains we could get by switching filters to apply down low, though this was for a filter that randomly accepts 50% of the index. And this is using the flex APIs (for 4.0); you may be able to do something similar using FilterIndexReader pre-4.0. Of course you shouldn't have to do such tricks -- https://issues.apache.org/jira/browse/LUCENE-1536 is open for Lucene to do this itself when you pass a filter. You should test, but, I suspect a MUST clause on an AND query may not perform that much better in general for filters that accept a biggish part of the index, since it's still using skipping, especially if your query wasn't already a BooleanQuery. For restrictive filters it should be a decent gain, but those queries are already fast to begin with. Do you have some perf numbers to share? What kind of queries are you running with the filters? Are there certain users that have a highish %tg of the documents, with a long tail of the other users? If so you could consider making dedicated indices for those high doc count users... Also note that static index partitioning like this does not result in the same scoring as you'd get if each user had their own index, since the term stats (IDF) is aggregated across all users. So for queries with more than one term, users can see docs sorted differently, and this is actually a known security risk in that users can gleen some details about the documents they aren't allowed to see due to the shared terms stats... there is a paper somewhere (Robert?) that delves into it. Mike On Sat, Oct 23, 2010 at 6:18 PM, Khash Sajadi kh...@sajadi.co.uk wrote: My index contains documents for different users. Each document has the user id as a field on it. There are about 500 different users with 3 million documents. Currently I'm calling Search with the query (parsed from user) and FieldCacheTermsFilter for the user id. It works but the performance is not great. Ideally, I would like to perform the search only on the documents that are relevant, this should make it much faster. However, it seems Search(Query, Filter) runs the query first and then applies the filter. Is there a way to improve this? (i.e. run the query only on a subset of documents) Thanks - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Using filters to speed up queries
Op zondag 24 oktober 2010 00:18:48 schreef Khash Sajadi: My index contains documents for different users. Each document has the user id as a field on it. There are about 500 different users with 3 million documents. Currently I'm calling Search with the query (parsed from user) and FieldCacheTermsFilter for the user id. It works but the performance is not great. Ideally, I would like to perform the search only on the documents that are relevant, this should make it much faster. However, it seems Search(Query, Filter) runs the query first and then applies the filter. Is there a way to improve this? (i.e. run the query only on a subset of documents) Thanks When running the query with the filter, the query is run at the same time as the filter. Initially and after each matching document, the filter is assumed to be cheaper to execute and its first or next matching document is determined. Then the query and the filter are repeatedly advanced to each other's next matching document until they are at the same document (ie. there is a match), similar to a boolean query with two required clauses. The java code doing this is in the private method IndexSearcher.searchWithFilter(). It could be that filling the field cache is the performance problem. How is the performance when this search call with the FieldCacheTermsFilter is repeated? Also, for a single indexed term to be used as a filter (the user id in this case) there may be no need for a cache, a QueryWrapperFilter around the TermQuery might suffice. Regards, Paul Elschot - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-trunk - Build # 506 - Failure
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/506/ 6 tests failed. REGRESSION: org.apache.solr.TestGroupingSearch.testGroupingGroupSortingScore_basic Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:368) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:335) at org.apache.solr.TestGroupingSearch.testGroupingGroupSortingScore_basic(TestGroupingSearch.java:47) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' at org.apache.solr.core.SolrCore.getQueryPlugin(SolrCore.java:1508) at org.apache.solr.search.QParser.getParser(QParser.java:286) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:330) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:231) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1359) at org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:348) at org.apache.solr.util.TestHarness.query(TestHarness.java:331) at org.apache.solr.util.TestHarness.query(TestHarness.java:316) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:342) REGRESSION: org.apache.solr.TestGroupingSearch.testGroupingGroupSortingScore_basicWithGroupSortEqualToSort Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:368) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:335) at org.apache.solr.TestGroupingSearch.testGroupingGroupSortingScore_basicWithGroupSortEqualToSort(TestGroupingSearch.java:77) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' at org.apache.solr.core.SolrCore.getQueryPlugin(SolrCore.java:1508) at org.apache.solr.search.QParser.getParser(QParser.java:286) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:330) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:231) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1359) at org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:348) at org.apache.solr.util.TestHarness.query(TestHarness.java:331) at org.apache.solr.util.TestHarness.query(TestHarness.java:316) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:342) REGRESSION: org.apache.solr.TestGroupingSearch.testGroupingGroupSortingName Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:368) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:335) at org.apache.solr.TestGroupingSearch.testGroupingGroupSortingName(TestGroupingSearch.java:103) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' at org.apache.solr.core.SolrCore.getQueryPlugin(SolrCore.java:1508) at org.apache.solr.search.QParser.getParser(QParser.java:286) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:330) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:231) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1359) at org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:348) at org.apache.solr.util.TestHarness.query(TestHarness.java:331) at org.apache.solr.util.TestHarness.query(TestHarness.java:316) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:342) REGRESSION: org.apache.solr.TestGroupingSearch.testGroupingGroupSortingWeight Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at
Re: Using filters to speed up queries
Here is what I've found so far: I have three main sets to use in a query: Account MUST be xxx User query DateRange on the query MUST be in (a,b) it is a NumericField I tried the following combinations (all using a BooleanQuery with the user query added to it) 1. One: - Add ACCOUNT as a TermQuery - Add DATE RANGE as Filter 2. Two - Add ACCOUNT as Filer - Add DATE RANGE as NumericRangeQuery I tried caching the filters on both scenarios. I also tried both scenarios by passing the query as a ConstantScoreQuery as well. I got the best result (about 4x faster) by using a cached filter for the DATE RANGE and leaving the ACCOUNT as a TermQuery. I think I'm happy with this approach. However, the security risk Uwe mentioned when using ACCOUNT as a Query makes me nervous. Any suggestions? As for document distribution, the ACCOUNTS have a similar distribution of documents. Also, I still would like to try the multi index approach, but not sure about the memory, file handle burden of it (having potentially thousands of reades/writers/searchers) open at the same time. I use two processes one as indexer and one for search with the same underlying FSDirectory. As for search, I use writer.getReader().reopen within a SearchManager as suggested by Lucene in Action. On 24 October 2010 10:27, Paul Elschot paul.elsc...@xs4all.nl wrote: Op zondag 24 oktober 2010 00:18:48 schreef Khash Sajadi: My index contains documents for different users. Each document has the user id as a field on it. There are about 500 different users with 3 million documents. Currently I'm calling Search with the query (parsed from user) and FieldCacheTermsFilter for the user id. It works but the performance is not great. Ideally, I would like to perform the search only on the documents that are relevant, this should make it much faster. However, it seems Search(Query, Filter) runs the query first and then applies the filter. Is there a way to improve this? (i.e. run the query only on a subset of documents) Thanks When running the query with the filter, the query is run at the same time as the filter. Initially and after each matching document, the filter is assumed to be cheaper to execute and its first or next matching document is determined. Then the query and the filter are repeatedly advanced to each other's next matching document until they are at the same document (ie. there is a match), similar to a boolean query with two required clauses. The java code doing this is in the private method IndexSearcher.searchWithFilter(). It could be that filling the field cache is the performance problem. How is the performance when this search call with the FieldCacheTermsFilter is repeated? Also, for a single indexed term to be used as a filter (the user id in this case) there may be no need for a cache, a QueryWrapperFilter around the TermQuery might suffice. Regards, Paul Elschot - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-1316) Create autosuggest component
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924305#action_12924305 ] Silvan Zurbruegg commented on SOLR-1316: Is there a possibility to have minimal query-logic when looking up suggestions with the suggester? Afaik, all syntax like 'AND' or 'OR' is stripped by the QueryConverter. From playing around with the suggester i figured out that looking up multiple terms is possible, resulting in a 'OR'-like list for each term. Is it possible to have support for an 'AND' logic as well? For example looking up the terms '+css' and '+web' would yield in suggestions from documents that contain both terms. The first thing coming to mind are TermVectors, but since term vectors are document based and probably not related to the suggester-dictionary this could get complicated and is probably out of the scope of the suggester component. Create autosuggest component Key: SOLR-1316 URL: https://issues.apache.org/jira/browse/SOLR-1316 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Andrzej Bialecki Priority: Minor Fix For: Next Attachments: SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316.patch, SOLR-1316_3x-2.patch, SOLR-1316_3x.patch, suggest.patch, suggest.patch, suggest.patch, TST.zip Original Estimate: 96h Remaining Estimate: 96h Autosuggest is a common search function that can be integrated into Solr as a SearchComponent. Our first implementation will use the TernaryTree found in Lucene contrib. * Enable creation of the dictionary from the index or via Solr's RPC mechanism * What types of parameters and settings are desirable? * Hopefully in the future we can include user click through rates to boost those terms/phrases higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Using filters to speed up queries
Security risk? I did not say anything about that! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Khash Sajadi [mailto:kh...@sajadi.co.uk] Sent: Sunday, October 24, 2010 12:34 PM To: dev@lucene.apache.org Subject: Re: Using filters to speed up queries Here is what I've found so far: I have three main sets to use in a query: Account MUST be xxx User query DateRange on the query MUST be in (a,b) it is a NumericField I tried the following combinations (all using a BooleanQuery with the user query added to it) 1. One: - Add ACCOUNT as a TermQuery - Add DATE RANGE as Filter 2. Two - Add ACCOUNT as Filer - Add DATE RANGE as NumericRangeQuery I tried caching the filters on both scenarios. I also tried both scenarios by passing the query as a ConstantScoreQuery as well. I got the best result (about 4x faster) by using a cached filter for the DATE RANGE and leaving the ACCOUNT as a TermQuery. I think I'm happy with this approach. However, the security risk Uwe mentioned when using ACCOUNT as a Query makes me nervous. Any suggestions? As for document distribution, the ACCOUNTS have a similar distribution of documents. Also, I still would like to try the multi index approach, but not sure about the memory, file handle burden of it (having potentially thousands of reades/writers/searchers) open at the same time. I use two processes one as indexer and one for search with the same underlying FSDirectory. As for search, I use writer.getReader().reopen within a SearchManager as suggested by Lucene in Action. On 24 October 2010 10:27, Paul Elschot paul.elsc...@xs4all.nl wrote: Op zondag 24 oktober 2010 00:18:48 schreef Khash Sajadi: My index contains documents for different users. Each document has the user id as a field on it. There are about 500 different users with 3 million documents. Currently I'm calling Search with the query (parsed from user) and FieldCacheTermsFilter for the user id. It works but the performance is not great. Ideally, I would like to perform the search only on the documents that are relevant, this should make it much faster. However, it seems Search(Query, Filter) runs the query first and then applies the filter. Is there a way to improve this? (i.e. run the query only on a subset of documents) Thanks When running the query with the filter, the query is run at the same time as the filter. Initially and after each matching document, the filter is assumed to be cheaper to execute and its first or next matching document is determined. Then the query and the filter are repeatedly advanced to each other's next matching document until they are at the same document (ie. there is a match), similar to a boolean query with two required clauses. The java code doing this is in the private method IndexSearcher.searchWithFilter(). It could be that filling the field cache is the performance problem. How is the performance when this search call with the FieldCacheTermsFilter is repeated? Also, for a single indexed term to be used as a filter (the user id in this case) there may be no need for a cache, a QueryWrapperFilter around the TermQuery might suffice. Regards, Paul Elschot - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Using filters to speed up queries
Terribly sorry. I meant Mike: Also note that static index partitioning like this does not result in the same scoring as you'd get if each user had their own index, since the term stats (IDF) is aggregated across all users. So for queries with more than one term, users can see docs sorted differently, and this is actually a known security risk in that users can gleen some details about the documents they aren't allowed to see due to the shared terms stats... there is a paper somewhere (Robert?) that delves into it. On 24 October 2010 11:46, Uwe Schindler u...@thetaphi.de wrote: Security risk? I did not say anything about that! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de *From:* Khash Sajadi [mailto:kh...@sajadi.co.uk] *Sent:* Sunday, October 24, 2010 12:34 PM *To:* dev@lucene.apache.org *Subject:* Re: Using filters to speed up queries Here is what I've found so far: I have three main sets to use in a query: Account MUST be xxx User query DateRange on the query MUST be in (a,b) it is a NumericField I tried the following combinations (all using a BooleanQuery with the user query added to it) 1. One: - Add ACCOUNT as a TermQuery - Add DATE RANGE as Filter 2. Two - Add ACCOUNT as Filer - Add DATE RANGE as NumericRangeQuery I tried caching the filters on both scenarios. I also tried both scenarios by passing the query as a ConstantScoreQuery as well. I got the best result (about 4x faster) by using a cached filter for the DATE RANGE and leaving the ACCOUNT as a TermQuery. I think I'm happy with this approach. However, the security risk Uwe mentioned when using ACCOUNT as a Query makes me nervous. Any suggestions? As for document distribution, the ACCOUNTS have a similar distribution of documents. Also, I still would like to try the multi index approach, but not sure about the memory, file handle burden of it (having potentially thousands of reades/writers/searchers) open at the same time. I use two processes one as indexer and one for search with the same underlying FSDirectory. As for search, I use writer.getReader().reopen within a SearchManager as suggested by Lucene in Action. On 24 October 2010 10:27, Paul Elschot paul.elsc...@xs4all.nl wrote: Op zondag 24 oktober 2010 00:18:48 schreef Khash Sajadi: My index contains documents for different users. Each document has the user id as a field on it. There are about 500 different users with 3 million documents. Currently I'm calling Search with the query (parsed from user) and FieldCacheTermsFilter for the user id. It works but the performance is not great. Ideally, I would like to perform the search only on the documents that are relevant, this should make it much faster. However, it seems Search(Query, Filter) runs the query first and then applies the filter. Is there a way to improve this? (i.e. run the query only on a subset of documents) Thanks When running the query with the filter, the query is run at the same time as the filter. Initially and after each matching document, the filter is assumed to be cheaper to execute and its first or next matching document is determined. Then the query and the filter are repeatedly advanced to each other's next matching document until they are at the same document (ie. there is a match), similar to a boolean query with two required clauses. The java code doing this is in the private method IndexSearcher.searchWithFilter(). It could be that filling the field cache is the performance problem. How is the performance when this search call with the FieldCacheTermsFilter is repeated? Also, for a single indexed term to be used as a filter (the user id in this case) there may be no need for a cache, a QueryWrapperFilter around the TermQuery might suffice. Regards, Paul Elschot - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
nocommit committed in SolrCore.java
Anyone know what's up with this one? solr/src/java/org/apache/solr/core/SolrCore.java: // nocommit: why did solrconfig override core descriptor !? Can we remove it? Change to TODO? Mike - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-trunk - Build # 507 - Still Failing
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/507/ 1 tests failed. REGRESSION: org.apache.solr.TestDistributedSearch.testDistribSearch Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:441) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:78) at org.apache.solr.BaseDistributedSearchTestCase.tearDown(BaseDistributedSearchTestCase.java:144) Build Log (for compile errors): [...truncated 8717 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Using filters to speed up queries
The trick is to wrap the TermQuery using a ConstantScoreQuery(new QueryWrapperFilter(new TermQuery(.))). Because for filtering, the TermQuery used instead of a filter should not contribute to score. This code is used quite often in Lucene, so don't care about the strange looking code. E.g. in MultiTermQuery. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Khash Sajadi [mailto:kh...@sajadi.co.uk] Sent: Sunday, October 24, 2010 12:50 PM To: dev@lucene.apache.org Subject: Re: Using filters to speed up queries Terribly sorry. I meant Mike: Also note that static index partitioning like this does not result in the same scoring as you'd get if each user had their own index, since the term stats (IDF) is aggregated across all users. So for queries with more than one term, users can see docs sorted differently, and this is actually a known security risk in that users can gleen some details about the documents they aren't allowed to see due to the shared terms stats... there is a paper somewhere (Robert?) that delves into it. On 24 October 2010 11:46, Uwe Schindler u...@thetaphi.de wrote: Security risk? I did not say anything about that! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de http://www.thetaphi.de/ eMail: u...@thetaphi.de From: Khash Sajadi [mailto:kh...@sajadi.co.uk] Sent: Sunday, October 24, 2010 12:34 PM To: dev@lucene.apache.org Subject: Re: Using filters to speed up queries Here is what I've found so far: I have three main sets to use in a query: Account MUST be xxx User query DateRange on the query MUST be in (a,b) it is a NumericField I tried the following combinations (all using a BooleanQuery with the user query added to it) 1. One: - Add ACCOUNT as a TermQuery - Add DATE RANGE as Filter 2. Two - Add ACCOUNT as Filer - Add DATE RANGE as NumericRangeQuery I tried caching the filters on both scenarios. I also tried both scenarios by passing the query as a ConstantScoreQuery as well. I got the best result (about 4x faster) by using a cached filter for the DATE RANGE and leaving the ACCOUNT as a TermQuery. I think I'm happy with this approach. However, the security risk Uwe mentioned when using ACCOUNT as a Query makes me nervous. Any suggestions? As for document distribution, the ACCOUNTS have a similar distribution of documents. Also, I still would like to try the multi index approach, but not sure about the memory, file handle burden of it (having potentially thousands of reades/writers/searchers) open at the same time. I use two processes one as indexer and one for search with the same underlying FSDirectory. As for search, I use writer.getReader().reopen within a SearchManager as suggested by Lucene in Action. On 24 October 2010 10:27, Paul Elschot paul.elsc...@xs4all.nl wrote: Op zondag 24 oktober 2010 00:18:48 schreef Khash Sajadi: My index contains documents for different users. Each document has the user id as a field on it. There are about 500 different users with 3 million documents. Currently I'm calling Search with the query (parsed from user) and FieldCacheTermsFilter for the user id. It works but the performance is not great. Ideally, I would like to perform the search only on the documents that are relevant, this should make it much faster. However, it seems Search(Query, Filter) runs the query first and then applies the filter. Is there a way to improve this? (i.e. run the query only on a subset of documents) Thanks When running the query with the filter, the query is run at the same time as the filter. Initially and after each matching document, the filter is assumed to be cheaper to execute and its first or next matching document is determined. Then the query and the filter are repeatedly advanced to each other's next matching document until they are at the same document (ie. there is a match), similar to a boolean query with two required clauses. The java code doing this is in the private method IndexSearcher.searchWithFilter(). It could be that filling the field cache is the performance problem. How is the performance when this search call with the FieldCacheTermsFilter is repeated? Also, for a single indexed term to be used as a filter (the user id in this case) there may be no need for a cache, a QueryWrapperFilter around the TermQuery might suffice. Regards, Paul Elschot - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Using filters to speed up queries
Some more speed up may be possible when the same combination of filters (user account and date range here) is reused for another query. The combined filter can then be made as an OpenBitSetDISI (in the util package) and kept around for reuse. Regards, Paul Elschot Op zondag 24 oktober 2010 12:34:07 schreef Khash Sajadi: Here is what I've found so far: I have three main sets to use in a query: Account MUST be xxx User query DateRange on the query MUST be in (a,b) it is a NumericField I tried the following combinations (all using a BooleanQuery with the user query added to it) 1. One: - Add ACCOUNT as a TermQuery - Add DATE RANGE as Filter 2. Two - Add ACCOUNT as Filer - Add DATE RANGE as NumericRangeQuery I tried caching the filters on both scenarios. I also tried both scenarios by passing the query as a ConstantScoreQuery as well. I got the best result (about 4x faster) by using a cached filter for the DATE RANGE and leaving the ACCOUNT as a TermQuery. I think I'm happy with this approach. However, the security risk Uwe mentioned when using ACCOUNT as a Query makes me nervous. Any suggestions? As for document distribution, the ACCOUNTS have a similar distribution of documents. Also, I still would like to try the multi index approach, but not sure about the memory, file handle burden of it (having potentially thousands of reades/writers/searchers) open at the same time. I use two processes one as indexer and one for search with the same underlying FSDirectory. As for search, I use writer.getReader().reopen within a SearchManager as suggested by Lucene in Action. On 24 October 2010 10:27, Paul Elschot paul.elsc...@xs4all.nl wrote: Op zondag 24 oktober 2010 00:18:48 schreef Khash Sajadi: My index contains documents for different users. Each document has the user id as a field on it. There are about 500 different users with 3 million documents. Currently I'm calling Search with the query (parsed from user) and FieldCacheTermsFilter for the user id. It works but the performance is not great. Ideally, I would like to perform the search only on the documents that are relevant, this should make it much faster. However, it seems Search(Query, Filter) runs the query first and then applies the filter. Is there a way to improve this? (i.e. run the query only on a subset of documents) Thanks When running the query with the filter, the query is run at the same time as the filter. Initially and after each matching document, the filter is assumed to be cheaper to execute and its first or next matching document is determined. Then the query and the filter are repeatedly advanced to each other's next matching document until they are at the same document (ie. there is a match), similar to a boolean query with two required clauses. The java code doing this is in the private method IndexSearcher.searchWithFilter(). It could be that filling the field cache is the performance problem. How is the performance when this search call with the FieldCacheTermsFilter is repeated? Also, for a single indexed term to be used as a filter (the user id in this case) there may be no need for a cache, a QueryWrapperFilter around the TermQuery might suffice. Regards, Paul Elschot - 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: nocommit committed in SolrCore.java
Removed - added it while working on solrcloud, then made an issue to make the behavior change (and committed), but forgot to remove the nocommit from the cloud patch before committing. - Mark On 10/24/10 6:55 AM, Michael McCandless wrote: Anyone know what's up with this one? solr/src/java/org/apache/solr/core/SolrCore.java: // nocommit: why did solrconfig override core descriptor !? Can we remove it? Change to TODO? Mike - 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: nocommit committed in SolrCore.java
Super, thanks! Now we are nocommit-free on trunk 3.x. Mike On Sun, Oct 24, 2010 at 7:33 AM, Mark Miller markrmil...@gmail.com wrote: Removed - added it while working on solrcloud, then made an issue to make the behavior change (and committed), but forgot to remove the nocommit from the cloud patch before committing. - Mark On 10/24/10 6:55 AM, Michael McCandless wrote: Anyone know what's up with this one? solr/src/java/org/apache/solr/core/SolrCore.java: // nocommit: why did solrconfig override core descriptor !? Can we remove it? Change to TODO? Mike - 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2190) slashdot sample: xpath not match
[ https://issues.apache.org/jira/browse/SOLR-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-2190: - Attachment: SOLR-2190.patch A very simple fix - this patch uses RSS 0.9 http://rss.slashdot.org/Slashdot/slashdot/to slashdot sample: xpath not match Key: SOLR-2190 URL: https://issues.apache.org/jira/browse/SOLR-2190 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.3, 1.4, 1.4.1, 3.1, 4.0 Reporter: Koji Sekiguchi Priority: Minor Fix For: 3.1, 4.0 Attachments: SOLR-2190.patch A user reported the problem: http://www.lucidimagination.com/search/document/3345551fe53af291/importing_slashdot_data I hit same issue today. The cause of the problem is xpath in rss-data-config.xml doesn't match RSS feed. It seems rss-data-config.xml expects RSS 0.9, but http://rss.slashdot.org/Slashdot/slashdot returns RSS 1.0 today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-trunk - Build # 514 - Failure
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/514/ 7 tests failed. REGRESSION: org.apache.solr.TestDistributedSearch.testDistribSearch Error Message: Some threads threw uncaught exceptions! Stack Trace: junit.framework.AssertionFailedError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:441) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:78) at org.apache.solr.BaseDistributedSearchTestCase.tearDown(BaseDistributedSearchTestCase.java:144) REGRESSION: org.apache.solr.TestGroupingSearch.testGroupingGroupSortingScore_basic Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:368) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:335) at org.apache.solr.TestGroupingSearch.testGroupingGroupSortingScore_basic(TestGroupingSearch.java:47) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' at org.apache.solr.core.SolrCore.getQueryPlugin(SolrCore.java:1508) at org.apache.solr.search.QParser.getParser(QParser.java:286) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:330) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:231) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1359) at org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:348) at org.apache.solr.util.TestHarness.query(TestHarness.java:331) at org.apache.solr.util.TestHarness.query(TestHarness.java:316) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:342) REGRESSION: org.apache.solr.TestGroupingSearch.testGroupingGroupSortingScore_basicWithGroupSortEqualToSort Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:368) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:335) at org.apache.solr.TestGroupingSearch.testGroupingGroupSortingScore_basicWithGroupSortEqualToSort(TestGroupingSearch.java:77) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' at org.apache.solr.core.SolrCore.getQueryPlugin(SolrCore.java:1508) at org.apache.solr.search.QParser.getParser(QParser.java:286) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:330) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:231) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1359) at org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:348) at org.apache.solr.util.TestHarness.query(TestHarness.java:331) at org.apache.solr.util.TestHarness.query(TestHarness.java:316) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:342) REGRESSION: org.apache.solr.TestGroupingSearch.testGroupingGroupSortingName Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:368) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:335) at org.apache.solr.TestGroupingSearch.testGroupingGroupSortingName(TestGroupingSearch.java:103) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' at org.apache.solr.core.SolrCore.getQueryPlugin(SolrCore.java:1508) at org.apache.solr.search.QParser.getParser(QParser.java:286) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:330) at
[jira] Updated: (SOLR-2190) slashdot sample: xpath not match
[ https://issues.apache.org/jira/browse/SOLR-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-2190: - Attachment: SOLR-2190.patch New patch - this sees RSS 1.0. I changed some fields from stored=false to true and added svn:ignore props for some folders. I'll commit soon. slashdot sample: xpath not match Key: SOLR-2190 URL: https://issues.apache.org/jira/browse/SOLR-2190 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.3, 1.4, 1.4.1, 3.1, 4.0 Reporter: Koji Sekiguchi Priority: Minor Fix For: 3.1, 4.0 Attachments: SOLR-2190.patch, SOLR-2190.patch A user reported the problem: http://www.lucidimagination.com/search/document/3345551fe53af291/importing_slashdot_data I hit same issue today. The cause of the problem is xpath in rss-data-config.xml doesn't match RSS feed. It seems rss-data-config.xml expects RSS 0.9, but http://rss.slashdot.org/Slashdot/slashdot returns RSS 1.0 today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Resolved: (SOLR-2190) slashdot sample: xpath not match
[ https://issues.apache.org/jira/browse/SOLR-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi resolved SOLR-2190. -- Resolution: Fixed Assignee: Koji Sekiguchi trunk: Committed revision 1026823. branch_3x: Committed revision 1026825. slashdot sample: xpath not match Key: SOLR-2190 URL: https://issues.apache.org/jira/browse/SOLR-2190 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.3, 1.4, 1.4.1, 3.1, 4.0 Reporter: Koji Sekiguchi Assignee: Koji Sekiguchi Priority: Minor Fix For: 3.1, 4.0 Attachments: SOLR-2190.patch, SOLR-2190.patch A user reported the problem: http://www.lucidimagination.com/search/document/3345551fe53af291/importing_slashdot_data I hit same issue today. The cause of the problem is xpath in rss-data-config.xml doesn't match RSS feed. It seems rss-data-config.xml expects RSS 0.9, but http://rss.slashdot.org/Slashdot/slashdot returns RSS 1.0 today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2160) Unknown query type 'func'
[ https://issues.apache.org/jira/browse/SOLR-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924345#action_12924345 ] Uwe Schindler commented on SOLR-2160: - bq. Grrr, I can't even run SolrInfoMBeanTest from by IDE. java.lang.AssertionError: there are at least 10 SolrInfoMBean that should be found in the classpath, found 0 Thats because the test only works if the class files are physically on disk and not in JAR file. And IDEs have own classloaders to serve classes directly from their debugger. Unknown query type 'func' - Key: SOLR-2160 URL: https://issues.apache.org/jira/browse/SOLR-2160 Project: Solr Issue Type: Test Components: Build Affects Versions: 3.1, 4.0 Environment: Hudson Reporter: Robert Muir Fix For: 3.1, 4.0 Several test methods in TestTrie failed in hudson, with errors such as this: Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2160) Unknown query type 'func'
[ https://issues.apache.org/jira/browse/SOLR-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924346#action_12924346 ] Yonik Seeley commented on SOLR-2160: I'm starting to think this may be a classloader issue. A SolrCore can have it's own classloader... and the SolrInfoMBeanTest loads the classes (I think) in the parent classloader. Unknown query type 'func' - Key: SOLR-2160 URL: https://issues.apache.org/jira/browse/SOLR-2160 Project: Solr Issue Type: Test Components: Build Affects Versions: 3.1, 4.0 Environment: Hudson Reporter: Robert Muir Fix For: 3.1, 4.0 Several test methods in TestTrie failed in hudson, with errors such as this: Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2127) When using the defaultCoreName attribute, after performing a swap, solr.xml no longer contains the defaultCoreName attribute, and the core which was dafult is now renamed t
[ https://issues.apache.org/jira/browse/SOLR-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ephraim Ofir updated SOLR-2127: --- Attachment: SOLR-2127.patch Fixed indentation of solr.xml when serializing and added to CHANGES.txt When using the defaultCoreName attribute, after performing a swap, solr.xml no longer contains the defaultCoreName attribute, and the core which was dafult is now renamed to Key: SOLR-2127 URL: https://issues.apache.org/jira/browse/SOLR-2127 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 1.4.2, 1.5 Reporter: Ephraim Ofir Assignee: Mark Miller Priority: Minor Fix For: 3.1, 4.0 Attachments: SOLR-2127.patch, SOLR-2127.patch Tried using the defaultCoreName attribute on a 2 core setup. After performing a swap, my solr.xml no longer contains the defaultCoreName attribute, and the core which was dafult is now renamed to , so after restart of the process can't access it by it's former name and can't perform other operations on it such as rename, reload or swap... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2160) Unknown query type 'func'
[ https://issues.apache.org/jira/browse/SOLR-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-2160: --- Attachment: SOLR-2160.patch If I change this test to be a Solr test, and use the classloader from the core, it seems to work. Unknown query type 'func' - Key: SOLR-2160 URL: https://issues.apache.org/jira/browse/SOLR-2160 Project: Solr Issue Type: Test Components: Build Affects Versions: 3.1, 4.0 Environment: Hudson Reporter: Robert Muir Fix For: 3.1, 4.0 Attachments: SOLR-2160.patch Several test methods in TestTrie failed in hudson, with errors such as this: Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (SOLR-2191) Change SolrException cstrs that take Throwable to default to alreadyLogged=false
Change SolrException cstrs that take Throwable to default to alreadyLogged=false Key: SOLR-2191 URL: https://issues.apache.org/jira/browse/SOLR-2191 Project: Solr Issue Type: Bug Reporter: Mark Miller Fix For: Next Because of misuse, many exceptions are now not logged at all - can be painful when doing dev. I think we should flip this setting and work at removing any double logging - losing logging is worse (and it almost looks like we lose more logging than we would get in double logging) - and bad solrexception/logging patterns are proliferating. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2160) Unknown query type 'func'
[ https://issues.apache.org/jira/browse/SOLR-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924357#action_12924357 ] Uwe Schindler commented on SOLR-2160: - Let's try it out? Unknown query type 'func' - Key: SOLR-2160 URL: https://issues.apache.org/jira/browse/SOLR-2160 Project: Solr Issue Type: Test Components: Build Affects Versions: 3.1, 4.0 Environment: Hudson Reporter: Robert Muir Fix For: 3.1, 4.0 Attachments: SOLR-2160.patch Several test methods in TestTrie failed in hudson, with errors such as this: Caused by: org.apache.solr.common.SolrException: Unknown query type 'func' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-3.x - Build # 508 - Failure
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/508/ 1 tests failed. REGRESSION: org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest.testStatistics Error Message: null Stack Trace: java.util.NoSuchElementException at java.util.LinkedList.getFirst(LinkedList.java:126) at java.util.LinkedList.peek(LinkedList.java:466) at org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer.blockUntilFinished(StreamingUpdateSolrServer.java:251) at org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer.request(StreamingUpdateSolrServer.java:198) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:105) at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:86) at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:75) at org.apache.solr.client.solrj.SolrExampleTests.testStatistics(SolrExampleTests.java:444) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:779) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:745) Build Log (for compile errors): [...truncated 9757 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2162) TestLBHttpSolrServer.testSimple test failure
[
https://issues.apache.org/jira/browse/SOLR-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924363#action_12924363
]
Yonik Seeley commented on SOLR-2162:
Interesting - it fails for me every time too.
I don't think that LBHttpSolrServer is using CommonsHttpSolrServer in a way
that would make it retry though.
And the method.releaseConnection() that doesn't have a corresponding
method=null - that's at the end of the method and method
is a local variable (was that the place you were talking about - line 486?
TestLBHttpSolrServer.testSimple test failure
Key: SOLR-2162
URL: https://issues.apache.org/jira/browse/SOLR-2162
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.1, 4.0
Environment: Hudson
Reporter: Robert Muir
Fix For: 3.1, 4.0
Attachments: SOLR-2162_test.patch
TestLBHttpSolrServer failed, with this error:
java.lang.IllegalStateException: Connection is not open
Here is the stacktrace:
{noformat}
[junit] Testsuite: org.apache.solr.client.solrj.TestLBHttpSolrServer
[junit] Testcase:
testSimple(org.apache.solr.client.solrj.TestLBHttpSolrServer): Caused an
ERROR
[junit] java.lang.IllegalStateException: Connection is not open
[junit] org.apache.solr.client.solrj.SolrServerException:
java.lang.IllegalStateException: Connection is not open
[junit] at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:409)
[junit] at
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:89)
[junit] at
org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:119)
[junit] at
org.apache.solr.client.solrj.TestLBHttpSolrServer.testSimple(TestLBHttpSolrServer.java:120)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:795)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:768)
[junit] Caused by: java.lang.IllegalStateException: Connection is not open
[junit] at
org.apache.commons.httpclient.HttpConnection.assertOpen(HttpConnection.java:1277)
[junit] at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1115)
[junit] at
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
[junit] at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
[junit] at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
[junit] at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
[junit] at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
[junit] at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
[junit] at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
[junit] at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:427)
[junit] at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:244)
[junit] at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:395)
[junit]
[junit]
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 10.319 sec
[junit]
[junit] - Standard Output ---
[junit] NOTE: reproduce with: ant test -Dtestcase=TestLBHttpSolrServer
-Dtestmethod=testSimple -Dtests.seed=-4677869093300417770:-570157895683071678
[junit] NOTE: test params are: codec=SimpleText, locale=hr_HR,
timezone=Asia/Kathmandu
[junit] - ---
[junit] TEST org.apache.solr.client.solrj.TestLBHttpSolrServer FAILED
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2162) TestLBHttpSolrServer.testSimple test failure
[
https://issues.apache.org/jira/browse/SOLR-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924365#action_12924365
]
Yonik Seeley commented on SOLR-2162:
If I instantiate HttpClient with a multi-threaded connection manager, this test
seems to pass again.
HttpClient myHttpClient = new HttpClient(new
MultiThreadedHttpConnectionManager());
TestLBHttpSolrServer.testSimple test failure
Key: SOLR-2162
URL: https://issues.apache.org/jira/browse/SOLR-2162
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.1, 4.0
Environment: Hudson
Reporter: Robert Muir
Fix For: 3.1, 4.0
Attachments: SOLR-2162_test.patch
TestLBHttpSolrServer failed, with this error:
java.lang.IllegalStateException: Connection is not open
Here is the stacktrace:
{noformat}
[junit] Testsuite: org.apache.solr.client.solrj.TestLBHttpSolrServer
[junit] Testcase:
testSimple(org.apache.solr.client.solrj.TestLBHttpSolrServer): Caused an
ERROR
[junit] java.lang.IllegalStateException: Connection is not open
[junit] org.apache.solr.client.solrj.SolrServerException:
java.lang.IllegalStateException: Connection is not open
[junit] at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:409)
[junit] at
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:89)
[junit] at
org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:119)
[junit] at
org.apache.solr.client.solrj.TestLBHttpSolrServer.testSimple(TestLBHttpSolrServer.java:120)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:795)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:768)
[junit] Caused by: java.lang.IllegalStateException: Connection is not open
[junit] at
org.apache.commons.httpclient.HttpConnection.assertOpen(HttpConnection.java:1277)
[junit] at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1115)
[junit] at
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
[junit] at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
[junit] at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
[junit] at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
[junit] at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
[junit] at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
[junit] at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
[junit] at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:427)
[junit] at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:244)
[junit] at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:395)
[junit]
[junit]
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 10.319 sec
[junit]
[junit] - Standard Output ---
[junit] NOTE: reproduce with: ant test -Dtestcase=TestLBHttpSolrServer
-Dtestmethod=testSimple -Dtests.seed=-4677869093300417770:-570157895683071678
[junit] NOTE: test params are: codec=SimpleText, locale=hr_HR,
timezone=Asia/Kathmandu
[junit] - ---
[junit] TEST org.apache.solr.client.solrj.TestLBHttpSolrServer FAILED
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Resolved: (SOLR-2162) TestLBHttpSolrServer.testSimple test failure
[
https://issues.apache.org/jira/browse/SOLR-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-2162.
Resolution: Fixed
Committed change so that setUp also used a multi-threaded connection manager.
Hopefully that will solve the issue.
TestLBHttpSolrServer.testSimple test failure
Key: SOLR-2162
URL: https://issues.apache.org/jira/browse/SOLR-2162
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 3.1, 4.0
Environment: Hudson
Reporter: Robert Muir
Fix For: 3.1, 4.0
Attachments: SOLR-2162_test.patch
TestLBHttpSolrServer failed, with this error:
java.lang.IllegalStateException: Connection is not open
Here is the stacktrace:
{noformat}
[junit] Testsuite: org.apache.solr.client.solrj.TestLBHttpSolrServer
[junit] Testcase:
testSimple(org.apache.solr.client.solrj.TestLBHttpSolrServer): Caused an
ERROR
[junit] java.lang.IllegalStateException: Connection is not open
[junit] org.apache.solr.client.solrj.SolrServerException:
java.lang.IllegalStateException: Connection is not open
[junit] at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:409)
[junit] at
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:89)
[junit] at
org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:119)
[junit] at
org.apache.solr.client.solrj.TestLBHttpSolrServer.testSimple(TestLBHttpSolrServer.java:120)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:795)
[junit] at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:768)
[junit] Caused by: java.lang.IllegalStateException: Connection is not open
[junit] at
org.apache.commons.httpclient.HttpConnection.assertOpen(HttpConnection.java:1277)
[junit] at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1115)
[junit] at
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
[junit] at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
[junit] at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
[junit] at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
[junit] at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
[junit] at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
[junit] at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
[junit] at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:427)
[junit] at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:244)
[junit] at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:395)
[junit]
[junit]
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 10.319 sec
[junit]
[junit] - Standard Output ---
[junit] NOTE: reproduce with: ant test -Dtestcase=TestLBHttpSolrServer
-Dtestmethod=testSimple -Dtests.seed=-4677869093300417770:-570157895683071678
[junit] NOTE: test params are: codec=SimpleText, locale=hr_HR,
timezone=Asia/Kathmandu
[junit] - ---
[junit] TEST org.apache.solr.client.solrj.TestLBHttpSolrServer FAILED
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-3.x - Build # 511 - Failure
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/511/ 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.highlight.HighlighterTest Error Message: ERROR: SolrIndexSearcher opens=46 closes=45 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=46 closes=45 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:114) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:287) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:65) FAILED: junit.framework.TestSuite.org.apache.solr.spelling.SpellCheckCollatorTest Error Message: ERROR: SolrIndexSearcher opens=2 closes=1 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=2 closes=1 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:114) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:287) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:65) FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: ERROR: SolrIndexSearcher opens=39 closes=34 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=39 closes=34 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:114) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:287) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:65) Build Log (for compile errors): [...truncated 9848 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (SOLR-2192) StreamingUpdateSolrServer not thread safe
StreamingUpdateSolrServer not thread safe - Key: SOLR-2192 URL: https://issues.apache.org/jira/browse/SOLR-2192 Project: Solr Issue Type: Bug Affects Versions: 1.4.1 Reporter: Yonik Seeley test error method suggest thread safety violation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2192) StreamingUpdateSolrServer not thread safe
[
https://issues.apache.org/jira/browse/SOLR-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924372#action_12924372
]
Yonik Seeley commented on SOLR-2192:
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/508/
{noformat}
1 tests failed.
REGRESSION:
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest.testStatistics
Error Message:
null
Stack Trace:
java.util.NoSuchElementException
at java.util.LinkedList.getFirst(LinkedList.java:126)
at java.util.LinkedList.peek(LinkedList.java:466)
at
org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer.blockUntilFinished(StreamingUpdateSolrServer.java:251)
at
org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer.request(StreamingUpdateSolrServer.java:198)
at
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:105)
at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:86)
at org.apache.solr.client.solrj.SolrServer.commit(SolrServer.java:75)
at
org.apache.solr.client.solrj.SolrExampleTests.testStatistics(SolrExampleTests.java:444)
at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:779)
at
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:745)
{noformat}
StreamingUpdateSolrServer not thread safe
-
Key: SOLR-2192
URL: https://issues.apache.org/jira/browse/SOLR-2192
Project: Solr
Issue Type: Bug
Affects Versions: 1.4.1
Reporter: Yonik Seeley
test error method suggest thread safety violation
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2192) StreamingUpdateSolrServer not thread safe
[ https://issues.apache.org/jira/browse/SOLR-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924373#action_12924373 ] Yonik Seeley commented on SOLR-2192: The only way I figure peek() could fail is if the LinkedList was being used in a non-thread safe manner. StreamingUpdateSolrServer not thread safe - Key: SOLR-2192 URL: https://issues.apache.org/jira/browse/SOLR-2192 Project: Solr Issue Type: Bug Affects Versions: 1.4.1 Reporter: Yonik Seeley test error method suggest thread safety violation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2192) StreamingUpdateSolrServer not thread safe
[ https://issues.apache.org/jira/browse/SOLR-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924374#action_12924374 ] Yonik Seeley commented on SOLR-2192: Yep - a quick look shows that runners is normally synchronized on itself, but it's not in blockUntilFinished StreamingUpdateSolrServer not thread safe - Key: SOLR-2192 URL: https://issues.apache.org/jira/browse/SOLR-2192 Project: Solr Issue Type: Bug Affects Versions: 1.4.1 Reporter: Yonik Seeley test error method suggest thread safety violation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2192) StreamingUpdateSolrServer not thread safe
[ https://issues.apache.org/jira/browse/SOLR-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-2192: --- Attachment: SOLR-2192.patch Here's a patch that synchronizes on runners only enough to call peek() StreamingUpdateSolrServer not thread safe - Key: SOLR-2192 URL: https://issues.apache.org/jira/browse/SOLR-2192 Project: Solr Issue Type: Bug Affects Versions: 1.4.1 Reporter: Yonik Seeley Attachments: SOLR-2192.patch test error method suggest thread safety violation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-3.x - Build # 512 - Still Failing
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/512/ 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.highlight.HighlighterTest Error Message: ERROR: SolrIndexSearcher opens=46 closes=45 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=46 closes=45 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:114) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:287) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:65) FAILED: junit.framework.TestSuite.org.apache.solr.spelling.SpellCheckCollatorTest Error Message: ERROR: SolrIndexSearcher opens=2 closes=1 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=2 closes=1 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:114) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:287) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:65) FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: ERROR: SolrIndexSearcher opens=39 closes=34 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=39 closes=34 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:114) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:287) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:65) Build Log (for compile errors): [...truncated 9847 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-3.x - Build # 513 - Still Failing
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/513/ 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.highlight.HighlighterTest Error Message: ERROR: SolrIndexSearcher opens=46 closes=45 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=46 closes=45 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:114) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:287) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:65) FAILED: junit.framework.TestSuite.org.apache.solr.spelling.SpellCheckCollatorTest Error Message: ERROR: SolrIndexSearcher opens=2 closes=1 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=2 closes=1 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:114) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:287) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:65) FAILED: junit.framework.TestSuite.org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest Error Message: ERROR: SolrIndexSearcher opens=39 closes=34 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=39 closes=34 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:114) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:287) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:65) Build Log (for compile errors): [...truncated 9752 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Resolved: (SOLR-2192) StreamingUpdateSolrServer not thread safe
[ https://issues.apache.org/jira/browse/SOLR-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-2192. Resolution: Fixed Fix Version/s: 4.0 3.1 1.4.2 StreamingUpdateSolrServer not thread safe - Key: SOLR-2192 URL: https://issues.apache.org/jira/browse/SOLR-2192 Project: Solr Issue Type: Bug Affects Versions: 1.4.1 Reporter: Yonik Seeley Fix For: 1.4.2, 3.1, 4.0 Attachments: SOLR-2192.patch test error method suggest thread safety violation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2010) Improvements to SpellCheckComponent Collate functionality
[ https://issues.apache.org/jira/browse/SOLR-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924391#action_12924391 ] Yonik Seeley commented on SOLR-2010: bq. James, I did the merge back to 3.x. FYI, you missed Robert's resource leak fixes to SpellCheckCollatorTest. Not sure what best practice is to catch stuff like this... if it's only a file or two, I guess check the history of each? I'm in the process of getting branch_3x to pass the searcher open/close test, so I'll handle this. Improvements to SpellCheckComponent Collate functionality - Key: SOLR-2010 URL: https://issues.apache.org/jira/browse/SOLR-2010 Project: Solr Issue Type: New Feature Components: clients - java, spellchecker Affects Versions: 1.4.1 Environment: Tested against trunk revision 966633 Reporter: James Dyer Assignee: Grant Ingersoll Priority: Minor Attachments: multiple_collations_as_an_array.patch, SOLR-2010.patch, SOLR-2010.patch, SOLR-2010.patch, SOLR-2010.patch, SOLR-2010.txt, SOLR-2010_141.patch, SOLR-2010_141.patch, SOLR-2010_shardRecombineCollations_993538.patch, SOLR-2010_shardRecombineCollations_999521.patch, SOLR-2010_shardSearchHandler_993538.patch, SOLR-2010_shardSearchHandler_999521.patch, solr_2010_3x.patch Improvements to SpellCheckComponent Collate functionality Our project requires a better Spell Check Collator. I'm contributing this as a patch to get suggestions for improvements and in case there is a broader need for these features. 1. Only return collations that are guaranteed to result in hits if re-queried (applying original fq params also). This is especially helpful when there is more than one correction per query. The 1.4 behavior does not verify that a particular combination will actually return hits. 2. Provide the option to get multiple collation suggestions 3. Provide extended collation results including the # of hits re-querying will return and a breakdown of each misspelled word and its correction. This patch is similar to what is described in SOLR-507 item #1. Also, this patch provides a viable workaround for the problem discussed in SOLR-1074. A dictionary could be created that combines the terms from the multiple fields. The collator then would prune out any spurious suggestions this would cause. This patch adds the following spellcheck parameters: 1. spellcheck.maxCollationTries - maximum # of collation possibilities to try before giving up. Lower values ensure better performance. Higher values may be necessary to find a collation that can return results. Default is 0, which maintains backwards-compatible behavior (do not check collations). 2. spellcheck.maxCollations - maximum # of collations to return. Default is 1, which maintains backwards-compatible behavior. 3. spellcheck.collateExtendedResult - if true, returns an expanded response format detailing collations found. default is false, which maintains backwards-compatible behavior. When true, output is like this (in context): lst name=spellcheck lst name=suggestions lst name=hopq int name=numFound94/int int name=startOffset7/int int name=endOffset11/int arr name=suggestion strhope/str strhow/str strhope/str strchops/str strhoped/str etc /arr lst name=faill int name=numFound100/int int name=startOffset16/int int name=endOffset21/int arr name=suggestion strfall/str strfails/str strfail/str strfill/str strfaith/str strall/str etc /arr /lst lst name=collation str name=collationQueryTitle:(how AND fails)/str int name=hits2/int lst name=misspellingsAndCorrections str name=hopqhow/str str name=faillfails/str /lst /lst lst name=collation str name=collationQueryTitle:(hope AND faith)/str int name=hits2/int lst name=misspellingsAndCorrections str
Lucene-Solr-tests-only-trunk - Build # 530 - Failure
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/530/ 1 tests failed. REGRESSION: org.apache.solr.TestDistributedSearch.testDistribSearch Error Message: Error executing query Stack Trace: org.apache.solr.client.solrj.SolrServerException: Error executing query at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:95) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:119) at org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:290) at org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:305) at org.apache.solr.TestDistributedSearch.doTest(TestDistributedSearch.java:103) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:568) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:882) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:848) Caused by: org.apache.solr.common.SolrException: org.apache.solr.client.solrj.SolrServerException: org.apache.commons.httpclient.NoHttpResponseException: The server localhost failed to respond org.apache.solr.common.SolrException: org.apache.solr.client.solrj.SolrServerException: org.apache.commons.httpclient.NoHttpResponseException: The server localhost failed to respond at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:318) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1359)at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) 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.headerComplete(HttpConnection.java:923) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by: org.apache.solr.client.solrj.SolrServerException: org.apache.commons.httpclient.NoHttpResponseException: The server localhost failed to respond at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:483) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.reque org.apache.solr.client.solrj.SolrServerException: org.apache.commons.httpclient.NoHttpResponseException: The server localhost failed to respond org.apache.solr.common.SolrException: org.apache.solr.client.solrj.SolrServerException: org.apache.commons.httpclient.NoHttpResponseException: The server localhost failed to respond at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:318) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1359)at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) 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.headerComplete(HttpConnection.java:923) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at
[jira] Issue Comment Edited: (SOLR-2010) Improvements to SpellCheckComponent Collate functionality
[
https://issues.apache.org/jira/browse/SOLR-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924391#action_12924391
]
Yonik Seeley edited comment on SOLR-2010 at 10/24/10 6:53 PM:
--
bq. James, I did the merge back to 3.x.
FYI, you missed Robert's resource leak fixes to SpellCheckCollatorTest.
Not sure what best practice is to catch stuff like this... if it's only a file
or two, I guess check the history of each?
edit: actually your backport to 3x didn't even touch SpellCheckCollatorTest. I
was misled by the fact that when you look at the history of
SpellCheckCollatorTest, it shows an update. But I guess it was just merge
properties. Ugh.
{noformat}
yo...@wolverine /cygdrive/c/code/lusolr_3x
$ svn log ./solr/src/test/org/apache/solr/spelling/SpellCheckCollatorTest.java
r1026000 | gsingers | 2010-10-21 09:48:34 -0400 (Thu, 21 Oct 2010) | 1 line
SOLR-2010, including Yonik's fix, SOLR-2181 -- hope I did this merge correctly
r1021439 | gsingers | 2010-10-11 13:32:11 -0400 (Mon, 11 Oct 2010) | 1 line
SOLR-2010: added richer support for spell checking collations
yo...@wolverine /cygdrive/c/code/lusolr_3x
$ svn diff -r 1021439:1026000
./solr/src/test/org/apache/solr/spelling/SpellCheckCollatorTest.java
yo...@wolverine /cygdrive/c/code/lusolr_3x
{noformat}
I'm in the process of getting branch_3x to pass the searcher open/close test,
so I'll handle this.
was (Author: ysee...@gmail.com):
bq. James, I did the merge back to 3.x.
FYI, you missed Robert's resource leak fixes to SpellCheckCollatorTest.
Not sure what best practice is to catch stuff like this... if it's only a file
or two, I guess check the history of each?
I'm in the process of getting branch_3x to pass the searcher open/close test,
so I'll handle this.
Improvements to SpellCheckComponent Collate functionality
-
Key: SOLR-2010
URL: https://issues.apache.org/jira/browse/SOLR-2010
Project: Solr
Issue Type: New Feature
Components: clients - java, spellchecker
Affects Versions: 1.4.1
Environment: Tested against trunk revision 966633
Reporter: James Dyer
Assignee: Grant Ingersoll
Priority: Minor
Attachments: multiple_collations_as_an_array.patch, SOLR-2010.patch,
SOLR-2010.patch, SOLR-2010.patch, SOLR-2010.patch, SOLR-2010.txt,
SOLR-2010_141.patch, SOLR-2010_141.patch,
SOLR-2010_shardRecombineCollations_993538.patch,
SOLR-2010_shardRecombineCollations_999521.patch,
SOLR-2010_shardSearchHandler_993538.patch,
SOLR-2010_shardSearchHandler_999521.patch, solr_2010_3x.patch
Improvements to SpellCheckComponent Collate functionality
Our project requires a better Spell Check Collator. I'm contributing this as
a patch to get suggestions for improvements and in case there is a broader
need for these features.
1. Only return collations that are guaranteed to result in hits if re-queried
(applying original fq params also). This is especially helpful when there is
more than one correction per query. The 1.4 behavior does not verify that a
particular combination will actually return hits.
2. Provide the option to get multiple collation suggestions
3. Provide extended collation results including the # of hits re-querying
will return and a breakdown of each misspelled word and its correction.
This patch is similar to what is described in SOLR-507 item #1. Also, this
patch provides a viable workaround for the problem discussed in SOLR-1074. A
dictionary could be created that combines the terms from the multiple fields.
The collator then would prune out any spurious suggestions this would cause.
This patch adds the following spellcheck parameters:
1. spellcheck.maxCollationTries - maximum # of collation possibilities to try
before giving up. Lower values ensure better performance. Higher values may
be necessary to find a collation that can return results. Default is 0,
which maintains backwards-compatible behavior (do not check collations).
2. spellcheck.maxCollations - maximum # of collations to return. Default is
1, which maintains backwards-compatible behavior.
3. spellcheck.collateExtendedResult - if true, returns an expanded response
format detailing collations found. default is false, which maintains
backwards-compatible behavior. When true, output is like this (in context):
lst name=spellcheck
lst name=suggestions
lst name=hopq
int name=numFound94/int
[jira] Commented: (SOLR-2010) Improvements to SpellCheckComponent Collate functionality
[ https://issues.apache.org/jira/browse/SOLR-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924397#action_12924397 ] Yonik Seeley commented on SOLR-2010: Still stuff messed up with the merge props I guess - when I try to merge in Robert's fixes, it does nothing (it thinks they are already merged). I guess I just need to copy the file at this point. Improvements to SpellCheckComponent Collate functionality - Key: SOLR-2010 URL: https://issues.apache.org/jira/browse/SOLR-2010 Project: Solr Issue Type: New Feature Components: clients - java, spellchecker Affects Versions: 1.4.1 Environment: Tested against trunk revision 966633 Reporter: James Dyer Assignee: Grant Ingersoll Priority: Minor Attachments: multiple_collations_as_an_array.patch, SOLR-2010.patch, SOLR-2010.patch, SOLR-2010.patch, SOLR-2010.patch, SOLR-2010.txt, SOLR-2010_141.patch, SOLR-2010_141.patch, SOLR-2010_shardRecombineCollations_993538.patch, SOLR-2010_shardRecombineCollations_999521.patch, SOLR-2010_shardSearchHandler_993538.patch, SOLR-2010_shardSearchHandler_999521.patch, solr_2010_3x.patch Improvements to SpellCheckComponent Collate functionality Our project requires a better Spell Check Collator. I'm contributing this as a patch to get suggestions for improvements and in case there is a broader need for these features. 1. Only return collations that are guaranteed to result in hits if re-queried (applying original fq params also). This is especially helpful when there is more than one correction per query. The 1.4 behavior does not verify that a particular combination will actually return hits. 2. Provide the option to get multiple collation suggestions 3. Provide extended collation results including the # of hits re-querying will return and a breakdown of each misspelled word and its correction. This patch is similar to what is described in SOLR-507 item #1. Also, this patch provides a viable workaround for the problem discussed in SOLR-1074. A dictionary could be created that combines the terms from the multiple fields. The collator then would prune out any spurious suggestions this would cause. This patch adds the following spellcheck parameters: 1. spellcheck.maxCollationTries - maximum # of collation possibilities to try before giving up. Lower values ensure better performance. Higher values may be necessary to find a collation that can return results. Default is 0, which maintains backwards-compatible behavior (do not check collations). 2. spellcheck.maxCollations - maximum # of collations to return. Default is 1, which maintains backwards-compatible behavior. 3. spellcheck.collateExtendedResult - if true, returns an expanded response format detailing collations found. default is false, which maintains backwards-compatible behavior. When true, output is like this (in context): lst name=spellcheck lst name=suggestions lst name=hopq int name=numFound94/int int name=startOffset7/int int name=endOffset11/int arr name=suggestion strhope/str strhow/str strhope/str strchops/str strhoped/str etc /arr lst name=faill int name=numFound100/int int name=startOffset16/int int name=endOffset21/int arr name=suggestion strfall/str strfails/str strfail/str strfill/str strfaith/str strall/str etc /arr /lst lst name=collation str name=collationQueryTitle:(how AND fails)/str int name=hits2/int lst name=misspellingsAndCorrections str name=hopqhow/str str name=faillfails/str /lst /lst lst name=collation str name=collationQueryTitle:(hope AND faith)/str int name=hits2/int lst name=misspellingsAndCorrections str name=hopqhope/str str name=faillfaith/str /lst /lst lst
Lucene-3.x - Build # 160 - Still Failing
Build: http://hudson.zones.apache.org/hudson/job/Lucene-3.x/160/ All tests passed Build Log (for compile errors): [...truncated 21249 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: possible to filter the output to commits@ list????
Another downside to the current situation - svn log shows all these updates to the mergeprops, so we're losing the real updates in the noise. Maybe we should try to merge only from trunk to branch_3x, so at least trunk says relatively clean. Making sense of branch_3x is getting very difficult. Example: yo...@wolverine /cygdrive/c/code/lusolr_3x $ svn log lucene/src/test/org/apache/lucene/search/spans/TestPayloadSpans.java r1026921 | yonik | 2010-10-24 20:23:17 -0400 (Sun, 24 Oct 2010) | 1 line tests: fix resource leaks (merge from trunk) r1026885 | yonik | 2010-10-24 16:56:54 -0400 (Sun, 24 Oct 2010) | 1 line SOLR-2192: sync runners in StreamingUpdateSolrServer.blockUntilFinished r1026873 | yonik | 2010-10-24 15:52:34 -0400 (Sun, 24 Oct 2010) | 1 line SOLR-2160: tests - use classloader from core resource loader r1026869 | yonik | 2010-10-24 15:24:39 -0400 (Sun, 24 Oct 2010) | 1 line SOLR-2162: tests should use multi-threaded connection manager r1026739 | koji | 2010-10-24 00:42:39 -0400 (Sun, 24 Oct 2010) | 1 line fix indent in DIH sample r1026593 | mikemccand | 2010-10-23 06:23:02 -0400 (Sat, 23 Oct 2010) | 1 line LUCENE-2618: allow optimize to complete during IW.close, take 2 r1026432 | mikemccand | 2010-10-22 13:59:16 -0400 (Fri, 22 Oct 2010) | 1 line LUCENE-2618: revert r1026337 | mikemccand | 2010-10-22 10:17:10 -0400 (Fri, 22 Oct 2010) | 1 line LUCENE-2618: make sure optimize merge complete even if a close is pending r1026170 | uschindler | 2010-10-21 18:39:44 -0400 (Thu, 21 Oct 2010) | 1 line merge: remove warning r1026053 | yonik | 2010-10-21 12:16:22 -0400 (Thu, 21 Oct 2010) | 1 line SOLR-2180: close request in finally block r1026035 | yonik | 2010-10-21 11:49:45 -0400 (Thu, 21 Oct 2010) | 1 line tests: fix resource leaks, convert to Junit4 (merged from trunk) r1026024 | yonik | 2010-10-21 11:09:32 -0400 (Thu, 21 Oct 2010) | 1 line axe extra distrib test (merge trunk 1022805) r1026000 | gsingers | 2010-10-21 09:48:34 -0400 (Thu, 21 Oct 2010) | 1 line SOLR-2010, including Yonik's fix, SOLR-2181 -- hope I did this merge correctly r1025931 | mikemccand | 2010-10-21 06:29:01 -0400 (Thu, 21 Oct 2010) | 1 line fix MTQ.CutOffTermCollector to check limits after adding term, not before r1025606 | rmuir | 2010-10-20 10:51:12 -0400 (Wed, 20 Oct 2010) | 1 line LUCENE-1938: Precedence query parser using the contrib/queryparser framework r1024481 | yonik | 2010-10-19 21:27:57 -0400 (Tue, 19 Oct 2010) | 1 line SOLR-2197: wait for search executor to close before closing main server (merge trunk 1024476) r1024409 | uschindler | 2010-10-19 16:57:52 -0400 (Tue, 19 Oct 2010) | 1 line LUCENE-2556: Improve memory usage after cloning TermAttribute r1024405 | rmuir | 2010-10-19 16:46:23 -0400 (Tue, 19 Oct 2010) | 1 line LUCENE-1937: add methods to manipulate QueryNodeProcessorPipeline elements r1024258 | rmuir | 2010-10-19 11:04:11 -0400 (Tue, 19 Oct 2010) | 1 line SOLR-1794: Dataimport of CLOB fields fails when getCharacterStream() is defined in a superclass r1024223 | rmuir | 2010-10-19 08:59:48 -0400 (Tue, 19 Oct 2010) | 1 line LUCENE-2652: remove obselete runners, they are inconsistent with @beforeClass and obselete in the build today r1024197 | mikemccand | 2010-10-19 06:27:19 -0400 (Tue, 19 Oct 2010) | 1 line add some missing super.setParams so alg.toString shows the params r1023877 | uschindler | 2010-10-18
Lucene-Solr-tests-only-3.x - Build # 521 - Failure
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/521/ 3 tests failed. FAILED: org.apache.solr.util.TestUtils.testRAMDirectory Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.handler.TestCSVLoader.xml.init Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/test-results/TEST-org.apache.solr.handler.TestCSVLoader.xml was length 0 FAILED: TEST-org.apache.solr.spelling.FileBasedSpellCheckerTest.xml.init Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/test-results/TEST-org.apache.solr.spelling.FileBasedSpellCheckerTest.xml was length 0 Build Log (for compile errors): [...truncated 146197 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-3.x - Build # 523 - Failure
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/523/ 2 tests failed. FAILED: org.apache.solr.velocity.VelocityResponseWriterTest.testFocusQueryParser Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.search.TestExtendedDismaxParser.xml.init Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/test-results/TEST-org.apache.solr.search.TestExtendedDismaxParser.xml was length 0 Build Log (for compile errors): [...truncated 191526 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2191) Change SolrException cstrs that take Throwable to default to alreadyLogged=false
[ https://issues.apache.org/jira/browse/SOLR-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2191: -- Attachment: SOLR-2191.patch patch that enables the logging of a whole slew of exceptions Change SolrException cstrs that take Throwable to default to alreadyLogged=false Key: SOLR-2191 URL: https://issues.apache.org/jira/browse/SOLR-2191 Project: Solr Issue Type: Bug Reporter: Mark Miller Fix For: Next Attachments: SOLR-2191.patch Because of misuse, many exceptions are now not logged at all - can be painful when doing dev. I think we should flip this setting and work at removing any double logging - losing logging is worse (and it almost looks like we lose more logging than we would get in double logging) - and bad solrexception/logging patterns are proliferating. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (SOLR-2193) Re-architect Update Handler
Re-architect Update Handler --- Key: SOLR-2193 URL: https://issues.apache.org/jira/browse/SOLR-2193 Project: Solr Issue Type: Improvement Reporter: Mark Miller Fix For: Next The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we know do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit. 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2193) Re-architect Update Handler
[ https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924427#action_12924427 ] Mark Miller commented on SOLR-2193: --- I've been playing with a patch the keeps the IndexWriter open always (shares them across core reloads) and drops our internal update locks - so far, all tests pass, but there are still issues to deal with. I'll post the patch once I work a few more things out. Won't cover everything - just a start to explore different ideas. Re-architect Update Handler --- Key: SOLR-2193 URL: https://issues.apache.org/jira/browse/SOLR-2193 Project: Solr Issue Type: Improvement Reporter: Mark Miller Fix For: Next The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we know do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit. 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2193) Re-architect Update Handler
[ https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2193: -- Description: The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we now do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit (still lazy IW init though). 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. was: The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we know do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit. 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. Re-architect Update Handler --- Key: SOLR-2193 URL: https://issues.apache.org/jira/browse/SOLR-2193 Project: Solr Issue Type: Improvement Reporter: Mark Miller Fix For: Next The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we now do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit (still lazy IW init though). 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12924428#action_12924428 ] Mark Miller commented on SOLR-1897: --- This went in with cloud - thought I had resolved this. I'll make a changes entry and resolve soon. 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: Next Attachments: SOLR-1897.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-1962) Index directory disagreement SolrCore#initIndex
[
https://issues.apache.org/jira/browse/SOLR-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924429#action_12924429
]
Mark Miller commented on SOLR-1962:
---
I'm going to commit this tomorrow.
Index directory disagreement SolrCore#initIndex
---
Key: SOLR-1962
URL: https://issues.apache.org/jira/browse/SOLR-1962
Project: Solr
Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
Fix For: Next
Attachments: SOLR-1962.patch
getNewIndexDir is widely used in this method - but then when a new index is
created, getIndexDir is used:
{code}
// Create the index if it doesn't exist.
if(!indexExists) {
log.warn(logid+Solr index directory ' + new File(getNewIndexDir())
+ ' doesn't exist.
+ Creating new index...);
SolrIndexWriter writer = new SolrIndexWriter(SolrCore.initIndex,
getIndexDir(), getDirectoryFactory(), true, schema,
solrConfig.mainIndexConfig, solrDelPolicy);
writer.close();
}
{code}
also this piece uses getIndexDir():
{code}
if (indexExists firstTime removeLocks) {
// to remove locks, the directory must already exist... so we create
it
// if it didn't exist already...
Directory dir = SolrIndexWriter.getDirectory(getIndexDir(),
getDirectoryFactory(), solrConfig.mainIndexConfig);
if (dir != null) {
if (IndexWriter.isLocked(dir)) {
log.warn(logid+WARNING: Solr index directory ' + getIndexDir()
+ ' is locked. Unlocking...);
IndexWriter.unlock(dir);
}
dir.close();
}
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-1674) improve analysis tests, cut over to new API
[ https://issues.apache.org/jira/browse/SOLR-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924431#action_12924431 ] Mark Miller commented on SOLR-1674: --- Going to close this if no one objects... improve analysis tests, cut over to new API --- Key: SOLR-1674 URL: https://issues.apache.org/jira/browse/SOLR-1674 Project: Solr Issue Type: Test Components: Schema and Analysis Reporter: Robert Muir Assignee: Mark Miller Fix For: 1.5, 3.1, 4.0 Attachments: SOLR-1674.patch, SOLR-1674.patch, SOLR-1674_speedup.patch This patch * converts all analysis tests to use the new tokenstream api * converts most tests to use the more stringent assertion mechanisms from lucene * adds new tests to improve coverage Most bugs found by more stringent testing have been fixed, with the exception of SynonymFilter. The problems with this filter are more serious, the previous tests were essentially a no-op. The new tests for SynonymFilter test the current behavior, but have FIXMEs with what I think the old test wanted to expect in the comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Lucene-Solr-tests-only-3.x - Build # 524 - Still Failing
Build: http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/524/ 2 tests failed. FAILED: org.apache.solr.util.PrimUtilsTest.testFaceting Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.xml.init Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/solr/build/test-results/TEST-org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.xml was length 0 Build Log (for compile errors): [...truncated 179694 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (SOLR-2193) Re-architect Update Handler
[ https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-2193: --- Description: The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we now do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit (still lazy IW init though). 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. 6. Keep microsharding in mind (maintain logical index as multiple physical indexes) was: The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we now do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit (still lazy IW init though). 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. Re-architect Update Handler --- Key: SOLR-2193 URL: https://issues.apache.org/jira/browse/SOLR-2193 Project: Solr Issue Type: Improvement Reporter: Mark Miller Fix For: Next The update handler needs an overhaul. A few goals I think we might want to look at: 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like UpdateHandler, DefaultUpdateHandler 2. Expose the SolrIndexWriter in the api or add the proper abstractions to get done what we now do with special casing: if (directupdatehandler2) success else failish 3. Stop closing the IndexWriter and start using commit (still lazy IW init though). 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level. 5. Keep NRT support in mind. 6. Keep microsharding in mind (maintain logical index as multiple physical indexes) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
