Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 13820 - Still Failing

I committed a fix... Mike McCandless http://blog.mikemccandless.com On Sun, May 6, 2012 at 5:37 AM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13820/ > > All tests passed > > Build Log (for compile errors): > [...truncated 24095 lines...] >

Re: [VOTE] Release PyLucene 3.6.0 rc2

+1 to release. I built/installed successfully on OS X 10.6.8, and ran my usual smoke test (index/search first 100 K docs from Wikipedia). Was the added 'print "setup args = %s" % args' intentional, in jcc/jcc/python.py? Just prints a lot of stuff out while building PyLucene... Mike McCandless

Re: [VOTE] Release PyLucene 3.6.0 rc2

On Tue, May 8, 2012 at 1:24 PM, Andi Vajda wrote: > > On May 8, 2012, at 10:18, Michael McCandless > wrote: > >> Was the added 'print "setup args = %s" % args' intentional, in >> jcc/jcc/python.py?  Just prints a lot of stuff out while building >

Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 13992 - Failure

It's getting the new AlcoholicMergePolicy!!! LOL :) Mike McCandless http://blog.mikemccandless.com On Sat, May 12, 2012 at 4:20 PM, Robert Muir wrote: > This is reproducible. i changed it to use newFSDirectory and it still > OOMs... needs more investigation > > also, when test fails from an ER

Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 13992 - Failure

OK I committed a fix. Mike McCandless http://blog.mikemccandless.com On Sat, May 12, 2012 at 4:43 PM, Michael McCandless wrote: > It's getting the new AlcoholicMergePolicy!!! LOL :) > > Mike McCandless > > http://blog.mikemccandless.com > > > On Sat, May 12,

Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 13992 - Failure

On Sat, May 12, 2012 at 5:27 PM, Robert Muir wrote: > right, I added the verbose option locally to try to see what it was doing > but didn't see the verbose output... could be a problem between keyboard and > chair as it seems mike figured it out??? Actually I cheated: I used the python runner (i

Re: Build failed in Jenkins: Lucene-Solr-trunk-Linux-Java6-64 #348

I committed a fix we were calling RateLimiter way too often from MockIndexOutputWrapper... Mike McCandless http://blog.mikemccandless.com On Sun, May 20, 2012 at 9:19 AM, Uwe Schindler wrote: > I killed that one because it was taking very long. See attached stack trace. > In fact it got a

Re: Minor typo in IndexReader and CompositeReader javadoc for trunk

Thanks Jack, I just committed the fix... Mike McCandless http://blog.mikemccandless.com On Mon, May 28, 2012 at 7:50 PM, Jack Krupansky wrote: > Minor typo in the javadoc for IndexReader.java and CompositeReader.java: > > DirectoryReader,open() > > (note the comma) > s.b. > > DirectoryReader.op

Re: mixing dv types in one IW session

I agree this inconsistency is bad... and silently losing stuff (float 2.5 becomes int 2) is really bad. We should do something before 4.0. I would prefer idea 2, i.e. that we never allow changing/promoting a DV type for a given field, and that we do our best to throw clear exc if you do so. I rea

Re: mixing dv types in one IW session

On Tue, May 29, 2012 at 12:31 PM, Robert Muir wrote: > On Tue, May 29, 2012 at 12:20 PM, Michael McCandless > wrote: >> I agree this inconsistency is bad... and silently losing stuff (float >> 2.5 becomes int 2) is really bad.  We should do something before 4.0. >> >&

Re: mixing dv types in one IW session

On Tue, May 29, 2012 at 3:00 PM, Robert Muir wrote: > On Tue, May 29, 2012 at 2:29 PM, Simon Willnauer > wrote: >> +1 I think we can easily build a "global" view of DV types like we do >> for field numbers and be consistent across DWPT > > if we do this, i would rather extend the fieldnumbers and

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

This test intentionally allocates ~256 MB packed ints ... the seed doesn't fail in isolation, but I think the test fails if it's run with other tests that leave too much uncollectible stuff allocated in the heap ... Can we somehow mark that a test should be run in isolation (it's own new JVM)...?

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

On Thu, May 31, 2012 at 5:16 PM, Dawid Weiss wrote: >> This test intentionally allocates ~256 MB packed ints ... the seed >> doesn't fail in isolation, but I think the test fails if it's run with >> other tests that leave too much uncollectible stuff allocated in the >> heap ... > > It doesn't nee

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

On Thu, May 31, 2012 at 8:05 PM, Robert Muir wrote: > On Thu, May 31, 2012 at 5:51 PM, Michael McCandless > wrote: >> I think the best option is to ignore the OOME from this test case...? >> >> Mike McCandless >> > > I think thats fine for now, but I'm n

seeing stdout when running "ant test"?

It looks like we redirect stdout somewhere when we run "ant test"? I don't see my sops coming out in that case but if I run a single test case, I do see them... Mike McCandless http://blog.mikemccandless.com - To unsubscri

Re: seeing stdout when running "ant test"?

Thanks Dawid! -Dtests.showSuccess=true is what I was looking for ... I'll add it to the wiki. Mike McCandless http://blog.mikemccandless.com On Sat, Jun 2, 2012 at 10:28 AM, Dawid Weiss wrote: >> It looks like we redirect stdout somewhere when we run "ant test"?  I >> don't see my sops coming

Re: seeing stdout when running "ant test"?

On Sat, Jun 2, 2012 at 11:37 AM, Dawid Weiss wrote: >> Thanks Dawid!  -Dtests.showSuccess=true is what I was looking for ... >> I'll add it to the wiki. > > Thanks, I'm wiki-challenged. There is also command-line help readily > available if you type: > > ant test-help > >     [echo] # Include addi

Re: [JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 744 - Failure!

Hmm I'll dig ... Mike McCandless http://blog.mikemccandless.com On Tue, Jun 5, 2012 at 2:11 PM, wrote: > Build: > http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/744/ > > 1 tests failed. > REGRESSION:  org.apache.lucene.search.TestSearcherManager.testSearcherManager >

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2776 - Failure

I committed a fix. Mike McCandless http://blog.mikemccandless.com On Tue, Jun 5, 2012 at 1:27 PM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2776/ > > 1 tests failed. > REGRESSION:  org.apache.lucene.search.TestSearcherManager.testSea

Re: [JENKINS] Lucene-Solr-trunk-Linux-Java7-64 - Build # 176 - Failure!

I committed a fix! Mike McCandless http://blog.mikemccandless.com On Tue, Jun 5, 2012 at 4:51 PM, wrote: > Build: > http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/176/ > > 1 tests failed. > REGRESSION:  org.apache.lucene.search.TestNRTManager.testNRTManager > > Error

Re: remove "via"

+1 Mike McCandless http://blog.mikemccandless.com On Tue, Jun 5, 2012 at 6:40 PM, Robert Muir wrote: > Hello, > > Currently we do this in CHANGES.txt: > > LUCENE-: >  Fixed a horrible nasty bug. (Joe Contributor via John Doe Committer) > > I propose we remove "via " from CHANGES.txt. I don

Welcome Adrien Grand as a new Lucene/Solr committer

I'm pleased to announce that Adrien Grand has joined our ranks as a committer. He has been contributing various patches to Lucene/Solr, recently to Lucene's packed ints implementation, giving a nice performance gain in some cases. For example check out http://people.apache.org/~mikemccand/luceneb

Re: Confusing method names to get the size of objects

+1 to standardize on two names. It is confusing now! Mike McCandless http://blog.mikemccandless.com On Fri, Jun 8, 2012 at 6:20 AM, Adrien Grand wrote: > Hi, > > Lucene and Solr have a few classes that expose the size of their > instances, but with different method names. There are at least >

Re: [JENKINS] Lucene-Solr-trunk-Windows-Java6-64 - Build # 516 - Failure!

On Tue, Jun 12, 2012 at 10:24 PM, Yonik Seeley wrote: > I just checked in a fix (hopefully) for this. > The snap puller was creating a temp directory that only used down to > seconds precision.  I've changed it to milliseconds. Can this somehow be fixed to not rely on timestamps? Mike McCandles

Re: [JENKINS] Lucene-Solr-4.x-Linux-Java6-64 - Build # 101 - Failure!

I could never repro this but I think I found the cause (just committed the fix)... Mike McCandless http://blog.mikemccandless.com On Wed, Jun 13, 2012 at 6:45 AM, wrote: > Build: > http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java6-64/101/ > > 1 tests failed. > REGRESSION:  or

Re: [JENKINS] Lucene-Solr-4.x-Linux-Java6-64 - Build # 101 - Failure!

, Jun 13, 2012 at 11:17 AM, Dawid Weiss wrote: > Was it a race condition of some sort? Why do you think it wasn't > reproducible from the same seed? > > Dawid > > On Wed, Jun 13, 2012 at 5:04 PM, Michael McCandless > wrote: >> I could never repro this but I think I

Re: Corrupt index

Hi Itamar, One quick question: does Lucene.Net include the fixes done for LUCENE-1044 (to fsync files on commit)? Those are very important for an index to be intact after OS/JVM crash or power loss. More responses below: On Tue, Jun 12, 2012 at 8:20 PM, Itamar Syn-Hershko wrote: > I'm a Lucen

Re: [JENKINS] Lucene-Solr-4.x-Linux-Java6-64 - Build # 101 - Failure!

om for experimenting though -- with the right > instrumentation you could have thread traces and visualize these... > much like with the jvms/ tests we talked in the other thread. > > Next GSoC :) > > Dawid > > On Wed, Jun 13, 2012 at 6:11 PM, Michael McCandless > wrote: &g

Re: [JENKINS] Lucene-Solr-4.x-Linux-Java6-64 - Build # 101 - Failure!

On Wed, Jun 13, 2012 at 4:05 PM, Dawid Weiss wrote: > This would require some kind of quantified per thread time > allocation... It would, and would probably have to have control down in the OS and CPU. > and would most likely be ruined by any I/O or some other > kind of external stimuli? I th

Re: Corrupt index

On Wed, Jun 13, 2012 at 8:45 PM, Itamar Syn-Hershko wrote: > Mike, > > On Wed, Jun 13, 2012 at 7:31 PM, Michael McCandless > wrote: >> >> Hi Itamar, >> >> One quick question: does Lucene.Net include the fixes done for >> LUCENE-1044 (to fsync files on co

Re: Corrupt index

you committing the index regularly?  I only ask because I >> >>> can't >> >>> reproduce it myself by forcibly terminating the process while it's >> >>> indexing.  I've tried both 3.0.3 and 2.9.4.  If I don't commit at all >> >&

Re: Corrupt index

see a lot of segments created and merged > while it operates. Expected? > > Reminding you, this is 2.9.4 / 3.0.3 > > On Fri, Jun 15, 2012 at 3:10 AM, Michael McCandless > wrote: >> >> Right: Lucene never autocommits anymore ... >> >> If you create a new

Re: Corrupt index

nd as again, if I kill the process and try to open the index with Luke 3.3, > the index folder is being wiped out. > > Not sure what to make of all that. > > On Fri, Jun 15, 2012 at 3:21 AM, Michael McCandless > wrote: >> >> Hmm, OK: in 2.9.4 / 3.0.x, if you open IW on a

Re: [JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 963 - Failure!

I'll dig. Mike McCandless http://blog.mikemccandless.com On Tue, Jun 19, 2012 at 3:24 AM, Dawid Weiss wrote: > This is an OOM. > > Dawid > > On Tue, Jun 19, 2012 at 9:01 AM, Policeman Jenkins Server > wrote: >> Build: >> http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64

Re: [JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 963 - Failure!

dless.com On Tue, Jun 19, 2012 at 7:00 AM, Michael McCandless wrote: > I'll dig. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Tue, Jun 19, 2012 at 3:24 AM, Dawid Weiss > wrote: >> This is an OOM. >> >> Dawid >> >> On

Re: [JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 963 - Failure!

omething (a > lot) printed to sysout it may be the rinner's buffering causing this. I have > it on the list of thngs to fix. > > On Jun 19, 2012 2:03 PM, "Michael McCandless" > wrote: >> >> I think this is because we are getting MemoryPostingsFormat

Re: [JENKINS] Lucene-Solr-tests-only-4.x - Build # 136 - Failure

I'll take this ... same situation as TestJapaneseTokenizer. Mike McCandless http://blog.mikemccandless.com On Tue, Jun 19, 2012 at 3:37 PM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/job/Lucene-Solr-tests-only-4.x/136/ > > 1 tests failed. > REGRESSION:   > org.apache.lucen

Re: [JENKINS] Lucene-Solr-tests-only-4.x - Build # 136 - Failure

men > http://www.thetaphi.de > > > > Michael McCandless schrieb: >> >> I'll take this ... same situation as TestJapaneseTokenizer. >> >> Mike McCandless >> >> http://blog.mikemccandless.com >> >> >> On Tue, Jun 19, 2012 at 3:37 PM, Apa

Re: Continuous stream indexing and time-based segment management

If you are willing/able to close the IndexWriter, it's easy to drop segments by reading the SegmentInfos, editing, and writing back. Mike McCandless http://blog.mikemccandless.com On Tue, Jun 19, 2012 at 3:44 PM, Simon Willnauer wrote: > On Tue, Jun 19, 2012 at 6:42 PM, mark harwood wrote: >>

Re: svn commit: r1351829 - in /lucene/dev/trunk/lucene: analysis/kuromoji/src/test/org/apache/lucene/analysis/ja/TestJapaneseTokenizer.java test-framework/src/java/org/apache/lucene/analysis/BaseToken

Ahhh good point: using the annotation, LuceneTestCase will simply pick a codec that's allowed, and the test runs. But using an Assume somewhere inside means ... LuceneTestCase can pick the "wrong" codec and then silently the test doesn't run. And, I hadn't realized I can add the annot to BaseToke

Re: svn commit: r1351829 - in /lucene/dev/trunk/lucene: analysis/kuromoji/src/test/org/apache/lucene/analysis/ja/TestJapaneseTokenizer.java test-framework/src/java/org/apache/lucene/analysis/BaseToken

On Tue, Jun 19, 2012 at 6:18 PM, Robert Muir wrote: > On Tue, Jun 19, 2012 at 6:13 PM, Michael McCandless > wrote: >> Ahhh good point: using the annotation, LuceneTestCase will simply pick >> a codec that's allowed, and the test runs. >> >> But usi

Re: [JENKINS] Lucene-Solr-trunk-Windows-Java6-64 - Build # 582 - Failure!

I committed a fix. Mike McCandless http://blog.mikemccandless.com On Wed, Jun 20, 2012 at 11:25 AM, Policeman Jenkins Server wrote: > Build: > http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/582/ > > 1 tests failed. > REGRESSION:   > org.apache.lucene.index.TestDeleti

Re: Welcome Greg Bowyer

Welcome Greg! Mike McCandless http://blog.mikemccandless.com On Thu, Jun 21, 2012 at 6:56 AM, Erick Erickson wrote: > I'm pleased to announce that Greg Bowyer has been added as a > Lucene/Solr committer. > > Greg: > It's a tradition that you reply with a brief bio. > > Your SVN access should be

Re: Build failed in Jenkins: Lucene-Core-4x-Beasting #6762

I committed a fix: rev 1353004 Mike McCandless http://blog.mikemccandless.com On Fri, Jun 22, 2012 at 6:18 AM, wrote: > See > > -- > [...truncated 894 lines...] >   [junit4] Suite: org

Re: Checksum mismatch in segments file

Hmm, the checksum is there to ensure all bits were persisted properly. But one trickiness is we first write 4 0 bytes, then seek back and write the checksum over those 4 bytes. Could it be that the HBase IndexOutput impl can't handle seeking back and overwriting? If so, you should have a look at

Re: JIRA problem

You get this error just in loading the "Attach files" page for LUCENE-2699? (Ie before even trying to attach a file?). If so, I'm able to load the page just fine... (But I haven't tried actually attaching something). Mike On Wed, Oct 13, 2010 at 12:19 PM, Steven A Rowe wrote: > When I try to

Re: Additional Hudson Jobs for tests only running all the time

This is most excellent :) Mike On Wed, Oct 13, 2010 at 11:00 AM, Simon Willnauer wrote: > On Wed, Oct 13, 2010 at 11:02 AM, Uwe Schindler wrote: >> Hi all, >> >> Robert and me setup two new combined (Lucene+Solr each) Hudson jobs that >> only compile Lucene/Solr with correct JVMs and then run t

Re: JIRA problem

-- >> > > From: Steven A Rowe [mailto:sar...@syr.edu] >> > > Sent: Wednesday, October 13, 2010 6:35 PM >> > > To: dev@lucene.apache.org >> > > Subject: RE: JIRA problem >> > > >> > > Sorry, no, I get the normal At

Re: Test failure: IndexWriterTest.testOptimizeTempSpaceUsage

Indeed, me too. Heh it's SimpleText codec. I'll take it... Mike On Fri, Oct 15, 2010 at 12:37 AM, Steven A Rowe wrote: > This fails consistently for me: > >    [junit] Testsuite: org.apache.lucene.index.TestIndexWriter >    [junit] Testcase: > testOptimizeTempSpaceUsage(org.apache.lucene.inde

odd VelocityResponseWriterTest failure...

Does anyone else see this failure? It must be a JAR classpath issue? Ie the test is compiled against one JAR but then run against another that's missing this method...? ant test-core -Dtestcase=VelocityResponseWriterTest junit-sequential: [junit] Testsuite: org.apache.solr.velocity.Vel

Re: Build failed in Hudson: Lucene-Solr-tests-only-trunk #278

Is there some way to have Hudson send us briefer emails, instead of a large extract from the console log? EG the page it shows if you click through the URL is great: Test Result (6 failures / +6) org.apache.solr.TestGroupingSearch.testGroupingGroupSortingScore_basic org.apache.solr.TestG

Re: Build failed in Hudson: Lucene-Solr-tests-only-trunk #278

d in the > email. I always click on the link at the beginning of the mail, then click > on "Status" and then on the failed test. > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >>

Re: possible to filter the output to commits@ list????

On Mon, Oct 18, 2010 at 3:03 PM, Grant Ingersoll wrote: >  It was just a bit of a shocker for me the first time I did it and I see like > 30 files changed when I only changed one file. Me too. In fact I think it's ridiculous -- violates principle of least surprise. I shouldn't have to see suc

Re: Analyzer forcing tokenStream and reusableTokenStream to be final

Can't we have only one API? Call it .tokenStream and it's always reusable? What breaks? Remember the re-use is only w/in a thread. Each thread gets its own instance. Apps that for some reason cannot reuse even w/in a thread can always make a Field w/ the tokenStream pre-set? Mike On Tue, Oct

Re: possible to filter the output to commits@ list????

On Tue, Oct 19, 2010 at 3:29 PM, Grant Ingersoll wrote: > I will go take a look at it, but as far as I could tell, I merged at the top > level, but maybe IntelliJ does individual file merges and I wasn't aware of > it (I believe I said merge trunk to branch_3x and then picked which revisions >

Re: svn commit: r1025929 - /lucene/dev/trunk/lucene/src/java/org/apache/lucene/search/MultiTermQuery.java

Whoa, thanks for catching this Uwe! On Thu, Oct 21, 2010 at 8:21 AM, Uwe Schindler wrote: > Why did you change this at all? I would revert or fix as described. Because the current impl is wasteful, ie it does one too many .next() calls. I like your fix (move up the count/cache)... I'll commit.

Re: svn commit: r1025978 - /lucene/dev/trunk/lucene/src/java/org/apache/lucene/search/MultiTermQuery.java

Thanks Uwe! Mike On Thu, Oct 21, 2010 at 8:51 AM, wrote: > Author: uschindler > Date: Thu Oct 21 12:51:06 2010 > New Revision: 1025978 > > URL: http://svn.apache.org/viewvc?rev=1025978&view=rev > Log: > fix caching on Mike's last commit. Also remove counting at all. > > Modified: >     > lucene

Re: Using filters to speed up queries

Unfortunately, Lucene's performance with filters isn't great. This is because we now always apply filters "up high", using a leapfrog approach, where we alternate asking the filter and then the scorer to skip to each other's docID. But if the filter accepts "enough" (~1% in my testing) of the doc

nocommit committed in SolrCore.java

Anyone know what's up with this one? solr/src/java/org/apache/solr/core/SolrCore.java: // nocommit: why did solrconfig override core descriptor !? Can we remove it? Change to TODO? Mike - To unsubscribe, e-mail: dev-unsub

Re: nocommit committed in SolrCore.java

patch before committing. > > - Mark > > On 10/24/10 6:55 AM, Michael McCandless wrote: >> Anyone know what's up with this one? >> >> solr/src/java/org/apache/solr/core/SolrCore.java:      // nocommit: >> why did solrconfig override core descriptor

Re: nocommit committed in SolrCore.java

On Mon, Oct 25, 2010 at 2:12 AM, Chris Hostetter wrote: > > : Now we are nocommit-free on trunk & 3.x. > > FWIW: we can make hudson fail the build if "nocommit" is found anywhere in > the source. > > Just an idea if people are intersted. +1! I can do this easily w/ Python... but does hudson have

Re: Using filters to speed up queries

Here's the paper I was thinking of (Robert found this): http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.159.9682 ... eg note this sentence from the abstract: We show that the first implementation, based on a postprocessing approach, allows an arbitrary user to obtain information about

Re: nocommit committed in SolrCore.java

Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -----Original Message- >> From: Michael McCandless [mailto:luc...@mikemccandless.com] >> Sent: Monday, October 25, 2010 11:19 AM >> To: dev@lucene.apache.org >> Subj

Re: Lucene-Solr-tests-only-trunk - Build # 639 - Failure

I committed a fix... the test was asserting that the random index wasn't optimized but IW can "inadvertently" optimize... there's even an issue open about that! Mike On Wed, Oct 27, 2010 at 9:01 AM, Apache Hudson Server wrote: > Build: > http://hudson.zones.apache.org/hudson/job/Lucene-Solr-tes

Re: ArrayIndexOutOfBounds exception using FieldCache

> think we've got a problem, Houston. ;-) > > Karl > > -Original Message- > From: ext Michael McCandless [mailto:luc...@mikemccandless.com] > Sent: Wednesday, October 27, 2010 11:08 AM > To: dev@lucene.apache.org > Subject: Re: ArrayIndexOutOfBounds exc

Re: ArrayIndexOutOfBounds exception using FieldCache

Nice find Yonik! Mike On Thu, Oct 28, 2010 at 10:16 AM, Yonik Seeley wrote: > On Thu, Oct 28, 2010 at 6:15 AM,   wrote: >> Synched to trunk, blew away old indexes, reindexed, same behavior.  So I >> think we've got a problem, Houston. ;-) > > Hey Karl, can you try the following patch on trunk:

Re: ArrayIndexOutOfBounds exception using FieldCache

On Thu, Oct 28, 2010 at 11:05 AM, Simon Willnauer wrote: > On Thu, Oct 28, 2010 at 4:59 PM, Walter Underwood > wrote: >> How big is it? The Internet works pretty well for large files. > > Mike, pick the USB stick up during you next run :) Heh, next time :) Karl, this is one big field cache ent

Re: Lucene 3.0.3 Release Date

+1 to do the next bugfix release for 2.9.x and 3.0.x. In general I think whenever we backport an important bug fix (which, if we are backporting to 2.9.x/3.0.x, it's only because it is in fact important!), we should do the point release. I commented on LUCENE-2675... Mike On Fri, Oct 29, 2010 a

Re: Lucene 3.0.3 Release Date

on a not-current >  commit, do not overwrite "future" commits.  (Mike McCandless) We should backport this one -- admittedly a corner case, but, it can remove commits from your index... > * LUCENE-2533: fix FileSwitchDirectory.listAll to not return dups when >  primary & seco

Re: Lucene 3.0.3 Release Date

On Fri, Oct 29, 2010 at 9:01 AM, Tim Smith wrote: >  I suggest backporting lucene-2328 as well > > the memory leak grows based on the number of commits > if you are doing extremely frequent commits, the memory leak becomes a > sizable loss that cannot be reclaimed without restarting and may requir

Re: Lucene 3.0.3 Release Date

memory would grow to a very noticeable > size just due to the synch hash map > > i've been using the lucene-2328 patch on lucene 3.0.2 for some time now with > no issue > obviously, i would like to back out my custom overlays (and not have to port > them to 3.0.3) > >  -- Tim

Re: Unsynced flush in IW get reader

IIRC there was a deadlock issue if we make flush sync'd, because of the call to maybeMerge. Ie doFlush is sync'd but we cannot sync around the call to maybeMerge since it invokes mergeScheduler.merge. I think it may be because CMS waits, if there are too many merges already running, and we don't

Re: Unsynced flush in IW get reader

On Thu, Nov 4, 2010 at 4:08 PM, Jason Rutherglen wrote: > Ah, deadlock is no good.  Maybe we should add a comment explaining > what's going on. Good idea, I'll add a comment. > I was thinking maybe the merge cost could be the > issue, even though in most cases CMS'll be running the merges in the

Re: Lucene-Solr-tests-only-trunk - Build # 1071 - Still Failing

Sadly, yes, this is SimpleText's "speedup", heh. However, the OOM actually occurs when the RIW used by TestNRQ64 calls optimize on .close(). But, this optimize is unused since the test has already pulled its reader. I think a simple workaround would be to close the RIW but never let it call opti

Re: Lucene-Solr-tests-only-3.x - Build # 1355 - Still Failing

I just committed a fix for this one -- test expects no merging. Mike On Sun, Nov 14, 2010 at 1:27 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/1355/ > > 1 tests failed. > REGRESSION:  org.apache.lucene.index.TestIndexWriterReader.testAd

Re: Lucene-Solr-tests-only-3.x - Build # 1354 - Still Failing

I just committed fix for this one too... same deal. Mike On Sun, Nov 14, 2010 at 1:07 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/1354/ > > 1 tests failed. > FAILED:  org.apache.lucene.index.TestIndexWriterReader.testUpdateDocument > >

Re: mergeinfo commit mails, possible solution

+1 to turning off propchange emails. A trivial back-port now generates 9 emails! The number of bits I cause to fly across the planet by hitting the return key on my lonely computer is insane. Mike On Tue, Nov 16, 2010 at 9:55 AM, Grant Ingersoll wrote: > From #lucene IRC: > gsingers:sarowe and

Re: ASF Public Mail Archives on Amazon S3

Grant, public_p_r.tar seems to be missing? Is that intentional? Maybe some super-secret project inside there :) Mike On Thu, Oct 14, 2010 at 12:05 PM, Grant Ingersoll wrote: > Hi ORPers, > > I put up the complete ASF public mail archives as of about 3 weeks ago on > Amazon's S3 and have made t

Re: Welcome Adriano Crestani as Lucene/Solr committer!

Welcome Adriano! Happy Hacking, Mike On Thu, Nov 18, 2010 at 3:30 AM, Michael Busch wrote: >  The PMC has accepted Adriano Crestani as Lucene/Solr committer! > > Welcome on board, Adriano!! > >  Michael > > PS:  Adriano, it's tradition to introduce yourself here as a new committer! > :) > > ---

Re: Lucene-Solr-tests-only-trunk - Build # 1598 - Still Failing

I think we've made Hudson angry/tired. Mike On Fri, Nov 19, 2010 at 5:25 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/1598/ > > 1 tests failed. > FAILED:  org.apache.lucene.util.automaton.TestMinimize.testPerFieldCodec > > Error Messa

Re: Lucene-Solr-tests-only-3.x - Build # 1456 - Failure

It looks like this is caused by a long-standing missing synchronized in IndexWriter.addIndexes(IndexReader[]). I'll open an issue... Mike On Tue, Nov 16, 2010 at 9:12 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/1456/ > > 1 tests fail

Re: Lucene-Solr-tests-only-trunk - Build # 1627 - Failure

I've got a fix for this (in my patch on LUCENE-2762 -- I'll go commit this!). It's a false test failure... it's because the test really requires no merging, but, w/ random config it sometimes gets a merge. Mike On Fri, Nov 19, 2010 at 8:28 PM, Uwe Schindler wrote: > I can reproduce this failure

Re: Lucene-Solr-tests-only-trunk - Build # 1652 - Still Failing

I just committed a fix for this one... Mike On Sat, Nov 20, 2010 at 2:59 PM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/1652/ > > 1 tests failed. > REGRESSION:   > org.apache.lucene.index.TestIndexWriterOnDiskFull.testAddDocumentOnDiskF

Re: Lucene-Solr-tests-only-3.x - Build # 1645 - Failure

I just committed a fix... was just a test bug (it depended on merge selection). Mike On Sun, Nov 21, 2010 at 2:43 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/1645/ > > 1 tests failed. > REGRESSION:   > org.apache.lucene.index.TestIndex

Re: Lucene-Solr-tests-only-3.x - Build # 1645 - Failure

I just committed a fix... was just a test bug (it depended on merge selection). Mike On Sun, Nov 21, 2010 at 2:43 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/1645/ > > 1 tests failed. > REGRESSION:   > org.apache.lucene.index.TestIndex

Re: Lucene-Solr-tests-only-trunk - Build # 1682 - Still Failing

I committed a fix... test only bug. Mike On Sun, Nov 21, 2010 at 8:30 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/1682/ > > 1 tests failed. > REGRESSION:  org.apache.lucene.util.TestBytesRefHash.testAdd > > Error Message: > expected:

Re: need some advice for modifying index format which supporting PForDelta compression/decompression

Are you sure you can't use trunk? Swapping in PForDelta as a codec is much easier and we are wanting to do that, anyway (as a hybrid codec w/ Pulsing as well), before releasing 4.0 :) Partial decode of PForDelta is challenging I think... because the exceptions are a linked list, you have to walk

Re: Ready to start Release process for Apache Lucene 2.9.4 and 3.0.3?

I just opened 2782 which I think we should back-port... I should finish today. Mike On Sat, Nov 27, 2010 at 1:10 PM, Uwe Schindler wrote: > I think we are ready to start the release process for the 2.9 and 3.0 series > of Apache Lucene? Anything against that like unresolved issues? If nobody > w

Re: Ready to start Release process for Apache Lucene 2.9.4 and 3.0.3?

I committed... let's release!! Mike On Sat, Nov 27, 2010 at 2:53 PM, Uwe Schindler wrote: > Ok. > > Uwe > > > > "Michael McCandless" schrieb: > >>I just opened 2782 which I think we should back-port... I should finish >>today. >> &

Re: PMC Additions

Welcome Simon and Koji! Mike On Sun, Nov 28, 2010 at 7:30 AM, Grant Ingersoll wrote: > I'm pleased to announce the addition of Simon Willnauer and Koji Sekiguchi to > the Lucene PMC.  Both Simon and Koji have been long time > contributors/committers to both Lucene and Solr. > > Congrats! > > -

Re: Lucene-Solr-tests-only-3.x - Build # 1917 - Failure

This is a false failure -- test was assuming own an IW and adding 3 docs results in an optimized index -- how silly ;) I just committed a fix. Mike On Sun, Nov 28, 2010 at 1:12 PM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/1917/ > > 1 t

Re: Lucene-Solr-tests-only-3.x - Build # 1950 - Failure

I ran my while(1) test for 4.5 hours and no failure! The failure is odd... because the test had just tested TermRangeFilter w/ includeUpper and includeLower both true, and it passed (10001 matches). Then it runs same query, but changing includeUpper to false, expecting 1 matches, but it got o

Re: Lucene-Solr-tests-only-3.x - Build # 1950 - Failure

On Mon, Nov 29, 2010 at 2:20 PM, Yonik Seeley wrote: > On Mon, Nov 29, 2010 at 1:30 PM, Michael McCandless > wrote: >> I ran my while(1) test for 4.5 hours and no failure! >> >> The failure is odd... because the test had just tested TermRangeFilter >> w/ includeUp

Re: Lucene-Solr-tests-only-3.x - Build # 1966 - Failure

I committed a fix. I had already fixed this on trunk and I thought I had merged the fix back to 3.x but missed one file... Mike On Mon, Nov 29, 2010 at 7:51 PM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/1966/ > > 1 tests failed. > REGRE

Re: deprecating Versions

On Sat, Nov 27, 2010 at 3:44 PM, Earwin Burrfoot wrote: > I think we should deprecate and remove Version constants as Lucene progresses? > > Imagine there's a number of features in 4.x that get deprecated and > un-defaulted in 5.x, then removed in 6.x > Our user compiled with Version.4_0, it was c

Re: Changes Mess

So, going forward... When committing an issue that needs a changes entry, where are we supposed to put it? EG if it's a bug fix that we'll backport all the way to 2.9.x... where does it go? If it's a new feature/API that's going to 3.x and trunk... only in 3.x's CHANGES? Mike On Wed, Dec 1, 20

Re: Consolidate MP and LMP

Hmm... but MegePolicy is our abstract base class, and LogMergePolicy adds alot of concrete stuff, ie choosing merges according to "level" so that you get an exponential staircase of segments in your index. Conceptually it seems like they are separate? Like if another merge policy came along that

Re: Consolidate MP and LMP

2010/12/2 Shai Erera : > Simon, sorry about that: MP = MergePolicy, LMP = LogMergePolicy. WTF = ... > well I know what that is :-). That one means "wow that's funny" right? Heh. Mike - To unsubscribe, e-mail: dev-unsubscr...@lu

Re: Consolidate MP and LMP

2010/12/2 Shai Erera : > Hmm .. now that I look closely at it, MP has useCompundFile/DocStore > methods, and LMP just adds getUseCompoundFile(). Why? > And IndexWriter.addIndexes(IndexReader...) queries instanceof LMP, instead > of calling mp.useCompoundFile()? Hmm I don't know. > So perhaps we

Re: Consolidate MP and LMP

On Thu, Dec 2, 2010 at 4:43 AM, Simon Willnauer wrote: > During the work on Column Stride Fields I was actually thinking that > Compound vs. Non-Compound should not be a global decision since we now > have codecs and each codec should use its own way of writing files. > Maybe it would make things

  1   2   3   4   5   6   7   8   9   10   >