[jira] [Commented] (LUCENE-3583) benchmark tests always fail on windows because directory cannot be removed
[ https://issues.apache.org/jira/browse/LUCENE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154937#comment-13154937 ] Shai Erera commented on LUCENE-3583: You're right, I didn't notice it. I'll work on it now. > benchmark tests always fail on windows because directory cannot be removed > -- > > Key: LUCENE-3583 > URL: https://issues.apache.org/jira/browse/LUCENE-3583 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.5, 4.0 > Environment: Only fails for Lucene trunk >Reporter: Uwe Schindler >Assignee: Shai Erera > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3583.patch, LUCENE-3583.patch, > benchmark-test-output.txt, io-event-log.txt > > > This seems to be a bug recently introduced. I have no idea what's wrong. > Attached is a log file, reproduces everytime. -- 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-3583) benchmark tests always fail on windows because directory cannot be removed
[ https://issues.apache.org/jira/browse/LUCENE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154947#comment-13154947 ] Shai Erera commented on LUCENE-3583: Committed Robert's changes to trunk rev 1204851. However after porting to 3x and running the tests, LineDocSourceTest consistently fails with this: ant test -Dtestcase=LineDocSourceTest -Dtests.seed=-2895bf521e2206c:0:4f1f278a279ce441 I'm investigating (don't know if it fails on trunk too yet). > benchmark tests always fail on windows because directory cannot be removed > -- > > Key: LUCENE-3583 > URL: https://issues.apache.org/jira/browse/LUCENE-3583 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.5, 4.0 > Environment: Only fails for Lucene trunk >Reporter: Uwe Schindler >Assignee: Shai Erera > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3583.patch, LUCENE-3583.patch, > benchmark-test-output.txt, io-event-log.txt > > > This seems to be a bug recently introduced. I have no idea what's wrong. > Attached is a log file, reproduces everytime. -- 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-3583) benchmark tests always fail on windows because directory cannot be removed
[ https://issues.apache.org/jira/browse/LUCENE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154950#comment-13154950 ] Shai Erera commented on LUCENE-3583: Ok found it: testInvalidFormat expected exceptions to be thrown while the algorithm runs, and so tasks.close() wasn't called. I'll change the code to close in a try-finally, for all Closeable resources. > benchmark tests always fail on windows because directory cannot be removed > -- > > Key: LUCENE-3583 > URL: https://issues.apache.org/jira/browse/LUCENE-3583 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.5, 4.0 > Environment: Only fails for Lucene trunk >Reporter: Uwe Schindler >Assignee: Shai Erera > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3583.patch, LUCENE-3583.patch, > benchmark-test-output.txt, io-event-log.txt > > > This seems to be a bug recently introduced. I have no idea what's wrong. > Attached is a log file, reproduces everytime. -- 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-3583) benchmark tests always fail on windows because directory cannot be removed
[ https://issues.apache.org/jira/browse/LUCENE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154959#comment-13154959 ] Shai Erera commented on LUCENE-3583: Committed test fixes to 3x and trunk. > benchmark tests always fail on windows because directory cannot be removed > -- > > Key: LUCENE-3583 > URL: https://issues.apache.org/jira/browse/LUCENE-3583 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.5, 4.0 > Environment: Only fails for Lucene trunk >Reporter: Uwe Schindler >Assignee: Shai Erera > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3583.patch, LUCENE-3583.patch, > benchmark-test-output.txt, io-event-log.txt > > > This seems to be a bug recently introduced. I have no idea what's wrong. > Attached is a log file, reproduces everytime. -- 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
[Lucene.Net] [jira] [Updated] (LUCENENET-457) Lucene locks directory with index after network related problems
[ https://issues.apache.org/jira/browse/LUCENENET-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Belousov updated LUCENENET-457: - Description: I have a directory for my index in shared folder on another computer in the network. My service writes data to the index. Sometimes the service gets network related exceptions like "The specified network name is no longer available.". After that the service cannot write anything to index because of lock, even if I delete "write.lock" file manually. Of course, I could restart the service, but I'd like to avoid it. I have done a research and have found that Lucene API has IndexWriter.Unlock() method, but in my case is does not work. I use NativeFSLockFactory class. Class NativeFSLock has private field LOCK_HELD with the list of current locks, but in my case (after network related issues) it has record with the lock (NativeFSLock uses it in Obtain() method) and I can't delete it through API. I suppose that method NativeFSLock.Release()(which is called from IndexWriter.Unlock()) should delete record from the field LOCK_HELD. May be I'm wrong and there is an appoarch to handle such problems? At the moment I have implemented the method which deletes the record from LOCK_HELD through reflection. Thanks a lot. was: I have a directory for my index in shared folder on another computer in the network. My service writes data to the index. Sometimes the service gets network related exceptions like "The specified network name is no longer available.". After that the service cannot write anything to index because of lock, even if I delete "write.lock" file manually. I have done a research and have found that Lucene API has IndexWriter.Unlock() method, but in my case is does not work. I use NativeFSLockFactory class. Class NativeFSLock has private field LOCK_HELD with the list of current locks, but in my case (after network related issues) it has record with the lock (NativeFSLock uses it in Obtain() method) and I can't delete it through API. I suppose that method NativeFSLock.Release()(which is called from IndexWriter.Unlock()) should delete record from the field LOCK_HELD. May be I'm wrong and there is an appoarch to handle such problems? At the moment I have implemented the method which deletes the record from LOCK_HELD through reflection. Thanks a lot. > Lucene locks directory with index after network related problems > > > Key: LUCENENET-457 > URL: https://issues.apache.org/jira/browse/LUCENENET-457 > Project: Lucene.Net > Issue Type: Bug > Components: Lucene.Net Core > Environment: Windows Server 2008 >Reporter: Pavel Belousov > > I have a directory for my index in shared folder on another computer in the > network. My service writes data to the index. Sometimes the service gets > network related exceptions like "The specified network name is no longer > available.". After that the service cannot write anything to index because of > lock, even if I delete "write.lock" file manually. Of course, I could restart > the service, but I'd like to avoid it. > I have done a research and have found that Lucene API has > IndexWriter.Unlock() method, but in my case is does not work. > I use NativeFSLockFactory class. Class NativeFSLock has private field > LOCK_HELD with the list of current locks, but in my case (after network > related issues) it has record with the lock (NativeFSLock uses it in Obtain() > method) and I can't delete it through API. I suppose that method > NativeFSLock.Release()(which is called from IndexWriter.Unlock()) should > delete record from the field LOCK_HELD. > May be I'm wrong and there is an appoarch to handle such problems? > At the moment I have implemented the method which deletes the record from > LOCK_HELD through reflection. > Thanks a lot. -- 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
[JENKINS] Solr-trunk - Build # 1682 - Failure
Build: https://builds.apache.org/job/Solr-trunk/1682/ No tests ran. Build Log (for compile errors): [...truncated 29826 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2699) Add SolrInputDocument support to javabin format
[ https://issues.apache.org/jira/browse/SOLR-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-2699. - Resolution: Fixed Fix Version/s: 4.0 Assignee: Yonik Seeley The back compat fix was committed with SOLR-2904. > Add SolrInputDocument support to javabin format > --- > > Key: SOLR-2699 > URL: https://issues.apache.org/jira/browse/SOLR-2699 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2699-backcompat-fix.patch, SOLR-2699.patch, > SOLR-2699.patch > > > Supporting SolrInputDocument (like SolrDocument is already supported) > directly in javabin will make both transaction logging and recovering updates > from peers much easier. -- 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-2755) StreamingUpdateSolrServer is hard-coded to write XML data. It should integrate the RequestWriter API so that it can be used to send binary update payloads.
[ https://issues.apache.org/jira/browse/SOLR-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155017#comment-13155017 ] Shalin Shekhar Mangar commented on SOLR-2755: - Patrick, I'm not sure that the amount of changes in this patch are necessary. Do you think that the patch I attached to SOLR-1565 will serve your purpose? > StreamingUpdateSolrServer is hard-coded to write XML data. It should > integrate the RequestWriter API so that it can be used to send binary update > payloads. > --- > > Key: SOLR-2755 > URL: https://issues.apache.org/jira/browse/SOLR-2755 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 3.3 >Reporter: Patrick Sauts > Labels: patch > Fix For: 3.5, 4.0 > > Attachments: patch-StreamingUpdateSolrServer.txt > > > The aim of this patch is to use the RequestWriter API with > StreamingUpdateSolrServer. -- 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-2607) Clean up /clients directory
[ https://issues.apache.org/jira/browse/SOLR-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155035#comment-13155035 ] Jan Høydahl commented on SOLR-2607: --- +1 I saw this earlier but just thought about it again when reviewing the 3.5.0 RC. I'd say get rid of /client altogether > Clean up /clients 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 >Priority: Minor > > 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-2904) BinaryUpdateRequestHandler should be able to accept multiple update requests from a stream
[ https://issues.apache.org/jira/browse/SOLR-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-2904: Attachment: SOLR-2904-branch_3x.patch Patch for branch_3x. > BinaryUpdateRequestHandler should be able to accept multiple update requests > from a stream > -- > > Key: SOLR-2904 > URL: https://issues.apache.org/jira/browse/SOLR-2904 > Project: Solr > Issue Type: Improvement >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 3.5, 4.0 > > Attachments: SOLR-2904-branch_3x.patch, SOLR-2904.patch > > > BinaryUpdateRequestHandler should accept multiple update requests from a > single HTTP request's input stream. Currently it does not and that makes it > very difficult for StreamingUpdateSolrServer to use Javabin format. -- 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-1565) StreamingUpdateSolrServer should support RequestWriter API
[ https://issues.apache.org/jira/browse/SOLR-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1565: Attachment: SOLR-1565-branch_3x.patch Patch for branch_3x. > StreamingUpdateSolrServer should support RequestWriter API > -- > > Key: SOLR-1565 > URL: https://issues.apache.org/jira/browse/SOLR-1565 > Project: Solr > Issue Type: Improvement > Components: clients - java, update >Affects Versions: 1.4 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 3.6, 4.0 > > Attachments: SOLR-1565-branch_3x.patch, SOLR-1565.patch > > > StreamingUpdateSolrServer is hard-coded to write XML data. It should > integrate the RequestWriter API so that it can be used to send binary update > payloads. -- 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-1565) StreamingUpdateSolrServer should support RequestWriter API
[ https://issues.apache.org/jira/browse/SOLR-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1565: Fix Version/s: (was: 3.5) 3.6 > StreamingUpdateSolrServer should support RequestWriter API > -- > > Key: SOLR-1565 > URL: https://issues.apache.org/jira/browse/SOLR-1565 > Project: Solr > Issue Type: Improvement > Components: clients - java, update >Affects Versions: 1.4 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 3.6, 4.0 > > Attachments: SOLR-1565-branch_3x.patch, SOLR-1565.patch > > > StreamingUpdateSolrServer is hard-coded to write XML data. It should > integrate the RequestWriter API so that it can be used to send binary update > payloads. -- 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-2904) BinaryUpdateRequestHandler should be able to accept multiple update requests from a stream
[ https://issues.apache.org/jira/browse/SOLR-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-2904: Fix Version/s: (was: 3.5) 3.6 > BinaryUpdateRequestHandler should be able to accept multiple update requests > from a stream > -- > > Key: SOLR-2904 > URL: https://issues.apache.org/jira/browse/SOLR-2904 > Project: Solr > Issue Type: Improvement >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 3.6, 4.0 > > Attachments: SOLR-2904-branch_3x.patch, SOLR-2904.patch > > > BinaryUpdateRequestHandler should accept multiple update requests from a > single HTTP request's input stream. Currently it does not and that makes it > very difficult for StreamingUpdateSolrServer to use Javabin format. -- 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-3464) Rename IndexReader.reopen to make it clear that reopen may not happen
[
https://issues.apache.org/jira/browse/LUCENE-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155094#comment-13155094
]
Uwe Schindler commented on LUCENE-3464:
---
I will add a comment to the javadocs with a simple statement:
{noformat}
* Note: The default implementation of {@link
FilterIndexReader#doOpenIfChanged}
* throws {@link UnsupportedOperationException} (like the base class),
* so it's not possible to reopen a FilterIndexReader.
* To reopen, you have to first reopen the underlying reader
* and wrap it again with the custom filter.
{noformat}
In this case the responsibility is moved over to the consumer. Its the same
like with SlowMultiReaderWrapper: It does not support reopen, to support this,
reopen the underlying reader and make it slow again :-)
> Rename IndexReader.reopen to make it clear that reopen may not happen
> -
>
> Key: LUCENE-3464
> URL: https://issues.apache.org/jira/browse/LUCENE-3464
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 3.5, 4.0
>
> Attachments: LUCENE-3464.3x.patch, LUCENE-3464.patch,
> LUCENE-3464.patch, LUCENE-3464_see_its_just_fine.patch
>
>
> Spinoff from LUCENE-3454 where Shai noted this inconsistency.
> IR.reopen sounds like an unconditional operation, which has trapped users in
> the past into always closing the old reader instead of only closing it if the
> returned reader is new.
> I think this hidden maybe-ness is trappy and we should rename it
> (maybeReopen? reopenIfNeeded?).
> In addition, instead of returning "this" when the reopen didn't happen, I
> think we should return null to enforce proper usage of the maybe-ness of this
> API.
--
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-3464) Rename IndexReader.reopen to make it clear that reopen may not happen
[ https://issues.apache.org/jira/browse/LUCENE-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-3464. --- Resolution: Fixed Committed 3.x revision: 1204970 Merged to trunk revision: 1204971 > Rename IndexReader.reopen to make it clear that reopen may not happen > - > > Key: LUCENE-3464 > URL: https://issues.apache.org/jira/browse/LUCENE-3464 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3464.3x.patch, LUCENE-3464.patch, > LUCENE-3464.patch, LUCENE-3464_see_its_just_fine.patch > > > Spinoff from LUCENE-3454 where Shai noted this inconsistency. > IR.reopen sounds like an unconditional operation, which has trapped users in > the past into always closing the old reader instead of only closing it if the > returned reader is new. > I think this hidden maybe-ness is trappy and we should rename it > (maybeReopen? reopenIfNeeded?). > In addition, instead of returning "this" when the reopen didn't happen, I > think we should return null to enforce proper usage of the maybe-ness of this > API. -- 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: [VOTE] Release Lucene/Solr 3.5.0, RC1
I merged the changed from LUCENE-3583 and uwe's javadoc improvements into the release branch and kicked off a RC2 I will let you know once it is up. simon On Tue, Nov 22, 2011 at 7:42 AM, Shai Erera wrote: > I fixed LUCENE-3583. It was a test issue, so I'm not sure if it's worth a > respin. But if you do, then we should mark the issue as Fix Version: 3.5 > (not 3.6) and merge the changes to the 3.5 branch. > > Shai > > On Mon, Nov 21, 2011 at 10:12 PM, Uwe Schindler wrote: >> >> Hi, >> >> the Lucene-Core package works for PANGAEA as drop-in replacement, so this >> is all fine. >> >> I found a problem (an inconsistency in the new openIfChanged API) when >> porting the code to not use deprecated stuff: >> https://issues.apache.org/jira/browse/LUCENE-3464 (reopened). The deprecated >> stuff successfully used the sophisticated backwards, cool, Mike! >> >> Another problem with the release candidate: When running contrib tests on >> windows, since the benchmark classes don’t correctly close all >> files/reader/whatever after Robert's commit 1203997 the benchmark tests fail >> on every run on windows. I don't like this for an official release, sorry. >> The test should pass (somehow most of the time - lol@solr), but consistently >> failing is bad (see https://issues.apache.org/jira/browse/LUCENE-3583). >> >> I checked CheckIndex on pre-3.5 indexes, all worked fine for the hug >> PANGAEA index, no hotspot bugs (1.6.0_24), will later try 1.6.0_29. >> Optimizing/Upgrading indexes worked, too. As said before, backwards >> compatibility is fine, no recompilation was needed here. >> >> I will try to run smoke tests later, but I don't like the above 2 issues, >> so my +/-0 (as there is a workaround for the first issue) :( >> >> Uwe >> >> - >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> >> > -Original Message- >> > From: Simon Willnauer [mailto:simon.willna...@googlemail.com] >> > Sent: Monday, November 21, 2011 1:47 PM >> > To: dev@lucene.apache.org >> > Subject: [VOTE] Release Lucene/Solr 3.5.0, RC1 >> > >> > Please vote to release the RC1 artifacts at: >> > >> > https://people.apache.org/~simonw/staging_area/lucene-solr-3.5.0-RC1- >> > rev1204425/ >> > >> > as Lucene 3.5.0 and Solr 3.5.0. >> > >> > Simon Willnauer >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional >> > commands, e-mail: dev-h...@lucene.apache.org >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3583) benchmark tests always fail on windows because directory cannot be removed
[ https://issues.apache.org/jira/browse/LUCENE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155136#comment-13155136 ] Robert Muir commented on LUCENE-3583: - Shai: thanks for getting to the bottom of this! > benchmark tests always fail on windows because directory cannot be removed > -- > > Key: LUCENE-3583 > URL: https://issues.apache.org/jira/browse/LUCENE-3583 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.5, 4.0 > Environment: Only fails for Lucene trunk >Reporter: Uwe Schindler >Assignee: Shai Erera > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3583.patch, LUCENE-3583.patch, > benchmark-test-output.txt, io-event-log.txt > > > This seems to be a bug recently introduced. I have no idea what's wrong. > Attached is a log file, reproduces everytime. -- 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-3583) benchmark tests always fail on windows because directory cannot be removed
[ https://issues.apache.org/jira/browse/LUCENE-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-3583: Fix Version/s: (was: 3.6) 3.5 > benchmark tests always fail on windows because directory cannot be removed > -- > > Key: LUCENE-3583 > URL: https://issues.apache.org/jira/browse/LUCENE-3583 > Project: Lucene - Java > Issue Type: Bug >Affects Versions: 3.5, 4.0 > Environment: Only fails for Lucene trunk >Reporter: Uwe Schindler >Assignee: Shai Erera > Fix For: 3.5, 4.0 > > Attachments: LUCENE-3583.patch, LUCENE-3583.patch, > benchmark-test-output.txt, io-event-log.txt > > > This seems to be a bug recently introduced. I have no idea what's wrong. > Attached is a log file, reproduces everytime. -- 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-java7 - Build # 1025 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1025/ 1 tests failed. REGRESSION: org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest.testMultiThreaded Error Message: java.lang.AssertionError: Some threads threw uncaught exceptions! Stack Trace: java.lang.RuntimeException: java.lang.AssertionError: Some threads threw uncaught exceptions! at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:650) at org.apache.solr.SolrTestCaseJ4.tearDown(SolrTestCaseJ4.java:86) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:149) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:51) at org.apache.lucene.util.LuceneTestCase.checkUncaughtExceptionsAfter(LuceneTestCase.java:678) at org.apache.lucene.util.LuceneTestCase.tearDown(LuceneTestCase.java:622) Build Log (for compile errors): [...truncated 11899 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3586) Choose a specific Directory implementation running the CheckIndex main
Choose a specific Directory implementation running the CheckIndex main -- Key: LUCENE-3586 URL: https://issues.apache.org/jira/browse/LUCENE-3586 Project: Lucene - Java Issue Type: Improvement Reporter: Luca Cavanna Priority: Minor It should be possible to choose a specific Directory implementation to use during the CheckIndex process when we run it from its main. What about an additional main parameter? In fact, I'm experiencing some problems with MMapDirectory working with a big segment, and after some failed attempts playing with maxChunkSize, I decided to switch to another FSDirectory implementation but I needed to do that on my own main. Should we also consider to use a FileSwitchDirectory? I'm willing to contribute, could you please let me know your thoughts about it? -- 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-566) Incorporate Lucene's CheckIndex tool into Solr
[ https://issues.apache.org/jira/browse/SOLR-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155174#comment-13155174 ] Luca Cavanna commented on SOLR-566: --- I would be willing to work on this. I agree that running it on startup isn't so handy, but it would be useful to have this feature available in my opinion. I see this as a request handler. Furthermore, actually we have a backup command available on the replication handler, I guess it would be useful to add an option to check the backup at the end of the process. Any thoughts? > Incorporate Lucene's CheckIndex tool into Solr > -- > > Key: SOLR-566 > URL: https://issues.apache.org/jira/browse/SOLR-566 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > > Not sure how to just yet, but I think it would be good to somehow incorporate > Lucene's CheckIndex tool into Solr. I imagine it can be done nicely through > the admin, but I suspect it makes sense to also do it on startup or even as a > request handler. -- 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-2607) Clean up /clients directory
[ https://issues.apache.org/jira/browse/SOLR-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned SOLR-2607: -- Assignee: Erik Hatcher > Clean up /clients 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 > > 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] [Commented] (SOLR-566) Incorporate Lucene's CheckIndex tool into Solr
[ https://issues.apache.org/jira/browse/SOLR-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155185#comment-13155185 ] Simon Willnauer commented on SOLR-566: -- bq. I agree that running it on startup isn't so handy, but it would be useful to have this feature available in my opinion. I see this as a request handler. +1 > Incorporate Lucene's CheckIndex tool into Solr > -- > > Key: SOLR-566 > URL: https://issues.apache.org/jira/browse/SOLR-566 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > > Not sure how to just yet, but I think it would be good to somehow incorporate > Lucene's CheckIndex tool into Solr. I imagine it can be done nicely through > the admin, but I suspect it makes sense to also do it on startup or even as a > request handler. -- 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-3586) Choose a specific Directory implementation running the CheckIndex main
[ https://issues.apache.org/jira/browse/LUCENE-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155184#comment-13155184 ] Simon Willnauer commented on LUCENE-3586: - I think this makes sense though. sometimes like in your usecase MMap just fails with OOM and since we create the directory instance based on constants like 64bit platform, OS etc. we could make this optional. another option would be to simply use NIOFSDirectory no matter where we are. I don't think it is necessary to use FileSwitchDirectory for CheckIndex. Maybe you can add a commandline option and get a specific Dir impl if specified? NIO, MMAP & SimpleFS should be enough and use FSDirectory.open by default. > Choose a specific Directory implementation running the CheckIndex main > -- > > Key: LUCENE-3586 > URL: https://issues.apache.org/jira/browse/LUCENE-3586 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Luca Cavanna >Priority: Minor > > It should be possible to choose a specific Directory implementation to use > during the CheckIndex process when we run it from its main. > What about an additional main parameter? > In fact, I'm experiencing some problems with MMapDirectory working with a big > segment, and after some failed attempts playing with maxChunkSize, I decided > to switch to another FSDirectory implementation but I needed to do that on my > own main. > Should we also consider to use a FileSwitchDirectory? > I'm willing to contribute, could you please let me know your thoughts about > it? -- 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-2607) Clean up /clients directory
[ https://issues.apache.org/jira/browse/SOLR-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155188#comment-13155188 ] Erik Hatcher commented on SOLR-2607: I'll take this one... since I'm the culprit littering /clients now. I'm going to move solr-ruby and flare over to my github account. solr-ruby will be entirely deprecated in favor of RSolr, and I'll be moving the remaining goodies from solr-ruby (Mapper and Indexer, both very handy features not found elsewhere) into RSolr. I'll aim to tackle this before years-end over holiday breaks. > Clean up /clients 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 > > 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] [Commented] (LUCENE-3586) Choose a specific Directory implementation running the CheckIndex main
[ https://issues.apache.org/jira/browse/LUCENE-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155187#comment-13155187 ] Simon Willnauer commented on LUCENE-3586: - Luca, I made you a contributor for Lucene & Solr (JIRA Role) so you can assign issues to you. > Choose a specific Directory implementation running the CheckIndex main > -- > > Key: LUCENE-3586 > URL: https://issues.apache.org/jira/browse/LUCENE-3586 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Luca Cavanna >Priority: Minor > > It should be possible to choose a specific Directory implementation to use > during the CheckIndex process when we run it from its main. > What about an additional main parameter? > In fact, I'm experiencing some problems with MMapDirectory working with a big > segment, and after some failed attempts playing with maxChunkSize, I decided > to switch to another FSDirectory implementation but I needed to do that on my > own main. > Should we also consider to use a FileSwitchDirectory? > I'm willing to contribute, could you please let me know your thoughts about > it? -- 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-2910) PingRequest fails if there is no defaultSearchField in the schema.xml
[ https://issues.apache.org/jira/browse/SOLR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Kats resolved SOLR-2910. - Resolution: Not A Problem Indeed, thanks for the pointer! I was able to make ping work using: search *:* none 0 > PingRequest fails if there is no defaultSearchField in the schema.xml > - > > Key: SOLR-2910 > URL: https://issues.apache.org/jira/browse/SOLR-2910 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Yury Kats > > PingRequest fails if there is no defaultSearchField in the schema.xml > CommonsHttpSolrServer#ping produces: > org.apache.solr.common.SolrException: Ping query caused exception: no field > name specified in query and no defaultSearchField defined in schema.xml > at > org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:77) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1407) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353) > ... > request: http://127.0.0.1:8983/solr/a1/admin/ping?wt=javabin&version=2' -- 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-2910) PingRequest fails if there is no defaultSearchField in the schema.xml
[ https://issues.apache.org/jira/browse/SOLR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Kats closed SOLR-2910. --- > PingRequest fails if there is no defaultSearchField in the schema.xml > - > > Key: SOLR-2910 > URL: https://issues.apache.org/jira/browse/SOLR-2910 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Yury Kats > > PingRequest fails if there is no defaultSearchField in the schema.xml > CommonsHttpSolrServer#ping produces: > org.apache.solr.common.SolrException: Ping query caused exception: no field > name specified in query and no defaultSearchField defined in schema.xml > at > org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:77) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1407) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353) > ... > request: http://127.0.0.1:8983/solr/a1/admin/ping?wt=javabin&version=2' -- 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-3586) Choose a specific Directory implementation running the CheckIndex main
[ https://issues.apache.org/jira/browse/LUCENE-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Cavanna reassigned LUCENE-3586: Assignee: Luca Cavanna > Choose a specific Directory implementation running the CheckIndex main > -- > > Key: LUCENE-3586 > URL: https://issues.apache.org/jira/browse/LUCENE-3586 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Luca Cavanna >Assignee: Luca Cavanna >Priority: Minor > > It should be possible to choose a specific Directory implementation to use > during the CheckIndex process when we run it from its main. > What about an additional main parameter? > In fact, I'm experiencing some problems with MMapDirectory working with a big > segment, and after some failed attempts playing with maxChunkSize, I decided > to switch to another FSDirectory implementation but I needed to do that on my > own main. > Should we also consider to use a FileSwitchDirectory? > I'm willing to contribute, could you please let me know your thoughts about > it? -- 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-3586) Choose a specific Directory implementation running the CheckIndex main
[ https://issues.apache.org/jira/browse/LUCENE-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155195#comment-13155195 ] Luca Cavanna commented on LUCENE-3586: -- Cool! Thanks, tomorrow I'll add a patch for this. > Choose a specific Directory implementation running the CheckIndex main > -- > > Key: LUCENE-3586 > URL: https://issues.apache.org/jira/browse/LUCENE-3586 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Luca Cavanna >Assignee: Luca Cavanna >Priority: Minor > > It should be possible to choose a specific Directory implementation to use > during the CheckIndex process when we run it from its main. > What about an additional main parameter? > In fact, I'm experiencing some problems with MMapDirectory working with a big > segment, and after some failed attempts playing with maxChunkSize, I decided > to switch to another FSDirectory implementation but I needed to do that on my > own main. > Should we also consider to use a FileSwitchDirectory? > I'm willing to contribute, could you please let me know your thoughts about > it? -- 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-2910) PingRequest fails if there is no defaultSearchField in the schema.xml
[ https://issues.apache.org/jira/browse/SOLR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155212#comment-13155212 ] Yury Kats commented on SOLR-2910: - "q" should be *:* > PingRequest fails if there is no defaultSearchField in the schema.xml > - > > Key: SOLR-2910 > URL: https://issues.apache.org/jira/browse/SOLR-2910 > Project: Solr > Issue Type: Bug >Affects Versions: 4.0 >Reporter: Yury Kats > > PingRequest fails if there is no defaultSearchField in the schema.xml > CommonsHttpSolrServer#ping produces: > org.apache.solr.common.SolrException: Ping query caused exception: no field > name specified in query and no defaultSearchField defined in schema.xml > at > org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:77) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1407) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353) > ... > request: http://127.0.0.1:8983/solr/a1/admin/ping?wt=javabin&version=2' -- 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-2910) PingRequest fails if there is no defaultSearchField in the schema.xml
[
https://issues.apache.org/jira/browse/SOLR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155213#comment-13155213
]
Yury Kats commented on SOLR-2910:
-
{noformat}*:*{noformat}
> PingRequest fails if there is no defaultSearchField in the schema.xml
> -
>
> Key: SOLR-2910
> URL: https://issues.apache.org/jira/browse/SOLR-2910
> Project: Solr
> Issue Type: Bug
>Affects Versions: 4.0
>Reporter: Yury Kats
>
> PingRequest fails if there is no defaultSearchField in the schema.xml
> CommonsHttpSolrServer#ping produces:
> org.apache.solr.common.SolrException: Ping query caused exception: no field
> name specified in query and no defaultSearchField defined in schema.xml
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:77)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1407)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353)
> ...
> request: http://127.0.0.1:8983/solr/a1/admin/ping?wt=javabin&version=2'
--
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-2607) Clean up /clients directory
[ https://issues.apache.org/jira/browse/SOLR-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155226#comment-13155226 ] Erik Hatcher commented on SOLR-2607: I went ahead and took care of this on trunk. svn exported to https://github.com/erikhatcher/solr-ruby-flare. RIP solr-ruby and flare. Long live Flare! For future reference, if you're using solr-ruby, consider switching to RSolr - http://rubygems.org/gems/rsolr Flare was the precursor prototype that morphed into the popular Blacklight framework - http://projectblacklight.org > Clean up /clients 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 > > 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] [Resolved] (SOLR-2607) Clean up /clients 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 Fix Version/s: 4.0 > Clean up /clients 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 > > > 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] [Reopened] (SOLR-2607) Clean up /clients directory
[ https://issues.apache.org/jira/browse/SOLR-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reopened SOLR-2607: going to re-open... we may want to also remove client/ fully? It's nice to have the pointer to the wiki though. Thoughts? > Clean up /clients 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 > > > 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] [Commented] (LUCENE-3586) Choose a specific Directory implementation running the CheckIndex main
[ https://issues.apache.org/jira/browse/LUCENE-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155233#comment-13155233 ] Uwe Schindler commented on LUCENE-3586: --- Hi Simon, hi Luca, Maybe we get some introduction and background from Luca, because in general issues are assigned to committers/contributors that have already done work for Lucene/Solr? Uwe > Choose a specific Directory implementation running the CheckIndex main > -- > > Key: LUCENE-3586 > URL: https://issues.apache.org/jira/browse/LUCENE-3586 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Luca Cavanna >Assignee: Luca Cavanna >Priority: Minor > > It should be possible to choose a specific Directory implementation to use > during the CheckIndex process when we run it from its main. > What about an additional main parameter? > In fact, I'm experiencing some problems with MMapDirectory working with a big > segment, and after some failed attempts playing with maxChunkSize, I decided > to switch to another FSDirectory implementation but I needed to do that on my > own main. > Should we also consider to use a FileSwitchDirectory? > I'm willing to contribute, could you please let me know your thoughts about > it? -- 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-3586) Choose a specific Directory implementation running the CheckIndex main
[ https://issues.apache.org/jira/browse/LUCENE-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155235#comment-13155235 ] Uwe Schindler commented on LUCENE-3586: --- About the issue at all: we should maybe have this parameter to all command line tools (e.g. IndexUpgrader,...). It would be good to have some general command line parser for those comand line tools that work on indexes, so we don't have the same/similar code several times. For me much more interesting is the problem you have with MMAP? Whats you Java VM / Lucene version and what's your complete command line to CheckIndex? What architecture are you using and which OS? Changing the chunk size is not needed in most cases, if it needs to we need complete configuration details to optimize auto detection. > Choose a specific Directory implementation running the CheckIndex main > -- > > Key: LUCENE-3586 > URL: https://issues.apache.org/jira/browse/LUCENE-3586 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Luca Cavanna >Assignee: Luca Cavanna >Priority: Minor > > It should be possible to choose a specific Directory implementation to use > during the CheckIndex process when we run it from its main. > What about an additional main parameter? > In fact, I'm experiencing some problems with MMapDirectory working with a big > segment, and after some failed attempts playing with maxChunkSize, I decided > to switch to another FSDirectory implementation but I needed to do that on my > own main. > Should we also consider to use a FileSwitchDirectory? > I'm willing to contribute, could you please let me know your thoughts about > it? -- 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-3586) Choose a specific Directory implementation running the CheckIndex main
[ https://issues.apache.org/jira/browse/LUCENE-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155235#comment-13155235 ] Uwe Schindler edited comment on LUCENE-3586 at 11/22/11 4:33 PM: - About the issue at all: we should maybe have this parameter to all command line tools (e.g. IndexUpgrader,...). It would be good to have some general command line parser for those comand line tools that work on indexes, so we don't have the same/similar code several times. For me much more interesting is the problem you have with MMAP? Whats you Java VM / Lucene version and what's your complete command line to CheckIndex? How big is the index? What architecture are you using and which OS? Changing the chunk size is not needed in most cases, if it needs to we need complete configuration details to optimize auto detection. was (Author: thetaphi): About the issue at all: we should maybe have this parameter to all command line tools (e.g. IndexUpgrader,...). It would be good to have some general command line parser for those comand line tools that work on indexes, so we don't have the same/similar code several times. For me much more interesting is the problem you have with MMAP? Whats you Java VM / Lucene version and what's your complete command line to CheckIndex? What architecture are you using and which OS? Changing the chunk size is not needed in most cases, if it needs to we need complete configuration details to optimize auto detection. > Choose a specific Directory implementation running the CheckIndex main > -- > > Key: LUCENE-3586 > URL: https://issues.apache.org/jira/browse/LUCENE-3586 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Luca Cavanna >Assignee: Luca Cavanna >Priority: Minor > > It should be possible to choose a specific Directory implementation to use > during the CheckIndex process when we run it from its main. > What about an additional main parameter? > In fact, I'm experiencing some problems with MMapDirectory working with a big > segment, and after some failed attempts playing with maxChunkSize, I decided > to switch to another FSDirectory implementation but I needed to do that on my > own main. > Should we also consider to use a FileSwitchDirectory? > I'm willing to contribute, could you please let me know your thoughts about > it? -- 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
[VOTE] Release Lucene/Solr 3.5.0, RC2
Please vote to release the RC2 artifacts at: http://people.apache.org/~simonw/staging_area/lucene-solr-3.5.0-RC2-rev1204988/ as Lucene 3.5.0 and Solr 3.5.0. Simon Willnauer - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [Lucene.Net] Roadmap
Mike, You're right about putting together a higher level discussion. Here are the road map items I see. I am interested in other have to say. None of the items I have listed are contigent on the other so they can be done in parallel or out of order. 1) Complete the release of 2.9.4 2) Create and release 3.0.3 3) Graduate from the incubator 4) Document a porting process that the community can reference. 5) Port 4.0 Scott > -Original Message- > From: Michael Herndon [mailto:mhern...@wickedsoftware.net] > Sent: Tuesday, November 22, 2011 10:28 AM > To: lucene-net-...@lucene.apache.org > Subject: Re: [Lucene.Net] Roadmap > > While much of the content in this thread is valid and is > important, especially concerns, pain points, and > implementation details... we've gotten way off topic. > > road map != implementation details. We should keep to a much > a higher level discussion to get this knocked out. > > Lets outline the roadmap, put it in a wiki page. > > Then discuss how to go about each major milestone in separate > threads to discuss implementation details. Or at least let > the people who are going to work on that particular milestone > publish their intentions to keep everyone else informed since > we're currently in a do-ocracy like state. > > And by all means, discuss the next immediate milestones first > so people who want to dive into that can proceed. > > So what are the next two major milestones? And from a higher > level perspective what are the major items that deem those > milestones complete? > > What would be the the next 3 ideal milestones after the first > two? And what would be the intentions for those milestones to > accomplish? > > - Michael > > > > On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens < > currens.ch...@gmail.com> wrote: > > > Next to impossible/really, really hard. There are just some things > > that don't map quite right. Sharpen is great, but it seems > you need > > to code written in a way that makes it easily convertible, > and I don't > > see the folks at Lucene changing their coding style to do that. > > > > An example: 3.0.3 changes classes that inherited from > util.Parameter, > > to java enums. Java enums are more similar to classes than > they are in C#. > > They can have methods, fields, etc. I wound up converting > them into > > enums with extension methods and/or static classes (usually to > > generate the enum). The way the code was written in Java, > there's no > > way a automated tool could figure that out on its own, > unless you had > > some sort of way to tell it what to do before hand. > > > > I imagine porting it by hand is probably easier, though it would be > > nice if there was a tool that would at least convert the > syntax from > > Java to C#, as well as changing the naming scheme to a .NET > compatible > > one. However, that only really helps if you're porting > classes from > > scratch. It could, also, hide bugs, since it's possible, however > > unlikely, something could port perfectly, but not behave > the same way. > > > > A class that has many calls to string.Substring is a good > example of this. > > If the name of the function is changed to the .Net version > > (.substring to .Substring), it would compile no problems, > but they are very different. > > C#'s signatures is Substring(int start, int count) while Java's is > > Substring(int startIndex, int endIndex). It may work > hiding issues, > > it may throw an exception, depending on the data. A porting tool > > would probably know many of the differences like this, so > it's sorta a > > moot point, in that this relies on the skills of the > developer anyway. > > > > I may be wrong, but I just don't see this being a fully automated > > process ever. I would love to have something automated > that at least > > fixed syntax errors, though this would only work on a line-by-line > > port. (Slightly off topic, I think we should always have a > > line-by-line port, even if our primary goals become focusing on a > > fully .Net style port) Either way, any sort of manual or > > partly-automated process would still require a lot of work to make > > sure things are ported correctly. I also think it's most > manageable > > if it were a tool that did it on a file per file basis > (instead of project level like Sharpen), for easy review and testing. > > > > > > Thanks, > > Christopher > > > > On Mon, Nov 21, 2011 at 3:30 PM, Scott Lombard > > > >wrote: > > > > > Chris, > > > > > > Now that you have spent some time dealing with the > porting what is > > > your view on creating a fully automated porting tool? > > > > > > Scott > > > > > > > -Original Message- > > > > From: Christopher Currens [mailto:currens.ch...@gmail.com] > > > > Sent: Monday, November 21, 2011 5:23 PM > > > > To: lucene-net-...@lucene.apache.org > > > > Subject: Re: [Lucene.Net] Roadmap > > > > > > > > Digy, > >
[jira] [Commented] (SOLR-2906) Implement LFU Cache
[ https://issues.apache.org/jira/browse/SOLR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155258#comment-13155258 ] Shawn Heisey commented on SOLR-2906: Something odd happens with the filterCache. When things are first starting off, the cache size and the number of inserts don't match up. It's usually off by 10, with more in the inserts. This doesn't seem to happen with the other cache types, also using LFU. > Implement LFU Cache > --- > > Key: SOLR-2906 > URL: https://issues.apache.org/jira/browse/SOLR-2906 > Project: Solr > Issue Type: Sub-task > Components: search >Affects Versions: 3.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: ConcurrentLFUCache.java, LFUCache.java, SOLR-2906.patch, > TestLFUCache.java > > > Implement an LFU (Least Frequently Used) cache as the first step towards a > full ARC cache -- 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-2906) Implement LFU Cache
[ https://issues.apache.org/jira/browse/SOLR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155267#comment-13155267 ] Yonik Seeley commented on SOLR-2906: bq. The cache size and the number of inserts don't match up. It's usually off by 10 Do you have any type of warming (autowarming or statically configured)? Statistics are counted differently during warming. > Implement LFU Cache > --- > > Key: SOLR-2906 > URL: https://issues.apache.org/jira/browse/SOLR-2906 > Project: Solr > Issue Type: Sub-task > Components: search >Affects Versions: 3.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: ConcurrentLFUCache.java, LFUCache.java, SOLR-2906.patch, > TestLFUCache.java > > > Implement an LFU (Least Frequently Used) cache as the first step towards a > full ARC cache -- 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] (PYLUCENE-12) Add PythonReusableAnalyzerBase, so we can create analyzers in Python
Add PythonReusableAnalyzerBase, so we can create analyzers in Python Key: PYLUCENE-12 URL: https://issues.apache.org/jira/browse/PYLUCENE-12 Project: PyLucene Issue Type: Improvement Reporter: Michael McCandless Lucene now has a useful helper class, ReusableAnalyzerBase; you subclass it and override one method, to create an analyzer that provides reusableTokenStream impl. I think we should expose it in Python... patch is simple. -- 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
[jira] [Updated] (PYLUCENE-12) Add PythonReusableAnalyzerBase, so we can create analyzers in Python
[ https://issues.apache.org/jira/browse/PYLUCENE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated PYLUCENE-12: --- Attachment: PYLUCENE-12.patch Patch w/ basic test. > Add PythonReusableAnalyzerBase, so we can create analyzers in Python > > > Key: PYLUCENE-12 > URL: https://issues.apache.org/jira/browse/PYLUCENE-12 > Project: PyLucene > Issue Type: Improvement >Reporter: Michael McCandless > Attachments: PYLUCENE-12.patch > > > Lucene now has a useful helper class, ReusableAnalyzerBase; you subclass it > and override one method, to create an analyzer that provides > reusableTokenStream impl. > I think we should expose it in Python... patch is simple. -- 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
[jira] [Commented] (SOLR-2906) Implement LFU Cache
[ https://issues.apache.org/jira/browse/SOLR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155280#comment-13155280 ] Shawn Heisey commented on SOLR-2906: The only static warming I have is a *:* search with a sort parameter (and no filter query), which precaches my sort. I do have autowarming configured, but this behavior happens from initial solr startup. Things seem to behave correctly with warming - size is autowarmCount, inserts are zero. FastLRUCache behavior: queryResultCache: size is one higher than inserts documentCache: size is one higher than inserts filterCache: size and inserts are identical LFUCache behavior: queryResultCache: size is one higher than inserts documentCache: size is one higher than inserts filterCache: inserts is higher than size by a variable amount I've seen 10 (on two different runs) and 2 (on the most recent run) as the difference between inserts and size. The FastLRUCache behavior is seen on my production servers with production queries, the LFUCache behavior is on my test server with a benchmark script providing the queries. I suppose there might be something weird about my canned queries that makes the filterCache behave differently, but the original source of the queries was a production Solr log at level INFO. > Implement LFU Cache > --- > > Key: SOLR-2906 > URL: https://issues.apache.org/jira/browse/SOLR-2906 > Project: Solr > Issue Type: Sub-task > Components: search >Affects Versions: 3.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: ConcurrentLFUCache.java, LFUCache.java, SOLR-2906.patch, > TestLFUCache.java > > > Implement an LFU (Least Frequently Used) cache as the first step towards a > full ARC cache -- 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-2906) Implement LFU Cache
[ https://issues.apache.org/jira/browse/SOLR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155280#comment-13155280 ] Shawn Heisey edited comment on SOLR-2906 at 11/22/11 5:32 PM: -- The only static warming I have is an all docs search with a sort parameter (and no filter query), which precaches my sort. I do have autowarming configured, but this behavior happens from initial solr startup. Things seem to behave correctly with warming - size is autowarmCount, inserts are zero. FastLRUCache behavior: queryResultCache: size is one higher than inserts documentCache: size is one higher than inserts filterCache: size and inserts are identical LFUCache behavior: queryResultCache: size is one higher than inserts documentCache: size is one higher than inserts filterCache: inserts is higher than size by a variable amount I've seen 10 (on two different runs) and 2 (on the most recent run) as the difference between inserts and size. The FastLRUCache behavior is seen on my production servers with production queries, the LFUCache behavior is on my test server with a benchmark script providing the queries. I suppose there might be something weird about my canned queries that makes the filterCache behave differently, but the original source of the queries was a production Solr log at level INFO. was (Author: elyograg): The only static warming I have is a *:* search with a sort parameter (and no filter query), which precaches my sort. I do have autowarming configured, but this behavior happens from initial solr startup. Things seem to behave correctly with warming - size is autowarmCount, inserts are zero. FastLRUCache behavior: queryResultCache: size is one higher than inserts documentCache: size is one higher than inserts filterCache: size and inserts are identical LFUCache behavior: queryResultCache: size is one higher than inserts documentCache: size is one higher than inserts filterCache: inserts is higher than size by a variable amount I've seen 10 (on two different runs) and 2 (on the most recent run) as the difference between inserts and size. The FastLRUCache behavior is seen on my production servers with production queries, the LFUCache behavior is on my test server with a benchmark script providing the queries. I suppose there might be something weird about my canned queries that makes the filterCache behave differently, but the original source of the queries was a production Solr log at level INFO. > Implement LFU Cache > --- > > Key: SOLR-2906 > URL: https://issues.apache.org/jira/browse/SOLR-2906 > Project: Solr > Issue Type: Sub-task > Components: search >Affects Versions: 3.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: ConcurrentLFUCache.java, LFUCache.java, SOLR-2906.patch, > TestLFUCache.java > > > Implement an LFU (Least Frequently Used) cache as the first step towards a > full ARC cache -- 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-3586) Choose a specific Directory implementation running the CheckIndex main
[ https://issues.apache.org/jira/browse/LUCENE-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155285#comment-13155285 ] Luca Cavanna commented on LUCENE-3586: -- Hi Uwe, hi all, you're right, I know (virtually) almost every people working at Solr/Lucene, but you of course don't know me! I'm Luca, I'm a software developer actually working at Dutchworks in Amsterdam within the enterprise search team. You certainly know my colleague Martijn, Solr/Lucene committer. I really like the open source world and the solr/lucene project. These are my contributions so far: SOLR-1499 and SOLR-2591. Just a few, but I would like to contribute as much as I can. Please,don't hesitate to ask if you have any questions. I assigned the issue to myself because I thought I was gonna work on it, but let me know if I made some mistakes. Tomorrow I'll add more details about the MMAP and the OOM. Thanks for your help and for your point of view about the issue, it would be great to do something more generic than I initially thought, I'll have a look at the code. > Choose a specific Directory implementation running the CheckIndex main > -- > > Key: LUCENE-3586 > URL: https://issues.apache.org/jira/browse/LUCENE-3586 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Luca Cavanna >Assignee: Luca Cavanna >Priority: Minor > > It should be possible to choose a specific Directory implementation to use > during the CheckIndex process when we run it from its main. > What about an additional main parameter? > In fact, I'm experiencing some problems with MMapDirectory working with a big > segment, and after some failed attempts playing with maxChunkSize, I decided > to switch to another FSDirectory implementation but I needed to do that on my > own main. > Should we also consider to use a FileSwitchDirectory? > I'm willing to contribute, could you please let me know your thoughts about > it? -- 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: [Lucene.Net] Roadmap
Regarding the short term goals that Scott mentioned, I agree. I think over the past 9 months that we've been active, it's time we see what we need to do to graduate from the incubator. Also, 3.0.3 is actually close to a release, *depending* on how we feel about the Contrib libraries, which I'll discuss in a separate thread. Scott didn't mention directly, but I think it would be good to port the 3.x branch past 3.0.3. Lucene has released 3.1, 3.2, 3.3, and 3.4 in addition to 3.0.3. Whether this means we release all those versions, or just port up to 3.4 and just release it, that's something we'd all have to agree upon. I want to get a 3.x branch up to where Java's is. Also, deciding if porting 4.0 can happen at the same time as 3.x is worked on and how to go about it, particularly how far we want to diverge from java. Either way, I think maintaining both 3.x and 4.x would be a good thing for the community to have. On Tue, Nov 22, 2011 at 8:56 AM, Scott Lombard wrote: > Mike, > > You're right about putting together a higher level discussion. Here are > the > road map items I see. I am interested in other have to say. > > None of the items I have listed are contigent on the other so they can be > done in parallel or out of order. > > > 1) Complete the release of 2.9.4 > 2) Create and release 3.0.3 > > 3) Graduate from the incubator > 4) Document a porting process that the community can reference. > 5) Port 4.0 > > > > Scott > > > -Original Message- > > From: Michael Herndon [mailto:mhern...@wickedsoftware.net] > > Sent: Tuesday, November 22, 2011 10:28 AM > > To: lucene-net-...@lucene.apache.org > > Subject: Re: [Lucene.Net] Roadmap > > > > While much of the content in this thread is valid and is > > important, especially concerns, pain points, and > > implementation details... we've gotten way off topic. > > > > road map != implementation details. We should keep to a much > > a higher level discussion to get this knocked out. > > > > Lets outline the roadmap, put it in a wiki page. > > > > Then discuss how to go about each major milestone in separate > > threads to discuss implementation details. Or at least let > > the people who are going to work on that particular milestone > > publish their intentions to keep everyone else informed since > > we're currently in a do-ocracy like state. > > > > And by all means, discuss the next immediate milestones first > > so people who want to dive into that can proceed. > > > > So what are the next two major milestones? And from a higher > > level perspective what are the major items that deem those > > milestones complete? > > > > What would be the the next 3 ideal milestones after the first > > two? And what would be the intentions for those milestones to > > accomplish? > > > > - Michael > > > > > > > > On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens < > > currens.ch...@gmail.com> wrote: > > > > > Next to impossible/really, really hard. There are just some things > > > that don't map quite right. Sharpen is great, but it seems > > you need > > > to code written in a way that makes it easily convertible, > > and I don't > > > see the folks at Lucene changing their coding style to do that. > > > > > > An example: 3.0.3 changes classes that inherited from > > util.Parameter, > > > to java enums. Java enums are more similar to classes than > > they are in C#. > > > They can have methods, fields, etc. I wound up converting > > them into > > > enums with extension methods and/or static classes (usually to > > > generate the enum). The way the code was written in Java, > > there's no > > > way a automated tool could figure that out on its own, > > unless you had > > > some sort of way to tell it what to do before hand. > > > > > > I imagine porting it by hand is probably easier, though it would be > > > nice if there was a tool that would at least convert the > > syntax from > > > Java to C#, as well as changing the naming scheme to a .NET > > compatible > > > one. However, that only really helps if you're porting > > classes from > > > scratch. It could, also, hide bugs, since it's possible, however > > > unlikely, something could port perfectly, but not behave > > the same way. > > > > > > A class that has many calls to string.Substring is a good > > example of this. > > > If the name of the function is changed to the .Net version > > > (.substring to .Substring), it would compile no problems, > > but they are very different. > > > C#'s signatures is Substring(int start, int count) while Java's is > > > Substring(int startIndex, int endIndex). It may work > > hiding issues, > > > it may throw an exception, depending on the data. A porting tool > > > would probably know many of the differences like this, so > > it's sorta a > > > moot point, in that this relies on the skills of the > > developer anyway. > > > > > > I may be wrong, but I just don't see this being a fully automated > > > process ever. I would love to have something au
[jira] [Commented] (SOLR-2906) Implement LFU Cache
[ https://issues.apache.org/jira/browse/SOLR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155290#comment-13155290 ] Shawn Heisey commented on SOLR-2906: I might have figured out the problem, and if I have, the cache code is fine. I just checked the log from my most recent run and have found that there are two errors from invalid filter queries. I think this means that when a filter is invalid, inserts gets incremented but size doesn't. > Implement LFU Cache > --- > > Key: SOLR-2906 > URL: https://issues.apache.org/jira/browse/SOLR-2906 > Project: Solr > Issue Type: Sub-task > Components: search >Affects Versions: 3.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: ConcurrentLFUCache.java, LFUCache.java, SOLR-2906.patch, > TestLFUCache.java > > > Implement an LFU (Least Frequently Used) cache as the first step towards a > full ARC cache -- 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=13155291#comment-13155291 ] Mark Johnson commented on SOLR-1301: Has anyone updated this contrib to work with the new ant tasks in solr 3.4? > 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.5, 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, 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
RE: [Lucene.Net] Roadmap
My goal is to release 2.9.4 this month - it looks like we have no -1s from our dev list so in the next day or so I will put that to the general incubator list. I'd then like to release 2.9.4g the first or second week of January. My thoughts would be to try and have 3.0.3 ready by march and 4.0 in the middle of the year. Im not sure how aggressive people think that is. With the 4.0 release we should be at or near parity with Java and ready to roll out of the incubator. We could do the 4 release and the graduation process at the same time as well Sent from my Windows Phone From: Scott Lombard Sent: 11/22/2011 8:56 AM To: lucene-net-...@lucene.apache.org Subject: RE: [Lucene.Net] Roadmap Mike, You're right about putting together a higher level discussion. Here are the road map items I see. I am interested in other have to say. None of the items I have listed are contigent on the other so they can be done in parallel or out of order. 1) Complete the release of 2.9.4 2) Create and release 3.0.3 3) Graduate from the incubator 4) Document a porting process that the community can reference. 5) Port 4.0 Scott > -Original Message- > From: Michael Herndon [mailto:mhern...@wickedsoftware.net] > Sent: Tuesday, November 22, 2011 10:28 AM > To: lucene-net-...@lucene.apache.org > Subject: Re: [Lucene.Net] Roadmap > > While much of the content in this thread is valid and is > important, especially concerns, pain points, and > implementation details... we've gotten way off topic. > > road map != implementation details. We should keep to a much > a higher level discussion to get this knocked out. > > Lets outline the roadmap, put it in a wiki page. > > Then discuss how to go about each major milestone in separate > threads to discuss implementation details. Or at least let > the people who are going to work on that particular milestone > publish their intentions to keep everyone else informed since > we're currently in a do-ocracy like state. > > And by all means, discuss the next immediate milestones first > so people who want to dive into that can proceed. > > So what are the next two major milestones? And from a higher > level perspective what are the major items that deem those > milestones complete? > > What would be the the next 3 ideal milestones after the first > two? And what would be the intentions for those milestones to > accomplish? > > - Michael > > > > On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens < > currens.ch...@gmail.com> wrote: > > > Next to impossible/really, really hard. There are just some things > > that don't map quite right. Sharpen is great, but it seems > you need > > to code written in a way that makes it easily convertible, > and I don't > > see the folks at Lucene changing their coding style to do that. > > > > An example: 3.0.3 changes classes that inherited from > util.Parameter, > > to java enums. Java enums are more similar to classes than > they are in C#. > > They can have methods, fields, etc. I wound up converting > them into > > enums with extension methods and/or static classes (usually to > > generate the enum). The way the code was written in Java, > there's no > > way a automated tool could figure that out on its own, > unless you had > > some sort of way to tell it what to do before hand. > > > > I imagine porting it by hand is probably easier, though it would be > > nice if there was a tool that would at least convert the > syntax from > > Java to C#, as well as changing the naming scheme to a .NET > compatible > > one. However, that only really helps if you're porting > classes from > > scratch. It could, also, hide bugs, since it's possible, however > > unlikely, something could port perfectly, but not behave > the same way. > > > > A class that has many calls to string.Substring is a good > example of this. > > If the name of the function is changed to the .Net version > > (.substring to .Substring), it would compile no problems, > but they are very different. > > C#'s signatures is Substring(int start, int count) while Java's is > > Substring(int startIndex, int endIndex). It may work > hiding issues, > > it may throw an exception, depending on the data. A porting tool > > would probably know many of the differences like this, so > it's sorta a > > moot point, in that this relies on the skills of the > developer anyway. > > > > I may be wrong, but I just don't see this being a fully automated > > process ever. I would love to have something automated > that at least > > fixed syntax errors, though this would only work on a line-by-line > > port. (Slightly off topic, I think we should always have a > > line-by-line port, even if our primary goals become focusing on a > > fully .Net style port) Either way, any sort of manual or > > partly-automated process would still require a lot of work to make > > sure things are ported correctly. I also think it's most > manageable > > if it were a tool th
[jira] [Commented] (SOLR-2906) Implement LFU Cache
[ https://issues.apache.org/jira/browse/SOLR-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155296#comment-13155296 ] Shawn Heisey commented on SOLR-2906: I can't reproduce it with LFUCache or FastLRUCache by manually sending invalid queries, so that's the wrong idea. > Implement LFU Cache > --- > > Key: SOLR-2906 > URL: https://issues.apache.org/jira/browse/SOLR-2906 > Project: Solr > Issue Type: Sub-task > Components: search >Affects Versions: 3.4 >Reporter: Shawn Heisey >Priority: Minor > Attachments: ConcurrentLFUCache.java, LFUCache.java, SOLR-2906.patch, > TestLFUCache.java > > > Implement an LFU (Least Frequently Used) cache as the first step towards a > full ARC cache -- 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-2438) Case Insensitive Search for Wildcard Queries
[ https://issues.apache.org/jira/browse/SOLR-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-2438: - Attachment: SOLR-2438-3x.patch Here's what the 3x version would look like if anyone's interested. There's some refactoring that was done between 3.x and 4.0 that made reconciling these a bit of a pain. Still need to modify the CHANGES files. I'll commit these tomorrow sometime if nobody objects. > Case Insensitive Search for Wildcard Queries > > > Key: SOLR-2438 > URL: https://issues.apache.org/jira/browse/SOLR-2438 > Project: Solr > Issue Type: Improvement >Reporter: Peter Sturge >Assignee: Erick Erickson > Attachments: SOLR-2438-3x.patch, SOLR-2438.patch, SOLR-2438.patch, > SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch > > > This patch adds support to allow case-insensitive queries on wildcard > searches for configured TextField field types. > This patch extends the excellent work done Yonik and Michael in SOLR-219. > The approach here is different enough (imho) to warrant a separate JIRA issue. -- 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
[Lucene.Net] Contrib and releases
I wanted to take some time to discuss our position on the Contrib projects. Digy and I were a little off topic in the roadmap thread and I brought it up. Digy mentioned he always felt that it was a "nice to have" but not necessarily required for a release. I can't say I disagree. I had some time to look over a lot of the contrib code in Java, and there are quite a few projects that cannot be ported directly, as they rely on 3rd party Java libraries that have no direct .Net equivalent. Porting them could delay releases a long time, which is why I think it hasn't really been kept up to date as it is. I think a requirement for releases should be to have whatever projects that are currently in contrib to be up to date and building, with valid and passing tests (our 2.9.4 Contrib.Analyzers project is missing tests for 9 namespaces). I think it should be as simple as that. I don't think we should worry about adding new projects, unless you feel compelled to do so. My opinion is that if someone wants a Contrib added to the project, someone can port and donate the code to our project, or if they request it, someone can volunteer to port it themselves. People do use our Contrib assemblies, I personally think this is a fair trade-off to only have to maintain what we already have. I would like to know how everyone else feels about it. Thanks, Christopher
[jira] [Commented] (SOLR-2888) FSTSuggester refactoring: utf8 storage, external sorts (OOM prevention), code cleanups
[ https://issues.apache.org/jira/browse/SOLR-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155339#comment-13155339 ] Dawid Weiss commented on SOLR-2888: --- I would like to commit this in if there are no objections. > FSTSuggester refactoring: utf8 storage, external sorts (OOM prevention), code > cleanups > -- > > Key: SOLR-2888 > URL: https://issues.apache.org/jira/browse/SOLR-2888 > Project: Solr > Issue Type: Improvement > Components: spellchecker >Reporter: Dawid Weiss >Assignee: Dawid Weiss > Fix For: 4.0 > > Attachments: SOLR-2888.patch > > > This issue incorporates several problems: > - utf16 was used previously to store and lookup terms, now it is utf8 > - the construction would OOM with large number of terms because of the need > to sort entries. Sorter APIs have been added and an implementation of > external (on-disk) sorting is also added (Robert Muir). > - the FSTLookup class has been split and refactored into FSTCompletion and > FSTCompletionBuilder, FSTCompletionLookup remains a facade connecting all the > pieces and implements Lookup interface. For large inputs use > FSTCompletionBuilder directly (and pre-bucket your input weights). > - Automatic bucketing in FSTCompletionLookup has been changed from linear > min/max discretization into dividing into ranges after all values have been > sorted. This empirically handles all potential distributions quite well. If > somebody needs something very specific, use FSTCompletionBuilder directly > (providing buckets), construct the automaton and then load it with > FSTCompletionLookup. -- 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: [VOTE] Release Lucene/Solr 3.5.0, RC2
+1 My basic Solr testing worked fine. Erik On Nov 22, 2011, at 11:43 , Simon Willnauer wrote: > Please vote to release the RC2 artifacts at: > > http://people.apache.org/~simonw/staging_area/lucene-solr-3.5.0-RC2-rev1204988/ > > as Lucene 3.5.0 and Solr 3.5.0. > > Simon Willnauer > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-2911) Add news to website for David and Eric's latest book, AS3ESS
Add news to website for David and Eric's latest book, AS3ESS Key: SOLR-2911 URL: https://issues.apache.org/jira/browse/SOLR-2911 Project: Solr Issue Type: Task Reporter: David Smiley David (me) and Eric's latest book, "Apache Solr 3 Enterprise Search Server", was just published by Packt. http://www.packtpub.com/apache-solr-3-enterprise-search-server/book I'd like to get Solr's website updated very soon. Once it is updated, the publisher will send the Apache Software Foundation 5% of revenue. I will attach a patch soon. I must profess that I didn't run Apache Forest to verify the result, since I don't have access to JDK 1.5 and I have high confidence I got it right. I would appreciate a committer doing a basic eyeball test of the results on the site, and clicking a few of the links. One thing I hope happens is that the book image should appear at the top-left to replace the first edition. Strangely I don't see "Solr 3.1 Cookbook" right below it as I would expect, after looking at the xml I had to modify in my patch. I don't know why. -- 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: [VOTE] Release Lucene/Solr 3.5.0, RC2
+1 On Tue, Nov 22, 2011 at 11:43 AM, Simon Willnauer wrote: > Please vote to release the RC2 artifacts at: > > http://people.apache.org/~simonw/staging_area/lucene-solr-3.5.0-RC2-rev1204988/ > > as Lucene 3.5.0 and Solr 3.5.0. > > Simon Willnauer > > - > 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
Re: [VOTE] Release Lucene/Solr 3.5.0, RC2
+1 Mike McCandless http://blog.mikemccandless.com On Tue, Nov 22, 2011 at 11:43 AM, Simon Willnauer wrote: > Please vote to release the RC2 artifacts at: > > http://people.apache.org/~simonw/staging_area/lucene-solr-3.5.0-RC2-rev1204988/ > > as Lucene 3.5.0 and Solr 3.5.0. > > Simon Willnauer > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2509) spellcheck: StringIndexOutOfBoundsException: String index out of range: -1
[ https://issues.apache.org/jira/browse/SOLR-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steffen Elberg Godskesen updated SOLR-2509: --- Attachment: SOLR-2509.patch This patch passes James' new unit tests, but fails testCollate() in org.apache.solr.handler.component.SpellCheckComponentTest, since the collation "pixmaa-a-b-c-d-e-f-g" is now returned for the query "pixma-a-b-c-d-e-f-g" with the word "pixmaa" in the index. The test expects the collation "pixmaa" to be returned. I'm not really in a position to decide which behavior is correct. The new behavior passes James' tests and fixes the StringIndexOutOfBoundsException, but may deviate enough from the current behavior to cause problems for existing users. > spellcheck: StringIndexOutOfBoundsException: String index out of range: -1 > -- > > Key: SOLR-2509 > URL: https://issues.apache.org/jira/browse/SOLR-2509 > Project: Solr > Issue Type: Bug >Affects Versions: 3.1 > Environment: Debian Lenny > JAVA Version "1.6.0_20" >Reporter: Thomas Gambier >Priority: Blocker > Attachments: SOLR-2509.patch, SOLR-2509.patch, document.xml, > schema.xml, solrconfig.xml > > > Hi, > I'm a french user of SOLR and i've encountered a problem since i've installed > SOLR 3.1. > I've got an error with this query : > cle_frbr:"LYSROUGE1149-73190" > *SEE COMMENTS BELOW* > I've tested to escape the minus char and the query worked : > cle_frbr:"LYSROUGE1149(BACKSLASH)-73190" > But, strange fact, if i change one letter in my query it works : > cle_frbr:"LASROUGE1149-73190" > I've tested the same query on SOLR 1.4 and it works ! > Can someone test the query on next line on a 3.1 SOLR version and tell me if > he have the same problem ? > yourfield:"LYSROUGE1149-73190" > Where do the problem come from ? > Thank you by advance for your help. > Tom -- 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: svn commit: r1205152 - /lucene/dev/trunk/lucene/src/java/org/apache/lucene/store/MMapDirectory.java
This one should have also been in 3.5 to work around the SIGSEGVs. But with
Mike's patch checking that IndexReaders are open, this should be not so
important.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: uschind...@apache.org [mailto:uschind...@apache.org]
> Sent: Tuesday, November 22, 2011 9:19 PM
> To: comm...@lucene.apache.org
> Subject: svn commit: r1205152 -
> /lucene/dev/trunk/lucene/src/java/org/apache/lucene/store/MMapDirectory.j
> ava
>
> Author: uschindler
> Date: Tue Nov 22 20:18:43 2011
> New Revision: 1205152
>
> URL: http://svn.apache.org/viewvc?rev=1205152&view=rev
> Log:
> LUCENE-3200: Add extra safety to MMapDirectory (as it could still use
> unmapped curBuf)!
>
> Modified:
>
> lucene/dev/trunk/lucene/src/java/org/apache/lucene/store/MMapDirectory.ja
> va
>
> Modified:
> lucene/dev/trunk/lucene/src/java/org/apache/lucene/store/MMapDirectory.ja
> va
> URL:
> http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/src/java/org/apache/lu
> cene/store/MMapDirectory.java?rev=1205152&r1=1205151&r2=1205152&vie
> w=diff
>
> ==
> ---
> lucene/dev/trunk/lucene/src/java/org/apache/lucene/store/MMapDirectory.ja
> va (original)
> +++
> lucene/dev/trunk/lucene/src/java/org/apache/lucene/store/MMapDirectory.ja
> va Tue Nov 22 20:18:43 2011
> @@ -412,6 +412,7 @@ public class MMapDirectory extends FSDir
>
> @Override
> public void close() throws IOException {
> + curBuf = null; curBufIndex = 0;
>try {
> if (isClone || buffers == null) return;
> for (int bufNr = 0; bufNr < buffers.length; bufNr++) {
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3200) Cleanup MMapDirectory to use only one MMapIndexInput impl with mapping sized of powers of 2
[ https://issues.apache.org/jira/browse/LUCENE-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155404#comment-13155404 ] Uwe Schindler commented on LUCENE-3200: --- MMapDirectory missed a explicit nulling of curBuf, commited trunk revision: 1205152, 3x in revision: 1205153 > Cleanup MMapDirectory to use only one MMapIndexInput impl with mapping sized > of powers of 2 > --- > > Key: LUCENE-3200 > URL: https://issues.apache.org/jira/browse/LUCENE-3200 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.3, 4.0 > > Attachments: LUCENE-3200.patch, LUCENE-3200.patch, LUCENE-3200.patch, > LUCENE-3200.patch, LUCENE-3200.patch, LUCENE-3200_tests.patch > > > Robert and me discussed a little bit after Mike's investigations, that using > SingleMMapIndexinput together with MultiMMapIndexInput leads to hotspot > slowdowns sometimes. > We had the following ideas: > - MultiMMapIndexInput is almost as fast as SingleMMapIndexInput, as the > switching between buffer boundaries is done in exception catch blocks. So > normal code path is always the same like for Single* > - Only the seek method uses strange calculations (the modulo is totally > bogus, it could be simply: int bufOffset = (int) (pos % maxBufSize); - very > strange way of calculating modulo in the original code) > - Because of speed we suggest to no longer use arbitrary buffer sizes. We > should pass only the power of 2 to the indexinput as size. All calculations > in seek and anywhere else would be simple bit shifts and AND operations (the > and masks for the modulo can be calculated in the ctor like NumericUtils does > when calculating precisionSteps). > - the maximum buffer size will now be 2^30, not 2^31-1. But thats not an > issue at all. In my opinion, a buffer size of 2^31-1 is stupid in all cases, > as it will no longer fit page boundaries and mmapping gets harder for the O/S. > We will provide a patch with those cleanups. -- 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: [VOTE] Release Lucene/Solr 3.5.0, RC2
: http://people.apache.org/~simonw/staging_area/lucene-solr-3.5.0-RC2-rev1204988/ +0 Two things jumped out at me as being bad, but i'm not certain if either warrant a re-spin... 1) in the src builds, attempts at building javadocs result in an ant failure because of a warning that it couldn't get the java1.5 package list from the oracle.com URL. I thought we'd switched this to using a local copy, but i guess i'm remembering wrong -- either way i'm not sure why the 3x jenkins build isn't failing non-stop (unless this is a really recent change on oracles site). NOTE: the javadocs do build (w/o links for java.* classes) but the ant task fails because of the warning. 2) if you build lucene or solr from source, the version in the artifact names are "3.5-SNAPSHOT" ... last time i checked, a release named "3.5" would have it's build.xml such that building from source w/o explicitly setting the version props would result in "3.6-SNAPSHOT" (or "3.5.1-SNAPSHOT") so it looks like perhaps we forgot to update the version on the branch before the release? ... either that or maybe there was a discussion about deliberately changing this that i just didn't notice? --- TEST NOTES BELOW -- NOTE: I only tested the TGZ Artifacts... apache-solr-3.5.0-src.tgz * MD5 checked clean: 8846bcd57e4fcef28360704b99d3f639 * SHA1 checked clean: bfe4ecf0baff0eea7882da3b848537bfc2b994d7 * lucene and solr CHANGES.txt looked sane * "ant test" passed * "cd solr && ant example" build cleanly * "cd solr && ant javadocs" failed because of a warning that the oracle 1.5 javadoc URL no longer works -- not sure why the 3x jenkins build isn't failing constantly. * local solr tutorial and local solr examples work fine * built solr javadocs worked fine (except for links to java core classes) * "cd lucene && ant javadocs" had same issues as solr javadocs but likewise read fine. * noticed that the artifacts build from source were labeled "3.5-SNAPSHOT" ... shouldn't they be 3.6-SNAPSHOT or 3.5.1-SNAPSHOT? apache-solr-3.5.0.tgz * MD5 checked clean: b7be2fc190b26377ced5ae6055ed43e2 * SHA1 checked clean: 020fc86dfd2405212c0f706111d8576dbb8e54b4 * CHANGES.txt looked sane * solr tutorial and javadocs looked good * solr example ran fine lucene-3.5.0.tgz * MD5 checked clean: e42d356a7cbf45f44a2187bb3d460cc3 * SHA1 checked clean: d5dc544cdd0b645eb0d6a79e33686a574f3e0e86 * javadocs look good * CHANGES.txt looked sane lucene-3.5.0-src.tgz * MD5 checked clean: ccbaf8ddd8915a3e9d8e7d657717cca2 * SHA1 checked clean: 06969f57ad93f31e173419b6991d117b5f111624 * CHANGES.txt looked sane * "ant test" passed * "ant javadocs" had same issues as mentioned above but likewise read fine. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.5.0, RC2
On Tue, Nov 22, 2011 at 4:04 PM, Chris Hostetter wrote: > > : > http://people.apache.org/~simonw/staging_area/lucene-solr-3.5.0-RC2-rev1204988/ > > +0 > > Two things jumped out at me as being bad, but i'm not certain if either > warrant a re-spin... > > 1) in the src builds, attempts at building javadocs result in an ant > failure because of a warning that it couldn't get the java1.5 package list > from the oracle.com URL. I thought we'd switched this to using a local > copy, but i guess i'm remembering wrong -- either way i'm not sure why the > 3x jenkins build isn't failing non-stop (unless this is a really recent > change on oracles site). NOTE: the javadocs do build (w/o links for > java.* classes) but the ant task fails because of the warning. Thats oracle's problem (not ours). The reason it doesn't fail in hudson is that I downloaded the javadocs to hudson so that when oracles servers flake out, it doesn't spam our list. But if users want to use this method too, good for them, they can use -Djavadoc.link. But we cannot enforce this: they might not be using an oracle jvm, nor can we ship with the javadocs from oracle (as the license.html that comes in the docs package does not look compatible with apache to me) http://svn.apache.org/repos/asf/lucene/dev/nightly/hudson-settings.sh # locations of javadocs used by the build JAVADOC_HOME_15=/usr/local/share/doc/jdk1.5/api JAVADOC_HOME_16=/usr/local/share/doc/jdk1.6/api http://svn.apache.org/repos/asf/lucene/dev/nightly/hudson-lusolr-tests-3.x.sh # verify lucene core javadocs have no warnings w/ Java 1.5 cd $WORKSPACE/$CORE_DIR JAVA_HOME=$JAVA_HOME_15 $ANT_HOME/bin/ant \ -Djavadoc.link=$JAVADOC_HOME_15 \ javadocs-all javadocs-test-framework > > 2) if you build lucene or solr from source, the version in the artifact > names are "3.5-SNAPSHOT" ... last time i checked, a release named "3.5" > would have it's build.xml such that building from source w/o explicitly > setting the version props would result in "3.6-SNAPSHOT" (or > "3.5.1-SNAPSHOT") so it looks like perhaps we forgot to update the version > on the branch before the release? ... either that or maybe there was a > discussion about deliberately changing this that i just didn't notice? > 3.5-SNAPSHOT is correct, at least this is the way it has been for every previous 3.x release... (well previously it was -dev) This way its clear that the user is creating an unofficial 3.x build -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2911) Add news to website for David and Eric's latest book, AS3ESS
[ https://issues.apache.org/jira/browse/SOLR-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-2911: --- Attachment: as3ess_book.jpg solr_website.patch FYI the attached image goes in: solr/site-src/src/documentation/content/xdocs/images/ > Add news to website for David and Eric's latest book, AS3ESS > > > Key: SOLR-2911 > URL: https://issues.apache.org/jira/browse/SOLR-2911 > Project: Solr > Issue Type: Task >Reporter: David Smiley > Attachments: as3ess_book.jpg, solr_website.patch > > > David (me) and Eric's latest book, "Apache Solr 3 Enterprise Search Server", > was just published by Packt. > http://www.packtpub.com/apache-solr-3-enterprise-search-server/book I'd like > to get Solr's website updated very soon. Once it is updated, the publisher > will send the Apache Software Foundation 5% of revenue. > I will attach a patch soon. I must profess that I didn't run Apache Forest > to verify the result, since I don't have access to JDK 1.5 and I have high > confidence I got it right. I would appreciate a committer doing a basic > eyeball test of the results on the site, and clicking a few of the links. > One thing I hope happens is that the book image should appear at the top-left > to replace the first edition. Strangely I don't see "Solr 3.1 Cookbook" right > below it as I would expect, after looking at the xml I had to modify in my > patch. I don't know why. -- 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: [VOTE] Release Lucene/Solr 3.5.0, RC2
> 2) if you build lucene or solr from source, the version in the artifact > names are "3.5-SNAPSHOT" ... last time i checked, a release named "3.5" > would have it's build.xml such that building from source w/o explicitly > setting the version props would result in "3.6-SNAPSHOT" (or > "3.5.1-SNAPSHOT") so it looks like perhaps we forgot to update the version > on the branch before the release? ... either that or maybe there was a > discussion about deliberately changing this that i just didn't notice? Lucene: The last time this was done was with the 2.1.0 release. From 2.2.0 through 2.4.1, the source release build version was left the same as the release, with no -dev and in most cases not even the proper patch version included (e.g. 2.3.1+ and 2.4.1). The current practice -- leaving the version intact, including the -dev/-SNAPSHOT suffix -- began with the 2.9.1 release. Solr: Prior to the Lucene-Solr development merge, Solr always did the set-the-source-release-version-to-the-next-patch-version thing (with the exception of 1.3, when the version was left the same as the release, very likely not intentionally). Steve
RE: [VOTE] Release Lucene/Solr 3.5.0, RC2
: Lucene: The last time this was done was with the 2.1.0 release. From ... : Solr: Prior to the Lucene-Solr development merge, Solr always did the ... Cool ... so I just haven't been paying attention and this is expected. thanks. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.5.0, RC2
: Thats oracle's problem (not ours). I would argue that if we release packages that fail to build cleanly because our build system: a) is explicitly configured to try and build linkages against a URL that 404s (which causes javadoc to issue a warning) b) is explicitly configured to fail on any javadoc warnings ..then that is our problem. (particularly since we don't do anything to document / encourage users to override the broken URL if they try to build from source) : can use -Djavadoc.link. But we cannot enforce this: they might not be : using an oracle jvm, nor can we ship with the javadocs from oracle (as : the license.html that comes in the docs package does not look : compatible with apache to me) Agreed -- we shouldn't / can't ship a package-list from Oracle, but we should change the hardcoded javadoc.link value in common-build.xml to "" (ie: the empty string) ... that causes the build to succeed completely -- if users want happy/shiny/pretty links to java.lang.* classes then they can override -- but they shouldn't have to dig through the build.xml just to figure out how to get a basic build to work cleanly. And FWIW: I was mistaken in my last email when i said "ant javadocs" built all the javadocs correctly and then failed because of the warning -- i failed to notice that only the "All" version of thes docs were building, and then the build was immediately failure (before it recursed and did the individual contribs and the test-framework) ... and since the test framework is not included in the "All" copy of the javadocs, that means src users don't get any copy of those javadocs at all. So I'm ammending my vote of RC2 to a -1. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3587) Attempting to link to Java SE JavaDocs is competely unreliable
Attempting to link to Java SE JavaDocs is competely unreliable -- Key: LUCENE-3587 URL: https://issues.apache.org/jira/browse/LUCENE-3587 Project: Lucene - Java Issue Type: Bug Reporter: Hoss Man Fix For: 3.6, 4.0 As noted several times since Oracle bought Sun, the canonical links to the Java SE JavaDocs have been unreliable and frequently cause warnings. Since we choose to fail the build on javadoc warnings, this is a serious problem for anyone trying to build from source if/when the package-list we reference in our common-build.xml is not available. We should eliminate this dependency. -- 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-3587) Attempting to link to Java SE JavaDocs is competely unreliable
[ https://issues.apache.org/jira/browse/LUCENE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated LUCENE-3587: - Attachment: LUCENE-3587.trunk.patch Patch against trunk demonstrating the change i suggest we make (to both trunk and 3x, and ideally the 3.5 release branch as well assuming we want to go with an RC3) This doesn't prevent us from continuing to use a local version of the package-list in our jenkins build, but since we can't ship that file in our releases, this is a good compromise that eliminates our dependency on a the flaky and ever changing URL for javadocs. > Attempting to link to Java SE JavaDocs is competely unreliable > -- > > Key: LUCENE-3587 > URL: https://issues.apache.org/jira/browse/LUCENE-3587 > Project: Lucene - Java > Issue Type: Bug >Reporter: Hoss Man > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3587.trunk.patch > > > As noted several times since Oracle bought Sun, the canonical links to the > Java SE JavaDocs have been unreliable and frequently cause warnings. > Since we choose to fail the build on javadoc warnings, this is a serious > problem for anyone trying to build from source if/when the package-list we > reference in our common-build.xml is not available. > We should eliminate this dependency. -- 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-3587) Attempting to link to Java SE JavaDocs is competely unreliable
[ https://issues.apache.org/jira/browse/LUCENE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated LUCENE-3587: - Attachment: LUCENE-3587.3x.patch equivalent patch for the 3x (and 3.5) branches. > Attempting to link to Java SE JavaDocs is competely unreliable > -- > > Key: LUCENE-3587 > URL: https://issues.apache.org/jira/browse/LUCENE-3587 > Project: Lucene - Java > Issue Type: Bug >Reporter: Hoss Man > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3587.3x.patch, LUCENE-3587.trunk.patch > > > As noted several times since Oracle bought Sun, the canonical links to the > Java SE JavaDocs have been unreliable and frequently cause warnings. > Since we choose to fail the build on javadoc warnings, this is a serious > problem for anyone trying to build from source if/when the package-list we > reference in our common-build.xml is not available. > We should eliminate this dependency. -- 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: [VOTE] Release Lucene/Solr 3.5.0, RC2
: Agreed -- we shouldn't / can't ship a package-list from Oracle, but we : should change the hardcoded javadoc.link value in common-build.xml to "" : (ie: the empty string) ... that causes the build to succeed completely -- : if users want happy/shiny/pretty links to java.lang.* classes then they : can override -- but they shouldn't have to dig through the build.xml just : to figure out how to get a basic build to work cleanly. I've put some patches in Jira to free us from Oracle's roller coaster of javadoc link bullshit forever https://issues.apache.org/jira/browse/LUCENE-3587 ...I think we should not only commit them to trunk & 3x but also the 3.5 branch and spin an RC3. It would look really silly to release 3.5 RC2 with a hardcoded URL in the build.xml that 404s and fails the build. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-3.x - Build # 558 - Failure
Build: https://builds.apache.org/job/Lucene-3.x/558/ No tests ran. Build Log (for compile errors): [...truncated 10746 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.5.0, RC2
On Tue, Nov 22, 2011 at 7:08 PM, Chris Hostetter wrote: > > ...I think we should not only commit them to trunk & 3x but also > the 3.5 branch and spin an RC3. It would look really silly to release > 3.5 RC2 with a hardcoded URL in the build.xml that 404s and fails the build. > And you seriously think this should block a release? Because we do have really important bugfixes etc that would be nice to get out. If the fact that javadocs fails because Oracle removed the package-list for java5 javadocs is a blocker, then on RC3 should i vote -1 because the tests often completely hang on java5 due to JVM concurrency bugs? These are just more reasons why I think we cannot support EOL'ed java5 anymore. -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3588) Try harder to prevent SIGSEGV on cloned MMapIndexInputs
Try harder to prevent SIGSEGV on cloned MMapIndexInputs --- Key: LUCENE-3588 URL: https://issues.apache.org/jira/browse/LUCENE-3588 Project: Lucene - Java Issue Type: Improvement Components: core/store Affects Versions: 3.4, 3.5 Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.6, 4.0 We are unmapping mmapped byte buffers which is disallowed by the JDK, because it has the risk of SIGSEGV when you access the mapped byte buffer after unmapping. We currently prevent this for the main IndexInput by setting its buffer to null, so we NPE if somebody tries to access the underlying buffer. I recently fixed also the stupid curBuf (LUCENE-3200) by setting to null. The big problem are cloned IndexInputs which are generally not closed. Those still contain references to the unmapped ByteBuffer, which lead to SIGSEGV easily. The patch from Mike in LUCENE-3439 prevents most of this in Lucene 3.5, but its still not 100% safe (as it uses non-volatiles). This patch will fix the remaining issues by also setting the buffers of clones to null when the original is closed. The trick is to record weak references of all clones created and close them together with the original. This uses a ConcurrentHashMap,?> as store with the logic borrowed from WeakHashMap to cleanup the GCed references (using ReferenceQueue). If we respin 3.5, we should maybe also get this in. -- 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-3588) Try harder to prevent SIGSEGV on cloned MMapIndexInputs
[ https://issues.apache.org/jira/browse/LUCENE-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3588: -- Attachment: LUCENE-3588.patch > Try harder to prevent SIGSEGV on cloned MMapIndexInputs > --- > > Key: LUCENE-3588 > URL: https://issues.apache.org/jira/browse/LUCENE-3588 > Project: Lucene - Java > Issue Type: Improvement > Components: core/store >Affects Versions: 3.4, 3.5 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3588.patch > > > We are unmapping mmapped byte buffers which is disallowed by the JDK, because > it has the risk of SIGSEGV when you access the mapped byte buffer after > unmapping. > We currently prevent this for the main IndexInput by setting its buffer to > null, so we NPE if somebody tries to access the underlying buffer. I recently > fixed also the stupid curBuf (LUCENE-3200) by setting to null. > The big problem are cloned IndexInputs which are generally not closed. Those > still contain references to the unmapped ByteBuffer, which lead to SIGSEGV > easily. The patch from Mike in LUCENE-3439 prevents most of this in Lucene > 3.5, but its still not 100% safe (as it uses non-volatiles). > This patch will fix the remaining issues by also setting the buffers of > clones to null when the original is closed. The trick is to record weak > references of all clones created and close them together with the original. > This uses a ConcurrentHashMap,?> as store with > the logic borrowed from WeakHashMap to cleanup the GCed references (using > ReferenceQueue). > If we respin 3.5, we should maybe also get this in. -- 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-3588) Try harder to prevent SIGSEGV on cloned MMapIndexInputs
[ https://issues.apache.org/jira/browse/LUCENE-3588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3588: Attachment: LUCENE-3588.patch +1, i added a simple test, sigsegv's without patch, passes with it. > Try harder to prevent SIGSEGV on cloned MMapIndexInputs > --- > > Key: LUCENE-3588 > URL: https://issues.apache.org/jira/browse/LUCENE-3588 > Project: Lucene - Java > Issue Type: Improvement > Components: core/store >Affects Versions: 3.4, 3.5 >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3588.patch, LUCENE-3588.patch > > > We are unmapping mmapped byte buffers which is disallowed by the JDK, because > it has the risk of SIGSEGV when you access the mapped byte buffer after > unmapping. > We currently prevent this for the main IndexInput by setting its buffer to > null, so we NPE if somebody tries to access the underlying buffer. I recently > fixed also the stupid curBuf (LUCENE-3200) by setting to null. > The big problem are cloned IndexInputs which are generally not closed. Those > still contain references to the unmapped ByteBuffer, which lead to SIGSEGV > easily. The patch from Mike in LUCENE-3439 prevents most of this in Lucene > 3.5, but its still not 100% safe (as it uses non-volatiles). > This patch will fix the remaining issues by also setting the buffers of > clones to null when the original is closed. The trick is to record weak > references of all clones created and close them together with the original. > This uses a ConcurrentHashMap,?> as store with > the logic borrowed from WeakHashMap to cleanup the GCed references (using > ReferenceQueue). > If we respin 3.5, we should maybe also get this in. -- 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: [VOTE] Release Lucene/Solr 3.5.0, RC2
: If the fact that javadocs fails because Oracle removed the : package-list for java5 javadocs is a blocker, : : then on RC3 should i vote -1 because the tests often completely hang : on java5 due to JVM concurrency bugs? a) API Compatibility has nothing to do with which JVM you choose to try and run tests on. If the Oracle Java5 JVM is buggy, you're welcome to use any other Java 1.5 compatible JVM you want -- but it doesn't change the fact that the 3x branch is documented to be Java 1.5 compatible. If you want to beat that horse some more go ahead, but it really has nothing to do with this dicussion. b) For the sake of argument: I do in fact think there is a huge difference between the following caveats: 1) "Some tests may fail, sometimes, depending on your JVM/Platform." 2) "Building javadocs is garunteed to fail (regardless of your JVM implementation, JVM Version, or Platform) unless you override a certain (undocumented) build property." ...if we're not going to care enough to respin an RC when the build.xml is completley unusable (and we already have a patch to fix it!) then why bother giving a crap if any of the code is usable? or if any tests pass? I mean seriously ... WTF is the point of a release that we know is broken for all users? the main reason we even have an RC2 is because one test (in a contrib!) would fail on some OS's -- if that's worth making RC2 then why the fuck isn't it worth making an RC3 when it's impossible to generate documentation on any fucking machine in the world? -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 3.5.0, RC2
On Tue, Nov 22, 2011 at 8:22 PM, Chris Hostetter wrote: > > I mean seriously ... WTF is the point of a release that we know is broken > for all users? the main reason we even have an RC2 is because one test > (in a contrib!) would fail on some OS's -- if that's worth making RC2 then > why the fuck isn't it worth making an RC3 when it's impossible to > generate documentation on any fucking machine in the world? > I don't think that one should have been a blocker either... But I'm just pointing out that with "bugs" like the javadocs thing, its not really a lucene bug. Likely its a transient issue with oracle's configuration... does that mean all of our past releases are broken too Because, ant javadocs won't work there either. I did a quick google search: "http://java.sun.com/j2se/1.5/docs/api/"; build.xml and this came across build files from all kinds of big projects like icu4j, hibernate, other apache projects like zookeeper, etc. Are all of their build files "completely unusable". Should the java world halt all development because oracle's servers return 404's, and yank all previous releases and mark as broken? -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3587) Attempting to link to Java SE JavaDocs is competely unreliable
[ https://issues.apache.org/jira/browse/LUCENE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155622#comment-13155622 ] Robert Muir commented on LUCENE-3587: - +1 to the patch (i think its the best solution), on the condition that the release process doesn't change... this means we won't have these links on the website. I don't want to make releases any harder so I don't think putting the burden on the RM to do something crazy to get those links on the website is worth it... for the most part lucene's classes extend other lucene classes or java.lang.Object so I don't think this is a bad compromise at all. > Attempting to link to Java SE JavaDocs is competely unreliable > -- > > Key: LUCENE-3587 > URL: https://issues.apache.org/jira/browse/LUCENE-3587 > Project: Lucene - Java > Issue Type: Bug >Reporter: Hoss Man > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3587.3x.patch, LUCENE-3587.trunk.patch > > > As noted several times since Oracle bought Sun, the canonical links to the > Java SE JavaDocs have been unreliable and frequently cause warnings. > Since we choose to fail the build on javadoc warnings, this is a serious > problem for anyone trying to build from source if/when the package-list we > reference in our common-build.xml is not available. > We should eliminate this dependency. -- 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: [VOTE] Release Lucene/Solr 3.5.0, RC2
: But I'm just pointing out that with "bugs" like the javadocs thing, : its not really a lucene bug. Likely its a transient issue with : oracle's configuration... does that mean all of our past releases are : broken too Because, ant javadocs won't work there either. Those releases are already out there, we can't change them, and if someone asks "how come the build for 3.4 fails?" we can explain. But shipping 3.5, knowing that everyone who tries to build it is going to get a failure the minute it goes live, seems idiotic. : I did a quick google search: "http://java.sun.com/j2se/1.5/docs/api/"; build.xml ... : Are all of their build files "completely unusable". Should the java Probably not, because I sincerly doubt those build.xml files jump through all the hoops we jump through to fail hard on any javadoc warning. (Remember: "fail on warning" is not a feature of javadoc, or the nat target -- it's something special we do in our build.xml. It's sometihng that in general i think is a very good idea, and i don't suggest we change it, but it's the reason why we shouldn't just say "it's oracles problem" when javadoc spits out a warning because the URL is down) So let's just fucking fix it once an for all, so we'll never-ever have to care if Oracle screws up the package-list yet again, and so the 3.5 build will actually *work* -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3587) Attempting to link to Java SE JavaDocs is competely unreliable
[ https://issues.apache.org/jira/browse/LUCENE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155634#comment-13155634 ] Steven Rowe commented on LUCENE-3587: - I think we should just stop failing the build for this particular warning. I'll work up a patch. > Attempting to link to Java SE JavaDocs is competely unreliable > -- > > Key: LUCENE-3587 > URL: https://issues.apache.org/jira/browse/LUCENE-3587 > Project: Lucene - Java > Issue Type: Bug >Reporter: Hoss Man > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3587.3x.patch, LUCENE-3587.trunk.patch > > > As noted several times since Oracle bought Sun, the canonical links to the > Java SE JavaDocs have been unreliable and frequently cause warnings. > Since we choose to fail the build on javadoc warnings, this is a serious > problem for anyone trying to build from source if/when the package-list we > reference in our common-build.xml is not available. > We should eliminate this dependency. -- 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: [VOTE] Release Lucene/Solr 3.5.0, RC2
On Tue, Nov 22, 2011 at 9:21 PM, Chris Hostetter wrote: > (Remember: "fail on warning" is not a feature of javadoc, or the > nat target -- it's something special we do in our build.xml. > It's sometihng that in general i think is a very good idea, and i don't > suggest we change it, but it's the reason why we shouldn't just say "it's > oracles problem" when javadoc spits out a warning because the URL is down) > While its true we do something special here to intentionally fail, I actually think its still not our bug, should be a feature of javadoc, and should be part of the ant target (they claim to strive for reproducable builds) If you don't fail on this warning, you don't actually have a reproducable build: your 'javadocs' target generates different output depending upon whether oracle's server is working correctly or not at the time you ran it. This is why I agree with your fix (versus adding a regular expression to ignore the warning in addition to Uwe's java 7 hack)... its just about whether it should be a blocker to release or not. Because chances are within the 72 hour vote period the link starts working again... if this happens will you rescind your -1? -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-trunk - Build # 1743 - Failure
Build: https://builds.apache.org/job/Lucene-trunk/1743/ No tests ran. Build Log (for compile errors): [...truncated 8603 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3587) Attempting to link to Java SE JavaDocs is competely unreliable
[ https://issues.apache.org/jira/browse/LUCENE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3587: Attachment: LUCENE-3587.keep-javadoc-link.3x.patch > Attempting to link to Java SE JavaDocs is competely unreliable > -- > > Key: LUCENE-3587 > URL: https://issues.apache.org/jira/browse/LUCENE-3587 > Project: Lucene - Java > Issue Type: Bug >Reporter: Hoss Man > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3587.3x.patch, > LUCENE-3587.keep-javadoc-link.3x.patch, LUCENE-3587.trunk.patch > > > As noted several times since Oracle bought Sun, the canonical links to the > Java SE JavaDocs have been unreliable and frequently cause warnings. > Since we choose to fail the build on javadoc warnings, this is a serious > problem for anyone trying to build from source if/when the package-list we > reference in our common-build.xml is not available. > We should eliminate this dependency. -- 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-3587) Attempting to link to Java SE JavaDocs is competely unreliable
[ https://issues.apache.org/jira/browse/LUCENE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3587: Attachment: LUCENE-3587.keep-javadoc-link.trunk.patch Trunk & branch_3x versions of patch to ignore the package-list download warning. This way we at least attempt to do the right thing, but don't fail the build when Oracle fails to not suck. > Attempting to link to Java SE JavaDocs is competely unreliable > -- > > Key: LUCENE-3587 > URL: https://issues.apache.org/jira/browse/LUCENE-3587 > Project: Lucene - Java > Issue Type: Bug >Reporter: Hoss Man > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3587.3x.patch, > LUCENE-3587.keep-javadoc-link.3x.patch, > LUCENE-3587.keep-javadoc-link.trunk.patch, LUCENE-3587.trunk.patch > > > As noted several times since Oracle bought Sun, the canonical links to the > Java SE JavaDocs have been unreliable and frequently cause warnings. > Since we choose to fail the build on javadoc warnings, this is a serious > problem for anyone trying to build from source if/when the package-list we > reference in our common-build.xml is not available. > We should eliminate this dependency. -- 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-2358) Distributing Indexing
[ https://issues.apache.org/jira/browse/SOLR-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155693#comment-13155693 ] Lance Norskog commented on SOLR-2358: - Lamport Clocks are a time-tested way to sequence actions across a network. In this case, you can use an iterate-until-happy algorithm using the locks. [Google Lamport Clock|https://www.google.com/search?q=lamport+clock] > Distributing Indexing > - > > Key: SOLR-2358 > URL: https://issues.apache.org/jira/browse/SOLR-2358 > Project: Solr > Issue Type: New Feature > Components: SolrCloud, update >Reporter: William Mayor >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-2358.patch > > > The first steps towards creating distributed indexing functionality in Solr -- 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
