[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.6.0_33) - Build # 258 - Failure!

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/258/ Java: 64bit/jdk1.6.0_33 -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfIndexWriterNotClosed Error Message: expected:<1> but was:<2> Stack Trace:

[jira] [Commented] (SOLR-3730) Rollback is not implemented quite right and can cause corner case fails in SolrCloud tests.

[ https://issues.apache.org/jira/browse/SOLR-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434803#comment-13434803 ] Mark Miller commented on SOLR-3730: --- So somehow this screwed up ref counting (which had a

[jira] [Commented] (SOLR-3730) Rollback is not implemented quite right and can cause corner case fails in SolrCloud tests.

[ https://issues.apache.org/jira/browse/SOLR-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434791#comment-13434791 ] Mark Miller commented on SOLR-3730: --- To clarify, the havoc was generally test havoc - Sol

[jira] [Updated] (SOLR-3730) Rollback is not implemented quite right and can cause corner case fails in SolrCloud tests.

[ https://issues.apache.org/jira/browse/SOLR-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3730: -- Priority: Minor (was: Major) > Rollback is not implemented quite right and can cause corner case fa

[jira] [Created] (SOLR-3730) Rollback is not implemented quite right and can cause corner case fails in SolrCloud tests.

Mark Miller created SOLR-3730: - Summary: Rollback is not implemented quite right and can cause corner case fails in SolrCloud tests. Key: SOLR-3730 URL: https://issues.apache.org/jira/browse/SOLR-3730 Pro

[jira] [Updated] (SOLR-3690) binary solr package isn't including lucene test-framework jar

[ https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-3690: --- Attachment: SOLR-3690.broken.jdoc.links.to.solrcore.patch SOLR-3690.patch bq. so this 'package

[jira] [Commented] (SOLR-3690) binary solr package isn't including lucene test-framework jar

[ https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434708#comment-13434708 ] Robert Muir commented on SOLR-3690: --- OK I was looking to 'show' the example on the websit

[jira] [Commented] (SOLR-3690) binary solr package isn't including lucene test-framework jar

[ https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434704#comment-13434704 ] Robert Muir commented on SOLR-3690: --- I can explain the screwed up unnecessary javadocs ho

[jira] [Updated] (SOLR-3690) binary solr package isn't including lucene test-framework jar

[ https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-3690: --- Attachment: SOLR-3690.patch Ok, patch ready for review. a few things to note: 1) adding the logic to solr-te

[jira] [Updated] (SOLR-2592) Pluggable shard lookup mechanism for SolrCloud

[ https://issues.apache.org/jira/browse/SOLR-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Garski updated SOLR-2592: - Attachment: SOLR-2592_r1373086.patch I've updated my patch which applies cleanly to r1373086. The

[jira] [Updated] (SOLR-3729) ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly

[ https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3729: - Description: I just happen to notice that (\*:\*) is not parsed properly by the edismax (Extended

[jira] [Updated] (SOLR-3729) ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly

[ https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3729: - Description: I just happen to notice that (\*:\*) is not parsed properly by the edismax (Extended

[jira] [Updated] (SOLR-3729) ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly

[ https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3729: - Description: I just happen to notice that (\*:\*) is not parsed properly by the edismax (Extended

[jira] [Updated] (SOLR-3729) ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly

[ https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3729: - Description: I just happen to notice that (\*:\*) is not parsed properly by the edismax (Extended

[jira] [Updated] (SOLR-3729) ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly

[ https://issues.apache.org/jira/browse/SOLR-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Krupansky updated SOLR-3729: - Description: I just happen to notice that (\*:\*) is not parsed properly by the edismax (Extended

[jira] [Created] (SOLR-3729) ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly

Jack Krupansky created SOLR-3729: Summary: ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly Key: SOLR-3729 URL: https://issues.apache.org/jira/browse/SOLR-3729 Project: Solr Issu

[jira] [Resolved] (SOLR-3572) Make Schema-Browser show custom similarities

[ https://issues.apache.org/jira/browse/SOLR-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Bowyer resolved SOLR-3572. --- Resolution: Fixed Fix Version/s: 4.0 Catching up with these things committed to trunk: 137311

Doc issue or bug? - only top-level query can be pure negative in standard Solr queries

The Solr query syntax wiki says that “Pure negative queries (all clauses prohibited) are allowed”, but this is only true at the top level – a pure negative query within parentheses gets evaluated in the same Boolean Query rather nested as a new BooleanQuery with a MUST for *:*. See: http://wiki

[jira] [Resolved] (LUCENE-4307) rename IR.getTopReaderContext to IR.getContext

[ https://issues.apache.org/jira/browse/LUCENE-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4307. - Resolution: Fixed Fix Version/s: 4.0 5.0 > rename IR.getTopReaderC

Re: disabling thread leak checks

> Yeah, I had a shell script looping "ant test" because of past issues > with tests.iters, but I haven't tried it lately... I think I commented on one of the issues related to OOMs -- you don't read my messages :) The recent update to the runner brings two of the features we once spoke about: 1)

Re: disabling thread leak checks

On Tue, Aug 14, 2012 at 4:08 PM, Dawid Weiss wrote: >> I'm only trying to run/loop a single test to reproduce a different problem. > > That's weird... I mean -- thread leaks are checked after a full suite > completes so a loop inside a test shouldn't matter (?). Anyway, you > can also try with -D

[jira] [Commented] (SOLR-3725) package-local-src-tgz target is pulling in non-source jars, dist/** and package/**

[ https://issues.apache.org/jira/browse/SOLR-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434466#comment-13434466 ] Michael Dodsworth commented on SOLR-3725: - Excellent. Thanks, Robert.

Re: disabling thread leak checks

> I'm only trying to run/loop a single test to reproduce a different problem. That's weird... I mean -- thread leaks are checked after a full suite completes so a loop inside a test shouldn't matter (?). Anyway, you can also try with -Dtests.iters unless you're really running gazillion iterations

Patch for SOLR-1093

Hi all, I have a patch for SOLR-1093. It isnt a complete solution but close. The sub queries are run serially as Lance Norskog mention's in his comment on 23/Dec/09. It has been very useful for us and would like

Re: disabling thread leak checks

On Tue, Aug 14, 2012 at 3:36 PM, Dawid Weiss wrote: > If you do ignore even one suite and it leaves threads behind then: I'm only trying to run/loop a single test to reproduce a different problem. > 1) it defeats the purpose of having those checks (and I really think > having background threads

Re: disabling thread leak checks

If you do ignore even one suite and it leaves threads behind then: 1) it defeats the purpose of having those checks (and I really think having background threads that do something after a suite completes is a Bad Thing (tm)). 2) it would hurt my feelings, really. I've put a lot of time and effort

disabling thread leak checks

I'm trying to debug other issues, but I can't seem to get past the new thread leak checks that cause the test case to fail. Is there a way to disable these checks? -Yonik http://lucidworks.com - To unsubscribe, e-mail: dev-unsubs

SolrTestCaseJ4: Can't avoid "collection1" convention

I've got some code that extends Solr and I use the Solr test framework for my tests. I upgraded from Solr 4 alpha to Solr 4 beta today, and it appears I am forced to put my test solr home directory in solr/collection1 rather than just plain solr/ (relative to my test classpath). I looked thro

Bug: edismax doesn't parse (*:*) properly

I just happen to notice that (*:*) is not parsed properly by edismax in 4.0-beta. It appears to require spaces before and after the *:*, otherwise it treats the colon as part of a wildcard term (see the escaping below). I haven’t tried other releases yet. Some variations I tried: (*:*) (*:*) (

Re: Guava RateLimiter possible replacement

Very cool! Much more sophisticated than ours ... eg it's not "instantaneous". Mike McCandless http://blog.mikemccandless.com On Tue, Aug 14, 2012 at 12:21 PM, Jason Rutherglen wrote: > Guava (Apache licensed) has a RateLimiter [1] class with additional options > available. > > 1. > http://code

Re: A lucene performance test

Am Tue, 14 Aug 2012 09:05:47 -0400 schrieb Robert Muir: > But If you just want to make changes visible to searches, you can open > your reader from IndexWriter (see the NRT ctor) and call openIfChanged > to refresh the view when you need. Ahhh - I know this, but we currently stay with separate pr

Re: Improve OOTB behavior: English word-splitting should default to autoGeneratePhraseQueries=true

On Tue, Aug 14, 2012 at 1:19 PM, Chris Hostetter wrote: 0D ( － ) FULLWIDTH HYPHEN-MINUS > > ...so seemingly, according to the word boundary docs, there should be an > option to treat those individual characters as "MidLetter" characters w/o > requiring the user to change them to \u2027 in a CharFi

Re: Improve OOTB behavior: English word-splitting should default to autoGeneratePhraseQueries=true

: But it really depends on how you want your whole analysis process to : work. e.g. in the above example if you want to treat "foo-bar" as : really equivalent to foobar, or you want to treat U.S.A as equivalent Unless i'm missreading the Word Boundary doc, the point of these types of tailorings

Re: Improve OOTB behavior: English word-splitting should default to autoGeneratePhraseQueries=true

I had forgotten about this but I agree it could also be used to handle challenging tokenizations. In general I think our Tokenizers should throw away as little information as possible (at least have options to do so). Subsequent TokenFilters can always remove things ... I agree there's a risk of

[jira] [Updated] (SOLR-3441) Make ElisionFilterFactory MultiTermAware

[ https://issues.apache.org/jira/browse/SOLR-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-3441: --- Fix Version/s: 4.0 adjusting this for 4.0 visibility > Make ElisionFilterFactory Mult

[jira] [Commented] (SOLR-3441) Make ElisionFilterFactory MultiTermAware

[ https://issues.apache.org/jira/browse/SOLR-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434253#comment-13434253 ] Jack Krupansky commented on SOLR-3441: -- It would be nice if this could be committed.

RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 421 - Still Failing!

Additionally, I disabled IBM J9 test runs (all word sizes and JDK versions) for now. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Tuesday, August 14, 2

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 421 - Still Failing!

one thing i tried when playing around (which might help) is to try to reproduce 'entire test run' with the master junit seed (the one printed after "Junit says hello") if you have the same SVN revision number and use this same seed and same # tests.jvms it will allocate all tests to the same slave

RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 421 - Still Failing!

Hi, I tried to reproduce this, it seems impossible to me. Without some helpful IBM support we cannot fix this. I tried everything in the guide (http://goo.gl/1jr5E, setting count to 0 or 1 to compile ASAP for both JIT and AOT), but the test does not fail at all with given seed. I checked, Codec

[jira] [Commented] (SOLR-3690) binary solr package isn't including lucene test-framework jar

[ https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434233#comment-13434233 ] Robert Muir commented on SOLR-3690: --- that sounds good. then we get consistency. separatel

RE: Improve OOTB behavior: English word-splitting should default to autoGeneratePhraseQueries=true

Another possibility that would increase customizability via exposing information we currently throw away, proposed by Mike McCandless on LUCENE-3940[1] (though controversially[2]): in addition to tokenizing alpha/numeric char sequences, StandardTokenizer could also tokenize everything else. Th

[jira] [Commented] (SOLR-3690) binary solr package isn't including lucene test-framework jar

[ https://issues.apache.org/jira/browse/SOLR-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434230#comment-13434230 ] Hoss Man commented on SOLR-3690: bq. It would be good to think about: ideally in the future

Re: Lucene.Net 3.0.3 and medium trust

It must be something we've missed, as we want to target medium trust locations in the future. I can't think of anything off the top of my head that would require medium trust, though, let alone unmanaged code. I'll dive into this. Thanks, Christopher On Mon, Aug 13, 2012 at 10:01 PM, Simon Sve

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 421 - Still Failing!

I've had some failures related to threads too... it'd be really nice if there was a public issue tracking system for J9 -- it's valuable for the product after all (and those free testers...). Dawid On Tue, Aug 14, 2012 at 5:08 PM, Michael McCandless wrote: > Hmm I've also hit test failures w/ J9

[jira] [Commented] (LUCENE-4307) rename IR.getTopReaderContext to IR.getContext

[ https://issues.apache.org/jira/browse/LUCENE-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434180#comment-13434180 ] Uwe Schindler commented on LUCENE-4307: --- +1 > rename IR.getTopRead

[jira] [Commented] (LUCENE-4307) rename IR.getTopReaderContext to IR.getContext

[ https://issues.apache.org/jira/browse/LUCENE-4307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434179#comment-13434179 ] Michael McCandless commented on LUCENE-4307: +1 > rename IR.

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/ibm-j9-jdk7) - Build # 421 - Still Failing!

Hmm I've also hit test failures w/ J9 64 bit that look likely to be a JVM bug: ant test -Dtestcase=TestJapaneseTokenizer -Dtests.method=testRandomHugeStringsMockGraphAfter -Dtests.seed=B8EC1E1E5DE1E925 -Dtests.slow=true -Dtests.locale=tr -Dtests.timezone=Pacific/Chatham -Dtests.file.encoding=UTF-

[jira] [Assigned] (SOLR-2747) Include formatted Changes.html for release

[ https://issues.apache.org/jira/browse/SOLR-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe reassigned SOLR-2747: - Assignee: Steven Rowe > Include formatted Changes.html for release > -

[jira] [Commented] (SOLR-2747) Include formatted Changes.html for release

[ https://issues.apache.org/jira/browse/SOLR-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434133#comment-13434133 ] Robert Muir commented on SOLR-2747: --- The script in general seems to almost work already.

[jira] [Updated] (SOLR-2747) Include formatted Changes.html for release

[ https://issues.apache.org/jira/browse/SOLR-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2747: -- Attachment: SOLR-2747.patch the start to a patch: but I only did the build piece here just as an experim

[jira] [Commented] (LUCENE-3668) offsets issues with multiword synonyms

[ https://issues.apache.org/jira/browse/LUCENE-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434125#comment-13434125 ] Marc Sturlese commented on LUCENE-3668: --- I've tried this with solr-4-beta and seein

[jira] [Resolved] (LUCENE-4306) Make IR.getSequentialSubReaders() protected

[ https://issues.apache.org/jira/browse/LUCENE-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-4306. --- Resolution: Fixed Committed branch_4x revision: 1372871 > Make IR.getSequen

Re: A lucene performance test

On Tue, Aug 14, 2012 at 8:58 AM, Stefan Trcek wrote: > Am Tue, 14 Aug 2012 06:46:22 -0400 schrieb Robert Muir: > >> I think this benchmark is not really benchmarking writes at all, but >> instead the time it takes to wait for merges to complete. >> >> don't indexwriter.close() in your benchmark li

Re: A lucene performance test

Am Tue, 14 Aug 2012 06:46:22 -0400 schrieb Robert Muir: > I think this benchmark is not really benchmarking writes at all, but > instead the time it takes to wait for merges to complete. > > don't indexwriter.close() in your benchmark like this. Ok, but how to? As I understand the api I need at

[jira] [Commented] (LUCENE-4306) Make IR.getSequentialSubReaders() protected

[ https://issues.apache.org/jira/browse/LUCENE-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434092#comment-13434092 ] Uwe Schindler commented on LUCENE-4306: --- Committed trunk revision: 1372866 Backport

[jira] [Resolved] (LUCENE-4304) Remove PayloadProcessProvider

[ https://issues.apache.org/jira/browse/LUCENE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4304. - Resolution: Fixed Fix Version/s: 4.0 5.0 > Remove PayloadProcessPr

[jira] [Commented] (LUCENE-4306) Make IR.getSequentialSubReaders() protected

[ https://issues.apache.org/jira/browse/LUCENE-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434082#comment-13434082 ] Uwe Schindler commented on LUCENE-4306: --- OK, I changed the cocommit to a TODO and w

[jira] [Commented] (SOLR-2789) Add showItems to LRUCache, display extra details about cached data for both LRUCache and FastLRUCache

[ https://issues.apache.org/jira/browse/SOLR-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434079#comment-13434079 ] Markus Jelsma commented on SOLR-2789: - This issue is not resolved but it's documented a

[jira] [Commented] (LUCENE-4306) Make IR.getSequentialSubReaders() protected

[ https://issues.apache.org/jira/browse/LUCENE-4306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434061#comment-13434061 ] Robert Muir commented on LUCENE-4306: - I dont think renaming it accomplishes anything

[ANNOUNCE] Apache Solr 4.0-beta released.

14 August 2012, Apache Solr™ 4.0-beta available The Lucene PMC is pleased to announce the release of Apache Solr 4.0-beta. Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, fa

[ANNOUNCE] Apache Lucene 4.0-beta released.

14 August 2012, Apache Lucene‚ 4.0-beta available The Lucene PMC is pleased to announce the release of Apache Lucene 4.0-beta Apache Lucene is a high-performance, full-featured text search engine library written entirely in Java. It is a technology suitable for nearly any application that requires

[jira] [Commented] (LUCENE-4304) Remove PayloadProcessProvider

[ https://issues.apache.org/jira/browse/LUCENE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434053#comment-13434053 ] Robert Muir commented on LUCENE-4304: - I think MIGRATE.txt is overkill here. This was

Re: A lucene performance test

I think this benchmark is not really benchmarking writes at all, but instead the time it takes to wait for merges to complete. don't indexwriter.close() in your benchmark like this. On Tue, Aug 14, 2012 at 6:44 AM, Stefan Trcek wrote: > Results for lucene-4.0.0-alpha: > > * Write performance dec

Re: A lucene performance test

Results for lucene-4.0.0-alpha: * Write performance decreased by a factor of about 2. * Index size increased by a factor 1.3 * Search speed increased by a factor 1.6 (1m requests, 10m entries) or even more * The ultra high performance for small indexes decreased. But this doesn't matter. *

Re: A lucene performance test

Now using lucene-4.0.0-alpha As the index size increased the indexes do not fit into IO cache. So I dropped the biggest index for searching. $ java misc.LuceneKeyValuePerformance write WRITING #entries seconds entries/s 1000 0,40 2520 2000 0,29 6863

Re: A lucene performance test

On Mon, 2012-08-13 at 17:36 +0200, Stefan Trcek wrote: > * There must be 2 "caches" in the system: The performance degrades > significantly beyond 1000 and again beyond 20 documents > in the index. With 1000 records, everything is in level 2 cache and a lot in level 1, which makes it blazi

[jira] [Commented] (LUCENE-4304) Remove PayloadProcessProvider

[ https://issues.apache.org/jira/browse/LUCENE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13433949#comment-13433949 ] Uwe Schindler commented on LUCENE-4304: --- +1 to commit. Can we also add a MIGRATE.tx