Re: Annotation for "run this test, but don't fail build if it fails" ?

On Fri, May 4, 2012 at 6:29 PM, Chris Hostetter wrote: > > Dawid: > > With the new test runner you created, would it be possible to setup an > annotation that we could use instead to indicate that a test should in fact > be run, and if it fails, include the failure info in the build report, but >

Re: Annotation for "run this test, but don't fail build if it fails" ?

On Sun, May 6, 2012 at 2:39 PM, Dawid Weiss wrote: > Any ideas? Hoss -- how do you envision "monitoring" of these tests? Manually? If the tests are run many times a day, it would be great to get a daily report of the percent of time the tests pass. Then if it goes from 5% to 50%, we can go uh-oh

Re: Annotation for "run this test, but don't fail build if it fails" ?

On Sun, May 6, 2012 at 3:38 PM, Dawid Weiss wrote: > I also admit I've never seen anything like > this -- a suite of tests with an allowed failure ratio over time and a > threshold that would trigger a warning... Not so much an "allowed" failure rate... more of "it fails sometimes and no one has

Re: Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #80

Hmmm, this is strange. Looking into it... -Yonik http://lucidimagination.com On Mon, May 21, 2012 at 8:54 PM, wrote: > See > > > Changes: > > [yonik] SOLR-3469: prevent false peersync recovery by recording

Re: Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #80

On Mon, May 21, 2012 at 8:57 PM, Yonik Seeley wrote: > Hmmm, this is strange. > Looking into it... Oops, spoke too soon. At a glance I mistook the list of file changes for the list of failed tests. - To unsubscribe,

Re: Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #175

On Thu, May 24, 2012 at 12:50 AM, Mark Miller wrote: > As far as I can tell, this appears to perhaps be a windows issue with > replication - if the logged errors are involved, it's not finding a file to > copy that it's expecting to find. Search me as to why. Certainly seems to be > finding the

Re: Welcome Adrien Grand as a new Lucene/Solr committer

Congrats Adrien! -Yonik http://lucidimagination.com On Thu, Jun 7, 2012 at 2:11 PM, Michael McCandless wrote: > 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 impleme

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

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. -Yonik http://lucidimagination.com On Tue, Jun 12, 2012 at 5:40 PM, wrote: > Build: > http://jenkins.sd-datasolutions.de/job/

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

On Wed, Jun 13, 2012 at 7:58 AM, Michael McCandless wrote: > 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&#x

Re: Welcome Greg Bowyer

Welcome! -Yonik http://lucidimagination.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 set up and ready

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

On Mon, Jun 25, 2012 at 3:04 PM, Robert Muir wrote: > On Mon, Jun 25, 2012 at 2:59 PM, Policeman Jenkins Server > wrote: > >> Caused by: java.lang.ArrayIndexOutOfBoundsException: 8192 >>        at >> com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(UTF8Reader.java:543) > > LOL Their r

Re: Is this warning expected?

On Thu, Oct 14, 2010 at 5:18 AM, Shai Erera wrote: > I ran SOLR tests today and I've noticed this print appearing several times: > >     [junit] >     [junit] - Standard Error - >     [junit] 14.okt.2010 12:14:28 > org.apache.solr.common.util.ConcurrentLRUCache finalize

Re: Is this warning expected?

On Thu, Oct 14, 2010 at 10:34 AM, Robert Muir wrote: > On Thu, Oct 14, 2010 at 10:24 AM, Yonik Seeley > wrote: > >> I'll try and take another look after we get the test logging straitened out. >> > > we can turn back on forking for each solr test to workaround

solr test development

Maintaining and fixing tests in solr has been a pain - I think mostly because in the past we probably reviewed core code well, but perhaps not the test code. For test code, we should really strive for conciseness and maintainability. Most things should be tested through higher level requests, and

Re: svn commit: r1022989 - in /lucene/dev/trunk/solr/src/test: org/apache/solr/core/AlternateDirectoryTest.java test-files/solr/conf/solrconfig-altdirectory.xml

On Fri, Oct 15, 2010 at 12:19 PM, Robert Muir wrote: > Yonik, thanks for hammering away at these tests! > > Curious, were you planning on merging all your test improvements to > 3.x? If you dont have the time, let me know and I could help. Hmmm, I hadn't realized that we had switched to non-forki

Re: svn commit: r1022989 - in /lucene/dev/trunk/solr/src/test: org/apache/solr/core/AlternateDirectoryTest.java test-files/solr/conf/solrconfig-altdirectory.xml

-Yonik http://www.lucidimagination.com On Fri, Oct 15, 2010 at 12:41 PM, Robert Muir wrote: > On Fri, Oct 15, 2010 at 12:38 PM, Yonik Seeley > wrote: >> Hmmm, I hadn't realized that we had switched to non-forking for 3x too. >> I guess all that should be backported.  He

Re: solr test development

this: -Yonik http://www.lucidimagination.com On Fri, Oct 15, 2010 at 9:48 AM, Yonik Seeley wrote: > Maintaining and fixing tests in solr has been a pain - I think mostly > because in the past we probably reviewed core code well, but perhaps > not the test code.  For test code, we should

Re: svn commit: r1022335 - /lucene/dev/trunk/solr/src/test/org/apache/solr/BaseDistributedSearchTestCase.java

On Fri, Oct 15, 2010 at 5:21 PM, Robert Muir wrote: > because the hudson jail has 'tcp blackhole' set, tests should *never* > depend on connecting to a port not accepting connections and getting > an RST (it won't happen). > > Thats why this test takes 5 minutes now on hudson... we should fix > si

Re: svn commit: r1023129 - in /lucene/dev/branches/branch_3x/solr: common-build.xml src/test/org/apache/solr/core/IndexReaderFactoryTest.java

On Fri, Oct 15, 2010 at 6:05 PM, Robert Muir wrote: > can we keep the warnings enabled still in common-build? otherwise they > will never get fixed (and some might be real problems)! Sure - accidental commit. I needed to turn them off to find where the compile error was ;-) -Yonik http://www.lu

default connection timeout for distributed search

I *think* we don't currently have a connection timeout for distributed search (i.e. the connections that solr makes to other solr servers). We've made it configurable, but perhaps we should either have a better default, or actually set it in the example solrconfig.xml? -Yonik http://www.lucidimagi

Re: svn commit: r1023520 - /lucene/dev/trunk/solr/src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java

FYI, rather than spamming the list with backports, I'm going to start batching my backports to the 3x branch. All the svn:mergeinfo updates for even the smallest merge is a real nightmare. Merges to the 3x branch are practically unreadable since the real update is lost in the noise. -Yonik http:

Re: [jira] Commented: (SOLR-1311) pseudo-field-collapsing

On Sun, Oct 17, 2010 at 3:43 AM, Simon Willnauer wrote: > Lets keep things constructive here! +1 We should strive to think and talk in terms of improvements. As it relates to field collapsing, some of the existing patches were simply too big for me to get my arms around. I personally needed t

Re: SolrInfoMBeanTest

Ha - going through and instantiating a ton of random classes does sound like a good way to screw things up! +1 to disable. -Yonik http://www.lucidimagination.com On Sun, Oct 17, 2010 at 3:22 PM, Robert Muir wrote: > Can we disable this test? I don't understand the purpose of it, and it > seems

Re: svn commit: r1023621 - in /lucene/dev/trunk/solr/src/test: org/apache/solr/handler/component/SpellCheckComponentTest.java test-files/solr/conf/solrconfig-spellcheckcomponent.xml test-files/solr/co

On Sun, Oct 17, 2010 at 9:38 PM, wrote: > Author: rmuir > Date: Mon Oct 18 01:38:41 2010 > New Revision: 1023621 > > URL: http://svn.apache.org/viewvc?rev=1023621&view=rev > Log: > only spellchecker tests need create spellcheck indexes Thanks! I've been meaning to do that for a while now. -Yon

Re: svn commit: r1024305 - in /lucene/dev/trunk/solr/src/test/org/apache/solr/core: SolrCoreTest.java TestPropInjectDefaults.java

On Tue, Oct 19, 2010 at 12:24 PM, Uwe Schindler wrote: > Yonik, > > Just to reduce the work you have to do: With a subclass of LuceneTestCase, > you don't need to add @Test, as the internal test runner behaves like JUnit3 > and runs all public methods starting with "test" Ah cool, thanks for th

Re: svn commit: r1024335 - in /lucene/dev/trunk/solr: ./ src/common/org/apache/solr/common/util/ src/java/org/apache/solr/core/ src/java/org/apache/solr/request/ src/java/org/apache/solr/search/ src/t

ack - misplaced quote in my commit... I'll fix. -Yonik On Tue, Oct 19, 2010 at 1:42 PM, wrote: > Author: yonik > Date: Tue Oct 19 17:42:27 2010 > New Revision: 1024335 > > URL: http://svn.apache.org/viewvc?rev=1024335&view=rev > Log: > tests: src/test/org/apache/solr/util/SolrPluginUtilsTest.ja

Re: svn commit: r1025784 - in /lucene/dev: branches/branch_3x/solr/src/java/org/apache/solr/spelling/suggest/Suggester.java trunk/solr/src/java/org/apache/solr/spelling/suggest/Suggester.java

Looks like this caused the tests to fail... I've checked in a temporary fix: r1025794 -Yonik http://www.lucidimagination.com On Wed, Oct 20, 2010 at 6:28 PM, wrote: > Author: ab > Date: Wed Oct 20 22:28:52 2010 > New Revision: 1025784 > > URL: http://svn.apache.org/viewvc?rev=1025784&view=rev

Re: solr build fails with java 1.5

Solr trunk (4.0-dev) requires Java6, as does zookeeper, a new Solr dependency. Not much we can do about it. Java6 has been out for almost 4 years now though, so it's not an unrealistic requirement either. -Yonik http://www.lucidimagination.com On Sat, Oct 23, 2010 at 2:13 AM, abhayd wrote: > > h

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

Another downside to the current situation - "svn log" shows all these updates to the mergeprops, so we're losing the real updates in the noise. Maybe we should try to merge only from trunk to branch_3x, so at least trunk says relatively clean. Making sense of branch_3x is getting very difficult.

Re: ArrayIndexOutOfBounds exception using FieldCache

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: Index: lucene/src/java/org/apache/lucene/search/cache/DocTermsCreator.java ==

Re: inconsistency/performance trap of empty terms

On Sat, Oct 30, 2010 at 11:43 AM, Robert Muir wrote: > On Sat, Oct 30, 2010 at 11:40 AM, Earwin Burrfoot wrote: >> On Sat, Oct 30, 2010 at 18:49, Uwe Schindler wrote: >>> In my opinion, we should not have analyzers at all (just my personal >>> opinion). "new Field(name, TokenStream)" is much en

solr example synonyms file

Just saw this tweet: "Solr initial synonyms file has aaa pointing to . Inconvenient when someone is searching for AAA related items." I think I'll review that example synonyms file ;-) -Yonik http://www.lucidimagination.com

Re: svn commit: r1032995 - in /lucene/dev/trunk/solr/src/site/src/documentation/content/xdocs/images: solr.jpg solr_FC.eps

IMO, any changes to our logos should be voted on. -Yonik - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org

Re: svn commit: r1032995 - in /lucene/dev/trunk/solr/src/site/src/documentation/content/xdocs/images: solr.jpg solr_FC.eps

On Tue, Nov 9, 2010 at 3:33 PM, Grant Ingersoll wrote: > Sorry, no choice.  Comes down from the board that logos need TMs on them. IMO, it's a little too much micromanagement (and IIRC not everyone agreed about logo TMs in the past). Have any pointers to more recent discussions for me? We can a

Re: svn commit: r1032995 - in /lucene/dev/trunk/solr/src/site/src/documentation/content/xdocs/images: solr.jpg solr_FC.eps

On Tue, Nov 9, 2010 at 3:51 PM, Grant Ingersoll wrote: > See the mail to the PMC on Branding Requirements and the associated website. I guess I was looking for something more specific. I followed a lot of the previous discussions on trademark stuff - I just missed the transition point where it be

Re: svn commit: r1032995 - in /lucene/dev/trunk/solr/src/site/src/documentation/content/xdocs/images: solr.jpg solr_FC.eps

On Tue, Nov 9, 2010 at 4:03 PM, Grant Ingersoll wrote: > Sorry, I figured the word "Requirements" in the title was pretty clear. I was seeking information on how this became an actual hard requirement, and if it actually was. It certainly wouldn't be the first time that something is listed as a r

Re: svn commit: r1032995 - in /lucene/dev/trunk/solr/src/site/src/documentation/content/xdocs/images: solr.jpg solr_FC.eps

FYI, I've followed up with trademarks@ -Yonik http://www.lucidimagination.com On Tue, Nov 9, 2010 at 4:06 PM, Yonik Seeley wrote: > On Tue, Nov 9, 2010 at 4:03 PM, Grant Ingersoll wrote: >> Sorry, I figured the word "Requirements" in the title was pretty clear. >

Re: svn commit: r1032995 - in /lucene/dev/trunk/solr/src/site/src/documentation/content/xdocs/images: solr.jpg solr_FC.eps

And FWIW, here's my bit of civil disobedience :-P http://yonik.wordpress.com/ -Yonik - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org

Re: svn commit: r1032995 - in /lucene/dev/trunk/solr/src/site/src/documentation/content/xdocs/images: solr.jpg solr_FC.eps

On Tue, Nov 9, 2010 at 4:58 PM, Grant Ingersoll wrote: > You can read it at http://www.apache.org/foundation/marks/pmcs I did - but just because it appears on a web page does not make it true. There have been *many* examples (and still are many examples) of things that are on our websites that a

Re: Index File Format change on trunk

Thanks for the heads-up... I tried not rebuilding the index on Solr just to see what type of exception I'd get: Caused by: java.lang.IllegalArgumentException: required codec 'tandardos Windows 7 os.version6.1sourceflushlucene.version34.0-SNAPSHOT 10' not found -Yonik http://www.lucidimagina

Re: Basic authentication for stream.url

On Tue, Nov 16, 2010 at 8:57 PM, Jayendra Patil wrote: > We intend to use schema.url for indexing documents. However, the remote urls > are secured and would need basic authentication to be able access the > document. > > The implementation with stream.file would mean to download the files and > w

Re: Is this misleading?

On Mon, Nov 22, 2010 at 9:42 AM, Erick Erickson wrote: > This *extremely* helpful page: > http://wiki.apache.org/solr/FieldOptionsByUseCase?highlight=(termvector)|(retrieve)|(contents) > Says: > 2. stored must always be true for highlighting. If you also add > both termVectors and termOffsets, thi

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

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/ includeUpper and includeLower both true, and it passed (10001 > matches). > > Then it runs same query, b

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

On Mon, Nov 29, 2010 at 2:52 PM, Michael McCandless wrote: > 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! >>> >>> Th

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

On Mon, Nov 29, 2010 at 2:52 PM, Michael McCandless wrote: > Though why doesn't the random seed reproduce it? OK, I think I see why. For reproducibility, the same random number generator should never be used across different threads. RandomIndexWriter does though... (via MockIndexWriter.testPoint

Re: svn commit: r1001318 - in /lucene/dev/trunk/solr: CHANGES.txt src/java/org/apache/solr/search/FunctionQParser.java src/test/org/apache/solr/search/QueryParsingTest.java src/test/org/apache/solr/se

On Thu, Dec 2, 2010 at 12:58 PM, Grant Ingersoll wrote: [...] > flds = sort.getSort(); > assertEquals(flds[0].getType(), SortField.FLOAT); > assertEquals(flds[0].getField(), "weight"); > - > -    try { > -  //bad number of parens, but the function parser can handle an extra > close

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

Well, darn upgrading jetty didn't seem to help this. -Yonik http://www.lucidimagination.com On Sun, Dec 5, 2010 at 7:05 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/2221/ > > 1 tests failed. > REGRESSION:  org.apache.solr.TestDi

Re: Testing UpdateProcessorChain

On Sun, Dec 5, 2010 at 3:28 PM, Grant Ingersoll wrote: > Anyone have any thoughts on testing UpdateProcessorChain (and Factory).  In > looking at the Signature (dedup) tests, it seems a little clunky, yet the > Solr base test class adoc (and related methods) don't seem to support > specifying t

Re: FieldCache usage for custom field collapse in solr 1.4

On Sun, Dec 5, 2010 at 6:12 PM, Adam H. wrote: > StringIndex fieldCacheVals = FieldCache.DEFAULT.getStringIndex(reader, > collapseField); > > where 'reader' is the instance of the SolrIndexReader passed along to the > component with the ResponseBuilder.SolrQueryRequest object. > > As I understand,

Re: FieldCache usage for custom field collapse in solr 1.4

On Mon, Dec 6, 2010 at 3:24 PM, Adam H. wrote: > Hey Yonik. > Thanks for clarifying. > The reason I went rolling my own way - I asked previously is there's any > plan to back-port the field collapse to solr 1.4 and > I understood that its not at all straight forward. Ahhh... I'd just use trunk if

Re: FieldCache usage for custom field collapse in solr 1.4

On Mon, Dec 6, 2010 at 3:41 PM, Adam H. wrote: > Fair enough - I might give it a shot if most functionality is compatible to > solr 1.4.1 to your mind? and is fairly stable? Yes, the external APIs are very compatible. The internal APIs - not so much. You should reindex also. > One last Q regardi

Re: FieldCache usage for custom field collapse in solr 1.4

On Mon, Dec 6, 2010 at 5:48 PM, Adam H. wrote: > In other words, using a per-segment fieldcache collection as a > post-processing step (e.g after QueryComponent did its collection) does not > seem at all trivial, if at all possible ( is it possible? ) Sure, it's possible, and not too hard (as lon

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

I wonder if this "No live SolrServers available" thing is caused by the NoHttpResponseException stuff from SOLR-2158... gotta try to get to the bottom of this! -Yonik http://www.lucidimagination.com On Wed, Dec 8, 2010 at 8:06 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/h

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

Hmmm, that's one I haven't seen before. I'll backport the jetty connector change I committed to trunk though - still crossing my fingers that it will solve most of these issues. -Yonik http://www.lucidimagination.com On Thu, Dec 9, 2010 at 3:19 PM, Apache Hudson Server wrote: > Build: https://

Re: Example documents and geospatial

On Thu, Dec 16, 2010 at 11:32 AM, Erick Erickson wrote: > The example docs we distribute have a bunch of stores that have the exact > same location. That lead to some head scratching about why changing the > distance in the example queries seemed to make no difference in the number > of returned r

Re: WARNING: re-index all trunk indices!

On Fri, Dec 17, 2010 at 11:18 AM, Michael McCandless wrote: > If you are using Lucene's trunk (nightly build) release, read on... > > I just committed a change (for LUCENE-2811) that changes the index > format on trunk, thus breaking (w/ likely strange exceptions on > reading the segments_N file)

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

oops... I think I ran "ant test" on the bulk branch instead of trunk before I checked this in. I'll fix. -Yonik http://www.lucidimagination.com On Thu, Dec 23, 2010 at 10:35 AM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/2899/ > > 1 t

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

Woops, when I saw clustering fail, I assumed it was due to the same failures yesterday. I'll add back the deprecated AnalysisRequestHandler for now. -Yonik http://www.lucidimagination.com On Fri, Dec 24, 2010 at 8:53 PM, Apache Hudson Server wrote: > Build: https://hudson.apache.org/hudson/job

Re: [jira] Commented: (SOLR-2218) Performance of start= and rows= parameters are exponentially slow with large data sets

On Thu, Nov 11, 2010 at 3:22 PM, Jan Høydahl / Cominvent wrote: > The problem with large "start" is probably worse when sharding is involved. > Anyone know how the shard component goes about fetching start=100&rows=10 > from say 10 shards? Does it have to merge sorted lists of 1mill+10 docsi

Re: FYI: Javadoc update needed re: omitTf

On Mon, Jan 3, 2011 at 2:03 PM, Simon Willnauer wrote: > While we are on it, would it make sense to move omitTfAP into the > Index enum. It always felt odd that you can omit norms using the enum > but use a setter to omit TF & Pos. I think the attempted move to type safety / enums is what added t

Re: LICENSE/NOTICE file contents

On Sat, Jan 8, 2011 at 8:10 AM, wrote: > From svn, Yonik seems to be the go-to guy for LICENSE and NOTICE stuff.   > Yonik, do you remember why the HSQLDB and Jetty notice text was included in > Solr's NOTICE.txt? Nope - wasn't me that added the license stuff into NOTICE.txt ;-) But, including

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

On Thu, Aug 9, 2012 at 6:49 AM, Michael McCandless wrote: > The text_general field type is meant to be a good default for all languages. What many of us not familiar with the tokenizing rules of the standard tokenizer just realized is that it's not a good default for english and probably most oth

Re: svn commit: r1371478 - /lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/TestSolrJ.java

On Thu, Aug 9, 2012 at 4:57 PM, Dawid Weiss wrote: >> -Random r = new Random(); >> +Random r = new Random(0); > > If you really want a local Random why not make it depend on the > current real seed? If anything, I'd rather have it the same each time. It's more for performance testing aga

Re: Proposal: Full support for multi-word synonyms at query time

On Fri, Aug 10, 2012 at 2:10 PM, Jack Krupansky wrote: > The Javadoc says "positionLength determines how many positions this token > spans". It's not obvious from the documentation how the full graph structure > for nested multi-word synonyms can be expressed merely using that attribute. > Is this

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

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

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

Re: null:java.lang.ArrayIndexOutOfBoundsException with solr-trunk

This is really strange - I just reviewed the code in question, and it looks fine. Could you open a JIRA issue for this? -Yonik http://lucidworks.com On Fri, Aug 17, 2012 at 4:28 PM, Ahmet Arslan wrote: > Hi All, > > I am indexing aspx files into solr-trunk (using ManifoldCF). And I am getting >

Re: null:java.lang.ArrayIndexOutOfBoundsException with solr-trunk

Actually, this must be due to SOLR-3715, I'll re-open that issue. -Yonik http://lucidworks.com On Fri, Aug 17, 2012 at 5:04 PM, Yonik Seeley wrote: > This is really strange - I just reviewed the code in question, and it > looks fine. > Could you open a JIRA issue for this? >

Re: null:java.lang.ArrayIndexOutOfBoundsException with solr-trunk

Thanks for the report Ahmet, I just checked in a fix for this bug. -Yonik http://lucidworks.com On Fri, Aug 17, 2012 at 5:11 PM, Yonik Seeley wrote: > Actually, this must be due to SOLR-3715, I'll re-open that issue. > > -Yonik > http://lucidworks.com > > > On Fr

Re: Maven and IntelliJ (but not Ant) compilation fails on branch_4x and trunk using Java6; Java7 works for all

On Wed, Aug 22, 2012 at 4:24 PM, Steven A Rowe wrote: > On Win7, I'm getting compilation failures on branch_4x and trunk, under Maven > (2.2.1 and 3.0.4) and IntelliJ (11.1.3). Under Ant (1.8.2), compilation > succeeds. I've tried Oracle JDK 1.6.0_21 and 1.6.0_34, both 64-bit, and both > beha

Re: large messages from Jenkins failures

On Tue, Aug 28, 2012 at 2:43 PM, Dawid Weiss wrote: > 2) I think Solr emits a LOT of logging information to the console. I > don't know if all of it is really useful -- I doubt it, really. > > The solutions I see are simple -- disable the tests that fail 3-5 > times and we still don't know what ca

Re: large messages from Jenkins failures

On Mon, Aug 20, 2012 at 2:22 PM, Dawid Weiss wrote: > Oh, one more thing -- if we suppress the console output we would > absolutely have to keep (at jenkins) multiple tests-report.txt files > because these always contain full output dumps (regardless of console > settings). Otherwise we'd suppress

Re: large messages from Jenkins failures

On Tue, Aug 28, 2012 at 3:57 PM, Dawid Weiss wrote: > I don't agree with you here. I think having two or three failures > daily from the same test (and typically with the same message) is far > worse than not having it at all. Imperfect test coverage is better than no test coverage? Seems like we

Re: large messages from Jenkins failures

On Tue, Aug 28, 2012 at 4:03 PM, Michael McCandless wrote: >> Another option is to redirect solr fails to a different mailing list >> that only those that care about solr development can follow. > > I don't think splintering the dev community is healthy. Well, it seems like some people would pref

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #64: POMs out of sync

On Fri, Aug 17, 2012 at 9:42 AM, Steven A Rowe wrote: > Five out of the last seven builds have failed with this exact same ERROR. > > I can't reproduce on my Win7+Cygwin environment. > > Does anybody know what's happening here? > > If not, I'll ignore this test under Maven. Pretty strange. I can

SPI loading failures

I'm getting SPI failures running any test in IntelliJ: Caused by: java.lang.IllegalArgumentException: A SPI class of type org.apache.lucene.codecs.Codec with name 'SimpleText' does not exist. You need to add the corresponding JAR file supporting this SPI to your classpath.The current classpath sup

Re: SPI loading failures

On Sat, Sep 8, 2012 at 2:58 PM, Alan Woodward wrote: > You need the codecs module resources/ directory to be set up as a source > directory in the IntelliJ project properties. Thanks. I had added the "codecs" module as a lucene dependency (that got things to compile from the codecs front). On a

Re: SPI loading failures

On Sat, Sep 8, 2012 at 3:24 PM, Yonik Seeley wrote: > On Sat, Sep 8, 2012 at 2:58 PM, Alan Woodward > wrote: >> You need the codecs module resources/ directory to be set up as a source >> directory in the IntelliJ project properties. > > Thanks. > I had added the

Re: SPI loading failures

letes(BufferedDeletesStream.java:208) at org.apache.lucene.index.IndexWriter.applyAllDeletes(IndexWriter.java:2895) -Yonik http://lucidworks.com On Sat, Sep 8, 2012 at 5:25 PM, Yonik Seeley wrote: > On Sat, Sep 8, 2012 at 3:24 PM, Yonik Seeley wrote: >> On Sat, Sep 8, 2012 at

Re: svn commit: r1382777 - /lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/common/cloud/Slice.java

Thanks for fixing that. I'm trying to run javadocs-lint myself, but it's not working: javadocs-lint: [exec] Traceback (most recent call last): [exec] File "/usr/local/bin/../Cellar/python3/3.2/lib/python3.2/functools.py", line 176, in wrapper [exec] result = cache[key] [

Re: svn commit: r1382777 - /lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/common/cloud/Slice.java

for valid characters (we >> had some javadocs that intended \u and so on but java preprocesses >> these, actually giving us invalid xml). >> >> Can you try removing the supplementary ranges from the regex just as a >> test? I don't really fully understand the state

Re: FuzzyQuery vs SlowFuzsyQuery docs? -- was: Re: [jira] [Commented] (LUCENE-2667) Fix FuzzyQuery's defaults, so its fast.

On Thu, Sep 13, 2012 at 6:41 PM, Jack Krupansky wrote: > I would argue that > SlowFuzzyQuery should be un-deprecated and moved from sandbox back into > Lucene proper since it does have value in SOME cases. Actually, I would > argue that it should be recombined with "fast" FuzzyQuery (joined at the

Re: being a good citizen is hard when you can't successfully run tests....

On Sun, Sep 16, 2012 at 2:26 PM, Steven A Rowe wrote: > Related question: how hard would it be to set up Ant testing to be like the > maven --fail-at-end test option? That definitely seems like an avenue worth pursuing. -Yonik http://lucidworks.com -

Re: being a good citizen is hard when you can't successfully run tests....

On Sun, Sep 16, 2012 at 6:27 PM, Erick Erickson wrote: > I suppose I went down the wrong track. I'd assumed since this seems to > happen (the test > takes forever) virtually all the time for me it was happening for > others too so there was some > "tribal knowledge" out there to make it stop No,

Re: being a good citizen is hard when you can't successfully run tests....

On Sun, Sep 16, 2012 at 2:51 PM, Robert Muir wrote: > not so much energy spent fixing these few shitty solr tests, some of > which (Like TestReplicationHandler) are totally useless and have been > failing sporatically for like, years. Can you explain why it's useless (without the derogatory adjec

Re: being a good citizen is hard when you can't successfully run tests....

On Sun, Sep 16, 2012 at 9:10 PM, Yonik Seeley wrote: > No, you've definitely hit on something Erick! > I can now reproduce this issue on my OS-X Lion macbook 100% of the > time, but not on any of my other machines. Further, it seems to work fine when run from my IDE (intelli

Re: being a good citizen is hard when you can't successfully run tests....

On Sun, Sep 16, 2012 at 9:53 PM, Robert Muir wrote: > I dont care about replication Yeah, I know. That's the crux of some of the biggest problems here. > I'm volunteering to disable this test -1 -Yonik http://lucidworks.com

Re: Is this a SolrCloud bug? Or expected behavior?

On Tue, Sep 18, 2012 at 11:49 AM, jimtronic wrote: > I've got a set up as follows: > > - 13 cores > - 2 servers > - running Solr 4.0 Beta with numShards=1 and an external zookeeper. > > I'm trying to figure out why some complex queries are running so slowly in > this setup versus quickly in a stan

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #617: POMs out of sync

On Tue, Sep 18, 2012 at 3:28 PM, Steven A Rowe wrote: > Three out of five of the last trunk Maven builds have failed in > SyncSliceTest.testDistribSearch - maybe a timeout needs upward adjustment or > something? Unfortunately Mark is traveling this week... But I wonder if the issue is mainly on

Re: Build failed in Jenkins: Lucene-Solr-Robocop #181

On Thu, Sep 20, 2012 at 1:56 PM, wrote: > See > > Changes: > > [yonik] SOLR-3825: Added optional capability to log what ids are in a response > > -- > Started by timer > Started by time

Re: VOTE: release 4.0

Folks, it looks like there definitely should be a respin, so please remember to back-port fixes that should go into 4.0 to the 4.0 branch in addition to the 4x branch. -Yonik http://lucidworks.com - To unsubscribe, e-mail: dev-un

Re: softCommitWithin ??

On Mon, Sep 24, 2012 at 1:19 PM, Jan Høydahl wrote: > In 4.0, it was talked about defaulting the update request parameter > ?commitWithin=nnn to do softCommit (SOLR-2193, SOLR-2565). Was that ever > done, or is there a separate ?softCommitWithin=nnn option? Yes, using commitWithin implies a sof

Re: So what query parser _does_ deleteByQuery use?

Yes, the lucene query parser is the default for deleteByQuery. -Yonik http://lucidworks.com On Thu, Sep 27, 2012 at 7:25 AM, Erick Erickson wrote: > While I think the person on the user's list is probably creating their > own problem, we don't say on the Wiki just what query parser is used > to

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

On Sat, Mar 10, 2012 at 4:01 AM, Dawid Weiss wrote: > This was caused by a timeout? > >   [junit] Caused by: > org.apache.commons.httpclient.ConnectTimeoutException: The host did > not accept the connection within timeout of 100 ms > > I don't think this is reasonable on jenkins? If a host is dow

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

Took a quick look, and at the end I see 152287 T188 C0 P15739 oasc.RecoveryStrategy.doRecovery SEVERE Recovery failed - trying again... 155191 T1 oas.SolrTestCaseJ4.endTrackingSearchers SEVERE ERROR: SolrIndexSearcher opens=91 closes=90 So the recovery thread is still going, hence a core is still

Re: Exposing Solr routing to SolrJ client

On Mon, Mar 12, 2012 at 8:15 AM, Mark Miller wrote: > Currently it doesn't send directly to the leader, but this is planned - it's > a little tricky due to lack of access to the Schema for hashing Hmmm, why is this? Identification of the "uniqueKey" field? Maybe we just assume "id", or let the

Re: Exposing Solr routing to SolrJ client

On Mon, Mar 12, 2012 at 5:39 PM, Mark Miller wrote: > > On Mar 12, 2012, at 5:32 PM, Yonik Seeley wrote: > >> On Mon, Mar 12, 2012 at 8:15 AM, Mark Miller wrote: >>> Currently it doesn't send directly to the leader, but this is planned - >>> it's a

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

Looks like the same underlying cause again... the recovery thread is still running when the test ends and hence a core (and it's searcher) are still open. I thought there was code in the test framework to wait for threads that hadn't finished yet? -Yonik lucenerevolution.com - Lucene/Solr Open Sou

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

On Tue, Mar 13, 2012 at 1:32 PM, Mark Miller wrote: > > On Mar 13, 2012, at 1:23 PM, Yonik Seeley wrote: > >> Looks like the same underlying cause again... the recovery thread is >> still running when the test ends and hence a core (and it's searcher) >> are still

  1   2   3   4   5   6   7   8   9   10   >