Re: Can we add isDaemon check to LTC.threadCleanup?
I use a Jetty server instance in my tests, and LTC almost always reports that the 'qtp' threads are left open. 'qtp' are the prefix name of Jetty's QueuedThreadPool threads. QueuedThreadPool has two defaults: 1) It is not daemon, therefore its PoolThreads are not set daemon too 2) It defaults to keep idle threads for 60 seconds around In real-life these two settings make sense, but in tests, when I know that I call server.stop only after all my tasks have completed, it's annoying. When you call server.stop() followed by server.join(), it calls qtp.stop() which interrupts all running PoolThreads. I'm not sure if there's a bug in QueuedThreadPool's impl (or maybe PoolThread's impl), but I can tell for sure that the JVM process keeps running for ~60 seconds, even though the Socket and port have been released. So I wrote this code in my tests that start a Server instance: Server s = new Server(); QueuedThreadPool qtp = new QueuedThreadPool(); qtp.setDaemon(true); // I don't mind it'll be daemon in tests. qtp.setMaxIdleTimeMs(0); // when a thread becomes idle, kill it s.setThreadPool(qtp); Yet, sometimes even that's not enough and LTC's afterClass is called before the PoolThread dies. So I'm just thinking that if LTC would ignore daemon threads, the annoying messages will be gone :). It's not a big deal, just annoying to see these prints, and wasting so much time trying to make them go away :). Shai On Thu, Feb 23, 2012 at 9:14 AM, Dawid Weiss wrote: > I think it should be closed gracefully, even if it's a daemon thread. > Which thread do you have in mind? > > Dawid > > On Thu, Feb 23, 2012 at 7:33 AM, Shai Erera wrote: > > Hi > > > > I think that if a thread is daemon, but still running, LTC.threadCleanup > > should not report it. What do you think? > > > > Shai > > - > 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 # 12514 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12514/ 1 tests failed. REGRESSION: org.apache.solr.client.solrj.embedded.JettyWebappTest.testJSP Error Message: Server returned HTTP response code: 500 for URL: http://localhost:56349/test/admin/threaddump.jsp Stack Trace: java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:56349/test/admin/threaddump.jsp at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1403) at java.net.URL.openStream(URL.java:1029) at org.apache.solr.client.solrj.embedded.JettyWebappTest.testJSP(JettyWebappTest.java:106) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:495) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:400) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:458) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) Build Log (for compile errors): [...truncated 16485 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-3810) Text Alignment in the "status-item" tab of the Website needs to be word wrapped
[ https://issues.apache.org/jira/browse/LUCENE-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker closed LUCENE-3810. - > Text Alignment in the "status-item" tab of the Website needs to be word > wrapped > --- > > Key: LUCENE-3810 > URL: https://issues.apache.org/jira/browse/LUCENE-3810 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Minor > Attachments: LUCENE-3810.patch, lucene.png > > > If we go to http://lucene.apache.org/core/ or http://lucene.apache.org/solr/ > under the Latest Dev section the text is exceeding the css boundary. This is > happening on both Firefox and Chrome. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3810) Text Alignment in the "status-item" tab of the Website needs to be word wrapped
[ https://issues.apache.org/jira/browse/LUCENE-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker resolved LUCENE-3810. --- Resolution: Duplicate Lucene Fields: (was: New) > Text Alignment in the "status-item" tab of the Website needs to be word > wrapped > --- > > Key: LUCENE-3810 > URL: https://issues.apache.org/jira/browse/LUCENE-3810 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Minor > Attachments: LUCENE-3810.patch, lucene.png > > > If we go to http://lucene.apache.org/core/ or http://lucene.apache.org/solr/ > under the Latest Dev section the text is exceeding the css boundary. This is > happening on both Firefox and Chrome. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[ https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214412#comment-13214412 ] Dawid Weiss commented on LUCENE-3820: - Thanks for looking at this, Robert. I'll go back to this later today, but I can tell you right now that from my paper considerations negative indexes make logical sense in case of "prepended" characters. So: PATTERN: A INPUT: ABCDEF REPLACEMENT: XYZ OUTPUT:XYZBCDEF then (in my patch) X and Y would have negative offsets. It's a matter of agreement I guess. Negative indexes are consistent with something like this: PATTERN: ^ INPUT: ABC REPLACEMENT: XYZ OUTPUT:XYZABC then all three characters (XYZ) have a negative index to indicate they're prepended. Thoughts? > Wrong trailing index calculation in PatternReplaceCharFilter > > > Key: LUCENE-3820 > URL: https://issues.apache.org/jira/browse/LUCENE-3820 > Project: Lucene - Java > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3820.patch, LUCENE-3820_test.patch, > LUCENE-3820_test.patch > > > I need to use PatternReplaceCharFilter's index corrections directly and it > fails for me -- the trailing index is not mapped correctly for a pattern > "\\.[\\s]*" and replacement ".", input "A. .B.". > I tried to understand the logic in getReplaceBlock but I eventually failed > and simply rewrote it from scratch. After my changes a few tests don't pass > but I don't know if it's the tests that are screwed up or my logic. In > essence, the difference between the previous implementation and my > implementation is how indexes are mapped for shorter replacements. I shift > indexes of shorter regions to the "right" of the original index pool and the > previous patch seems to squeeze them to the left (don't know why though). > If anybody remembers how it's supposed to work, feel free to correct me? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3810) Text Alignment in the "status-item" tab of the Website needs to be word wrapped
[ https://issues.apache.org/jira/browse/LUCENE-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214411#comment-13214411 ] Varun Thacker commented on LUCENE-3810: --- Hi Mark, I just saw LUCENE-3819. All the problems stated here have been addressed there. So closing this issue. > Text Alignment in the "status-item" tab of the Website needs to be word > wrapped > --- > > Key: LUCENE-3810 > URL: https://issues.apache.org/jira/browse/LUCENE-3810 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Minor > Attachments: LUCENE-3810.patch, lucene.png > > > If we go to http://lucene.apache.org/core/ or http://lucene.apache.org/solr/ > under the Latest Dev section the text is exceeding the css boundary. This is > happening on both Firefox and Chrome. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Can we add isDaemon check to LTC.threadCleanup?
I think it should be closed gracefully, even if it's a daemon thread. Which thread do you have in mind? Dawid On Thu, Feb 23, 2012 at 7:33 AM, Shai Erera wrote: > Hi > > I think that if a thread is daemon, but still running, LTC.threadCleanup > should not report it. What do you think? > > Shai - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3144) Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec
[ https://issues.apache.org/jira/browse/SOLR-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214401#comment-13214401 ] Sami Siren commented on SOLR-3144: -- b1. However it might be a good idea to replace the toNamedList method in the Codec by the toNamedList method from SolrParams. Yeah, I agree. > Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec > --- > > Key: SOLR-3144 > URL: https://issues.apache.org/jira/browse/SOLR-3144 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Jörg Maier > Fix For: 4.0 > > Attachments: JavaBinUpdateRequestCodec.patch > > > The parameter marshalling de-marshalling is broken in Solrj's > JavaBinUpdateRequestCodec. > The bug can be reproduced by adding a parameter e.g. overwrite=false as > parameter to the UpdateRequest. After desiarilizing on the backend side the > value will be not "false" it will be "[false]" which results in an Exception > in the backend and documents will not be imported. > This issue can easily be fixed by replacing the serialization method with the > correct one in SolrParams. See also this gist for a working version: > https://gist.github.com/1853544 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-3144) Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec
[ https://issues.apache.org/jira/browse/SOLR-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Maier closed SOLR-3144. > Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec > --- > > Key: SOLR-3144 > URL: https://issues.apache.org/jira/browse/SOLR-3144 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Jörg Maier > Fix For: 4.0 > > Attachments: JavaBinUpdateRequestCodec.patch > > > The parameter marshalling de-marshalling is broken in Solrj's > JavaBinUpdateRequestCodec. > The bug can be reproduced by adding a parameter e.g. overwrite=false as > parameter to the UpdateRequest. After desiarilizing on the backend side the > value will be not "false" it will be "[false]" which results in an Exception > in the backend and documents will not be imported. > This issue can easily be fixed by replacing the serialization method with the > correct one in SolrParams. See also this gist for a working version: > https://gist.github.com/1853544 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3144) Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec
[ https://issues.apache.org/jira/browse/SOLR-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Maier resolved SOLR-3144. -- Resolution: Duplicate Hi Sami, i was working on an earlier build than the current head. Obviously previous to your fix. I couldnt verify the existence of this bug on trunk anymore and everything works fine for me. I missed SOLR-3037. However it might be a good idea to replace the toNamedList method in the Codec by the toNamedList method from SolrParams. I close this as duplicate to SOLR-3037. > Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec > --- > > Key: SOLR-3144 > URL: https://issues.apache.org/jira/browse/SOLR-3144 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Jörg Maier > Fix For: 4.0 > > Attachments: JavaBinUpdateRequestCodec.patch > > > The parameter marshalling de-marshalling is broken in Solrj's > JavaBinUpdateRequestCodec. > The bug can be reproduced by adding a parameter e.g. overwrite=false as > parameter to the UpdateRequest. After desiarilizing on the backend side the > value will be not "false" it will be "[false]" which results in an Exception > in the backend and documents will not be imported. > This issue can easily be fixed by replacing the serialization method with the > correct one in SolrParams. See also this gist for a working version: > https://gist.github.com/1853544 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3155) Zookeeper info servlet should use JSON library
[ https://issues.apache.org/jira/browse/SOLR-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3155: Attachment: ZookeeperInfoServlet.java Here is an updated version that uses the noggit library to write JSON I don't have a good zookeeper setup... stefan, can you test this? > Zookeeper info servlet should use JSON library > -- > > Key: SOLR-3155 > URL: https://issues.apache.org/jira/browse/SOLR-3155 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley > Attachments: ZookeeperInfoServlet.java > > > Some of the JSON that the zookeeper info servlet spits out is not valid. > Rather then try to fix it, I think we should just use an existing (tested!) > json framework. the noggit writer is available, or maybe expose the solr > JSONWriter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Can we add isDaemon check to LTC.threadCleanup?
Hi I think that if a thread is daemon, but still running, LTC.threadCleanup should not report it. What do you think? Shai
[jira] [Resolved] (SOLR-3153) When a leader goes down he should ask replicas to sync in parallel rather than serially.
[ https://issues.apache.org/jira/browse/SOLR-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3153. --- Resolution: Fixed Committed. > When a leader goes down he should ask replicas to sync in parallel rather > than serially. > > > Key: SOLR-3153 > URL: https://issues.apache.org/jira/browse/SOLR-3153 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3153.patch > > > Need to finish this todo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3040) Avoid use of qt param for the DIH in the admin UI
[ https://issues.apache.org/jira/browse/SOLR-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214321#comment-13214321 ] David Smiley commented on SOLR-3040: I'm going to commit this within 24 hours unless someone says otherwise. > Avoid use of qt param for the DIH in the admin UI > - > > Key: SOLR-3040 > URL: https://issues.apache.org/jira/browse/SOLR-3040 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: David Smiley >Priority: Minor > Attachments: SOLR-3040_avoid_qt_for_DIH_in_admin_ui.patch > > > I really, really dislike that the qt parameter can used to refer to request > handlers starting with a '/', _especially_ for non-search handlers. The > admin UI has one place I am aware of that attempts to do this, which is the > DIH's admin page. Since we have two UIs in trunk, the new and old, there are > actually two UIs where this occurs, and the old UI has two related files that > need updating, in order to address this issue. > An example URL generated by the UI today is this: > http://localhost:8983/solr/rss/select?qt=/dataimport&command=show-config > And here it is without using qt: > http://localhost:8983/solr/rss/dataimport?command=show-config > I do realize that fixing this issue as I do in my patch will make the UI not > work if the DIH isn't registered with a leading '/', but honestly I wonder > who if anyone out there does that. And even then, it's easily rectified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 12502 - Failure
should be fixed in revision: 1292642 On Wed, Feb 22, 2012 at 7:15 PM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12502/ > > 1 tests failed. > FAILED: > org.apache.solr.handler.admin.LogLevelHandlerTest.testLogLevelHandlerOutput > > Error Message: > Exception during query > > Stack Trace: > java.lang.RuntimeException: Exception during query > at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:423) > at > org.apache.solr.handler.admin.LogLevelHandlerTest.testLogLevelHandlerOutput(LogLevelHandlerTest.java:35) > at > org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707) > at > org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) > at > org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) > at > org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) > Caused by: java.lang.RuntimeException: REQUEST FAILED: > xpath=//arr[@name='loggers']/lst/str[.='global']/../str[@name='level'][.='INFO'] > xml response was: > > 0 name="QTime">5java.util.logging name="levels">FINESTFINECONFIGINFOWARNINGSEVEREOFF name="loggers">root name="level">SEVEREtrue name="name">/solrSEVERE name="set">falseglobal name="level">SEVEREfalse name="name">httpclient name="set">falsehttpclient.wire name="level"/>false name="name">httpclient.wire.contentSEVERE name="set">false name="name">httpclient.wire.headerSEVERE name="set">falsejavax name="level"/>false name="name">javax.managementSEVERE name="set">false name="name">javax.management.mbeanserver name="level">SEVEREfalse name="name">javax.management.miscSEVERE name="set">false name="name">javax.management.mletSEVERE name="set">false name="name">javax.management.modelmbean name="level">SEVEREfalse name="name">javax.management.monitorSEVERE name="set">false name="name">javax.management.notification name="level">SEVEREfalse name="name">javax.management.relation name="level">SEVEREfalse name="name">javax.management.remote name="set">false name="name">javax.management.remote.misc name="level">SEVEREfalse name="name">javax.management.remote.rmi name="level">SEVEREfalse name="name">javax.management.remote.timeout name="level">SEVEREfalse name="name">javax.management.snmpSEVERE name="set">false name="name">javax.management.snmp.daemon name="level">SEVEREfalse name="name">javax.management.timerSEVERE name="set">falseorg name="level"/>false name="name">org.apache name="set">false name="name">org.apache.commons name="set">false name="name">org.apache.commons.httpclient name="set">false name="name">org.apache.commons.httpclient.ChunkedInputStream name="level">SEVEREfalse name="name">org.apache.commons.httpclient.HeaderElement name="level">SEVEREfalse name="name">org.apache.commons.httpclient.HttpClient name="level">SEVEREfalse name="name">org.apache.commons.httpclient.HttpConnection name="level">SEVEREfalse name="name">org.apache.commons.httpclient.HttpMethodBase name="level">SEVEREfalse name="name">org.apache.commons.httpclient.HttpMethodDirector name="level">SEVEREfalse name="name">org.apache.commons.httpclient.HttpParser name="level">SEVEREfalse name="name">org.apache.commons.httpclient.HttpState name="level">SEVEREfalse name="name">org.apache.commons.httpclient.MultiThreadedHttpConnectionManager name="level">SEVEREfalse name="name">org.apache.commons.httpclient.SimpleHttpConnectionManager name="level">SEVEREfalse name="name">org.apache.commons.httpclient.auth name="set">false name="name">org.apache.commons.httpclient.auth.AuthChallengeProcessor name="level">SEVEREfalse name="name">org.apache.commons.httpclient.cookie name="level"/>false name="name">org.apache.commons.httpclient.cookie.CookiePolicy name="level">SEVEREfalse name="name">org.apache.commons.httpclient.cookie.CookieSpec name="level">SEVEREfalse name="name">org.apache.commons.httpclient.methods name="level"/>false name="name">org.apache.commons.httpclient.methods.EntityEnclosingMethod name="level">SEVEREfalse name="name">org.apache.commons.httpclient.methods.ExpectContinueMethod name="level">SEVEREfalse name="name">org.apache.commons.httpclient.methods.GetMethod name="level">SEVEREfalse name="name">org.apache.commons.httpclient.methods.InputStreamRequestEntity name="level">SEVEREfalse name="name">org.apache.commons.httpclient.methods.PostMethod name="level">SEVEREfalse name="name">org.apache.commons.httpclient.params name="level"/>false name="name">org.apache.commons.httpclient.params.DefaultHttpParams name="level">SEVEREfalse name="name">org.apache.commons.httpclient.params.HttpMethodParams name="level">SEVEREfalse name="name">org.apache.common
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1794 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1794/ 1 tests failed. FAILED: org.apache.solr.handler.admin.LogLevelHandlerTest.testLogLevelHandlerOutput Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:423) at org.apache.solr.handler.admin.LogLevelHandlerTest.testLogLevelHandlerOutput(LogLevelHandlerTest.java:35) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//arr[@name='loggers']/lst/str[.='global']/../str[@name='level'][.='INFO'] xml response was: 08java.util.loggingFINESTFINECONFIGINFOWARNINGSEVEREOFFrootSEVEREtrue/solrSEVEREfalseglobalSEVEREfalsehttpclientfalsehttpclient.wirefalsehttpclient.wire.contentSEVEREfalsehttpclient.wire.headerSEVEREfalsejavaxfalsejavax.managementSEVEREfalsejavax.management.mbeanserverSEVEREfalsejavax.management.miscSEVEREfalsejavax.management.mletSEVEREfalsejavax.management.modelmbeanSEVEREfalsejavax.management.monitorSEVEREfalsejavax.management.notificationSEVEREfalsejavax.management.relationSEVEREfalsejavax.management.snmpSEVEREfalsejavax.management.snmp.daemonSEVEREfalsejavax.management.timerSEVEREfalseorgfalseorg.apachefalseorg.apache.commonsfalseorg.apache.commons.httpclientfalseorg.apache.commons.httpclient.ChunkedInputStreamSEVEREfalseorg.apache.commons.httpclient.HeaderElementSEVEREfalseorg.apache.commons.httpclient.HttpClientSEVEREfalseorg.apache.commons.httpclient.HttpConnectionSEVEREfalseorg.apache.commons.httpclient.HttpMethodBaseSEVEREfalseorg.apache.commons.httpclient.HttpMethodDirectorSEVEREfalseorg.apache.commons.httpclient.HttpParserSEVEREfalseorg.apache.commons.httpclient.HttpStateSEVEREfalseorg.apache.commons.httpclient.MultiThreadedHttpConnectionManagerSEVEREfalseorg.apache.commons.httpclient.SimpleHttpConnectionManagerSEVEREfalseorg.apache.commons.httpclient.authfalseorg.apache.commons.httpclient.auth.AuthChallengeProcessorSEVEREfalseorg.apache.commons.httpclient.cookiefalseorg.apache.commons.httpclient.cookie.CookiePolicySEVEREfalseorg.apache.commons.httpclient.cookie.CookieSpecSEVEREfalseorg.apache.commons.httpclient.methodsfalseorg.apache.commons.httpclient.methods.EntityEnclosingMethodSEVEREfalseorg.apache.commons.httpclient.methods.ExpectContinueMethodSEVEREfalseorg.apache.commons.httpclient.methods.GetMethodSEVEREfalseorg.apache.commons.httpclient.methods.InputStreamRequestEntitySEVEREfalseorg.apache.commons.httpclient.methods.PostMethodSEVEREfalseorg.apache.commons.httpclient.paramsfalseorg.apache.commons.httpclient.params.DefaultHttpParamsSEVEREfalseorg.apache.commons.httpclient.params.HttpMethodParamsSEVEREfalseorg.apache.commons.httpclient.utilfalseorg.apache.commons.httpclient.util.EncodingUtilSEVEREfalseorg.apache.commons.httpclient.util.ExceptionUtilSEVEREfalseorg.apache.commons.httpclient.util.IdleConnectionHandlerSEVEREfalseorg.apache.solrfalseorg.apache.solr.BaseDistributedSearchTestCaseSEVEREfalseorg.apache.solr.SolrTestCaseJ4SEVEREfalseorg.apache.solr.analysisfalseorg.apache.solr.analysis.BaseCharFilterFactorySEVEREfalseorg.apache.solr.analysis.BaseTokenFilterFactorySEVEREfalseorg.apache.solr.analysis.BaseTokenStreamFactorySEVEREfalseorg.apache.solr.analysis.BaseTokenizerFactorySEVEREfalseorg.apache.solr.clientfalseorg.apache.solr.client.solrjfalseorg.apache.solr.client.solrj.implfalseorg.apache.solr.client.solrj.impl.CommonsHttpSolrServerSEVEREfalseorg.apache.solr.cloudfalseorg.apache.solr.cloud.AbstractZkTestCaseSEVEREfalseorg.apache.solr.cloud.LeaderElectorSEVEREfalseorg.apache.solr.cloud.NodeStateWatcherSEVEREfalseorg.apache.solr.cloud.OverseerSEVEREfalseorg.apache.solr.cloud.RecoveryStrategySEVEREfalseorg.apache.solr.cloud.ShardLeaderWatcherSEVEREfalseorg.apache.solr.cloud.SyncStrategySEVEREfalseorg.apache.solr.cloud.ZkControllerSEVEREfalseorg.apache.solr.cloud.ZkTestServerSEVEREfalseorg.apache.solr.commonfalseorg.apache.solr.common.cloudfalseorg.apache.solr.common.cloud.ConnectionManagerSEVEREfalseorg.apache.solr.common.cloud.DefaultConnectionStrategySEVEREfalseorg.apache.solr.common.cloud.SolrZkClientSEVEREfalseorg.apache.solr.common.cloud.ZkStateReaderSEVEREfalseorg.apache.solr.common.utilfalseorg.apache.solr.common.util.SystemIdResolverSEVEREfalseorg.apache.solr.corefalseorg.apache.solr.core.CachingDirectoryFactorySEVEREfalse
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12502 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12502/ 1 tests failed. FAILED: org.apache.solr.handler.admin.LogLevelHandlerTest.testLogLevelHandlerOutput Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:423) at org.apache.solr.handler.admin.LogLevelHandlerTest.testLogLevelHandlerOutput(LogLevelHandlerTest.java:35) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//arr[@name='loggers']/lst/str[.='global']/../str[@name='level'][.='INFO'] xml response was: 05java.util.loggingFINESTFINECONFIGINFOWARNINGSEVEREOFFrootSEVEREtrue/solrSEVEREfalseglobalSEVEREfalsehttpclientfalsehttpclient.wirefalsehttpclient.wire.contentSEVEREfalsehttpclient.wire.headerSEVEREfalsejavaxfalsejavax.managementSEVEREfalsejavax.management.mbeanserverSEVEREfalsejavax.management.miscSEVEREfalsejavax.management.mletSEVEREfalsejavax.management.modelmbeanSEVEREfalsejavax.management.monitorSEVEREfalsejavax.management.notificationSEVEREfalsejavax.management.relationSEVEREfalsejavax.management.remotefalsejavax.management.remote.miscSEVEREfalsejavax.management.remote.rmiSEVEREfalsejavax.management.remote.timeoutSEVEREfalsejavax.management.snmpSEVEREfalsejavax.management.snmp.daemonSEVEREfalsejavax.management.timerSEVEREfalseorgfalseorg.apachefalseorg.apache.commonsfalseorg.apache.commons.httpclientfalseorg.apache.commons.httpclient.ChunkedInputStreamSEVEREfalseorg.apache.commons.httpclient.HeaderElementSEVEREfalseorg.apache.commons.httpclient.HttpClientSEVEREfalseorg.apache.commons.httpclient.HttpConnectionSEVEREfalseorg.apache.commons.httpclient.HttpMethodBaseSEVEREfalseorg.apache.commons.httpclient.HttpMethodDirectorSEVEREfalseorg.apache.commons.httpclient.HttpParserSEVEREfalseorg.apache.commons.httpclient.HttpStateSEVEREfalseorg.apache.commons.httpclient.MultiThreadedHttpConnectionManagerSEVEREfalseorg.apache.commons.httpclient.SimpleHttpConnectionManagerSEVEREfalseorg.apache.commons.httpclient.authfalseorg.apache.commons.httpclient.auth.AuthChallengeProcessorSEVEREfalseorg.apache.commons.httpclient.cookiefalseorg.apache.commons.httpclient.cookie.CookiePolicySEVEREfalseorg.apache.commons.httpclient.cookie.CookieSpecSEVEREfalseorg.apache.commons.httpclient.methodsfalseorg.apache.commons.httpclient.methods.EntityEnclosingMethodSEVEREfalseorg.apache.commons.httpclient.methods.ExpectContinueMethodSEVEREfalseorg.apache.commons.httpclient.methods.GetMethodSEVEREfalseorg.apache.commons.httpclient.methods.InputStreamRequestEntitySEVEREfalseorg.apache.commons.httpclient.methods.PostMethodSEVEREfalseorg.apache.commons.httpclient.paramsfalseorg.apache.commons.httpclient.params.DefaultHttpParamsSEVEREfalseorg.apache.commons.httpclient.params.HttpMethodParamsSEVEREfalseorg.apache.commons.httpclient.utilfalseorg.apache.commons.httpclient.util.EncodingUtilSEVEREfalseorg.apache.commons.httpclient.util.ExceptionUtilSEVEREfalseorg.apache.commons.httpclient.util.IdleConnectionHandlerSEVEREfalseorg.apache.solrfalseorg.apache.solr.BaseDistributedSearchTestCaseSEVEREfalseorg.apache.solr.SolrTestCaseJ4SEVEREfalseorg.apache.solr.analysisfalseorg.apache.solr.analysis.BaseCharFilterFactorySEVEREfalseorg.apache.solr.analysis.BaseTokenFilterFactorySEVEREfalseorg.apache.solr.analysis.BaseTokenStreamFactorySEVEREfalseorg.apache.solr.analysis.BaseTokenizerFactorySEVEREfalseorg.apache.solr.clientfalseorg.apache.solr.client.solrjfalseorg.apache.solr.client.solrj.implfalseorg.apache.solr.client.solrj.impl.CommonsHttpSolrServerSEVEREfalseorg.apache.solr.client.solrj.impl.StreamingUpdateSolrServerSEVEREfalseorg.apache.solr.cloudfalseorg.apache.solr.cloud.AbstractZkTestCaseSEVEREfalseorg.apache.solr.cloud.LeaderElectorSEVEREfalseorg.apache.solr.cloud.NodeStateWatcherSEVEREfalseorg.apache.solr.cloud.OverseerSEVEREfalseorg.apache.solr.cloud.RecoveryStrategySEVEREfalseorg.apache.solr.cloud.ShardLeaderWatcherSEVEREfalseorg.apache.solr.cloud.SyncStrategySEVEREfalseorg.apache.solr.cloud.ZkControllerSEVEREfalseorg.apache.solr.cloud.ZkTestServerSEVEREfalseorg.apache.solr.commonfalseorg.apache.solr.common.cloudfalseorg.apache.solr.common.cloud.ConnectionManagerSEVEREfalseorg.apache.solr.common.cloud.DefaultConnectionStrategySEVEREfalseorg.apache.solr.common.cloud.SolrZkClientSEVEREfalseorg.apac
[jira] [Updated] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[ https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3820: Attachment: LUCENE-3820_test.patch updated patch, this tests only ascii (to avoid stupid problems in outdated regex support). But there are a lot of offset problems (perhaps this corresponds to the warning in the class's javadocs?), including things like offsets being corrected to negative numbers... > Wrong trailing index calculation in PatternReplaceCharFilter > > > Key: LUCENE-3820 > URL: https://issues.apache.org/jira/browse/LUCENE-3820 > Project: Lucene - Java > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3820.patch, LUCENE-3820_test.patch, > LUCENE-3820_test.patch > > > I need to use PatternReplaceCharFilter's index corrections directly and it > fails for me -- the trailing index is not mapped correctly for a pattern > "\\.[\\s]*" and replacement ".", input "A. .B.". > I tried to understand the logic in getReplaceBlock but I eventually failed > and simply rewrote it from scratch. After my changes a few tests don't pass > but I don't know if it's the tests that are screwed up or my logic. In > essence, the difference between the previous implementation and my > implementation is how indexes are mapped for shorter replacements. I shift > indexes of shorter regions to the "right" of the original index pool and the > previous patch seems to squeeze them to the left (don't know why though). > If anybody remembers how it's supposed to work, feel free to correct me? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[ https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214235#comment-13214235 ] Robert Muir commented on LUCENE-3820: - to fix dawid's problem we can probably modify this test only for ascii, i suspect the unicode "problems" are going to be impossible to fix given java's regex library (i think it does not treat "." as codepoint but code unit). I'll take another stab at that just to tackle the offsets issue he is seeing. > Wrong trailing index calculation in PatternReplaceCharFilter > > > Key: LUCENE-3820 > URL: https://issues.apache.org/jira/browse/LUCENE-3820 > Project: Lucene - Java > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3820.patch, LUCENE-3820_test.patch > > > I need to use PatternReplaceCharFilter's index corrections directly and it > fails for me -- the trailing index is not mapped correctly for a pattern > "\\.[\\s]*" and replacement ".", input "A. .B.". > I tried to understand the logic in getReplaceBlock but I eventually failed > and simply rewrote it from scratch. After my changes a few tests don't pass > but I don't know if it's the tests that are screwed up or my logic. In > essence, the difference between the previous implementation and my > implementation is how indexes are mapped for shorter replacements. I shift > indexes of shorter regions to the "right" of the original index pool and the > previous patch seems to squeeze them to the left (don't know why though). > If anybody remembers how it's supposed to work, feel free to correct me? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214232#comment-13214232
]
Robert Muir commented on LUCENE-3767:
-
{quote}
Mike, could you share some details on any query-time trickiness here? Are you
thinking about composing a query with both the compound and its
parts/decompounds? Thanks.
{quote}
I don't understand Mike's comment there either. positionIncrement=0 is really
going to be treated like synonyms by the QP,
so it shouldn't involve any trickiness.
> Explore streaming Viterbi search in Kuromoji
>
>
> Key: LUCENE-3767
> URL: https://issues.apache.org/jira/browse/LUCENE-3767
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
> compound_diffs.txt
>
>
> I've been playing with the idea of changing the Kuromoji viterbi
> search to be 2 passes (intersect, backtrace) instead of 4 passes
> (break into sentences, intersect, score, backtrace)... this is very
> much a work in progress, so I'm just getting my current state up.
> It's got tons of nocommits, doesn't properly handle the user dict nor
> extended modes yet, etc.
> One thing I'm playing with is to add a double backtrace for the long
> compound tokens, ie, instead of penalizing these tokens so that
> shorter tokens are picked, leave the scores unchanged but on backtrace
> take that penalty and use it as a threshold for a 2nd best
> segmentation...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214227#comment-13214227
]
Christian Moen commented on LUCENE-3767:
{quote}
I left the default mode as Mode.SEARCH... maybe if we can somehow run some
relevance tests we can make the default SEARCH_WITH_COMPOUNDS.
But it'd also be tricky at query time...
{quote}
Mike, could you share some details on any query-time trickiness here? Are you
thinking about composing a query with both the compound and its
parts/decompounds? Thanks.
> Explore streaming Viterbi search in Kuromoji
>
>
> Key: LUCENE-3767
> URL: https://issues.apache.org/jira/browse/LUCENE-3767
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
> compound_diffs.txt
>
>
> I've been playing with the idea of changing the Kuromoji viterbi
> search to be 2 passes (intersect, backtrace) instead of 4 passes
> (break into sentences, intersect, score, backtrace)... this is very
> much a work in progress, so I'm just getting my current state up.
> It's got tons of nocommits, doesn't properly handle the user dict nor
> extended modes yet, etc.
> One thing I'm playing with is to add a double backtrace for the long
> compound tokens, ie, instead of penalizing these tokens so that
> shorter tokens are picked, leave the scores unchanged but on backtrace
> take that penalty and use it as a threshold for a 2nd best
> segmentation...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[ https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3820: Attachment: LUCENE-3820_test.patch Here's a simple random test showing some existing bugs in the filter... * there are offsets problems as dawid notices... * blockbuffer should always oversize by 1 character, if a block ends on a high surrogate (rare) it should do one additional read() so it doesnt create invalid unicode > Wrong trailing index calculation in PatternReplaceCharFilter > > > Key: LUCENE-3820 > URL: https://issues.apache.org/jira/browse/LUCENE-3820 > Project: Lucene - Java > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3820.patch, LUCENE-3820_test.patch > > > I need to use PatternReplaceCharFilter's index corrections directly and it > fails for me -- the trailing index is not mapped correctly for a pattern > "\\.[\\s]*" and replacement ".", input "A. .B.". > I tried to understand the logic in getReplaceBlock but I eventually failed > and simply rewrote it from scratch. After my changes a few tests don't pass > but I don't know if it's the tests that are screwed up or my logic. In > essence, the difference between the previous implementation and my > implementation is how indexes are mapped for shorter replacements. I shift > indexes of shorter regions to the "right" of the original index pool and the > previous patch seems to squeeze them to the left (don't know why though). > If anybody remembers how it's supposed to work, feel free to correct me? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214217#comment-13214217
]
Christian Moen commented on LUCENE-3767:
Robert, some comments are below.
{quote}
And I tend to like Mike's improvements from a relevance perspective for these
reasons:
# keeping the original compound term for improved precision
# preventing compound decomposition from having any unrelated negative impact
on the rest of the tokenization
{quote}
Very good points.
{quote}
So I think we should pursue this change, even if we want to separately train a
dictionary in the future, because in that case, we would just disable the kanji
decomposition heuristic but keep the heuristic (obviously re-tuned!) for
katakana?
{quote}
I agree completely.
{quote}
The dictionary documentation for the original ipadic has the ability to hold
compound data (not in mecab-ipadic though, so maybe it was never
implemented?!), but I don't actually see it in any implementations. So yeah, we
would need to find a corpus containing compound information (and of course
extend the file format and add support to kuromoji) to support that.
However, would this really solve the total issue? Wouldn't that really only
help for known kanji compounds... whereas most katakana compounds (e.g. the
software engineer example) are expected to be OOV anyway? So it seems like,
even if we ensured the dictionary was annotated for long kanji such that we
always used decompounded forms, we need a 'heuristical' decomposition like
search-mode either way, at least for the unknown katakana case?
{quote}
I've made an inquiry to a friend who did his PhD work at Prof. Matsumoto's lab
at NAIST (where ChaSen was made) and I've made en inquiry regarding compound
information and the Kyoto Corpus.
You are perfectly right that this doesn't solve the complete problem as unknown
words can actually be compounds -- unknown compounds. The approach used today
is basically adding all the potential decompounds the model knows about to the
lattice and see if a short path can be found often in combination with an
unknown word.
We get errors such as クイーンズコミックス (Queen's Comics) becoming クイーン ズコミックス (Queen
Zukuomikkusu) because クイーン (Queen) is known.
I'll open up a separate JIRA for discussing search-mode improvements. :)
> Explore streaming Viterbi search in Kuromoji
>
>
> Key: LUCENE-3767
> URL: https://issues.apache.org/jira/browse/LUCENE-3767
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
> compound_diffs.txt
>
>
> I've been playing with the idea of changing the Kuromoji viterbi
> search to be 2 passes (intersect, backtrace) instead of 4 passes
> (break into sentences, intersect, score, backtrace)... this is very
> much a work in progress, so I'm just getting my current state up.
> It's got tons of nocommits, doesn't properly handle the user dict nor
> extended modes yet, etc.
> One thing I'm playing with is to add a double backtrace for the long
> compound tokens, ie, instead of penalizing these tokens so that
> shorter tokens are picked, leave the scores unchanged but on backtrace
> take that penalty and use it as a threshold for a 2nd best
> segmentation...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3151) Replace zookeeper.jsp with a servlet
[ https://issues.apache.org/jira/browse/SOLR-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-3151. - Resolution: Fixed This is now a servlet, and future improvements can be tracked in SOLR-3155 > Replace zookeeper.jsp with a servlet > > > Key: SOLR-3151 > URL: https://issues.apache.org/jira/browse/SOLR-3151 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-3151-invalid-json-for-solrconfig.json, > SOLR-3151-zookeeper-servlet.patch > > > The zookeeper info is currently generated with a jsp file -- making it harder > to maintain then it should be, and harder to include in other applications -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3155) Zookeeper info servlet should use JSON library
Zookeeper info servlet should use JSON library -- Key: SOLR-3155 URL: https://issues.apache.org/jira/browse/SOLR-3155 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Some of the JSON that the zookeeper info servlet spits out is not valid. Rather then try to fix it, I think we should just use an existing (tested!) json framework. the noggit writer is available, or maybe expose the solr JSONWriter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[ https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214203#comment-13214203 ] Robert Muir commented on LUCENE-3820: - Unrelated to this change: we should be using StringBuilder here. > Wrong trailing index calculation in PatternReplaceCharFilter > > > Key: LUCENE-3820 > URL: https://issues.apache.org/jira/browse/LUCENE-3820 > Project: Lucene - Java > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3820.patch > > > I need to use PatternReplaceCharFilter's index corrections directly and it > fails for me -- the trailing index is not mapped correctly for a pattern > "\\.[\\s]*" and replacement ".", input "A. .B.". > I tried to understand the logic in getReplaceBlock but I eventually failed > and simply rewrote it from scratch. After my changes a few tests don't pass > but I don't know if it's the tests that are screwed up or my logic. In > essence, the difference between the previous implementation and my > implementation is how indexes are mapped for shorter replacements. I shift > indexes of shorter regions to the "right" of the original index pool and the > previous patch seems to squeeze them to the left (don't know why though). > If anybody remembers how it's supposed to work, feel free to correct me? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[ https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214201#comment-13214201 ] Robert Muir commented on LUCENE-3767: - Well my comments are only questions based on your previous JIRA comments, I don't really know anything about decompounding Japanese and my suggestions are only intuition, mostly based on patterns that have worked for other languages... so just consider it thinking out loud. I think your points on search mode are actually related here: though we can't really have a plan its good to think about possible paths we might take in the future so that we don't lock ourselves out. > Explore streaming Viterbi search in Kuromoji > > > Key: LUCENE-3767 > URL: https://issues.apache.org/jira/browse/LUCENE-3767 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/analysis >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, > compound_diffs.txt > > > I've been playing with the idea of changing the Kuromoji viterbi > search to be 2 passes (intersect, backtrace) instead of 4 passes > (break into sentences, intersect, score, backtrace)... this is very > much a work in progress, so I'm just getting my current state up. > It's got tons of nocommits, doesn't properly handle the user dict nor > extended modes yet, etc. > One thing I'm playing with is to add a double backtrace for the long > compound tokens, ie, instead of penalizing these tokens so that > shorter tokens are picked, leave the scores unchanged but on backtrace > take that penalty and use it as a threshold for a 2nd best > segmentation... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-1301) Solr + Hadoop
[ https://issues.apache.org/jira/browse/SOLR-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214102#comment-13214102 ] Alexander Kanarsky edited comment on SOLR-1301 at 2/23/12 2:09 AM: --- Note, the hadoop-core-0.20.2-cdh3u3.jar is a part of Cloudera's CDH3 Hadoop distribution and is licensed under Apache License v. 2.0. was (Author: kanarsky): Note, the hadoop-core-0.20.2-cdh3u3.jar is part of the Coludera's CDH3u3 Hadoop distribution and licensed under Apache License v. 2.0. > Solr + Hadoop > - > > Key: SOLR-1301 > URL: https://issues.apache.org/jira/browse/SOLR-1301 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Fix For: 3.6, 4.0 > > Attachments: README.txt, SOLR-1301-hadoop-0-20.patch, > SOLR-1301-hadoop-0-20.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SolrRecordWriter.java, commons-logging-1.0.4.jar, > commons-logging-api-1.0.4.jar, hadoop-0.19.1-core.jar, > hadoop-0.20.1-core.jar, hadoop-core-0.20.2-cdh3u3.jar, hadoop.patch, > log4j-1.2.15.jar > > > This patch contains a contrib module that provides distributed indexing > (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is > twofold: > * provide an API that is familiar to Hadoop developers, i.e. that of > OutputFormat > * avoid unnecessary export and (de)serialization of data maintained on HDFS. > SolrOutputFormat consumes data produced by reduce tasks directly, without > storing it in intermediate files. Furthermore, by using an > EmbeddedSolrServer, the indexing task is split into as many parts as there > are reducers, and the data to be indexed is not sent over the network. > Design > -- > Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, > which in turn uses SolrRecordWriter to write this data. SolrRecordWriter > instantiates an EmbeddedSolrServer, and it also instantiates an > implementation of SolrDocumentConverter, which is responsible for turning > Hadoop (key, value) into a SolrInputDocument. This data is then added to a > batch, which is periodically submitted to EmbeddedSolrServer. When reduce > task completes, and the OutputFormat is closed, SolrRecordWriter calls > commit() and optimize() on the EmbeddedSolrServer. > The API provides facilities to specify an arbitrary existing solr.home > directory, from which the conf/ and lib/ files will be taken. > This process results in the creation of as many partial Solr home directories > as there were reduce tasks. The output shards are placed in the output > directory on the default filesystem (e.g. HDFS). Such part-N directories > can be used to run N shard servers. Additionally, users can specify the > number of reduce tasks, in particular 1 reduce task, in which case the output > will consist of a single shard. > An example application is provided that processes large CSV files and uses > this API. It uses a custom CSV processing to avoid (de)serialization overhead. > This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this > issue, you should put it in contrib/hadoop/lib. > Note: the development of this patch was sponsored by an anonymous contributor > and approved for release under Apache License. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[ https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3820: Attachment: LUCENE-3820.patch A patch with reimplementation of getReplaceBlock and a test case that is failing with AIOOB (apply test changes without modifying PatternReplaceCharFilter to get the error). > Wrong trailing index calculation in PatternReplaceCharFilter > > > Key: LUCENE-3820 > URL: https://issues.apache.org/jira/browse/LUCENE-3820 > Project: Lucene - Java > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3820.patch > > > I need to use PatternReplaceCharFilter's index corrections directly and it > fails for me -- the trailing index is not mapped correctly for a pattern > "\\.[\\s]*" and replacement ".", input "A. .B.". > I tried to understand the logic in getReplaceBlock but I eventually failed > and simply rewrote it from scratch. After my changes a few tests don't pass > but I don't know if it's the tests that are screwed up or my logic. In > essence, the difference between the previous implementation and my > implementation is how indexes are mapped for shorter replacements. I shift > indexes of shorter regions to the "right" of the original index pool and the > previous patch seems to squeeze them to the left (don't know why though). > If anybody remembers how it's supposed to work, feel free to correct me? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[ https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214196#comment-13214196 ] Christian Moen commented on LUCENE-3767: I agree completely; we should definitely proceed with Mike's improvements. A big +1 from me. I'm sorry if this wasn't clear. My comments on search mode are unrelated and I didn't mean to confuse these with the improvements made. None of this is necessary for Mike's improvements to be used, of course. > Explore streaming Viterbi search in Kuromoji > > > Key: LUCENE-3767 > URL: https://issues.apache.org/jira/browse/LUCENE-3767 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/analysis >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, > compound_diffs.txt > > > I've been playing with the idea of changing the Kuromoji viterbi > search to be 2 passes (intersect, backtrace) instead of 4 passes > (break into sentences, intersect, score, backtrace)... this is very > much a work in progress, so I'm just getting my current state up. > It's got tons of nocommits, doesn't properly handle the user dict nor > extended modes yet, etc. > One thing I'm playing with is to add a double backtrace for the long > compound tokens, ie, instead of penalizing these tokens so that > shorter tokens are picked, leave the scores unchanged but on backtrace > take that penalty and use it as a threshold for a 2nd best > segmentation... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
Wrong trailing index calculation in PatternReplaceCharFilter Key: LUCENE-3820 URL: https://issues.apache.org/jira/browse/LUCENE-3820 Project: Lucene - Java Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 I need to use PatternReplaceCharFilter's index corrections directly and it fails for me -- the trailing index is not mapped correctly for a pattern "\\.[\\s]*" and replacement ".", input "A. .B.". I tried to understand the logic in getReplaceBlock but I eventually failed and simply rewrote it from scratch. After my changes a few tests don't pass but I don't know if it's the tests that are screwed up or my logic. In essence, the difference between the previous implementation and my implementation is how indexes are mapped for shorter replacements. I shift indexes of shorter regions to the "right" of the original index pool and the previous patch seems to squeeze them to the left (don't know why though). If anybody remembers how it's supposed to work, feel free to correct me? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2459) Implement LogLevelSelection as a RequestHandler
[ https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214193#comment-13214193 ] Ryan McKinley commented on SOLR-2459: - Added in revision: 1292617 Lets keep the existing servlet in place until the admin UI works > Implement LogLevelSelection as a RequestHandler > --- > > Key: SOLR-2459 > URL: https://issues.apache.org/jira/browse/SOLR-2459 > Project: Solr > Issue Type: Wish > Components: web gui >Reporter: Stefan Matheis (steffkes) >Priority: Trivial > Attachments: LogLevelHandler.patch, SOLR-2459-LogLevel.patch, > SOLR-2459-LogLevel.patch, sample-output.json, sample-output.xml > > > The current available Output of the LogLevelSelection Servlet is plain HTML, > which made it unpossible, to integrate the Logging-Information in the new > Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would > be really nice! > Just as an Idea for a future structure, the new admin-ui is [actually based > on that > json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json] > :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2459) Implement LogLevelSelection as a RequestHandler
[ https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-2459: Attachment: SOLR-2459-LogLevel.patch An updated/simplified generic version that uses the SolrTestCaseJ4 The format is different, but seems to match the JS needs better. I will commit this soon so the UI stuff can continue in a different issue > Implement LogLevelSelection as a RequestHandler > --- > > Key: SOLR-2459 > URL: https://issues.apache.org/jira/browse/SOLR-2459 > Project: Solr > Issue Type: Wish > Components: web gui >Reporter: Stefan Matheis (steffkes) >Priority: Trivial > Attachments: LogLevelHandler.patch, SOLR-2459-LogLevel.patch, > SOLR-2459-LogLevel.patch, sample-output.json, sample-output.xml > > > The current available Output of the LogLevelSelection Servlet is plain HTML, > which made it unpossible, to integrate the Logging-Information in the new > Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would > be really nice! > Just as an Idea for a future structure, the new admin-ui is [actually based > on that > json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json] > :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214159#comment-13214159
]
Robert Muir commented on LUCENE-3767:
-
{quote}
I've done some analysis of these cases and it's possible to add more heuristics
to deal with some that are obviouslt wrong, such a word starting with a long
vowel sound in katakana. This is a slippery slope that I'm reluctant to
pursue...
{quote}
I've wondered about that also at least for the unknown katakana case: (though I
don't know all the rules that could be applied).
Adding such heuristics isn't really unprecedented, in a way its very similar to
the compounds/ package (geared towards german, etc)
using TeX hyphenation rules to restrict word splits to hyphenation breaks; and
similar to DictionaryBasedBreakIterators in
ICU/your JRE that use orthographic rules in combination with a dictionary to
segment southeast asian languages like Thai, and
not too far from simple rules like "don't separate a base character from any
combining characters that follow it", or "don't
separate a lead surrogate from a trail surrogate" that you would generally use
across all languages.
> Explore streaming Viterbi search in Kuromoji
>
>
> Key: LUCENE-3767
> URL: https://issues.apache.org/jira/browse/LUCENE-3767
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
> compound_diffs.txt
>
>
> I've been playing with the idea of changing the Kuromoji viterbi
> search to be 2 passes (intersect, backtrace) instead of 4 passes
> (break into sentences, intersect, score, backtrace)... this is very
> much a work in progress, so I'm just getting my current state up.
> It's got tons of nocommits, doesn't properly handle the user dict nor
> extended modes yet, etc.
> One thing I'm playing with is to add a double backtrace for the long
> compound tokens, ie, instead of penalizing these tokens so that
> shorter tokens are picked, leave the scores unchanged but on backtrace
> take that penalty and use it as a threshold for a 2nd best
> segmentation...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1301) Solr + Hadoop
[ https://issues.apache.org/jira/browse/SOLR-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214152#comment-13214152 ] Alexander Kanarsky commented on SOLR-1301: -- OK, so I changed the patch to work with 3.5 ant build and re-tested it with Solr 3.5 and Cloudera's CDH3u3 (both the build and csv test run in pseudo-distributed mode). Still no unit tests but I am working on this :) No changes compared to previous version except that I had to comment out the code that sets the debug level dynamically in SolrRecordWriter - because of the conflics with slf4j parts in current Solr; I think it is minor but if not please feel free to resolve this and update the patch. With this done, no need to put the log4j and commons-logging jars in the hadoop/lib at a compile time anymore, only the hadoop jar. I provided the hadoop-core-0.20.2-cdh3u3.jar used for testing as a part of the patch but you can use the other versions of 0.20.x if you'd like; it also should work with hadoop 0.21.x. Note that you still need to make the other related jars (solr, solrj, lucene, commons etc) available while you running your job; one way to do this is to put all the needed jars into the lib subfolder of apache-solr-hadoop jar, another ways are described here: http://www.cloudera.com/blog/2011/01/how-to-include-third-party-libraries-in-your-map-reduce-job/. Finally, the quick steps to get the patch compiled (on linux): 1. get the solr source tarball (apache-solr-3.5.0-src.tgz in this example), put it into some folder, cd there 2. tar -xzf apache-solr-3.5.0-src.tgz 3. cd apache-solr-3.5.0/solr 4. wget https://issues.apache.org/jira/secure/attachment/12515662/SOLR-1301.patch 5. patch -p0 -i SOLR-1301.patch 6. mkdir contrib/hadoop/lib 7. cd contrib/hadoop/lib 8. wget https://issues.apache.org/jira/secure/attachment/12515663/hadoop-core-0.20.2-cdh3u3.jar 9. cd ../../.. 10. ant dist and you should have the apache-solr-hadoop-3.5-SNAPSHOT.jar in solr/dist folder. > Solr + Hadoop > - > > Key: SOLR-1301 > URL: https://issues.apache.org/jira/browse/SOLR-1301 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Fix For: 3.6, 4.0 > > Attachments: README.txt, SOLR-1301-hadoop-0-20.patch, > SOLR-1301-hadoop-0-20.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SolrRecordWriter.java, commons-logging-1.0.4.jar, > commons-logging-api-1.0.4.jar, hadoop-0.19.1-core.jar, > hadoop-0.20.1-core.jar, hadoop-core-0.20.2-cdh3u3.jar, hadoop.patch, > log4j-1.2.15.jar > > > This patch contains a contrib module that provides distributed indexing > (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is > twofold: > * provide an API that is familiar to Hadoop developers, i.e. that of > OutputFormat > * avoid unnecessary export and (de)serialization of data maintained on HDFS. > SolrOutputFormat consumes data produced by reduce tasks directly, without > storing it in intermediate files. Furthermore, by using an > EmbeddedSolrServer, the indexing task is split into as many parts as there > are reducers, and the data to be indexed is not sent over the network. > Design > -- > Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, > which in turn uses SolrRecordWriter to write this data. SolrRecordWriter > instantiates an EmbeddedSolrServer, and it also instantiates an > implementation of SolrDocumentConverter, which is responsible for turning > Hadoop (key, value) into a SolrInputDocument. This data is then added to a > batch, which is periodically submitted to EmbeddedSolrServer. When reduce > task completes, and the OutputFormat is closed, SolrRecordWriter calls > commit() and optimize() on the EmbeddedSolrServer. > The API provides facilities to specify an arbitrary existing solr.home > directory, from which the conf/ and lib/ files will be taken. > This process results in the creation of as many partial Solr home directories > as there were reduce tasks. The output shards are placed in the output > directory on the default filesystem (e.g. HDFS). Such part-N directories > can be used to run N shard servers. Additionally, users can specify the > number of reduce tasks, in particular 1 reduce task, in which case the output > will consist of a single shard. > An example application is provided that processes large CSV files and uses > this API. It uses a custom CSV processing to avoid (de)serialization overhead. > This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this > issue, you should put it in contrib/hadoop/lib. > Note: the development of this patch was spons
[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214148#comment-13214148
]
Robert Muir commented on LUCENE-3767:
-
{quote}
Robert mentioned earlier that he believes IPADIC could have been annotated with
compounds as the documentation mentions them, but they're not part of the
IPADIC model we are using. If it is possible to get the decompounds from the
training data (Kyoto Corpus), a better overall approach is then to do regular
segmentation (normal mode) and then provide the decompounds directly from the
token info for the compounds. We might need to retrain the model and preserving
the decompounds in order for this to work, but I think it is worth
investigating.
{quote}
The dictionary documentation for the original ipadic has the ability to hold
compound data (not in mecab-ipadic though, so maybe it was never
implemented?!),
but I don't actually see it in any implementations. So yeah, we would need to
find a corpus containing compound information (and of course extend the file
format
and add support to kuromoji) to support that.
However, would this really solve the total issue? Wouldn't that really only
help for known kanji compounds... whereas most katakana compounds
(e.g. the software engineer example) are expected to be OOV anyway? So it seems
like, even if we ensured the dictionary was annotated for
long kanji such that we always used decompounded forms, we need a 'heuristical'
decomposition like search-mode either way, at least for
the unknown katakana case?
And I tend to like Mike's improvements from a relevance perspective for these
reasons:
# keeping the original compound term for improved precision
# preventing compound decomposition from having any unrelated negative impact
on the rest of the tokenization
So I think we should pursue this change, even if we want to separately train a
dictionary in the future, because in that case,
we would just disable the kanji decomposition heuristic but keep the heuristic
(obviously re-tuned!) for katakana?
> Explore streaming Viterbi search in Kuromoji
>
>
> Key: LUCENE-3767
> URL: https://issues.apache.org/jira/browse/LUCENE-3767
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
> compound_diffs.txt
>
>
> I've been playing with the idea of changing the Kuromoji viterbi
> search to be 2 passes (intersect, backtrace) instead of 4 passes
> (break into sentences, intersect, score, backtrace)... this is very
> much a work in progress, so I'm just getting my current state up.
> It's got tons of nocommits, doesn't properly handle the user dict nor
> extended modes yet, etc.
> One thing I'm playing with is to add a double backtrace for the long
> compound tokens, ie, instead of penalizing these tokens so that
> shorter tokens are picked, leave the scores unchanged but on backtrace
> take that penalty and use it as a threshold for a 2nd best
> segmentation...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-1301) Solr + Hadoop
[ https://issues.apache.org/jira/browse/SOLR-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214102#comment-13214102 ] Alexander Kanarsky edited comment on SOLR-1301 at 2/22/12 11:33 PM: Note, the hadoop-core-0.20.2-cdh3u3.jar is part of the Coludera's CDH3u3 Hadoop distribution and licensed under Apache License v. 2.0. was (Author: kanarsky): part of the Coludera's CDH3u3 distribution (licensed under Apache License v. 2.0) > Solr + Hadoop > - > > Key: SOLR-1301 > URL: https://issues.apache.org/jira/browse/SOLR-1301 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Fix For: 3.6, 4.0 > > Attachments: README.txt, SOLR-1301-hadoop-0-20.patch, > SOLR-1301-hadoop-0-20.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SolrRecordWriter.java, commons-logging-1.0.4.jar, > commons-logging-api-1.0.4.jar, hadoop-0.19.1-core.jar, > hadoop-0.20.1-core.jar, hadoop-core-0.20.2-cdh3u3.jar, hadoop.patch, > log4j-1.2.15.jar > > > This patch contains a contrib module that provides distributed indexing > (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is > twofold: > * provide an API that is familiar to Hadoop developers, i.e. that of > OutputFormat > * avoid unnecessary export and (de)serialization of data maintained on HDFS. > SolrOutputFormat consumes data produced by reduce tasks directly, without > storing it in intermediate files. Furthermore, by using an > EmbeddedSolrServer, the indexing task is split into as many parts as there > are reducers, and the data to be indexed is not sent over the network. > Design > -- > Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, > which in turn uses SolrRecordWriter to write this data. SolrRecordWriter > instantiates an EmbeddedSolrServer, and it also instantiates an > implementation of SolrDocumentConverter, which is responsible for turning > Hadoop (key, value) into a SolrInputDocument. This data is then added to a > batch, which is periodically submitted to EmbeddedSolrServer. When reduce > task completes, and the OutputFormat is closed, SolrRecordWriter calls > commit() and optimize() on the EmbeddedSolrServer. > The API provides facilities to specify an arbitrary existing solr.home > directory, from which the conf/ and lib/ files will be taken. > This process results in the creation of as many partial Solr home directories > as there were reduce tasks. The output shards are placed in the output > directory on the default filesystem (e.g. HDFS). Such part-N directories > can be used to run N shard servers. Additionally, users can specify the > number of reduce tasks, in particular 1 reduce task, in which case the output > will consist of a single shard. > An example application is provided that processes large CSV files and uses > this API. It uses a custom CSV processing to avoid (de)serialization overhead. > This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this > issue, you should put it in contrib/hadoop/lib. > Note: the development of this patch was sponsored by an anonymous contributor > and approved for release under Apache License. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1301) Solr + Hadoop
[ https://issues.apache.org/jira/browse/SOLR-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kanarsky updated SOLR-1301: - Attachment: hadoop-core-0.20.2-cdh3u3.jar part of the Coludera's CDH3u3 distribution (licensed under Apache License v. 2.0) > Solr + Hadoop > - > > Key: SOLR-1301 > URL: https://issues.apache.org/jira/browse/SOLR-1301 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Fix For: 3.6, 4.0 > > Attachments: README.txt, SOLR-1301-hadoop-0-20.patch, > SOLR-1301-hadoop-0-20.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SolrRecordWriter.java, commons-logging-1.0.4.jar, > commons-logging-api-1.0.4.jar, hadoop-0.19.1-core.jar, > hadoop-0.20.1-core.jar, hadoop-core-0.20.2-cdh3u3.jar, hadoop.patch, > log4j-1.2.15.jar > > > This patch contains a contrib module that provides distributed indexing > (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is > twofold: > * provide an API that is familiar to Hadoop developers, i.e. that of > OutputFormat > * avoid unnecessary export and (de)serialization of data maintained on HDFS. > SolrOutputFormat consumes data produced by reduce tasks directly, without > storing it in intermediate files. Furthermore, by using an > EmbeddedSolrServer, the indexing task is split into as many parts as there > are reducers, and the data to be indexed is not sent over the network. > Design > -- > Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, > which in turn uses SolrRecordWriter to write this data. SolrRecordWriter > instantiates an EmbeddedSolrServer, and it also instantiates an > implementation of SolrDocumentConverter, which is responsible for turning > Hadoop (key, value) into a SolrInputDocument. This data is then added to a > batch, which is periodically submitted to EmbeddedSolrServer. When reduce > task completes, and the OutputFormat is closed, SolrRecordWriter calls > commit() and optimize() on the EmbeddedSolrServer. > The API provides facilities to specify an arbitrary existing solr.home > directory, from which the conf/ and lib/ files will be taken. > This process results in the creation of as many partial Solr home directories > as there were reduce tasks. The output shards are placed in the output > directory on the default filesystem (e.g. HDFS). Such part-N directories > can be used to run N shard servers. Additionally, users can specify the > number of reduce tasks, in particular 1 reduce task, in which case the output > will consist of a single shard. > An example application is provided that processes large CSV files and uses > this API. It uses a custom CSV processing to avoid (de)serialization overhead. > This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this > issue, you should put it in contrib/hadoop/lib. > Note: the development of this patch was sponsored by an anonymous contributor > and approved for release under Apache License. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1301) Solr + Hadoop
[ https://issues.apache.org/jira/browse/SOLR-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214101#comment-13214101 ] Randy Prager commented on SOLR-1301: I will be out of the office from 2/21 to 2/27 with limited email access. For immediate inquiries please contact supp...@fixflyer.com or 888-349-3593. > Solr + Hadoop > - > > Key: SOLR-1301 > URL: https://issues.apache.org/jira/browse/SOLR-1301 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Fix For: 3.6, 4.0 > > Attachments: README.txt, SOLR-1301-hadoop-0-20.patch, > SOLR-1301-hadoop-0-20.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SolrRecordWriter.java, commons-logging-1.0.4.jar, > commons-logging-api-1.0.4.jar, hadoop-0.19.1-core.jar, > hadoop-0.20.1-core.jar, hadoop.patch, log4j-1.2.15.jar > > > This patch contains a contrib module that provides distributed indexing > (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is > twofold: > * provide an API that is familiar to Hadoop developers, i.e. that of > OutputFormat > * avoid unnecessary export and (de)serialization of data maintained on HDFS. > SolrOutputFormat consumes data produced by reduce tasks directly, without > storing it in intermediate files. Furthermore, by using an > EmbeddedSolrServer, the indexing task is split into as many parts as there > are reducers, and the data to be indexed is not sent over the network. > Design > -- > Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, > which in turn uses SolrRecordWriter to write this data. SolrRecordWriter > instantiates an EmbeddedSolrServer, and it also instantiates an > implementation of SolrDocumentConverter, which is responsible for turning > Hadoop (key, value) into a SolrInputDocument. This data is then added to a > batch, which is periodically submitted to EmbeddedSolrServer. When reduce > task completes, and the OutputFormat is closed, SolrRecordWriter calls > commit() and optimize() on the EmbeddedSolrServer. > The API provides facilities to specify an arbitrary existing solr.home > directory, from which the conf/ and lib/ files will be taken. > This process results in the creation of as many partial Solr home directories > as there were reduce tasks. The output shards are placed in the output > directory on the default filesystem (e.g. HDFS). Such part-N directories > can be used to run N shard servers. Additionally, users can specify the > number of reduce tasks, in particular 1 reduce task, in which case the output > will consist of a single shard. > An example application is provided that processes large CSV files and uses > this API. It uses a custom CSV processing to avoid (de)serialization overhead. > This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this > issue, you should put it in contrib/hadoop/lib. > Note: the development of this patch was sponsored by an anonymous contributor > and approved for release under Apache License. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1301) Solr + Hadoop
[ https://issues.apache.org/jira/browse/SOLR-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kanarsky updated SOLR-1301: - Attachment: SOLR-1301.patch SOLR-1301 patch modified to work with Solr 3.x ant build. tested with Solr 3.5.0 and Cloudera CDH3u3 (also attached) > Solr + Hadoop > - > > Key: SOLR-1301 > URL: https://issues.apache.org/jira/browse/SOLR-1301 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Fix For: 3.6, 4.0 > > Attachments: README.txt, SOLR-1301-hadoop-0-20.patch, > SOLR-1301-hadoop-0-20.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SolrRecordWriter.java, commons-logging-1.0.4.jar, > commons-logging-api-1.0.4.jar, hadoop-0.19.1-core.jar, > hadoop-0.20.1-core.jar, hadoop.patch, log4j-1.2.15.jar > > > This patch contains a contrib module that provides distributed indexing > (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is > twofold: > * provide an API that is familiar to Hadoop developers, i.e. that of > OutputFormat > * avoid unnecessary export and (de)serialization of data maintained on HDFS. > SolrOutputFormat consumes data produced by reduce tasks directly, without > storing it in intermediate files. Furthermore, by using an > EmbeddedSolrServer, the indexing task is split into as many parts as there > are reducers, and the data to be indexed is not sent over the network. > Design > -- > Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, > which in turn uses SolrRecordWriter to write this data. SolrRecordWriter > instantiates an EmbeddedSolrServer, and it also instantiates an > implementation of SolrDocumentConverter, which is responsible for turning > Hadoop (key, value) into a SolrInputDocument. This data is then added to a > batch, which is periodically submitted to EmbeddedSolrServer. When reduce > task completes, and the OutputFormat is closed, SolrRecordWriter calls > commit() and optimize() on the EmbeddedSolrServer. > The API provides facilities to specify an arbitrary existing solr.home > directory, from which the conf/ and lib/ files will be taken. > This process results in the creation of as many partial Solr home directories > as there were reduce tasks. The output shards are placed in the output > directory on the default filesystem (e.g. HDFS). Such part-N directories > can be used to run N shard servers. Additionally, users can specify the > number of reduce tasks, in particular 1 reduce task, in which case the output > will consist of a single shard. > An example application is provided that processes large CSV files and uses > this API. It uses a custom CSV processing to avoid (de)serialization overhead. > This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this > issue, you should put it in contrib/hadoop/lib. > Note: the development of this patch was sponsored by an anonymous contributor > and approved for release under Apache License. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3731) Create a analysis/uima module for UIMA based tokenizers/analyzers
[ https://issues.apache.org/jira/browse/LUCENE-3731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214093#comment-13214093 ] Tommaso Teofili commented on LUCENE-3731: - After some more testing I think the CasPool is good just for scenarios where the pool serves different CAS to different clients (the tokenizers), so not really helpful in the current implementation, however it may be useful if we abstract the operation of obtaining and releasing a CAS outside the BaseTokenizer. In the meantime I noticed the AEProviderFactory getAEProvider() methods have a keyPrefix parameter that came from Solr implementation and was intended to hold the core name, so, at the moment I think it'd be better to have (also) methods which don't need that paramater for the Lucene uses. > Create a analysis/uima module for UIMA based tokenizers/analyzers > - > > Key: LUCENE-3731 > URL: https://issues.apache.org/jira/browse/LUCENE-3731 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/analysis >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3731.patch, LUCENE-3731_2.patch, > LUCENE-3731_3.patch, LUCENE-3731_4.patch, LUCENE-3731_rsrel.patch, > LUCENE-3731_speed.patch, LUCENE-3731_speed.patch, LUCENE-3731_speed.patch > > > As discussed in SOLR-3013 the UIMA Tokenizers/Analyzer should be refactored > out in a separate module (modules/analysis/uima) as they can be used in plain > Lucene. Then the solr/contrib/uima will contain only the related factories. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved LUCENE-3819. - Resolution: Fixed > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214009#comment-13214009 ] Mark Miller commented on LUCENE-3819: - So I'm done here for now - just made my last tweak. Thank you everyone for your suggestions and input! > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3810) Text Alignment in the "status-item" tab of the Website needs to be word wrapped
[ https://issues.apache.org/jira/browse/LUCENE-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213986#comment-13213986 ] Mark Miller commented on LUCENE-3810: - Thanks Varun! Hand't seen this issue - I'll take a look at making this change (though we have trimmed some from the sidebar recently). > Text Alignment in the "status-item" tab of the Website needs to be word > wrapped > --- > > Key: LUCENE-3810 > URL: https://issues.apache.org/jira/browse/LUCENE-3810 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Minor > Attachments: LUCENE-3810.patch, lucene.png > > > If we go to http://lucene.apache.org/core/ or http://lucene.apache.org/solr/ > under the Latest Dev section the text is exceeding the css boundary. This is > happening on both Firefox and Chrome. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213983#comment-13213983 ] Mark Miller commented on LUCENE-3819: - Explicitly, based on some informal feedback and my thoughts: 1. Changed color of Solr download button to orange. 2. On the main page, put small gray text indicating what each download button points to (lucene/solr) 3. Added new redirects so that Download buttons now points to the latest release explicitly (3.5) > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3804) Swap Features and News on the website.
[ https://issues.apache.org/jira/browse/LUCENE-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213976#comment-13213976 ] Mark Miller commented on LUCENE-3804: - Thanks hossman - ill get to some of this shortly. > Swap Features and News on the website. > -- > > Key: LUCENE-3804 > URL: https://issues.apache.org/jira/browse/LUCENE-3804 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller > > I think we can do even better, but that is a nice, easy incremental > improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213966#comment-13213966 ] Mark Miller commented on LUCENE-3819: - I just made some more improvements as well. > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3154) SolrJ CloudServer should be leader aware when adding docs
SolrJ CloudServer should be leader aware when adding docs - Key: SOLR-3154 URL: https://issues.apache.org/jira/browse/SOLR-3154 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0 Reporter: Grant Ingersoll Priority: Minor Fix For: 4.0 It would be good when indexing if the SolrJ CloudServer was leader aware so that we could avoid doing an extra hop for the data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 1821 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/1821/ 1 tests failed. REGRESSION: org.apache.solr.TestDistributedGrouping.testDistribSearch Error Message: java.lang.AssertionError: Some threads threw uncaught exceptions! Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:679) at org.apache.lucene.util.LuceneTestCase.access$1000(LuceneTestCase.java:116) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:496) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:400) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:458) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) at org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:707) at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:651) Build Log (for compile errors): [...truncated 16072 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213848#comment-13213848 ] Mark Miller commented on LUCENE-3819: - bq. Thoughts? Sounds good - I've made a first pass at this. > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2604) add regexpquery to queryparser
[ https://issues.apache.org/jira/browse/LUCENE-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213847#comment-13213847 ] Robert Muir commented on LUCENE-2604: - Its no bug: the regexp syntax is optionalField:/stuff/ > add regexpquery to queryparser > -- > > Key: LUCENE-2604 > URL: https://issues.apache.org/jira/browse/LUCENE-2604 > Project: Lucene - Java > Issue Type: New Feature > Components: core/queryparser >Affects Versions: 4.0 >Reporter: Robert Muir >Assignee: Simon Willnauer > Fix For: 4.0 > > Attachments: LUCENE-2604.patch, LUCENE-2604.patch, LUCENE-2604.patch > > > patch that adds RegexpQuery if you /enter an expression between slashes like > this/ > i didnt do the contrib ones but could add it there too if it seems like a > good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2604) add regexpquery to queryparser
[ https://issues.apache.org/jira/browse/LUCENE-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213841#comment-13213841 ] Yury Kats commented on LUCENE-2604: --- I just came across a problem with this, where regular expressions are being parsed across fields. Feels like a bug to me. Queries like these fail to parse: fieldName:/a fieldName:/a SEVERE: org.apache.solr.common.SolrException: no field name specified in query and no defaultSearchField defined in schema.xml at org.apache.solr.search.SolrQueryParser.checkNullField(SolrQueryParser.java:106) at org.apache.solr.search.SolrQueryParser.getFieldQuery(SolrQueryParser.java:124) at org.apache.lucene.queryparser.classic.QueryParserBase.handleBareTokenQuery(QueryParserBase.java:1058) at org.apache.lucene.queryparser.classic.QueryParser.Term(QueryParser.java:358) at org.apache.lucene.queryparser.classic.QueryParser.Clause(QueryParser.java:257) at org.apache.lucene.queryparser.classic.QueryParser.Query(QueryParser.java:212) at org.apache.lucene.queryparser.classic.QueryParser.TopLevelQuery(QueryParser.java:170) at org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:118) at org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:74) at org.apache.solr.search.QParser.getQuery(QParser.java:143) fieldName:/* fieldName:/* java.lang.NullPointerException at org.apache.solr.schema.IndexSchema$DynamicReplacement.matches(IndexSchema.java:747) at org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1026) at org.apache.solr.schema.IndexSchema.getFieldType(IndexSchema.java:980) at org.apache.solr.search.SolrQueryParser.getWildcardQuery(SolrQueryParser.java:172) at org.apache.lucene.queryparser.classic.QueryParserBase.handleBareTokenQuery(QueryParserBase.java:1039) at org.apache.lucene.queryparser.classic.QueryParser.Term(QueryParser.java:358) at org.apache.lucene.queryparser.classic.QueryParser.Clause(QueryParser.java:257) at org.apache.lucene.queryparser.classic.QueryParser.Query(QueryParser.java:212) at org.apache.lucene.queryparser.classic.QueryParser.TopLevelQuery(QueryParser.java:170) at org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:118) at org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:74) at org.apache.solr.search.QParser.getQuery(QParser.java:143) > add regexpquery to queryparser > -- > > Key: LUCENE-2604 > URL: https://issues.apache.org/jira/browse/LUCENE-2604 > Project: Lucene - Java > Issue Type: New Feature > Components: core/queryparser >Affects Versions: 4.0 >Reporter: Robert Muir >Assignee: Simon Willnauer > Fix For: 4.0 > > Attachments: LUCENE-2604.patch, LUCENE-2604.patch, LUCENE-2604.patch > > > patch that adds RegexpQuery if you /enter an expression between slashes like > this/ > i didnt do the contrib ones but could add it there too if it seems like a > good idea. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213787#comment-13213787 ] Steven Rowe commented on LUCENE-3819: - +1 to all of Christian's suggestions > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213776#comment-13213776 ] Christian Moen commented on LUCENE-3819: Thanks, Mark. I like your idea of renaming "User Resources" to "Projects" on the top level page. "Lucene Projects" is perhaps also possible, but I think I like "Projects" better. Regarding downloads, the idea was to make convenience links to the most common downloads -- Lucene Core and Solr -- from the top page, but I realize this breaks the layering structure somewhat. Perhaps "Downloads", "Common Downloads" or "Download Shortcuts" makes sense? Alternatively, we could put download buttons for Lucene Core and Solr in the sidebar. If we follow this approach perhaps we might want to move the buttons to the sidebar for the Lucene Core and Solr page as well. To sum up, I'm proposing: # We rename "User Resources" to "Projects" as you suggested (on the top page) # We add two download buttons for Solr and Lucene to the sidebar (on the top page) # We move the download button to the sidebar on the Lucene Core and Solr pages. (Lucene gets a green button and Solr gets an orange button on the relevant pages.) Thoughts? > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3144) Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec
[ https://issues.apache.org/jira/browse/SOLR-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213758#comment-13213758 ] Sami Siren commented on SOLR-3144: -- Hi Jörg, What version did you see this problem with? I tried to fix this already in SOLR-3037 but perhaps I missed something... > Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec > --- > > Key: SOLR-3144 > URL: https://issues.apache.org/jira/browse/SOLR-3144 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Jörg Maier > Fix For: 4.0 > > Attachments: JavaBinUpdateRequestCodec.patch > > > The parameter marshalling de-marshalling is broken in Solrj's > JavaBinUpdateRequestCodec. > The bug can be reproduced by adding a parameter e.g. overwrite=false as > parameter to the UpdateRequest. After desiarilizing on the backend side the > value will be not "false" it will be "[false]" which results in an Exception > in the backend and documents will not be imported. > This issue can easily be fixed by replacing the serialization method with the > correct one in SolrParams. See also this gist for a working version: > https://gist.github.com/1853544 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213753#comment-13213753 ] Mark Miller commented on LUCENE-3819: - bq. I also think it might be useful to have download shortcuts to Lucene Core (Java) and Solr available in the sidebar from http://lucene.apache.org/. How do you propose we do this? Right now we have links to each subproject called User Resources (could use a better name) - Should we add another section below that called Project Downloads? And rename User Resources to Projects or something? > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213740#comment-13213740 ] Christian Moen edited comment on LUCENE-3819 at 2/22/12 4:21 PM: - +1, Mark. +1, Yonik. I also think it might be useful to have download shortcuts to Lucene Core (Java) and Solr available in the sidebar from http://lucene.apache.org/. Perhaps "Download" could be considered becoming a standard sidebar item for the subprojects? was (Author: cm): +1, Mark. +1, Yonik. I also think it might be useful to have download shortcuts to Lucene Core (Java) and Solr available in the sidebar from http://lucene.apache.org/. Perhaps "Download" could be considered to be a standard sidebar item. (I quite like the red download button, though! :)) > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213740#comment-13213740 ] Christian Moen commented on LUCENE-3819: +1, Mark. +1, Yonik. I also think it might be useful to have download shortcuts to Lucene Core (Java) and Solr available in the sidebar from http://lucene.apache.org/. Perhaps "Download" could be considered to be a standard sidebar item. (I quite like the red download button, though! :)) > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3819) Clean up what we show in right side bar of website.
[ https://issues.apache.org/jira/browse/LUCENE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213713#comment-13213713 ] Yonik Seeley commented on LUCENE-3819: -- +1 And make the sidebar take less horizontal space too (currently ~40%) > Clean up what we show in right side bar of website. > --- > > Key: LUCENE-3819 > URL: https://issues.apache.org/jira/browse/LUCENE-3819 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > I'd love to remove a couple things - it's pretty crowded on the right side > bar. I find the latest JIRA and email displays are hard to read, tend to > format badly, and don't offer much value. > I'd like to remove them and just leave svn commits and twitter mentions > (which are much easier to read and format better). Will help with some info > overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3819) Clean up what we show in right side bar of website.
Clean up what we show in right side bar of website. --- Key: LUCENE-3819 URL: https://issues.apache.org/jira/browse/LUCENE-3819 Project: Lucene - Java Issue Type: Improvement Reporter: Mark Miller Assignee: Mark Miller Priority: Minor I'd love to remove a couple things - it's pretty crowded on the right side bar. I find the latest JIRA and email displays are hard to read, tend to format badly, and don't offer much value. I'd like to remove them and just leave svn commits and twitter mentions (which are much easier to read and format better). Will help with some info overload on each page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3144) Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec
[ https://issues.apache.org/jira/browse/SOLR-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Maier updated SOLR-3144: - Attachment: JavaBinUpdateRequestCodec.patch Attached patch. > Parameter marshalling is broken in Solrj JavaBinUpdateRequestCodec > --- > > Key: SOLR-3144 > URL: https://issues.apache.org/jira/browse/SOLR-3144 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Jörg Maier > Fix For: 4.0 > > Attachments: JavaBinUpdateRequestCodec.patch > > > The parameter marshalling de-marshalling is broken in Solrj's > JavaBinUpdateRequestCodec. > The bug can be reproduced by adding a parameter e.g. overwrite=false as > parameter to the UpdateRequest. After desiarilizing on the backend side the > value will be not "false" it will be "[false]" which results in an Exception > in the backend and documents will not be imported. > This issue can easily be fixed by replacing the serialization method with the > correct one in SolrParams. See also this gist for a working version: > https://gist.github.com/1853544 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3074) SimpleTextCodec needs SimpleText DocValues impl
[ https://issues.apache.org/jira/browse/LUCENE-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213672#comment-13213672 ] Robert Muir commented on LUCENE-3074: - first thoughts: looks nice! Thanks for working on this! I will try to take a look later, I noticed a few imports from lucene40 codec into simpletext (which i think we should avoid), but I think these were just javadocs relics! > SimpleTextCodec needs SimpleText DocValues impl > --- > > Key: LUCENE-3074 > URL: https://issues.apache.org/jira/browse/LUCENE-3074 > Project: Lucene - Java > Issue Type: Task > Components: core/index, core/search >Affects Versions: 4.0 >Reporter: Simon Willnauer >Assignee: Simon Willnauer >Priority: Blocker > Fix For: 4.0 > > Attachments: LUCENE-3074.patch > > > currently SimpleTextCodec uses binary docValues we should move that to a > simple text impl. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3818) TestIndexWriterNRTIsCurrent failure
TestIndexWriterNRTIsCurrent failure
---
Key: LUCENE-3818
URL: https://issues.apache.org/jira/browse/LUCENE-3818
Project: Lucene - Java
Issue Type: Bug
Reporter: Robert Muir
Fix For: 4.0
found by jenkins:
https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12492/
make your computer busy (e.g. run tests in another checkout) then,
ant test-core -Dtests.iter=100 -Dtestcase=TestIndexWriterNRTIsCurrent
-Dtestmethod=testIsCurrentWithThreads
-Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3
-Dtests.multiplier=3 -Dargs="-Dfile.encoding=ISO8859-1"
takes a few tries till it pops...
{noformat}
junit-sequential:
[junit] Testsuite: org.apache.lucene.index.TestIndexWriterNRTIsCurrent
[junit] Tests run: 100, Failures: 1, Errors: 1, Time elapsed: 277.818 sec
[junit]
[junit] - Standard Output ---
[junit] WARNING: you are using -Dtests.iter=n where n > 1, not all tests
support this option.
[junit] Some may crash or fail: this is not a bug.
[junit] - ---
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test
-Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads
-Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3
-Dtests.multiplier=3 -Dargs="-Dfile.encoding=ISO8859-1"
[junit] The following exceptions were thrown by threads:
[junit] *** Thread: Lucene Merge Thread #17 ***
[junit] org.apache.lucene.index.MergePolicy$MergeException:
java.lang.AssertionError
[junit] at
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:520)
[junit] at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:480)
[junit] Caused by: java.lang.AssertionError
[junit] at
org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.initWritableLiveDocs(IndexWriter.java:580)
[junit] at
org.apache.lucene.index.IndexWriter.commitMergedDeletes(IndexWriter.java:3061)
[junit] at
org.apache.lucene.index.IndexWriter.commitMerge(IndexWriter.java:3137)
[junit] at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3718)
[junit] at
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3257)
[junit] at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
[junit] at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
[junit] NOTE: reproduce with: ant test
-Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads
-Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3
-Dtests.multiplier=3 -Dargs="-Dfile.encoding=ISO8859-1"
[junit] NOTE: reproduce with: ant test
-Dtestcase=TestIndexWriterNRTIsCurrent -Dtestmethod=testIsCurrentWithThreads
-Dtests.seed=-78f6fa16b849cf27:382126da79c1e146:-d2cdec79e86e1b3
-Dtests.multiplier=3 -Dargs="-Dfile.encoding=ISO8859-1"
[junit] NOTE: test params are: codec=Lucene40:
{id=MockFixedIntBlock(blockSize=525)}, sim=DefaultSimilarity, locale=es_PY,
timezone=Africa/Luanda
[junit] NOTE: all tests run in this JVM:
[junit] [TestIndexWriterNRTIsCurrent]
[junit] NOTE: Linux 3.0.0-14-generic amd64/Sun Microsystems Inc. 1.6.0_24
(64-bit)/cpus=8,threads=1,free=74907448,total=255787008
[junit] - ---
[junit] Testcase:
testIsCurrentWithThreads(org.apache.lucene.index.TestIndexWriterNRTIsCurrent):
FAILED
[junit] info=_qx(4.0):C1/1 isn't live
[junit] junit.framework.AssertionFailedError: info=_qx(4.0):C1/1 isn't live
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
[junit] at
org.apache.lucene.index.IndexWriter$ReaderPool.infoIsLive(IndexWriter.java:663)
[junit] at
org.apache.lucene.index.IndexWriter$ReaderPool.dropAll(IndexWriter.java:717)
[junit] at
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1136)
[junit] at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1069)
[junit] at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1033)
[junit] at
org.apache.lucene.index.TestIndexWriterNRTIsCurrent.testIsCurrentWithThreads(TestIndexWriterNRTIsCurrent.java:68)
[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707)
[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606)
[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(
[jira] [Updated] (SOLR-3153) When a leader goes down he should ask replicas to sync in parallel rather than serially.
[ https://issues.apache.org/jira/browse/SOLR-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3153: -- Attachment: SOLR-3153.patch > When a leader goes down he should ask replicas to sync in parallel rather > than serially. > > > Key: SOLR-3153 > URL: https://issues.apache.org/jira/browse/SOLR-3153 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3153.patch > > > Need to finish this todo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3074) SimpleTextCodec needs SimpleText DocValues impl
[ https://issues.apache.org/jira/browse/LUCENE-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-3074: Attachment: LUCENE-3074.patch here is a first patch adding SimpleTextDV and replacing SimpleTextNorms with it directly. I had to change some upstream classes and especially the merging done in the DocValuesConsumer which used the "wrong" type for merging. In general we should use the target type instead of the source type and sources need to implement getBytes and do auto conversion otherwise type promotion doesn't work. this patch writes individual files per field like sep codec which made things a lot easier and is maybe better suited for SimpleText comments welcome > SimpleTextCodec needs SimpleText DocValues impl > --- > > Key: LUCENE-3074 > URL: https://issues.apache.org/jira/browse/LUCENE-3074 > Project: Lucene - Java > Issue Type: Task > Components: core/index, core/search >Affects Versions: 4.0 >Reporter: Simon Willnauer >Assignee: Simon Willnauer >Priority: Blocker > Fix For: 4.0 > > Attachments: LUCENE-3074.patch > > > currently SimpleTextCodec uses binary docValues we should move that to a > simple text impl. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3153) When a leader goes down he should ask replicas to sync in parallel rather than serially.
When a leader goes down he should ask replicas to sync in parallel rather than serially. Key: SOLR-3153 URL: https://issues.apache.org/jira/browse/SOLR-3153 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.0 Need to finish this todo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (LUCENE-3800) Readers wrapping other readers don't prevent usage if any of their subreaders was closed
[ https://issues.apache.org/jira/browse/LUCENE-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213642#comment-13213642 ] Uwe Schindler edited comment on LUCENE-3800 at 2/22/12 2:18 PM: Yes! By the way, the same trick is used for MMapDirectory to keep track of its clones IndexInputs. was (Author: thetaphi): Yes! > Readers wrapping other readers don't prevent usage if any of their subreaders > was closed > > > Key: LUCENE-3800 > URL: https://issues.apache.org/jira/browse/LUCENE-3800 > Project: Lucene - Java > Issue Type: Bug > Components: core/index >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.0 > > Attachments: LUCENE-3800.patch, LUCENE-3800.patch, LUCENE-3800.patch > > > On recent trunk test we got this problem: > org.apache.lucene.index.TestReaderClosed.test > fails because the inner reader is closed but the wrapped outer ones are still > open. > I fixed the issue partially for SlowCompositeReaderWrapper and > ParallelAtomicReader but it failed again. The cool thing with this test is > the following: > The test opens an DirectoryReader and then creates a searcher, closes the > reader and executes a search. This is not an issue, if the reader is closed > that the search is running on. This test uses LTC.newSearcher(wrap=true), > which randomly wraps the passed Reader with SlowComposite or ParallelReader - > or with both!!! If you then close the original inner reader, the close is not > detected when excuting search. This can cause SIGSEGV when MMAP is used. > The problem in (in Slow* and Parallel*) is, that both have their own Fields > instances thats are kept alive until the reader itsself is closed. If the > child reader is closed, the wrapping reader does not know and still uses its > own Fields instance that delegates to the inner readers. On this step no more > ensureOpen checks are done, causing the failures. > The first fix done in Slow and Parallel was to call ensureOpen() on the > subReader, too when requesting fields(). This works fine until you wrap two > times: > ParallelAtomicReader(SlowCompositeReaderWrapper(StandardDirectoryReader(segments_1:3:nrt > _0(4.0):C42))) > One solution would be to make ensureOpen also check all subreaders, but that > would do the volatile checks way too often (with n is the total number of > subreaders and m is the number of hierarchical levels this is n^m) - we > cannot do this. Currently we only have n*m which is fine. > The proposal how to solve this (closing subreaders under the hood of parent > readers is to use the readerClosedListeners. Whenever a composite or slow > reader wraps another readers, it registers itself as interested in > readerClosed events. When a subreader is then forcefully closed (e.g by a > programming error or this crazy test), we automatically close the parents, > too. > We should also fix this in 3.x, if we have similar problems there (needs > investigation). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3009) hitGrouped.vm isn't shipped with 3.x
[ https://issues.apache.org/jira/browse/SOLR-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-3009. --- Resolution: Fixed > hitGrouped.vm isn't shipped with 3.x > > > Key: SOLR-3009 > URL: https://issues.apache.org/jira/browse/SOLR-3009 > Project: Solr > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Erik Hatcher >Assignee: Jan Høydahl > Fix For: 3.6 > > Attachments: SOLR-3009.patch > > > A user reported getting "Can't find resource 'hitGrouped.vm'" when trying > /browse?q=Titel%3Anike&group=true&group.field=EAN on a 3.x version. Looking > at svn, we don't ship hitGrouped.vm on 3.x, but we do on trunk/4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3009) hitGrouped.vm isn't shipped with 3.x
[ https://issues.apache.org/jira/browse/SOLR-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-3009: - Assignee: Jan Høydahl (was: Erik Hatcher) > hitGrouped.vm isn't shipped with 3.x > > > Key: SOLR-3009 > URL: https://issues.apache.org/jira/browse/SOLR-3009 > Project: Solr > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Erik Hatcher >Assignee: Jan Høydahl > Fix For: 3.6 > > Attachments: SOLR-3009.patch > > > A user reported getting "Can't find resource 'hitGrouped.vm'" when trying > /browse?q=Titel%3Anike&group=true&group.field=EAN on a 3.x version. Looking > at svn, we don't ship hitGrouped.vm on 3.x, but we do on trunk/4.0. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3800) Readers wrapping other readers don't prevent usage if any of their subreaders was closed
[ https://issues.apache.org/jira/browse/LUCENE-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213642#comment-13213642 ] Uwe Schindler commented on LUCENE-3800: --- Yes! > Readers wrapping other readers don't prevent usage if any of their subreaders > was closed > > > Key: LUCENE-3800 > URL: https://issues.apache.org/jira/browse/LUCENE-3800 > Project: Lucene - Java > Issue Type: Bug > Components: core/index >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.0 > > Attachments: LUCENE-3800.patch, LUCENE-3800.patch, LUCENE-3800.patch > > > On recent trunk test we got this problem: > org.apache.lucene.index.TestReaderClosed.test > fails because the inner reader is closed but the wrapped outer ones are still > open. > I fixed the issue partially for SlowCompositeReaderWrapper and > ParallelAtomicReader but it failed again. The cool thing with this test is > the following: > The test opens an DirectoryReader and then creates a searcher, closes the > reader and executes a search. This is not an issue, if the reader is closed > that the search is running on. This test uses LTC.newSearcher(wrap=true), > which randomly wraps the passed Reader with SlowComposite or ParallelReader - > or with both!!! If you then close the original inner reader, the close is not > detected when excuting search. This can cause SIGSEGV when MMAP is used. > The problem in (in Slow* and Parallel*) is, that both have their own Fields > instances thats are kept alive until the reader itsself is closed. If the > child reader is closed, the wrapping reader does not know and still uses its > own Fields instance that delegates to the inner readers. On this step no more > ensureOpen checks are done, causing the failures. > The first fix done in Slow and Parallel was to call ensureOpen() on the > subReader, too when requesting fields(). This works fine until you wrap two > times: > ParallelAtomicReader(SlowCompositeReaderWrapper(StandardDirectoryReader(segments_1:3:nrt > _0(4.0):C42))) > One solution would be to make ensureOpen also check all subreaders, but that > would do the volatile checks way too often (with n is the total number of > subreaders and m is the number of hierarchical levels this is n^m) - we > cannot do this. Currently we only have n*m which is fine. > The proposal how to solve this (closing subreaders under the hood of parent > readers is to use the readerClosedListeners. Whenever a composite or slow > reader wraps another readers, it registers itself as interested in > readerClosed events. When a subreader is then forcefully closed (e.g by a > programming error or this crazy test), we automatically close the parents, > too. > We should also fix this in 3.x, if we have similar problems there (needs > investigation). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3800) Readers wrapping other readers don't prevent usage if any of their subreaders was closed
[ https://issues.apache.org/jira/browse/LUCENE-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213638#comment-13213638 ] Yonik Seeley commented on LUCENE-3800: -- Ouch - more weak references. I was hoping we could reduce the number of those (I've seen them cause worse GC problems for a number of people). But if I understand the description correctly, then without this patch things could core dump when using mmap directory? > Readers wrapping other readers don't prevent usage if any of their subreaders > was closed > > > Key: LUCENE-3800 > URL: https://issues.apache.org/jira/browse/LUCENE-3800 > Project: Lucene - Java > Issue Type: Bug > Components: core/index >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.0 > > Attachments: LUCENE-3800.patch, LUCENE-3800.patch, LUCENE-3800.patch > > > On recent trunk test we got this problem: > org.apache.lucene.index.TestReaderClosed.test > fails because the inner reader is closed but the wrapped outer ones are still > open. > I fixed the issue partially for SlowCompositeReaderWrapper and > ParallelAtomicReader but it failed again. The cool thing with this test is > the following: > The test opens an DirectoryReader and then creates a searcher, closes the > reader and executes a search. This is not an issue, if the reader is closed > that the search is running on. This test uses LTC.newSearcher(wrap=true), > which randomly wraps the passed Reader with SlowComposite or ParallelReader - > or with both!!! If you then close the original inner reader, the close is not > detected when excuting search. This can cause SIGSEGV when MMAP is used. > The problem in (in Slow* and Parallel*) is, that both have their own Fields > instances thats are kept alive until the reader itsself is closed. If the > child reader is closed, the wrapping reader does not know and still uses its > own Fields instance that delegates to the inner readers. On this step no more > ensureOpen checks are done, causing the failures. > The first fix done in Slow and Parallel was to call ensureOpen() on the > subReader, too when requesting fields(). This works fine until you wrap two > times: > ParallelAtomicReader(SlowCompositeReaderWrapper(StandardDirectoryReader(segments_1:3:nrt > _0(4.0):C42))) > One solution would be to make ensureOpen also check all subreaders, but that > would do the volatile checks way too often (with n is the total number of > subreaders and m is the number of hierarchical levels this is n^m) - we > cannot do this. Currently we only have n*m which is fine. > The proposal how to solve this (closing subreaders under the hood of parent > readers is to use the readerClosedListeners. Whenever a composite or slow > reader wraps another readers, it registers itself as interested in > readerClosed events. When a subreader is then forcefully closed (e.g by a > programming error or this crazy test), we automatically close the parents, > too. > We should also fix this in 3.x, if we have similar problems there (needs > investigation). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3817) TestThreadedForceMerge failure
TestThreadedForceMerge failure
--
Key: LUCENE-3817
URL: https://issues.apache.org/jira/browse/LUCENE-3817
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir
leaks a file handle
was running tests a lot to keep my computer busy while debugging something else.
{noformat}
[junit] Testsuite: org.apache.lucene.index.TestThreadedForceMerge
[junit] Testcase:
testThreadedForceMerge(org.apache.lucene.index.TestThreadedForceMerge):
Caused an ERROR
[junit] MockDirectoryWrapper: cannot close: there are still open files:
{_58_1.skp=1, _58_1.tib=1, _58_1.tii=1, _58_0.frq=1, _58_0.tim=1, _58.tvf=1,
_58.tvd=1, _58_1.doc=1, _58.tvx=1, _58.fdt=1, _58.fdx=1}
[junit] java.lang.RuntimeException: MockDirectoryWrapper: cannot close:
there are still open files: {_58_1.skp=1, _58_1.tib=1, _58_1.tii=1,
_58_0.frq=1, _58_0.tim=1, _58.tvf=1, _58.tvd=1, _58_1.doc=1, _58.tvx=1,
_58.fdt=1, _58.fdx=1}
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:555)
[junit] at
org.apache.lucene.index.TestThreadedForceMerge.testThreadedForceMerge(TestThreadedForceMerge.java:141)
[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707)
[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606)
[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511)
[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
[junit] Caused by: java.lang.RuntimeException: unclosed IndexInput:
_58_1.doc
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:479)
[junit] at
org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:504)
[junit] at
org.apache.lucene.codecs.mocksep.MockSingleIntIndexInput.(MockSingleIntIndexInput.java:41)
[junit] at
org.apache.lucene.codecs.mocksep.MockSingleIntFactory.openInput(MockSingleIntFactory.java:32)
[junit] at
org.apache.lucene.codecs.sep.SepPostingsReader.(SepPostingsReader.java:68)
[junit] at
org.apache.lucene.codecs.mocksep.MockSepPostingsFormat.fieldsProducer(MockSepPostingsFormat.java:89)
[junit] at
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader$1.visitOneFormat(PerFieldPostingsFormat.java:189)
[junit] at
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$VisitPerFieldFile.(PerFieldPostingsFormat.java:280)
[junit] at
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader$1.(PerFieldPostingsFormat.java:186)
[junit] at
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:186)
[junit] at
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:256)
[junit] at
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:108)
[junit] at
org.apache.lucene.index.SegmentReader.(SegmentReader.java:51)
[junit] at
org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.getMergeReader(IndexWriter.java:521)
[junit] at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3586)
[junit] at
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3256)
[junit] at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
[junit] at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
[junit]
[junit]
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.704 sec
[junit]
[junit] - Standard Error -
[junit] NOTE: reproduce with: ant test -Dtestcase=TestThreadedForceMerge
-Dtestmethod=testThreadedForceMerge
-Dtests.seed=-36d98ee49f3f6205:-602830ebcb0e2f6d:9429978db44e64b
-Dargs="-Dfile.encoding=UTF-8"
[junit] NOTE: test params are: codec=Lucene40:
{id=PostingsFormat(name=MockSep), contents=PostingsFormat(name=NestedPulsing)},
sim=RandomSimilarityProvider(queryNorm=false,coord=true): {}, locale=ar_JO,
timezone=Asia/Pontianak
[junit] NOTE: all tests run in this JVM:
[junit] [TestSearchForDuplicates, TestMockAnalyzer, TestToken,
TestIntBlockCodec, TestImpersonation, TestBitVector, TestAtomicUpdate,
TestBinaryTerms, TestCheckIndex, TestCrashCausesCorruptIndex,
TestDirectoryReaderReopen, TestDocCount, TestDocValuesIndexing,
TestForTooMuchCloning, TestIndexInput
[jira] [Commented] (LUCENE-3800) Readers wrapping other readers don't prevent usage if any of their subreaders was closed
[ https://issues.apache.org/jira/browse/LUCENE-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213626#comment-13213626 ] Uwe Schindler commented on LUCENE-3800: --- If this would be good for 3.x, too -> reopen. 3.x is more safe as if a child reader is closed also parent readers have mostly no chance to do anything. > Readers wrapping other readers don't prevent usage if any of their subreaders > was closed > > > Key: LUCENE-3800 > URL: https://issues.apache.org/jira/browse/LUCENE-3800 > Project: Lucene - Java > Issue Type: Bug > Components: core/index >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.0 > > Attachments: LUCENE-3800.patch, LUCENE-3800.patch, LUCENE-3800.patch > > > On recent trunk test we got this problem: > org.apache.lucene.index.TestReaderClosed.test > fails because the inner reader is closed but the wrapped outer ones are still > open. > I fixed the issue partially for SlowCompositeReaderWrapper and > ParallelAtomicReader but it failed again. The cool thing with this test is > the following: > The test opens an DirectoryReader and then creates a searcher, closes the > reader and executes a search. This is not an issue, if the reader is closed > that the search is running on. This test uses LTC.newSearcher(wrap=true), > which randomly wraps the passed Reader with SlowComposite or ParallelReader - > or with both!!! If you then close the original inner reader, the close is not > detected when excuting search. This can cause SIGSEGV when MMAP is used. > The problem in (in Slow* and Parallel*) is, that both have their own Fields > instances thats are kept alive until the reader itsself is closed. If the > child reader is closed, the wrapping reader does not know and still uses its > own Fields instance that delegates to the inner readers. On this step no more > ensureOpen checks are done, causing the failures. > The first fix done in Slow and Parallel was to call ensureOpen() on the > subReader, too when requesting fields(). This works fine until you wrap two > times: > ParallelAtomicReader(SlowCompositeReaderWrapper(StandardDirectoryReader(segments_1:3:nrt > _0(4.0):C42))) > One solution would be to make ensureOpen also check all subreaders, but that > would do the volatile checks way too often (with n is the total number of > subreaders and m is the number of hierarchical levels this is n^m) - we > cannot do this. Currently we only have n*m which is fine. > The proposal how to solve this (closing subreaders under the hood of parent > readers is to use the readerClosedListeners. Whenever a composite or slow > reader wraps another readers, it registers itself as interested in > readerClosed events. When a subreader is then forcefully closed (e.g by a > programming error or this crazy test), we automatically close the parents, > too. > We should also fix this in 3.x, if we have similar problems there (needs > investigation). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3800) Readers wrapping other readers don't prevent usage if any of their subreaders was closed
[ https://issues.apache.org/jira/browse/LUCENE-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3800. --- Resolution: Fixed Committed trunk revision: 1292293 > Readers wrapping other readers don't prevent usage if any of their subreaders > was closed > > > Key: LUCENE-3800 > URL: https://issues.apache.org/jira/browse/LUCENE-3800 > Project: Lucene - Java > Issue Type: Bug > Components: core/index >Affects Versions: 4.0 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.0 > > Attachments: LUCENE-3800.patch, LUCENE-3800.patch, LUCENE-3800.patch > > > On recent trunk test we got this problem: > org.apache.lucene.index.TestReaderClosed.test > fails because the inner reader is closed but the wrapped outer ones are still > open. > I fixed the issue partially for SlowCompositeReaderWrapper and > ParallelAtomicReader but it failed again. The cool thing with this test is > the following: > The test opens an DirectoryReader and then creates a searcher, closes the > reader and executes a search. This is not an issue, if the reader is closed > that the search is running on. This test uses LTC.newSearcher(wrap=true), > which randomly wraps the passed Reader with SlowComposite or ParallelReader - > or with both!!! If you then close the original inner reader, the close is not > detected when excuting search. This can cause SIGSEGV when MMAP is used. > The problem in (in Slow* and Parallel*) is, that both have their own Fields > instances thats are kept alive until the reader itsself is closed. If the > child reader is closed, the wrapping reader does not know and still uses its > own Fields instance that delegates to the inner readers. On this step no more > ensureOpen checks are done, causing the failures. > The first fix done in Slow and Parallel was to call ensureOpen() on the > subReader, too when requesting fields(). This works fine until you wrap two > times: > ParallelAtomicReader(SlowCompositeReaderWrapper(StandardDirectoryReader(segments_1:3:nrt > _0(4.0):C42))) > One solution would be to make ensureOpen also check all subreaders, but that > would do the volatile checks way too often (with n is the total number of > subreaders and m is the number of hierarchical levels this is n^m) - we > cannot do this. Currently we only have n*m which is fine. > The proposal how to solve this (closing subreaders under the hood of parent > readers is to use the readerClosedListeners. Whenever a composite or slow > reader wraps another readers, it registers itself as interested in > readerClosed events. When a subreader is then forcefully closed (e.g by a > programming error or this crazy test), we automatically close the parents, > too. > We should also fix this in 3.x, if we have similar problems there (needs > investigation). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3816) FilteredDocIdSet does not handle a case where the inner set iterator is null
[ https://issues.apache.org/jira/browse/LUCENE-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3816. --- Resolution: Fixed Committed trunk revision: 1292282 Committed 3.x revision: 1292288 Thanks Shay! > FilteredDocIdSet does not handle a case where the inner set iterator is null > > > Key: LUCENE-3816 > URL: https://issues.apache.org/jira/browse/LUCENE-3816 > Project: Lucene - Java > Issue Type: Bug > Components: core/search >Affects Versions: 3.5 >Reporter: Shay Banon >Assignee: Uwe Schindler > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3816.patch, LUCENE-3816.patch > > > DocIdSet#iterator is allowed to return null, when used in FilteredDocIdSet, > if null is returned from the inner set, the FilteredDocIdSetIterator fails > since it does not allow for nulls to be passed to it. > The fix is simple, return null in FilteredDocIdSet in the iterator method is > the iterator is null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3816) FilteredDocIdSet does not handle a case where the inner set iterator is null
[ https://issues.apache.org/jira/browse/LUCENE-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3816: -- Attachment: LUCENE-3816.patch Patch with a new test that verifies this works. Fails without Shay's patch. Will commit now. > FilteredDocIdSet does not handle a case where the inner set iterator is null > > > Key: LUCENE-3816 > URL: https://issues.apache.org/jira/browse/LUCENE-3816 > Project: Lucene - Java > Issue Type: Bug > Components: core/search >Affects Versions: 3.5 >Reporter: Shay Banon >Assignee: Uwe Schindler > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3816.patch, LUCENE-3816.patch > > > DocIdSet#iterator is allowed to return null, when used in FilteredDocIdSet, > if null is returned from the inner set, the FilteredDocIdSetIterator fails > since it does not allow for nulls to be passed to it. > The fix is simple, return null in FilteredDocIdSet in the iterator method is > the iterator is null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2607) Clean up /client directory
[ https://issues.apache.org/jira/browse/SOLR-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved SOLR-2607. Resolution: Fixed Thanks Jan, committed. > Clean up /client directory > -- > > Key: SOLR-2607 > URL: https://issues.apache.org/jira/browse/SOLR-2607 > Project: Solr > Issue Type: Task > Components: clients - java, clients - ruby - flare >Affects Versions: 4.0 >Reporter: Eric Pugh >Assignee: Erik Hatcher >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2607.patch > > > The /clients directory is a bit of a mess. The only actively maintained > client SolrJ is actually in the /dist directory! The other clients that > used to be in here, /php and /javascript (I think!) have been moved. The > only one is /ruby, and it isn't actively maintained the way other ruby > clients are. > I'd recommend just removing the /clients directory since it's very confusing > to a new user who would logically go here to find clients, and only find a > ruby one! It would also let us slim down the size of the download. > Alterntively if we want the /clients directory, then lets copy over the solrj > lib to this dir instead of /dist > I am happy to submit a patch if this makes sense. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2607) Clean up /client directory
[ https://issues.apache.org/jira/browse/SOLR-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-2607: --- Summary: Clean up /client directory (was: Clean up /clients directory) > Clean up /client directory > -- > > Key: SOLR-2607 > URL: https://issues.apache.org/jira/browse/SOLR-2607 > Project: Solr > Issue Type: Task > Components: clients - java, clients - ruby - flare >Affects Versions: 4.0 >Reporter: Eric Pugh >Assignee: Erik Hatcher >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2607.patch > > > The /clients directory is a bit of a mess. The only actively maintained > client SolrJ is actually in the /dist directory! The other clients that > used to be in here, /php and /javascript (I think!) have been moved. The > only one is /ruby, and it isn't actively maintained the way other ruby > clients are. > I'd recommend just removing the /clients directory since it's very confusing > to a new user who would logically go here to find clients, and only find a > ruby one! It would also let us slim down the size of the download. > Alterntively if we want the /clients directory, then lets copy over the solrj > lib to this dir instead of /dist > I am happy to submit a patch if this makes sense. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3816) FilteredDocIdSet does not handle a case where the inner set iterator is null
[ https://issues.apache.org/jira/browse/LUCENE-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3816: -- Fix Version/s: 4.0 3.6 > FilteredDocIdSet does not handle a case where the inner set iterator is null > > > Key: LUCENE-3816 > URL: https://issues.apache.org/jira/browse/LUCENE-3816 > Project: Lucene - Java > Issue Type: Bug > Components: core/search >Affects Versions: 3.5 >Reporter: Shay Banon >Assignee: Uwe Schindler > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3816.patch > > > DocIdSet#iterator is allowed to return null, when used in FilteredDocIdSet, > if null is returned from the inner set, the FilteredDocIdSetIterator fails > since it does not allow for nulls to be passed to it. > The fix is simple, return null in FilteredDocIdSet in the iterator method is > the iterator is null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3816) FilteredDocIdSet does not handle a case where the inner set iterator is null
[ https://issues.apache.org/jira/browse/LUCENE-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213592#comment-13213592 ] Uwe Schindler commented on LUCENE-3816: --- Tha nks for reporting this, I will check and commit trunk and 3.x branch! > FilteredDocIdSet does not handle a case where the inner set iterator is null > > > Key: LUCENE-3816 > URL: https://issues.apache.org/jira/browse/LUCENE-3816 > Project: Lucene - Java > Issue Type: Bug > Components: core/search >Affects Versions: 3.5 >Reporter: Shay Banon >Assignee: Uwe Schindler > Attachments: LUCENE-3816.patch > > > DocIdSet#iterator is allowed to return null, when used in FilteredDocIdSet, > if null is returned from the inner set, the FilteredDocIdSetIterator fails > since it does not allow for nulls to be passed to it. > The fix is simple, return null in FilteredDocIdSet in the iterator method is > the iterator is null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-3816) FilteredDocIdSet does not handle a case where the inner set iterator is null
[ https://issues.apache.org/jira/browse/LUCENE-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-3816: - Assignee: Uwe Schindler > FilteredDocIdSet does not handle a case where the inner set iterator is null > > > Key: LUCENE-3816 > URL: https://issues.apache.org/jira/browse/LUCENE-3816 > Project: Lucene - Java > Issue Type: Bug > Components: core/search >Affects Versions: 3.5 >Reporter: Shay Banon >Assignee: Uwe Schindler > Attachments: LUCENE-3816.patch > > > DocIdSet#iterator is allowed to return null, when used in FilteredDocIdSet, > if null is returned from the inner set, the FilteredDocIdSetIterator fails > since it does not allow for nulls to be passed to it. > The fix is simple, return null in FilteredDocIdSet in the iterator method is > the iterator is null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 12492 - Failure
OK for the TestIndexWriterNRTisCurrent, it reproduces better if you make your computer busy (run it with -Dtests.iter=100 or so at the same time as running 'ant test' in another checkout) improving the assert a bit: [junit] Caused by: java.lang.AssertionError: out of bounds: docid=0,liveDocsLength=0 [junit] at org.apache.lucene.index.IndexWriter$ReadersAndLiveDocs.delete(IndexWriter.java:535) [junit] at org.apache.lucene.index.IndexWriter.commitMergedDeletes(IndexWriter.java:3062) [junit] at org.apache.lucene.index.IndexWriter.commitMerge(IndexWriter.java:3136) seems bogus that we have a 0-length bitvector... On Wed, Feb 22, 2012 at 6:15 AM, Robert Muir wrote: > There are actually 2 failures here... TestDeletionPolicy was a bug in > LuceneTestCase. > TestIndexWriterNRTIsCurrent is something else, and it doesnt reproduce > easily yet > > On Wed, Feb 22, 2012 at 4:11 AM, Apache Jenkins Server > wrote: >> Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12492/ >> >> 2 tests failed. >> REGRESSION: >> org.apache.lucene.index.TestDeletionPolicy.testKeepLastNDeletionPolicyWithCreates >> >> Error Message: >> null >> >> Stack Trace: >> java.lang.NullPointerException >> at >> org.apache.lucene.index.FilterAtomicReader$FilterFields.terms(FilterAtomicReader.java:53) >> at org.apache.lucene.util.TermContext.build(TermContext.java:94) >> at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:180) >> at >> org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:584) >> at >> org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59) >> at >> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:258) >> at >> org.apache.lucene.index.TestDeletionPolicy.testKeepLastNDeletionPolicyWithCreates(TestDeletionPolicy.java:701) >> at >> org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707) >> at >> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) >> at >> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) >> at >> org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) >> at >> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) >> at >> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) >> >> >> REGRESSION: >> org.apache.lucene.index.TestIndexWriterNRTIsCurrent.testIsCurrentWithThreads >> >> Error Message: >> java.lang.AssertionError: Some threads threw uncaught exceptions! >> >> Stack Trace: >> java.lang.RuntimeException: java.lang.AssertionError: Some threads threw >> uncaught exceptions! >> at >> org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:780) >> at >> org.apache.lucene.util.LuceneTestCase.access$1000(LuceneTestCase.java:138) >> at >> org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:607) >> at >> org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) >> at >> org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) >> at >> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) >> at >> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) >> at >> org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:808) >> at >> org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:752) >> >> >> >> >> Build Log (for compile errors): >> [...truncated 1547 lines...] >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org > > > > -- > lucidimagination.com -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3151) Replace zookeeper.jsp with a servlet
[ https://issues.apache.org/jira/browse/SOLR-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213568#comment-13213568 ] Erik Hatcher commented on SOLR-3151: Ok, so definitely not appropriate for this to be a request handler. And yeah, that core admin is crazy stuff - wouldn't allow for a custom (or non-default, thus not Velocity) response writing. Carry on... > Replace zookeeper.jsp with a servlet > > > Key: SOLR-3151 > URL: https://issues.apache.org/jira/browse/SOLR-3151 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-3151-invalid-json-for-solrconfig.json, > SOLR-3151-zookeeper-servlet.patch > > > The zookeeper info is currently generated with a jsp file -- making it harder > to maintain then it should be, and harder to include in other applications -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12494 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12494/ 2 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch Error Message: There are still nodes recoverying Stack Trace: junit.framework.AssertionFailedError: There are still nodes recoverying at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:124) at org.apache.solr.cloud.BasicDistributedZkTest.testANewCollectionInOneInstanceWithManualShardAssignement(BasicDistributedZkTest.java:306) at org.apache.solr.cloud.BasicDistributedZkTest.doTest(BasicDistributedZkTest.java:276) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:664) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: ERROR: SolrIndexSearcher opens=86 closes=85 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=86 closes=85 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:152) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:76) Build Log (for compile errors): [...truncated 7939 lines...] - 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-java7 - Build # 1788 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1788/ 2 tests failed. REGRESSION: org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch Error Message: There are still nodes recoverying Stack Trace: junit.framework.AssertionFailedError: There are still nodes recoverying at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:124) at org.apache.solr.cloud.BasicDistributedZkTest.testANewCollectionInOneInstanceWithManualShardAssignement(BasicDistributedZkTest.java:306) at org.apache.solr.cloud.BasicDistributedZkTest.doTest(BasicDistributedZkTest.java:276) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:664) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest Error Message: ERROR: SolrIndexSearcher opens=88 closes=87 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=88 closes=87 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:152) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:76) Build Log (for compile errors): [...truncated 9741 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3688) Bucketing of association value of a certain category
[ https://issues.apache.org/jira/browse/LUCENE-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivan Yogev updated LUCENE-3688: Attachment: LUCENE-association-buckets.r1292224.patch New patch > Bucketing of association value of a certain category > > > Key: LUCENE-3688 > URL: https://issues.apache.org/jira/browse/LUCENE-3688 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/facet >Reporter: Sivan Yogev >Priority: Minor > Labels: bucket, facet > Attachments: LUCENE-association-buckets.patch, > LUCENE-association-buckets.r1292224.patch > > > Add facet requests which collect associations of a certain category into > buckets, and returns each bucket as a facet result node. Association type is > either int or float, and there are two methods to define buckets. The first > by providing buckets which contain pre-defined ranges. The other is by > declaring the required number of buckets, where the ranges of the different > buckets are dynamicly set to create balanced bucket sizes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 12492 - Failure
There are actually 2 failures here... TestDeletionPolicy was a bug in LuceneTestCase. TestIndexWriterNRTIsCurrent is something else, and it doesnt reproduce easily yet On Wed, Feb 22, 2012 at 4:11 AM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12492/ > > 2 tests failed. > REGRESSION: > org.apache.lucene.index.TestDeletionPolicy.testKeepLastNDeletionPolicyWithCreates > > Error Message: > null > > Stack Trace: > java.lang.NullPointerException > at > org.apache.lucene.index.FilterAtomicReader$FilterFields.terms(FilterAtomicReader.java:53) > at org.apache.lucene.util.TermContext.build(TermContext.java:94) > at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:180) > at > org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:584) > at > org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59) > at > org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:258) > at > org.apache.lucene.index.TestDeletionPolicy.testKeepLastNDeletionPolicyWithCreates(TestDeletionPolicy.java:701) > at > org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707) > at > org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) > at > org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) > at > org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) > > > REGRESSION: > org.apache.lucene.index.TestIndexWriterNRTIsCurrent.testIsCurrentWithThreads > > Error Message: > java.lang.AssertionError: Some threads threw uncaught exceptions! > > Stack Trace: > java.lang.RuntimeException: java.lang.AssertionError: Some threads threw > uncaught exceptions! > at > org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:780) > at > org.apache.lucene.util.LuceneTestCase.access$1000(LuceneTestCase.java:138) > at > org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:607) > at > org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) > at > org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) > at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) > at > org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:808) > at > org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:752) > > > > > Build Log (for compile errors): > [...truncated 1547 lines...] > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3807) Cleanup suggester API
[ https://issues.apache.org/jira/browse/LUCENE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-3807: Attachment: LUCENE-3807.patch updated patch with davids suggestions > Cleanup suggester API > - > > Key: LUCENE-3807 > URL: https://issues.apache.org/jira/browse/LUCENE-3807 > Project: Lucene - Java > Issue Type: Improvement > Components: modules/other >Affects Versions: 3.6, 4.0 >Reporter: Simon Willnauer > Fix For: 4.0 > > Attachments: LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch, > LUCENE-3807.patch > > > Currently the suggester api and especially TermFreqIterator don't play that > nice with BytesRef and other paradigms we use in lucene, further the java > iterator pattern isn't that useful when it gets to work with TermsEnum, > BytesRef etc. We should try to clean up this api step by step moving over to > BytesRef including the Lookup class and its interface... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3807) Cleanup suggester API
[
https://issues.apache.org/jira/browse/LUCENE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213519#comment-13213519
]
Simon Willnauer commented on LUCENE-3807:
-
bq. This shows up in a number of places. I have mixed feelings about certain
types having a comparator and others not having it, but it's minor.
well this an indicator if we know something about the order or not. if you get
null there is not order specified...
bq. BufferingTermFreqIteratorWrapper is a nuisance (buffers in memory). It
would be nicer to have a sort on disk if something doesn't support sorted
iteration order.
this is the ultimate goal... see my comment above ({noformat} next steps would
be cleaning up the in-memory sorting stuff and use the sorter which goes to
disk to do the actual sorting internally if needed {noformat})
bq. I also wonder float -> long = 4 -> 8 bytes... would this count as an
incompatible API change (because what used to work for a given amount of RAM
won't work anymore – BufferingTermFreqIteratorWrapper again)?
see above
bq. if I remember correctly Math.min/max are intrinsics, so you can afford to
be explicit
I will upload a new patch - we use this in BytesRefComp too, I think its safe
to fix
bq. This doesn't seem necessary (lookup accepts a CharSequence?).
right - leftover from an old iteration
bq. Why not a specific covariant here?
that would be Float get(String) or Float get(CharSequence) or... ;)
> Cleanup suggester API
> -
>
> Key: LUCENE-3807
> URL: https://issues.apache.org/jira/browse/LUCENE-3807
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/other
>Affects Versions: 3.6, 4.0
>Reporter: Simon Willnauer
> Fix For: 4.0
>
> Attachments: LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch
>
>
> Currently the suggester api and especially TermFreqIterator don't play that
> nice with BytesRef and other paradigms we use in lucene, further the java
> iterator pattern isn't that useful when it gets to work with TermsEnum,
> BytesRef etc. We should try to clean up this api step by step moving over to
> BytesRef including the Lookup class and its interface...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12493 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12493/ 1 tests failed. FAILED: org.apache.lucene.queries.function.TestOrdValues.testReverseOrdFieldRank Error Message: java.lang.AssertionError: org.apache.lucene.queries.function.TestOrdValues.testReverseOrdFieldRank: Insane FieldCache usage(s) found expected:<0> but was:<1> Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: org.apache.lucene.queries.function.TestOrdValues.testReverseOrdFieldRank: Insane FieldCache usage(s) found expected:<0> but was:<1> at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:780) at org.apache.lucene.util.LuceneTestCase.access$1000(LuceneTestCase.java:138) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:607) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.LuceneTestCase.assertSaneFieldCaches(LuceneTestCase.java:907) at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:770) Build Log (for compile errors): [...truncated 5037 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-trunk - Build # 1836 - Still Failing
I committed a fix - test bug... simon On Wed, Feb 22, 2012 at 5:57 AM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > Build: https://builds.apache.org/job/Lucene-trunk/1836/ > > 1 tests failed. > FAILED: > org.apache.lucene.search.suggest.fst.FSTCompletionTest.testMultilingualInput > > Error Message: > expected:<[74 68 72 65 65 62 79 74 65 f0 a4 ad a2 63 68 61 72]> but > was: > > Stack Trace: > junit.framework.AssertionFailedError: expected:<[74 68 72 65 65 62 79 74 > 65 f0 a4 ad a2 63 68 61 72]> but was: >at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) >at > org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) >at > org.apache.lucene.search.suggest.fst.FSTCompletionTest.testMultilingualInput(FSTCompletionTest.java:187) >at > org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707) >at > org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) >at > org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) >at > org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) > > > > > Build Log (for compile errors): > [...truncated 16827 lines...] > > > > > - > 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-java7 - Build # 1787 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1787/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.RecoveryZkTest Error Message: ERROR: SolrIndexSearcher opens=15 closes=14 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=15 closes=14 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:152) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:76) Build Log (for compile errors): [...truncated 10428 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3151) Replace zookeeper.jsp with a servlet
[ https://issues.apache.org/jira/browse/SOLR-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3151: Attachment: SOLR-3151-invalid-json-for-solrconfig.json Generated w/ SVN Revision 1245905, is not valid. I don't not all reasons why it's correct but one will be that it contains raw linebreaks, which doesn't fit the specs. more on http://jsonlint.com/ > Replace zookeeper.jsp with a servlet > > > Key: SOLR-3151 > URL: https://issues.apache.org/jira/browse/SOLR-3151 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-3151-invalid-json-for-solrconfig.json, > SOLR-3151-zookeeper-servlet.patch > > > The zookeeper info is currently generated with a jsp file -- making it harder > to maintain then it should be, and harder to include in other applications -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3151) Replace zookeeper.jsp with a servlet
[ https://issues.apache.org/jira/browse/SOLR-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213495#comment-13213495 ] Stefan Matheis (steffkes) commented on SOLR-3151: - Just a quick note. Depending on which file you select, the current zookeeper.jsp renders invalid json. That will of course not work for the Javascript-Part, we can of course display a message in that case, but i guess it should be possible to ensure that we return valid json? > Replace zookeeper.jsp with a servlet > > > Key: SOLR-3151 > URL: https://issues.apache.org/jira/browse/SOLR-3151 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-3151-zookeeper-servlet.patch > > > The zookeeper info is currently generated with a jsp file -- making it harder > to maintain then it should be, and harder to include in other applications -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3116) new Admin UI does not allow drill-down into ZooKeeper
[ https://issues.apache.org/jira/browse/SOLR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3116: Attachment: SOLR-3116-file-content.png Erick, that's correct .. what about that one? Usable? The current zookeeper.jsp responds sometimes w/ a invalid json-structure, that breaks the javascript .. will have a look on SOLR-3151 to ensure that this does not happen there. > new Admin UI does not allow drill-down into ZooKeeper > - > > Key: SOLR-3116 > URL: https://issues.apache.org/jira/browse/SOLR-3116 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 > Environment: All >Reporter: Erick Erickson >Priority: Minor > Attachments: SOLR-3116-file-content.png > > > One thing missing from the old UI for the ZooKeeper view - you can no longer > see the data at each node (or at least I have not figured out how) - just the > node listing. (Mark Miller, broken out from SOLR-2667) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-trunk - Build # 1770 - Failure
Build: https://builds.apache.org/job/Solr-trunk/1770/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.RecoveryZkTest Error Message: ERROR: SolrIndexSearcher opens=15 closes=14 Stack Trace: junit.framework.AssertionFailedError: ERROR: SolrIndexSearcher opens=15 closes=14 at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:152) at org.apache.solr.SolrTestCaseJ4.afterClassSolrTestCase(SolrTestCaseJ4.java:76) Build Log (for compile errors): [...truncated 10151 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (LUCENE-3807) Cleanup suggester API
[
https://issues.apache.org/jira/browse/LUCENE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213477#comment-13213477
]
Dawid Weiss edited comment on LUCENE-3807 at 2/22/12 9:16 AM:
--
Sorry for being late, work. I like the patch. Comments:
{noformat}
+public Comparator getComparator() {
+ return null;
+}
{noformat}
This shows up in a number of places. I have mixed feelings about certain types
having a comparator and others not having it, but it's minor.
BufferingTermFreqIteratorWrapper is a nuisance (buffers in memory). It would be
nicer to have a sort on disk if something doesn't support sorted iteration
order.
I also wonder float -> long = 4 -> 8 bytes... would this count as an
incompatible API change (because what used to work for a given amount of RAM
won't work anymore -- BufferingTermFreqIteratorWrapper again)?
{noformat}
+ if (l1 < l2) {
+aStop = l1;
+ } else {
+aStop = l2;
+ }
{noformat}
if I remember correctly Math.min/max are intrinsics, so you can afford to be
explicit ;)
Why not a specific covariant here?
{noformat}
- public Float get(String key) {
+ public Object get(CharSequence key) {
{noformat}
This doesn't seem necessary (lookup accepts a CharSequence?).
{noformat}
@@ -199,7 +199,7 @@ public class LookupBenchmarkTest extends LuceneTestCase {
public Integer call() throws Exception {
int v = 0;
for (String term : input) {
-v += lookup.lookup(term, onlyMorePopular, num).size();
+v += lookup.lookup(new CharsRef(term), onlyMorePopular,
num).size();
{noformat}
I like the rest, including the CharSequenceish evilness of bytesToCharSequence
:)
was (Author: dweiss):
Sorry for being late, work. I like the patch. Comments:
+public Comparator getComparator() {
+ return null;
+}
This shows up in a number of places. I have mixed feelings about certain types
having a comparator and others not having it, but it's minor.
BufferingTermFreqIteratorWrapper is a nuisance (buffers in memory). It would be
nicer to have a sort on disk if something doesn't support sorted iteration
order.
I also wonder float -> long = 4 -> 8 bytes... would this count as an
incompatible API change (because what used to work for a given amount of RAM
won't work anymore -- BufferingTermFreqIteratorWrapper again)?
+ if (l1 < l2) {
+aStop = l1;
+ } else {
+aStop = l2;
+ }
if I remember correctly Math.min/max are intrinsics, so you can afford to be
explicit ;)
Why not a specific covariant here?
- public Float get(String key) {
+ public Object get(CharSequence key) {
@@ -199,7 +199,7 @@ public class LookupBenchmarkTest extends LuceneTestCase {
public Integer call() throws Exception {
int v = 0;
for (String term : input) {
-v += lookup.lookup(term, onlyMorePopular, num).size();
+v += lookup.lookup(new CharsRef(term), onlyMorePopular,
num).size();
This doesn't seem necessary (lookup accepts a CharSequence?).
I like the rest, including the CharSequenceish evilness of bytesToCharSequence
:)
> Cleanup suggester API
> -
>
> Key: LUCENE-3807
> URL: https://issues.apache.org/jira/browse/LUCENE-3807
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/other
>Affects Versions: 3.6, 4.0
>Reporter: Simon Willnauer
> Fix For: 4.0
>
> Attachments: LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch
>
>
> Currently the suggester api and especially TermFreqIterator don't play that
> nice with BytesRef and other paradigms we use in lucene, further the java
> iterator pattern isn't that useful when it gets to work with TermsEnum,
> BytesRef etc. We should try to clean up this api step by step moving over to
> BytesRef including the Lookup class and its interface...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3807) Cleanup suggester API
[
https://issues.apache.org/jira/browse/LUCENE-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213477#comment-13213477
]
Dawid Weiss commented on LUCENE-3807:
-
Sorry for being late, work. I like the patch. Comments:
+public Comparator getComparator() {
+ return null;
+}
This shows up in a number of places. I have mixed feelings about certain types
having a comparator and others not having it, but it's minor.
BufferingTermFreqIteratorWrapper is a nuisance (buffers in memory). It would be
nicer to have a sort on disk if something doesn't support sorted iteration
order.
I also wonder float -> long = 4 -> 8 bytes... would this count as an
incompatible API change (because what used to work for a given amount of RAM
won't work anymore -- BufferingTermFreqIteratorWrapper again)?
+ if (l1 < l2) {
+aStop = l1;
+ } else {
+aStop = l2;
+ }
if I remember correctly Math.min/max are intrinsics, so you can afford to be
explicit ;)
Why not a specific covariant here?
- public Float get(String key) {
+ public Object get(CharSequence key) {
@@ -199,7 +199,7 @@ public class LookupBenchmarkTest extends LuceneTestCase {
public Integer call() throws Exception {
int v = 0;
for (String term : input) {
-v += lookup.lookup(term, onlyMorePopular, num).size();
+v += lookup.lookup(new CharsRef(term), onlyMorePopular,
num).size();
This doesn't seem necessary (lookup accepts a CharSequence?).
I like the rest, including the CharSequenceish evilness of bytesToCharSequence
:)
> Cleanup suggester API
> -
>
> Key: LUCENE-3807
> URL: https://issues.apache.org/jira/browse/LUCENE-3807
> Project: Lucene - Java
> Issue Type: Improvement
> Components: modules/other
>Affects Versions: 3.6, 4.0
>Reporter: Simon Willnauer
> Fix For: 4.0
>
> Attachments: LUCENE-3807.patch, LUCENE-3807.patch, LUCENE-3807.patch
>
>
> Currently the suggester api and especially TermFreqIterator don't play that
> nice with BytesRef and other paradigms we use in lucene, further the java
> iterator pattern isn't that useful when it gets to work with TermsEnum,
> BytesRef etc. We should try to clean up this api step by step moving over to
> BytesRef including the Lookup class and its interface...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12492 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12492/ 2 tests failed. REGRESSION: org.apache.lucene.index.TestDeletionPolicy.testKeepLastNDeletionPolicyWithCreates Error Message: null Stack Trace: java.lang.NullPointerException at org.apache.lucene.index.FilterAtomicReader$FilterFields.terms(FilterAtomicReader.java:53) at org.apache.lucene.util.TermContext.build(TermContext.java:94) at org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:180) at org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:584) at org.apache.lucene.search.AssertingIndexSearcher.createNormalizedWeight(AssertingIndexSearcher.java:59) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:258) at org.apache.lucene.index.TestDeletionPolicy.testKeepLastNDeletionPolicyWithCreates(TestDeletionPolicy.java:701) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:707) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) REGRESSION: org.apache.lucene.index.TestIndexWriterNRTIsCurrent.testIsCurrentWithThreads Error Message: java.lang.AssertionError: Some threads threw uncaught exceptions! Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:780) at org.apache.lucene.util.LuceneTestCase.access$1000(LuceneTestCase.java:138) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:607) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:569) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:808) at org.apache.lucene.util.LuceneTestCase.tearDownInternal(LuceneTestCase.java:752) Build Log (for compile errors): [...truncated 1547 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
[ https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213445#comment-13213445 ] Chris Male commented on LUCENE-3795: bq. LSP Lucene spatial is in as a module, actually as two modules, spatial/base & spatial/strategy. That complicates the build but Chris & Ryan insist. The maven build works. I don't recall insisting that here. I think we should do what's best in this situation. If having two sub modules is causing too much difficulty for no benefit, then +1 to reducing them to one. > Replace spatial contrib module with LSP's spatial-lucene module > --- > > Key: LUCENE-3795 > URL: https://issues.apache.org/jira/browse/LUCENE-3795 > Project: Lucene - Java > Issue Type: New Feature > Components: modules/spatial >Reporter: David Smiley >Assignee: David Smiley > Fix For: 4.0 > > > I propose that Lucene's spatial contrib module be replaced with the > spatial-lucene module within Lucene Spatial Playground (LSP). LSP has been > in development for approximately 1 year by David Smiley, Ryan McKinley, and > Chris Male and we feel it is ready. LSP is here: > http://code.google.com/p/lucene-spatial-playground/ and the spatial-lucene > module is intuitively in svn/trunk/spatial-lucene/. > I'll add more comments to prevent the issue description from being too long. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
