Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
+1 (According to Digy's suggestion) On Mon, May 9, 2011 at 10:04 PM, Troy Howard thowar...@gmail.com wrote: All, Please cast your votes regarding the topic of .Net Framework support. The question on the table is: Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 Framework? Some options are: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. [0] - Yes, focus on the latest .Net Framework, but also include patches and/or preprocessor directives and conditional compilation blocks to include support for 2.0 when needed. New features, performance, and backwards compatibility are all equally important and it's worth the additional complexity and coding work to meet all of those goals. [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. This vote is not limited to the Apache Lucene.Net IPMC. All users/contributors/committers/mailing list lurkers are welcome to cast their votes with an equal weight. This has been cross posted to both the dev and user mailing lists. Thanks, Troy
Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
+1 one option is that we could go forward with .NET 4, but still keep a fix branch that keeps the current .NET 2 based version free from bugs and security issues that ppl report. Simone On Tue, May 10, 2011 at 9:18 AM, Amanuel Workneh ma...@rotselleri.comwrote: +1 (According to Digy's suggestion) On Mon, May 9, 2011 at 10:04 PM, Troy Howard thowar...@gmail.com wrote: All, Please cast your votes regarding the topic of .Net Framework support. The question on the table is: Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 Framework? Some options are: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. [0] - Yes, focus on the latest .Net Framework, but also include patches and/or preprocessor directives and conditional compilation blocks to include support for 2.0 when needed. New features, performance, and backwards compatibility are all equally important and it's worth the additional complexity and coding work to meet all of those goals. [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. This vote is not limited to the Apache Lucene.Net IPMC. All users/contributors/committers/mailing list lurkers are welcome to cast their votes with an equal weight. This has been cross posted to both the dev and user mailing lists. Thanks, Troy -- Simone Chiaretta Microsoft MVP ASP.NET - ASPInsider Blog: http://codeclimber.net.nz RSS: http://feeds2.feedburner.com/codeclimber twitter: @simonech Any sufficiently advanced technology is indistinguishable from magic Life is short, play hard
RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
This is my +1 as well Date: Tue, 10 May 2011 09:24:07 +0200 From: simone.chiare...@gmail.com To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 +1 one option is that we could go forward with .NET 4, but still keep a fix branch that keeps the current .NET 2 based version free from bugs and security issues that ppl report. Simone On Tue, May 10, 2011 at 9:18 AM, Amanuel Workneh wrote: +1 (According to Digy's suggestion) On Mon, May 9, 2011 at 10:04 PM, Troy Howard wrote: All, Please cast your votes regarding the topic of .Net Framework support. The question on the table is: Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 Framework? Some options are: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. [0] - Yes, focus on the latest .Net Framework, but also include patches and/or preprocessor directives and conditional compilation blocks to include support for 2.0 when needed. New features, performance, and backwards compatibility are all equally important and it's worth the additional complexity and coding work to meet all of those goals. [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. This vote is not limited to the Apache Lucene.Net IPMC. All users/contributors/committers/mailing list lurkers are welcome to cast their votes with an equal weight. This has been cross posted to both the dev and user mailing lists. Thanks, Troy -- Simone Chiaretta Microsoft MVP ASP.NET - ASPInsider Blog: http://codeclimber.net.nz RSS: http://feeds2.feedburner.com/codeclimber twitter: @simonech Any sufficiently advanced technology is indistinguishable from magic Life is short, play hard
RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
+1, go for .NET 4... Thanks -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: 09 May 2011 21:05 To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 All, Please cast your votes regarding the topic of .Net Framework support. The question on the table is: Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 Framework? Some options are: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. [0] - Yes, focus on the latest .Net Framework, but also include patches and/or preprocessor directives and conditional compilation blocks to include support for 2.0 when needed. New features, performance, and backwards compatibility are all equally important and it's worth the additional complexity and coding work to meet all of those goals. [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. This vote is not limited to the Apache Lucene.Net IPMC. All users/contributors/committers/mailing list lurkers are welcome to cast their votes with an equal weight. This has been cross posted to both the dev and user mailing lists. Thanks, Troy
Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
+1, but I'm partial to 0 if the demand is there for it. I don't mind keeping up support for 2.0, in a separate branch, for a set amount of time. On Tue, May 10, 2011 at 2:01 AM, Moray McConnachie mmcco...@oxford-analytica.com wrote: PS: If you are supporting .NET 3.5 then you get .NET 2.0 support anyway, you just have to bin-deploy the .NET 3.5 dependencies (System.Core, etc) since they are all the same CLR Aaron Powell Aaron, I think the move to 4.0 is actually to stop supporting 3.5 as well judging by later emails... Moray - Moray McConnachie Director of IT+44 1865 261 600 Oxford Analytica http://www.oxan.com - Disclaimer This message and any attachments are confidential and/or privileged. If this has been sent to you in error, please do not use, retain or disclose them, and contact the sender as soon as possible. Oxford Analytica Ltd Registered in England: No. 1196703 5 Alfred Street, Oxford United Kingdom, OX1 4EH -
Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
+1, burn the ships. On Tue, May 10, 2011 at 12:43 PM, Christopher Currens currens.ch...@gmail.com wrote: +1, but I'm partial to 0 if the demand is there for it. I don't mind keeping up support for 2.0, in a separate branch, for a set amount of time. On Tue, May 10, 2011 at 2:01 AM, Moray McConnachie mmcco...@oxford-analytica.com wrote: PS: If you are supporting .NET 3.5 then you get .NET 2.0 support anyway, you just have to bin-deploy the .NET 3.5 dependencies (System.Core, etc) since they are all the same CLR Aaron Powell Aaron, I think the move to 4.0 is actually to stop supporting 3.5 as well judging by later emails... Moray - Moray McConnachie Director of IT +44 1865 261 600 Oxford Analytica http://www.oxan.com - Disclaimer This message and any attachments are confidential and/or privileged. If this has been sent to you in error, please do not use, retain or disclose them, and contact the sender as soon as possible. Oxford Analytica Ltd Registered in England: No. 1196703 5 Alfred Street, Oxford United Kingdom, OX1 4EH -
[Lucene.Net] OT: Wyatt's expression was - RE: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
I've cast my vote already, but +1 to Wyatt's expression -Original Message- From: Wyatt Barnett [mailto:wyatt.barn...@gmail.com] Sent: Tuesday, May 10, 2011 12:46 PM To: lucene-net-dev@lucene.apache.org Subject: Re: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 +1, burn the ships. On Tue, May 10, 2011 at 12:43 PM, Christopher Currens currens.ch...@gmail.com wrote: +1, but I'm partial to 0 if the demand is there for it. I don't mind keeping up support for 2.0, in a separate branch, for a set amount of time. On Tue, May 10, 2011 at 2:01 AM, Moray McConnachie mmcco...@oxford-analytica.com wrote: PS: If you are supporting .NET 3.5 then you get .NET 2.0 support anyway, you just have to bin-deploy the .NET 3.5 dependencies (System.Core, etc) since they are all the same CLR Aaron Powell Aaron, I think the move to 4.0 is actually to stop supporting 3.5 as well judging by later emails... Moray - Moray McConnachie Director of IT +44 1865 261 600 Oxford Analytica http://www.oxan.com - Disclaimer This message and any attachments are confidential and/or privileged. If this has been sent to you in error, please do not use, retain or disclose them, and contact the sender as soon as possible. Oxford Analytica Ltd Registered in England: No. 1196703 5 Alfred Street, Oxford United Kingdom, OX1 4EH -
[jira] [Commented] (PYLUCENE-9) QueryParser replacing stop words with wildcards
[ https://issues.apache.org/jira/browse/PYLUCENE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031259#comment-13031259 ] Christopher Currens commented on PYLUCENE-9: I've posted a question to the java-lucene list, however, I'm sure it won't help at all. The simple fact is that the lucene 3.0 jar parses the query as ft:calendar item msg. The *same* lucene 3.0 jar when invoked from pylucene, produces ft:calendar item ? msg for me, on both windows and ubuntu boxes. I suppose this just might be an issue with jcc? I've been able to produce this both on my boxes at work, and my box at home, both producing the incorrect output. Perhaps I'm most curious if this can be reproduced by any developer for pylucene, or if its just some crazy environment issue happening on my boxes and everyone else I know. QueryParser replacing stop words with wildcards --- Key: PYLUCENE-9 URL: https://issues.apache.org/jira/browse/PYLUCENE-9 Project: PyLucene Issue Type: Bug Environment: Windows XP 32-bit Sp3, Ubuntu 10.04.2 LTS i686 GNU/Linux, jdk1.6.0_23 Reporter: Christopher Currens Was using query parser to build a query. In Java Lucene (as well as Lucene.Net), the query Calendar Item as Msg (quotes included), is parsed properly as FullText:calendar item msg in Java Lucene and Lucene.Net. In pylucene, it is parsed as: FullText:calendar item ? msg. This causes obvious problems when comparing search results from python, java and .net. Initially, I thought it was the Analyzer I was using, but I've tried the StandardAnalyzer and StopAnalyzer, which work properly in Java and .Net, but not pylucene. Here is code I've used to reproduce the issue: from lucene import StandardAnalyzer, StopAnalyzer, QueryParser, Version analyzer = StandardAnalyzer(Version.LUCENE_30) query = QueryParser(Version.LUCENE_30, FullText, analyzer) parsedQuery = query.parse(\Calendar Item as Msg\) parsedQuery Query: FullText:calendar item ? msg analyzer = StopAnalyzer(Version.LUCENE_30) query = QueryParser(Version.LUCENE_30) parsedQuery = query.parse(\Calendar Item as Msg\) parsedQuery Query: FullText:calendar item ? msg I've noticed this in pylucene 2.9.4, 2.9.3, and 3.0.3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LUCENE-3018) Lucene Native Directory implementation need automated build
[ https://issues.apache.org/jira/browse/LUCENE-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031063#comment-13031063 ] Simon Willnauer commented on LUCENE-3018: - varun, can you update the build.xml with the solaris line. I think we are ready to commit once this is in so I will take over once you upload a new patch. simon Lucene Native Directory implementation need automated build --- Key: LUCENE-3018 URL: https://issues.apache.org/jira/browse/LUCENE-3018 Project: Lucene - Java Issue Type: Wish Components: Build Affects Versions: 4.0 Reporter: Simon Willnauer Assignee: Varun Thacker Priority: Minor Fix For: 4.0 Attachments: LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, cpptasks-1.0b5.jar, cpptasks-LICENSE-ASL.txt, cpptasks.jar, cpptasks.jar Currently the native directory impl in contrib/misc require manual action to compile the c code (partially) documented in https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/contrib/misc/src/java/overview.html yet it would be nice if we had an ant task and documentation for all platforms how to compile them and set up the prerequisites. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3018) Lucene Native Directory implementation need automated build
[ https://issues.apache.org/jira/browse/LUCENE-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated LUCENE-3018: -- Attachment: LUCENE-3018.patch I added the solaris line but I guess it will be useful only after LUCENE-2795 is patched. Lucene Native Directory implementation need automated build --- Key: LUCENE-3018 URL: https://issues.apache.org/jira/browse/LUCENE-3018 Project: Lucene - Java Issue Type: Wish Components: Build Affects Versions: 4.0 Reporter: Simon Willnauer Assignee: Varun Thacker Priority: Minor Fix For: 4.0 Attachments: LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, LUCENE-3018.patch, cpptasks-1.0b5.jar, cpptasks-LICENSE-ASL.txt, cpptasks.jar, cpptasks.jar Currently the native directory impl in contrib/misc require manual action to compile the c code (partially) documented in https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/contrib/misc/src/java/overview.html yet it would be nice if we had an ant task and documentation for all platforms how to compile them and set up the prerequisites. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: 'waiting on condition' caused by DirectUpdateHandler2.commit - Solr-1.3
Hi Bernard, Are you using the latest Java 6? Please see here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6741489 We have seen similar bugs in Lucene itself, too (SpellChecker as far as I know). Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Bernhard C Gass [mailto:bg...@apple.com] Sent: Monday, May 09, 2011 10:43 PM To: dev@lucene.apache.org Subject: 'waiting on condition' caused by DirectUpdateHandler2.commit - Solr-1.3 I found locking issues reported against 1.2 and 1.4 on the mailing lists, but not against 1.3. We are running five Solr-1.3 shards under OSX on Tomcat under JDK-1.6 without any problems for quite a while. We copied the instance over to a Linux environment and now observe occasional deadlocks. This shard would lock and never recover. Each time a different shard would would lock. Any ideas or recommendations? Regards, Bernhard Below the stack trace: Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.2-b04 mixed mode): http-12003-2 daemon prio=10 tid=0x5c45f800 nid=0x573 in Object.wait() [0x42391000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x2aaaea0bf008 (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:423) - locked 0x2aaaea0bf008 (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:449) at java.lang.Thread.run(Thread.java:619) http-12003-1 daemon prio=10 tid=0x5c714000 nid=0x50c9 waiting on condition [0x4228f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2aaae19f2238 (a java.util.concurrent.FutureTask$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterr upt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInt erruptibly(AbstractQueuedSynchronizer.java:905) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterr uptibly(AbstractQueuedSynchronizer.java:1217) at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler 2.java:389) at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(Run UpdateProcessorFactory.java:77) at org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandle rUtils.java:104) at org.apache.solr.handler.XmlUpdateRequestHandler.handleRequestBody(Xm lUpdateRequestHandler.java:113) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandl erBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:3 03 ) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java: 232 ) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application Fi lterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ai n.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextVal ve.java:191) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.ja va:269) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java :81) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java: 128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1 02) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2 93) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84 9) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proces s(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) http-12003-Acceptor-0 daemon prio=10 tid=0x2aab181de800 nid=0x5088 runnable [0x41831000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native
[jira] [Updated] (SOLR-2448) Upgrade Carrot2 to version 3.5.0
[ https://issues.apache.org/jira/browse/SOLR-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislaw Osinski updated SOLR-2448: Attachment: SOLR-2448-2449-2450-2505-trunk.zip Hi, we've finally [released Carrot2 3.5.0|http://project.carrot2.org/release-3.5.0], so I'm attaching the patch (git) against Solr trunk for your review. The patch contains several separate commits related to the upgrade (SOLR-2448, SOLR-2449, SOLR-2450, SOLR-2505), I hope it will be easier to review this way. One thing I'm wondering about is Maven artifact generation that seems to be gone from trunk contribs (compared to the 3.x branch). Let me know if I need to update the dependencies/version numbers anywhere. The patch for Solr 3.x is in the works, we need to release JDK1.5-compatible version of some of the dependencies (HPPC) to make it happen. Upgrade Carrot2 to version 3.5.0 Key: SOLR-2448 URL: https://issues.apache.org/jira/browse/SOLR-2448 Project: Solr Issue Type: Task Components: contrib - Clustering Reporter: Stanislaw Osinski Assignee: Stanislaw Osinski Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2448-2449-2450-2505-trunk.zip, SOLR-2448.zip Carrot2 version 3.5.0 should be available very soon. After the upgrade, it will be possible to implement a few improvements to the clustering plugin; I'll file separate issues for these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2448) Upgrade Carrot2 to version 3.5.0
[ https://issues.apache.org/jira/browse/SOLR-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislaw Osinski updated SOLR-2448: Attachment: (was: SOLR-2448.zip) Upgrade Carrot2 to version 3.5.0 Key: SOLR-2448 URL: https://issues.apache.org/jira/browse/SOLR-2448 Project: Solr Issue Type: Task Components: contrib - Clustering Reporter: Stanislaw Osinski Assignee: Stanislaw Osinski Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2448-2449-2450-2505-trunk.zip Carrot2 version 3.5.0 should be available very soon. After the upgrade, it will be possible to implement a few improvements to the clustering plugin; I'll file separate issues for these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 7915 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7915/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestMultiSearcherRanking.testOneTermQuery Error Message: expected:one [foobar three multiT]hree but was:one [blah t]hree Stack Trace: at org.apache.lucene.search.TestMultiSearcherRanking.checkQuery(TestMultiSearcherRanking.java:101) at org.apache.lucene.search.TestMultiSearcherRanking.testOneTermQuery(TestMultiSearcherRanking.java:42) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1156) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1084) Build Log (for compile errors): [...truncated 5270 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2448) Upgrade Carrot2 to version 3.5.0
[ https://issues.apache.org/jira/browse/SOLR-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031133#comment-13031133 ] Steven Rowe commented on SOLR-2448: --- Hi Stanisław, bq. One thing I'm wondering about is Maven artifact generation that seems to be gone from trunk contribs (compared to the 3.x branch). I'll look into it. Upgrade Carrot2 to version 3.5.0 Key: SOLR-2448 URL: https://issues.apache.org/jira/browse/SOLR-2448 Project: Solr Issue Type: Task Components: contrib - Clustering Reporter: Stanislaw Osinski Assignee: Stanislaw Osinski Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2448-2449-2450-2505-trunk.zip Carrot2 version 3.5.0 should be available very soon. After the upgrade, it will be possible to implement a few improvements to the clustering plugin; I'll file separate issues for these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-3.x - Build # 7915 - Failure
I committed a fix... Mike http://blog.mikemccandless.com On Tue, May 10, 2011 at 6:55 AM, Apache Jenkins Server hud...@hudson.apache.org wrote: Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7915/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestMultiSearcherRanking.testOneTermQuery Error Message: expected:one [foobar three multiT]hree but was:one [blah t]hree Stack Trace: at org.apache.lucene.search.TestMultiSearcherRanking.checkQuery(TestMultiSearcherRanking.java:101) at org.apache.lucene.search.TestMultiSearcherRanking.testOneTermQuery(TestMultiSearcherRanking.java:42) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1156) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1084) Build Log (for compile errors): [...truncated 5270 lines...] - 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: 'waiting on condition' caused by DirectUpdateHandler2.commit - Solr-1.3
Hmm, one thread is actively running a query (stuck building up field cache), while another thread is waiting to acquire lock to commit? Are you sure this is deadlock, vs it taks a really really long time to init the field cache for this one query? Also, you might want to try the tiny patch on https://issues.apache.org/jira/browse/SOLR-2342 -- this gives commit priority over threads just doing searching, when it tries to acquire its lock. Mike http://blog.mikemccandless.com On Mon, May 9, 2011 at 4:42 PM, Bernhard C Gass bg...@apple.com wrote: I found locking issues reported against 1.2 and 1.4 on the mailing lists, but not against 1.3. We are running five Solr-1.3 shards under OSX on Tomcat under JDK-1.6 without any problems for quite a while. We copied the instance over to a Linux environment and now observe occasional deadlocks. This shard would lock and never recover. Each time a different shard would would lock. Any ideas or recommendations? Regards, Bernhard Below the stack trace: Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.2-b04 mixed mode): http-12003-2 daemon prio=10 tid=0x5c45f800 nid=0x573 in Object.wait() [0x42391000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x2aaaea0bf008 (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:423) - locked 0x2aaaea0bf008 (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:449) at java.lang.Thread.run(Thread.java:619) http-12003-1 daemon prio=10 tid=0x5c714000 nid=0x50c9 waiting on condition [0x4228f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2aaae19f2238 (a java.util.concurrent.FutureTask$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217) at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:389) at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:77) at org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:104) at org.apache.solr.handler.XmlUpdateRequestHandler.handleRequestBody(XmlUpdateRequestHandler.java:113) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:269) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:81) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) http-12003-Acceptor-0 daemon prio=10 tid=0x2aab181de800 nid=0x5088 runnable [0x41831000] java.lang.Thread.State: RUNNABLE at
[jira] [Commented] (SOLR-2502) Add in Examples/Documentation on the new Join functionality
[ https://issues.apache.org/jira/browse/SOLR-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031144#comment-13031144 ] Erik Hatcher commented on SOLR-2502: My main concern is the overloading of the example data and tutorial to carry along too much of this complexity - complexity that wouldn't be needed in many real-world scenarios. It's great to have examples of this stuff, but our kitchen sink is getting pretty full and dirty. Splitting the example into multiple different examples/scenarios each with their own simple light-weight UI's is where I'd rather see this go. Add in Examples/Documentation on the new Join functionality --- Key: SOLR-2502 URL: https://issues.apache.org/jira/browse/SOLR-2502 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Priority: Minor Attachments: SOLR-2502.patch, SOLR-2502.patch As the title says, add in an example and docs on the new Join functionality added via SOLR-2272. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2448) Upgrade Carrot2 to version 3.5.0
[ https://issues.apache.org/jira/browse/SOLR-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031162#comment-13031162 ] Steven Rowe commented on SOLR-2448: --- bq. Hi, we've finally released Carrot2 3.5.0, so I'm attaching the patch (git) against Solr trunk for your review. I've never used git. I took a peek at the patch and there is zero chance of using it directly with Subversion. Do you know how I can convert it to use with Subversion? Upgrade Carrot2 to version 3.5.0 Key: SOLR-2448 URL: https://issues.apache.org/jira/browse/SOLR-2448 Project: Solr Issue Type: Task Components: contrib - Clustering Reporter: Stanislaw Osinski Assignee: Stanislaw Osinski Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2448-2449-2450-2505-trunk.zip Carrot2 version 3.5.0 should be available very soon. After the upgrade, it will be possible to implement a few improvements to the clustering plugin; I'll file separate issues for these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2448) Upgrade Carrot2 to version 3.5.0
[ https://issues.apache.org/jira/browse/SOLR-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislaw Osinski updated SOLR-2448: Attachment: SOLR-2448-2449-2450-2505-svn.patch Hi Steven, Thanks for you help and apologies for git confusion, here's the SVN patch. After patching, you'd also need to delete: trunk/solr/contrib/clustering/lib/carrot2-core-3.4.2.jar trunk/solr/contrib/clustering/lib/hppc-0.3.1.jar and replace them with new versions: http://repo1.maven.org/maven2/org/carrot2/carrot2-core/3.5.0/carrot2-core-3.5.0.jar http://repo1.maven.org/maven2/com/carrotsearch/hppc/0.3.3/hppc-0.3.3.jar Upgrade Carrot2 to version 3.5.0 Key: SOLR-2448 URL: https://issues.apache.org/jira/browse/SOLR-2448 Project: Solr Issue Type: Task Components: contrib - Clustering Reporter: Stanislaw Osinski Assignee: Stanislaw Osinski Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2448-2449-2450-2505-svn.patch, SOLR-2448-2449-2450-2505-trunk.zip Carrot2 version 3.5.0 should be available very soon. After the upgrade, it will be possible to implement a few improvements to the clustering plugin; I'll file separate issues for these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2448) Upgrade Carrot2 to version 3.5.0
[ https://issues.apache.org/jira/browse/SOLR-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031186#comment-13031186 ] Stanislaw Osinski commented on SOLR-2448: - bq. So, I first tried running ant generate-maven-artifacts from solr/ on trunk, without applying your patches, and all artifacts, including contribs, are generated under solr/package/maven/. Are you using a different Ant target for Maven artifact generation? The target runs fine for me too (on the patched code). I just wanted to update the version number of the Carrot2 dependency, but couldn't find any file referencing the old number (3.4.2). Now I see that the generated solr-clustering POM XML has carrot2-core as a dependency, but does not specify the exact version number. I guess there's some more Maven magic I need to learn to understand this :-) Upgrade Carrot2 to version 3.5.0 Key: SOLR-2448 URL: https://issues.apache.org/jira/browse/SOLR-2448 Project: Solr Issue Type: Task Components: contrib - Clustering Reporter: Stanislaw Osinski Assignee: Stanislaw Osinski Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2448-2449-2450-2505-svn.patch, SOLR-2448-2449-2450-2505-trunk.zip Carrot2 version 3.5.0 should be available very soon. After the upgrade, it will be possible to implement a few improvements to the clustering plugin; I'll file separate issues for these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2448) Upgrade Carrot2 to version 3.5.0
[
https://issues.apache.org/jira/browse/SOLR-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031195#comment-13031195
]
Steven Rowe commented on SOLR-2448:
---
Versions for all dependencies for both Solr and Lucene are specified in one
place: the grandparent POM, in the root of the sources. Here's the
carrot2-core dependency (in the POM template under {{dev-tools/maven/}}):
http://svn.apache.org/viewvc/lucene/dev/trunk/dev-tools/maven/pom.xml.template?view=markup#l305
Upgrade Carrot2 to version 3.5.0
Key: SOLR-2448
URL: https://issues.apache.org/jira/browse/SOLR-2448
Project: Solr
Issue Type: Task
Components: contrib - Clustering
Reporter: Stanislaw Osinski
Assignee: Stanislaw Osinski
Priority: Minor
Fix For: 3.2, 4.0
Attachments: SOLR-2448-2449-2450-2505-svn.patch,
SOLR-2448-2449-2450-2505-trunk.zip
Carrot2 version 3.5.0 should be available very soon. After the upgrade, it
will be possible to implement a few improvements to the clustering plugin;
I'll file separate issues for these.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2448) Upgrade Carrot2 to version 3.5.0
[ https://issues.apache.org/jira/browse/SOLR-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031197#comment-13031197 ] Stanislaw Osinski commented on SOLR-2448: - bq. Versions for all dependencies for both Solr and Lucene are specified in one place: the grandparent POM, in the root of the sources. Everything is clear then, thanks! I'll update the version number and remove Carrot2 Maven repository, the latest Carrot2 binaries are now available from Maven central. Upgrade Carrot2 to version 3.5.0 Key: SOLR-2448 URL: https://issues.apache.org/jira/browse/SOLR-2448 Project: Solr Issue Type: Task Components: contrib - Clustering Reporter: Stanislaw Osinski Assignee: Stanislaw Osinski Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2448-2449-2450-2505-svn.patch, SOLR-2448-2449-2450-2505-trunk.zip Carrot2 version 3.5.0 should be available very soon. After the upgrade, it will be possible to implement a few improvements to the clustering plugin; I'll file separate issues for these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2448) Upgrade Carrot2 to version 3.5.0
[ https://issues.apache.org/jira/browse/SOLR-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031199#comment-13031199 ] Steven Rowe commented on SOLR-2448: --- bq. I'll [...] remove Carrot2 Maven repository, the latest Carrot2 binaries are now available from Maven central. Excellent! Upgrade Carrot2 to version 3.5.0 Key: SOLR-2448 URL: https://issues.apache.org/jira/browse/SOLR-2448 Project: Solr Issue Type: Task Components: contrib - Clustering Reporter: Stanislaw Osinski Assignee: Stanislaw Osinski Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2448-2449-2450-2505-svn.patch, SOLR-2448-2449-2450-2505-trunk.zip Carrot2 version 3.5.0 should be available very soon. After the upgrade, it will be possible to implement a few improvements to the clustering plugin; I'll file separate issues for these. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1316) 3
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031223#comment-13031223 ] David Smiley commented on SOLR-1316: Hoss, you inadvertently renamed the title from Create autosuggest component to the number 3. Please put it back. 3 - 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: 3.1 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, TST.zip, suggest.patch, suggest.patch, suggest.patch 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. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1316) Create autosuggest component
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-1316: --- Summary: Create autosuggest component (was: 3) 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: 3.1 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, TST.zip, suggest.patch, suggest.patch, suggest.patch 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. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1421) Ability to group search results by field
[ https://issues.apache.org/jira/browse/LUCENE-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031266#comment-13031266 ] Michael McCandless commented on LUCENE-1421: bq. I think that grouping code should be part of Lucene instead of Solr. +1 This is a very popular issue (currently tied for 2nd place in votes). Unfortunately, I think the single-pass collector attached here doesn't scale very well to large maxDoc and/or large number of unique groups. Also, it pulls a DocTermsIndex on the top-level reader (costly in an NRT/reopen setting since it's not per-segment). So I decided to factor out parts of Solr's current two-pass approach into a shared grouping module. The downside of the two-pass approach is you run the query twice, automatically halving your QPS. (It's even worse because the grouping itself is somewhat computing intensive too). To try to help mitigate this, I also added a new CachingCollector, which just holds hits (docID and optionally score) up to a max allowed RAM consumption, and can then replay them for the 2nd pass. In includes a max RAM setting so that if too many hits are found, it stops caching (and you must then re-execute the query). But one nice side effect of the two-phased approach is that sharding is in theory straightforward (I think?). Ie, all shards would do the first phase, concurrently, to get the top N groups. Then you merge-sort the resulting top groups, then run second phase (finding docs w/in the top groups) on all shards, then merge results from the same group across all shards. Ability to group search results by field Key: LUCENE-1421 URL: https://issues.apache.org/jira/browse/LUCENE-1421 Project: Lucene - Java Issue Type: New Feature Components: Search Reporter: Artyom Sokolov Priority: Minor Attachments: lucene-grouping.patch It would be awesome to group search results by specified field. Some functionality was provided for Apache Solr but I think it should be done in Core Lucene. There could be some useful information like total hits about collapsed data like total count and so on. Thanks, Artyom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-1421) Ability to group search results by field
[ https://issues.apache.org/jira/browse/LUCENE-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-1421: -- Assignee: Michael McCandless Ability to group search results by field Key: LUCENE-1421 URL: https://issues.apache.org/jira/browse/LUCENE-1421 Project: Lucene - Java Issue Type: New Feature Components: Search Reporter: Artyom Sokolov Assignee: Michael McCandless Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-1421.patch, lucene-grouping.patch It would be awesome to group search results by specified field. Some functionality was provided for Apache Solr but I think it should be done in Core Lucene. There could be some useful information like total hits about collapsed data like total count and so on. Thanks, Artyom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-1421) Ability to group search results by field
[ https://issues.apache.org/jira/browse/LUCENE-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1421: --- Attachment: LUCENE-1421.patch Initial rough patch. I think it's working well. I reused the test case from the original patch (thank you Martijn!), and also created a new random test case. There are still nocommits/sops/javadocs to clean up... but I think it's close. We cannot yet cutover Solr to this module because it doesn't support grouping by ValueSource (from a function query) nor by arbitrary query. (This refactoring groups by a single-valued indexed field.) I think we need to first refactor function queries (LUCENE-2883) and also filter caches out of Solr before cutting Solr over. I plan to backport this to 3.x as contrib/grouping. Ability to group search results by field Key: LUCENE-1421 URL: https://issues.apache.org/jira/browse/LUCENE-1421 Project: Lucene - Java Issue Type: New Feature Components: Search Reporter: Artyom Sokolov Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-1421.patch, lucene-grouping.patch It would be awesome to group search results by specified field. Some functionality was provided for Apache Solr but I think it should be done in Core Lucene. There could be some useful information like total hits about collapsed data like total count and so on. Thanks, Artyom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-1421) Ability to group search results by field
[ https://issues.apache.org/jira/browse/LUCENE-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-1421: --- Fix Version/s: 4.0 3.2 Ability to group search results by field Key: LUCENE-1421 URL: https://issues.apache.org/jira/browse/LUCENE-1421 Project: Lucene - Java Issue Type: New Feature Components: Search Reporter: Artyom Sokolov Assignee: Michael McCandless Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-1421.patch, lucene-grouping.patch It would be awesome to group search results by specified field. Some functionality was provided for Apache Solr but I think it should be done in Core Lucene. There could be some useful information like total hits about collapsed data like total count and so on. Thanks, Artyom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 7924 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/7924/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock 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:1282) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:557) Build Log (for compile errors): [...truncated 3241 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 7924 - Failure
I'm digging... Mike http://blog.mikemccandless.com On Tue, May 10, 2011 at 1:57 PM, Apache Jenkins Server hud...@hudson.apache.org wrote: Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/7924/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock 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:1282) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:557) Build Log (for compile errors): [...truncated 3241 lines...] - 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: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 7924 - Failure
I committed fix... false failure tickled by the cool new sneaky throttling MockDirWrapper now does! Mike http://blog.mikemccandless.com On Tue, May 10, 2011 at 1:57 PM, Apache Jenkins Server hud...@hudson.apache.org wrote: Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/7924/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock 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:1282) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:557) Build Log (for compile errors): [...truncated 3241 lines...] - 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: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4
+1 -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Monday, May 09, 2011 4:05 PM To: lucene-net-...@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: [Lucene.Net] VOTE: .NET 2.0 Framework Support After Apache Lucene.Net 2.9.4 All, Please cast your votes regarding the topic of .Net Framework support. The question on the table is: Should Apache Lucene.Net 2.9.4 be the last release which supports the .Net 2.0 Framework? Some options are: [+1] - Yes, move forward to the latest .Net Framework version, and drop support for 2.0 completely. New features and performance are more important than backwards compatibility. [0] - Yes, focus on the latest .Net Framework, but also include patches and/or preprocessor directives and conditional compilation blocks to include support for 2.0 when needed. New features, performance, and backwards compatibility are all equally important and it's worth the additional complexity and coding work to meet all of those goals. [-1] No, .Net Framework 2.0 should remain our target platform. Backwards compatibility is more important than new features and performance. This vote is not limited to the Apache Lucene.Net IPMC. All users/contributors/committers/mailing list lurkers are welcome to cast their votes with an equal weight. This has been cross posted to both the dev and user mailing lists. Thanks, Troy This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you, King Industries, Inc.
[jira] [Created] (LUCENE-3086) add ElisionsFilter to ItalianAnalyzer
add ElisionsFilter to ItalianAnalyzer - Key: LUCENE-3086 URL: https://issues.apache.org/jira/browse/LUCENE-3086 Project: Lucene - Java Issue Type: Improvement Reporter: Robert Muir Fix For: 3.2, 4.0 Attachments: LUCENE-3086.patch we set this up for french by default, but we don't for italian. we should enable it with the standard italian contractions (e.g. definite articles). the various stemmers for these languages assume this is already being taken care of and don't do anything about it... in general things like snowball assume really dumb tokenization, that you will split on the word-internal ', and they add these to stoplists. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3086) add ElisionsFilter to ItalianAnalyzer
[ https://issues.apache.org/jira/browse/LUCENE-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3086: Attachment: LUCENE-3086.patch add ElisionsFilter to ItalianAnalyzer - Key: LUCENE-3086 URL: https://issues.apache.org/jira/browse/LUCENE-3086 Project: Lucene - Java Issue Type: Improvement Reporter: Robert Muir Fix For: 3.2, 4.0 Attachments: LUCENE-3086.patch we set this up for french by default, but we don't for italian. we should enable it with the standard italian contractions (e.g. definite articles). the various stemmers for these languages assume this is already being taken care of and don't do anything about it... in general things like snowball assume really dumb tokenization, that you will split on the word-internal ', and they add these to stoplists. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-2984) Move hasVectors() hasProx() responsibility out of SegmentInfo to FieldInfos
[ https://issues.apache.org/jira/browse/LUCENE-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer reassigned LUCENE-2984: --- Assignee: Simon Willnauer Move hasVectors() hasProx() responsibility out of SegmentInfo to FieldInfos -- Key: LUCENE-2984 URL: https://issues.apache.org/jira/browse/LUCENE-2984 Project: Lucene - Java Issue Type: Improvement Components: Index Affects Versions: 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Spin-off from LUCENE-2881 which had this change already but due to some random failures related to this change I remove this part of the patch to make it more isolated and easier to test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 7924 - Failure
On Tue, May 10, 2011 at 8:02 PM, Michael McCandless luc...@mikemccandless.com wrote: I committed fix... false failure tickled by the cool new sneaky throttling MockDirWrapper now does! YAY! :) simon Mike http://blog.mikemccandless.com On Tue, May 10, 2011 at 1:57 PM, Apache Jenkins Server hud...@hudson.apache.org wrote: Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/7924/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriter.testThreadInterruptDeadlock 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:1282) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:557) Build Log (for compile errors): [...truncated 3241 lines...] - 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] (LUCENE-2984) Move hasVectors() hasProx() responsibility out of SegmentInfo to FieldInfos
[ https://issues.apache.org/jira/browse/LUCENE-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-2984: Attachment: LUCENE-2984.patch Attaching my current state. This patch moves all responsibility for hasVectors / hasProx out of SI into FIs. I also added some transactional code to FI that resets the FI#storeTermVector for a field if the TermVectors creation for that FI in the current segment has not successful. Move hasVectors() hasProx() responsibility out of SegmentInfo to FieldInfos -- Key: LUCENE-2984 URL: https://issues.apache.org/jira/browse/LUCENE-2984 Project: Lucene - Java Issue Type: Improvement Components: Index Affects Versions: 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: LUCENE-2984.patch Spin-off from LUCENE-2881 which had this change already but due to some random failures related to this change I remove this part of the patch to make it more isolated and easier to test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (PYLUCENE-9) QueryParser replacing stop words with wildcards
[ https://issues.apache.org/jira/browse/PYLUCENE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031284#comment-13031284 ] Christopher Currens commented on PYLUCENE-9: Hmm, the code I have is nearly identical, and when I pull it out of the contained code, it behaves as it should. I can't post the whole code, but the issue must be that there's a lingering Version.LUCENE_24 somewhere I suppose. I'll try figuring it out on my own, I'm glad to see its something idiotic I've done. :) QueryParser replacing stop words with wildcards --- Key: PYLUCENE-9 URL: https://issues.apache.org/jira/browse/PYLUCENE-9 Project: PyLucene Issue Type: Bug Environment: Windows XP 32-bit Sp3, Ubuntu 10.04.2 LTS i686 GNU/Linux, jdk1.6.0_23 Reporter: Christopher Currens Was using query parser to build a query. In Java Lucene (as well as Lucene.Net), the query Calendar Item as Msg (quotes included), is parsed properly as FullText:calendar item msg in Java Lucene and Lucene.Net. In pylucene, it is parsed as: FullText:calendar item ? msg. This causes obvious problems when comparing search results from python, java and .net. Initially, I thought it was the Analyzer I was using, but I've tried the StandardAnalyzer and StopAnalyzer, which work properly in Java and .Net, but not pylucene. Here is code I've used to reproduce the issue: from lucene import StandardAnalyzer, StopAnalyzer, QueryParser, Version analyzer = StandardAnalyzer(Version.LUCENE_30) query = QueryParser(Version.LUCENE_30, FullText, analyzer) parsedQuery = query.parse(\Calendar Item as Msg\) parsedQuery Query: FullText:calendar item ? msg analyzer = StopAnalyzer(Version.LUCENE_30) query = QueryParser(Version.LUCENE_30) parsedQuery = query.parse(\Calendar Item as Msg\) parsedQuery Query: FullText:calendar item ? msg I've noticed this in pylucene 2.9.4, 2.9.3, and 3.0.3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LUCENE-3084) MergePolicy.OneMerge.segments should be ListSegmentInfo not SegmentInfos
[ https://issues.apache.org/jira/browse/LUCENE-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-3084. Resolution: Fixed MergePolicy.OneMerge.segments should be ListSegmentInfo not SegmentInfos -- Key: LUCENE-3084 URL: https://issues.apache.org/jira/browse/LUCENE-3084 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-3084.patch SegmentInfos carries a bunch of fields beyond the list of SI, but for merging purposes these fields are unused. We should cutover to ListSI instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-1076) Allow MergePolicy to select non-contiguous merges
[ https://issues.apache.org/jira/browse/LUCENE-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reopened LUCENE-1076: I think we should change 3.2's default MP to TieredMP? This means docIDs may be reordered, since Tiered MP can merge out-of-order segments. Allow MergePolicy to select non-contiguous merges - Key: LUCENE-1076 URL: https://issues.apache.org/jira/browse/LUCENE-1076 Project: Lucene - Java Issue Type: Improvement Components: Index Affects Versions: 2.3 Reporter: Michael McCandless Assignee: Michael McCandless Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-1076-3x.patch, LUCENE-1076.patch, LUCENE-1076.patch, LUCENE-1076.patch I started work on this but with LUCENE-1044 I won't make much progress on it for a while, so I want to checkpoint my current state/patch. For backwards compatibility we must leave the default MergePolicy as selecting contiguous merges. This is necessary because some applications rely on temporal monotonicity of doc IDs, which means even though merges can re-number documents, the renumbering will always reflect the order in which the documents were added to the index. Still, for those apps that do not rely on this, we should offer a MergePolicy that is free to select the best merges regardless of whether they are continuguous. This requires fixing IndexWriter to accept such a merge, and, fixing LogMergePolicy to optionally allow it the freedom to do so. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2502) Add in Examples/Documentation on the new Join functionality
[ https://issues.apache.org/jira/browse/SOLR-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031305#comment-13031305 ] Grant Ingersoll commented on SOLR-2502: --- I think the data extension I've added is fairly reasonable (products are manufactured by a manufacturer). As for the overloading of the tutorial, I don't know. I'm not a UI guy, but I don't think it's too bad at this point. I'm not sure about splitting it out or not, as I think that will create a lot of redundancy in the configuration as well as in the example dir (similar to multicore, DIH, etc. which are a bit clunky now) which then becomes more confusing as it's not clear where to look for what. I think, ideally, we have a more holistic example that seamlessly ties in all the things and presents a single unified app that mirrors a real world application, such as a store. Add in Examples/Documentation on the new Join functionality --- Key: SOLR-2502 URL: https://issues.apache.org/jira/browse/SOLR-2502 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Priority: Minor Attachments: SOLR-2502.patch, SOLR-2502.patch As the title says, add in an example and docs on the new Join functionality added via SOLR-2272. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2984) Move hasVectors() hasProx() responsibility out of SegmentInfo to FieldInfos
[ https://issues.apache.org/jira/browse/LUCENE-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031350#comment-13031350 ] selckin commented on LUCENE-2984: - http://www.selckin.be/trunk-2984-patched.txt Move hasVectors() hasProx() responsibility out of SegmentInfo to FieldInfos -- Key: LUCENE-2984 URL: https://issues.apache.org/jira/browse/LUCENE-2984 Project: Lucene - Java Issue Type: Improvement Components: Index Affects Versions: 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.0 Attachments: LUCENE-2984.patch Spin-off from LUCENE-2881 which had this change already but due to some random failures related to this change I remove this part of the patch to make it more isolated and easier to test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2496) JSON Update Handler doesn't handle multiple docs properly
[
https://issues.apache.org/jira/browse/SOLR-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-2496:
---
Attachment: SOLR-2496.patch
Here's a patch that extends the current syntax with a simplified syntax that
allows an array of documents at the top level or inside an add command.
It also adds the ability to specify commitWithin and overwrite on the URL
(same as the CSVLoader).
Examples of new simplified syntax:
[{id:1},{id:2}]
{add:[{id:1},{id:2}]}
JSON Update Handler doesn't handle multiple docs properly
-
Key: SOLR-2496
URL: https://issues.apache.org/jira/browse/SOLR-2496
Project: Solr
Issue Type: Improvement
Components: update
Affects Versions: 3.1
Reporter: Neil Hooey
Labels: json, update
Attachments: SOLR-2496.patch
The following is the current Solr 3.1 format for sending multiple documents
by JSON. It's not analogous to the XML method, and isn't easily generated and
serialized from a hash in Perl, Python, Ruby, et al to JSON, because it has
duplicate keys for add.
It's cited at this page: http://wiki.apache.org/solr/UpdateJSON
Near the text: Here's a simple example of adding more than one document at
once:
{code}
{
add: {doc: {id : TestDoc1, title : test1} },
add: {doc: {id : TestDoc2, title : another test} }
}'
{code}
Here's a better format that's analogous to the XML method of submission, and
is easily serialized from a hash to JSON:
{code}
{
add: {
doc: [
{id : TestDoc1, title : test1},
{id : TestDoc2, title : another test},
],
},
}
{code}
The original XML method:
{code}
add
doc
field name=idTestDoc1fieldfield name=titletest1/field
/doc
doc
field name=idTestDoc2fieldfield
name=titletest2/field/field
/doc
/add
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 7930 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/7930/ No tests ran. Build Log (for compile errors): [...truncated 8703 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2504) Combined usage of Synonyms/SpellChecker causes java.lang.NullPointerException, when searching for a word out of synonyms.txt
[ https://issues.apache.org/jira/browse/SOLR-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031396#comment-13031396 ] Stefan Moises commented on SOLR-2504: - Just for the record - works now for me in trunk, too! Many thanks for the quick help! Combined usage of Synonyms/SpellChecker causes java.lang.NullPointerException, when searching for a word out of synonyms.txt Key: SOLR-2504 URL: https://issues.apache.org/jira/browse/SOLR-2504 Project: Solr Issue Type: Bug Components: clients - java, spellchecker Affects Versions: 3.1 Reporter: Jens Bertheau After migrating from 1.4 to 3.1 we experience the following behaviour: When SpellChecking is turned off, everything works fine. When Synonyms are *not* being used, everything works fine. When both, SpellChecking and Synonyms, are being used and a search is triggered, that contains at least one of the words out of synonyms.txt the following error is thrown: java.lang.NullPointerException at org.apache.lucene.util.AttributeSource.cloneAttributes(AttributeSource.java:542) at org.apache.solr.analysis.SynonymFilter.incrementToken(SynonymFilter.java:132) at org.apache.lucene.analysis.FilteringTokenFilter.incrementToken(FilteringTokenFilter.java:58) at org.apache.solr.handler.component.SpellCheckComponent.getTokens(SpellCheckComponent.java:485) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:131) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1360) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) The problem has been described already here: http://osdir.com/ml/solr-user.lucene.apache.org/2010-09/msg00945.html I have a report of a third person, experiencing the same problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2506) EOFException from SolrServer.queryAndStreamResponse() in /trunk
EOFException from SolrServer.queryAndStreamResponse() in /trunk
---
Key: SOLR-2506
URL: https://issues.apache.org/jira/browse/SOLR-2506
Project: Solr
Issue Type: Bug
Affects Versions: 4.0
Reporter: Ryan McKinley
Priority: Minor
Ran into this on trunk... don't have time to dig into it now, but will post it
here so it is not lost.
I suspect this is caused by something in SOLR-1566, need to add some better
tests to flush it out
{code}
org.apache.solr.client.solrj.SolrServerException: java.lang.RuntimeException:
java.io.EOFException
at
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:223)
at
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:89)
at
org.apache.solr.client.solrj.SolrServer.queryAndStreamResponse(SolrServer.java:143)
...
Caused by: java.lang.RuntimeException: java.io.EOFException
at
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:211)
... 51 more
Caused by: java.io.EOFException
at
org.apache.solr.common.util.FastInputStream.readByte(FastInputStream.java:160)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:158)
at
org.apache.solr.common.util.JavaBinCodec.readArray(JavaBinCodec.java:401)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:172)
at
org.apache.solr.common.util.JavaBinCodec.readOrderedMap(JavaBinCodec.java:110)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:174)
at
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:102)
at
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:208)
... 51 more
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-2504) Combined usage of Synonyms/SpellChecker causes java.lang.NullPointerException, when searching for a word out of synonyms.txt
[ https://issues.apache.org/jira/browse/SOLR-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned SOLR-2504: --- Assignee: Uwe Schindler Combined usage of Synonyms/SpellChecker causes java.lang.NullPointerException, when searching for a word out of synonyms.txt Key: SOLR-2504 URL: https://issues.apache.org/jira/browse/SOLR-2504 Project: Solr Issue Type: Bug Components: clients - java, spellchecker Affects Versions: 3.1 Reporter: Jens Bertheau Assignee: Uwe Schindler After migrating from 1.4 to 3.1 we experience the following behaviour: When SpellChecking is turned off, everything works fine. When Synonyms are *not* being used, everything works fine. When both, SpellChecking and Synonyms, are being used and a search is triggered, that contains at least one of the words out of synonyms.txt the following error is thrown: java.lang.NullPointerException at org.apache.lucene.util.AttributeSource.cloneAttributes(AttributeSource.java:542) at org.apache.solr.analysis.SynonymFilter.incrementToken(SynonymFilter.java:132) at org.apache.lucene.analysis.FilteringTokenFilter.incrementToken(FilteringTokenFilter.java:58) at org.apache.solr.handler.component.SpellCheckComponent.getTokens(SpellCheckComponent.java:485) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:131) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1360) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) The problem has been described already here: http://osdir.com/ml/solr-user.lucene.apache.org/2010-09/msg00945.html I have a report of a third person, experiencing the same problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2504) Combined usage of Synonyms/SpellChecker causes java.lang.NullPointerException, when searching for a word out of synonyms.txt
[ https://issues.apache.org/jira/browse/SOLR-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031436#comment-13031436 ] Uwe Schindler commented on SOLR-2504: - Can we close this issue then? The reason for this problem is still unknown, I suspect an JVM bug, because NPE is impossible at that point. The changes in code simply removed the problem - but I don't understand why. Can we confirm that it works with current updated 3.1 branch, future 3.2 (branch_3x) and 4.0 (trunk)? Combined usage of Synonyms/SpellChecker causes java.lang.NullPointerException, when searching for a word out of synonyms.txt Key: SOLR-2504 URL: https://issues.apache.org/jira/browse/SOLR-2504 Project: Solr Issue Type: Bug Components: clients - java, spellchecker Affects Versions: 3.1 Reporter: Jens Bertheau After migrating from 1.4 to 3.1 we experience the following behaviour: When SpellChecking is turned off, everything works fine. When Synonyms are *not* being used, everything works fine. When both, SpellChecking and Synonyms, are being used and a search is triggered, that contains at least one of the words out of synonyms.txt the following error is thrown: java.lang.NullPointerException at org.apache.lucene.util.AttributeSource.cloneAttributes(AttributeSource.java:542) at org.apache.solr.analysis.SynonymFilter.incrementToken(SynonymFilter.java:132) at org.apache.lucene.analysis.FilteringTokenFilter.incrementToken(FilteringTokenFilter.java:58) at org.apache.solr.handler.component.SpellCheckComponent.getTokens(SpellCheckComponent.java:485) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:131) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1360) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:619) The problem has been described already here: http://osdir.com/ml/solr-user.lucene.apache.org/2010-09/msg00945.html I have a report of a third person, experiencing the same problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2451) Add assertQScore() to SolrTestCaseJ4 to account for small deltas
[
https://issues.apache.org/jira/browse/SOLR-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-2451:
---
Attachment: SOLR-2451.patch
David,
One concern i have with your impl is that really only works with simple score
comparisons from the main result set -- for a public api we should probably try
to be more general (as is this wouldn't work if people wanted flexible score
comparisons using group by for instance -- let alone any custom plugins users
might want to write tests for)
The underlying code that processes assertJQ already applies a tolerance level
when doing equality tests between the JSON structure and the expected value,
but that is currently hardcoded.
Here's a patch bubbles that tollerance up that up so that it can be specified
in the individual assertJQ calls. What do you think of this approach?
Add assertQScore() to SolrTestCaseJ4 to account for small deltas
-
Key: SOLR-2451
URL: https://issues.apache.org/jira/browse/SOLR-2451
Project: Solr
Issue Type: Improvement
Affects Versions: 3.2
Reporter: David Smiley
Priority: Minor
Attachments: SOLR-2451.patch, SOLR-2451_assertQScore.patch
Attached is a patch that adds the following method to SolrTestCaseJ4: (just
javadoc signature shown)
{code:java}
/**
* Validates that the document at the specified index in the results has
the specified score, within 0.0001.
*/
public static void assertQScore(SolrQueryRequest req, int docIdx, float
targetScore) {
{code}
This is especially useful for geospatial in which slightly different
precision deltas might occur when trying different geospatial indexing
strategies are used, assuming the score is some geospatial distance. This
patch makes a simple modification to DistanceFunctionTest to use it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: 'waiting on condition' caused by DirectUpdateHandler2.commit - Solr-1.3
There are no requests running against the shards. - Bernhard On May 10, 2011, at 5:31 AM, Michael McCandless wrote: Hmm, one thread is actively running a query (stuck building up field cache), while another thread is waiting to acquire lock to commit? Are you sure this is deadlock, vs it taks a really really long time to init the field cache for this one query? Also, you might want to try the tiny patch on https://issues.apache.org/jira/browse/SOLR-2342 -- this gives commit priority over threads just doing searching, when it tries to acquire its lock. Mike http://blog.mikemccandless.com On Mon, May 9, 2011 at 4:42 PM, Bernhard C Gass bg...@apple.com wrote: I found locking issues reported against 1.2 and 1.4 on the mailing lists, but not against 1.3. We are running five Solr-1.3 shards under OSX on Tomcat under JDK-1.6 without any problems for quite a while. We copied the instance over to a Linux environment and now observe occasional deadlocks. This shard would lock and never recover. Each time a different shard would would lock. Any ideas or recommendations? Regards, Bernhard Below the stack trace: Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.2-b04 mixed mode): http-12003-2 daemon prio=10 tid=0x5c45f800 nid=0x573 in Object.wait() [0x42391000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0x2aaaea0bf008 (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:423) - locked 0x2aaaea0bf008 (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:449) at java.lang.Thread.run(Thread.java:619) http-12003-1 daemon prio=10 tid=0x5c714000 nid=0x50c9 waiting on condition [0x4228f000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x2aaae19f2238 (a java.util.concurrent.FutureTask$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217) at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:389) at org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:77) at org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:104) at org.apache.solr.handler.XmlUpdateRequestHandler.handleRequestBody(XmlUpdateRequestHandler.java:113) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:269) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:81) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) http-12003-Acceptor-0 daemon
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 7936 - Failure
Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/7936/ No tests ran. Build Log (for compile errors): [...truncated 4918 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-trunk - Build # 1558 - Still Failing
Build: https://builds.apache.org/hudson/job/Lucene-trunk/1558/ 1 tests failed. FAILED: org.apache.lucene.index.TestNRTThreads.testNRTThreads Error Message: Java heap space Stack Trace: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.store.RAMFile.newBuffer(RAMFile.java:85) at org.apache.lucene.store.RAMFile.addBuffer(RAMFile.java:58) at org.apache.lucene.store.RAMOutputStream.switchCurrentBuffer(RAMOutputStream.java:132) at org.apache.lucene.store.RAMOutputStream.writeBytes(RAMOutputStream.java:118) at org.apache.lucene.index.codecs.BlockTermsWriter$TermsWriter.flushBlock(BlockTermsWriter.java:288) at org.apache.lucene.index.codecs.BlockTermsWriter$TermsWriter.finish(BlockTermsWriter.java:239) at org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:395) at org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:87) at org.apache.lucene.index.TermsHash.flush(TermsHash.java:118) at org.apache.lucene.index.DocInverter.flush(DocInverter.java:80) at org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:75) at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:382) at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:384) at org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:511) at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:370) at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:283) at org.apache.lucene.index.TestNRTThreads.testNRTThreads(TestNRTThreads.java:345) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1282) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1211) Build Log (for compile errors): [...truncated 11975 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1421) Ability to group search results by field
[ https://issues.apache.org/jira/browse/LUCENE-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031537#comment-13031537 ] Bill Bell commented on LUCENE-1421: --- The issue I have with the group=true feature in Solr is that the facets are not calculated post grouping. So I cannot show the (count) in the facet list for a field. If we can get the facets to return counts POST grouping that would be ideal. Bill Ability to group search results by field Key: LUCENE-1421 URL: https://issues.apache.org/jira/browse/LUCENE-1421 Project: Lucene - Java Issue Type: New Feature Components: Search Reporter: Artyom Sokolov Assignee: Michael McCandless Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-1421.patch, lucene-grouping.patch It would be awesome to group search results by specified field. Some functionality was provided for Apache Solr but I think it should be done in Core Lucene. There could be some useful information like total hits about collapsed data like total count and so on. Thanks, Artyom -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031539#comment-13031539
]
Bill Bell commented on SOLR-2242:
-
OK. Can you point me in the right direction. Are you a committer? Can we get
this committed?
Get distinct count of names for a facet field
-
Key: SOLR-2242
URL: https://issues.apache.org/jira/browse/SOLR-2242
Project: Solr
Issue Type: New Feature
Components: Response Writers
Affects Versions: 4.0
Reporter: Bill Bell
Priority: Minor
Fix For: 4.0
Attachments: SOLR-2242.patch, SOLR-2242.solr3.1.patch,
SOLR.2242.solr3.1.patch, SOLR.2242.v2.patch
When returning facet.field=name of field you will get a list of matches for
distinct values. This is normal behavior. This patch tells you how many
distinct values you have (# of rows). Use with limit=-1 and mincount=1.
The feature is called namedistinct. Here is an example:
http://localhost:8983/solr/select?q=*:*facet=truefacet.field=manufacet.mincount=1facet.limit=-1f.manu.facet.namedistinct=0facet.field=pricef.price.facet.namedistinct=1
Here is an example on field hgid (without namedistinct):
{code}
- lst name=facet_fields
- lst name=hgid
int name=HGPY045FD36D4000A1/int
int name=HGPY0FBC6690453A91/int
int name=HGPY1E44ED6C4FB3B1/int
int name=HGPY1FA631034A1B81/int
int name=HGPY3317ABAC43B481/int
int name=HGPY3A17B2294CB5A5/int
int name=HGPY3ADD2B3D48C391/int
/lst
/lst
{code}
With namedistinct (HGPY045FD36D4000A, HGPY0FBC6690453A9,
HGPY1E44ED6C4FB3B, HGPY1FA631034A1B8, HGPY3317ABAC43B48,
HGPY3A17B2294CB5A, HGPY3ADD2B3D48C39). This returns number of rows
(7), not the number of values (11).
{code}
- lst name=facet_fields
- lst name=hgid
int name=_count_7/int
/lst
/lst
{code}
This works actually really good to get total number of fields for a
group.field=hgid. Enjoy!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
