1) does anyone understand why this is failing?
2) should we just disabble this cron completley in favor of using the
Hudson builds exclusively? (i use to think it was nice to have multiple
systems doing nightly buidls as a sanity cehck ... but it also seems like
an adminstrative hassle, and
On Wed, Apr 14, 2010 at 2:43 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
1) does anyone understand why this is failing?
The compiler barfed... (a compiler bug.)
I updated it to use the Java6 compiler this morning.
I had previously disabled the nightly test and build part, but kept
the
The carrot2 download links are broken. I have file a bug with them:
http://issues.carrot2.org/browse/CARROT-653
Bill
On Tue, Mar 23, 2010 at 4:09 AM, solr-dev@lucene.apache.org wrote:
init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[mkdir] Created dir:
Hi there,
The carrot2 download links are broken. I have file a bug with them:
http://issues.carrot2.org/browse/CARROT-653
It's fixed now, thanks for the report! When Solr switches to Carrot2 v3.2.0
(https://issues.apache.org/jira/browse/SOLR-1804), which is LGPL-free, the
extra build
The exception:
Testcase: testCacheControl took 6.011 sec
Caused an ERROR
The host did not accept the connection within timeout of 100 ms
org.apache.commons.httpclient.ConnectTimeoutException: The host did
not accept the connection within timeout of 100 ms
at
Aparently the replication handler tests are failing too frequently.
Any idea why is it so?
On Fri, Oct 23, 2009 at 2:12 PM, solr-dev@lucene.apache.org wrote:
init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[mkdir] Created dir:
Here's an interesting warning in the failed TestLBHttpSolrServer logs:
WARNING: SimpleHttpConnectionManager being used incorrectly. Be sure
that HttpMethod.releaseConnection() is always called and that only on
e thread and/or method is using this connection manager at a time.
The test failure
Not sure what's causing the problem with this test
(TestLBHttpSolrServer)... here's the exception.
I've just changed the check interval from 1000ms to 500ms for now...
maybe it wasn't completing in time.
Testcase: testTwoServers took 9.852 sec
Caused an ERROR
No live SolrServers available
Not sure what's up with the failures below - looks like SolrJ got an
error from Solr reporting a failure instantiating a lazy request
handler... but there's no matching exception in the Solr logs.
Running this test by hand worked fine too. I just kicked off another
nightly by hand.
-Yonik
Ah, of course.
This consistently fails:
ant test -Dversion=nightly -Dtestcase=SolrExampleEmbeddedTest
It's because the version nightly makes the regex not match! We
should probably relax the expressions.
-Yonik
http://www.lucidimagination.com
On Tue, Oct 13, 2009 at 10:25 AM, Yonik Seeley
OK, the nightly now passes latest here:
http://people.apache.org/builds/lucene/solr/nightly/
-Yonik
http://www.lucidimagination.com
On Tue, Oct 13, 2009 at 11:10 AM, Yonik Seeley
yo...@lucidimagination.com wrote:
Ah, of course.
This consistently fails:
ant test -Dversion=nightly
Hmmm, wonder why this would fail...
Testcase: testMultiThreaded took 11.47 sec
FAILED
expected:500 but was:484
junit.framework.AssertionFailedError: expected:500 but was:484
at
org.apache.solr.client.solrj.LargeVolumeTestBase.query(LargeVolumeTestBase.java:63)
at
Ahh, this is why...
SEVERE: org.apache.solr.common.SolrException: Error opening new
searcher. exceeded limit of maxWarmingSearchers=2, try again later.
So it's using the example config, but commiting from 5 different
threads and hence not all of the commits are guaranteed to succeed.
Not sure
Exception that caused the failure shown below...
is this an exception that should be handled internally by LBHttpSolrServer?
-Yonik
http://www.lucidimagination.com
testcase classname=org.apache.solr.client.solrj.TestLBHttpSolrServer
name=testSimple time=22.99/testcase
testcase
I guess yes. But in this case it should have retried. And probably the
next attempt would have succeeded.
On Wed, Sep 23, 2009 at 7:48 PM, Yonik Seeley
yo...@lucidimagination.com wrote:
Exception that caused the failure shown below...
is this an exception that should be handled internally by
Hmm, this looks like my commit. I'll check into it. Anyone else
seeing failures?
On Sep 11, 2009, at 4:38 AM, solr-dev@lucene.apache.org wrote:
init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[mkdir] Created dir: /tmp/apache-solr-nightly/build/web
i'm seeing this one too
On Fri, Sep 11, 2009 at 8:25 AM, Grant Ingersoll gsing...@apache.org wrote:
Hmm, this looks like my commit. I'll check into it. Anyone else seeing
failures?
On Sep 11, 2009, at 4:38 AM, solr-dev@lucene.apache.org wrote:
init-forrest-entities:
[mkdir] Created
Hmm, ant clean test passes for me.
On Sep 11, 2009, at 8:25 AM, Grant Ingersoll wrote:
Hmm, this looks like my commit. I'll check into it. Anyone else
seeing failures?
On Sep 11, 2009, at 4:38 AM, solr-dev@lucene.apache.org wrote:
init-forrest-entities:
[mkdir] Created dir:
i see this with a clean checkout and ant test
On Fri, Sep 11, 2009 at 8:37 AM, Grant Ingersoll gsing...@apache.org wrote:
Hmm, ant clean test passes for me.
On Sep 11, 2009, at 8:25 AM, Grant Ingersoll wrote:
Hmm, this looks like my commit. I'll check into it. Anyone else seeing
I bet it is due to ant example not being run first.
On Sep 11, 2009, at 9:02 AM, Robert Muir wrote:
i see this with a clean checkout and ant test
On Fri, Sep 11, 2009 at 8:37 AM, Grant Ingersoll
gsing...@apache.org wrote:
Hmm, ant clean test passes for me.
On Sep 11, 2009, at 8:25 AM,
On Sep 11, 2009, at 9:23 AM, Grant Ingersoll wrote:
I bet it is due to ant example not being run first.
I confirm that's the issue. Argh. Don't really want to make people
run example first (because it is slow) but if the example is going to
include /update/extract, then we need to make
Please try https://issues.apache.org/jira/browse/SOLR-1411 SOLR-1411-
build.patch
On Sep 11, 2009, at 9:34 AM, Grant Ingersoll wrote:
On Sep 11, 2009, at 9:23 AM, Grant Ingersoll wrote:
I bet it is due to ant example not being run first.
I confirm that's the issue. Argh. Don't really
thanks, this patch fixes the build issue
On Fri, Sep 11, 2009 at 10:14 AM, Grant Ingersoll gsing...@apache.org wrote:
Please try https://issues.apache.org/jira/browse/SOLR-1411
SOLR-1411-build.patch
--
Robert Muir
rcm...@gmail.com
I think these failures might be due to waiting until a commit, but not
waiting until the new searcher is registered before trying the search.
I'll see if I can work up a patch.
-Yonik
http://www.lucidimagination.com
On Thu, Aug 27, 2009 at 4:37 AM, solr-dev@lucene.apache.org wrote:
I kicked off the nightly build manually - seems to have worked for now at least.
-Yonik
http://www.lucidimagination.com
On Thu, Aug 27, 2009 at 8:26 AM, Yonik Seeleyyo...@lucidimagination.com wrote:
I think these failures might be due to waiting until a commit, but not
waiting until the new
Hmmm... no idea why this would happen.
testcase classname=org.apache.solr.client.solrj.embedded.JettyWebappTest
name=testJSP time=14.789
error message=Server returned HTTP response code: 500 for URL:
http://localhost:56914/test/admin/threaddump.jsp;
My fault - committed part of a future patch with my last commit. Fixing now...
-Yonik
On Sat, Jun 27, 2009 at 4:05 AM, solr-dev@lucene.apache.org wrote:
init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[mkdir] Created dir: /tmp/apache-solr-nightly/build/web
The same test fails in my box consistently
On Sat, May 23, 2009 at 4:58 PM, Mark Miller markrmil...@gmail.com wrote:
[junit] Running
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest
[junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 20.341 sec
--
[junit] Running
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest
[junit] Tests run: 8, Failures: 1, Errors: 0, Time elapsed: 20.341 sec
On Sat, Mar 14, 2009 at 1:49 PM, solr-dev@lucene.apache.org wrote:
[junit] Running org.apache.solr.TestTrie
[junit] response
[junit] lst name=responseHeaderint name=status0/intint
name=QTime2/int/lstresult name=response numFound=6
start=0docfloat name=id0.0/floatdate
Fixed.
SimpleDateFormat needed it's timezone set to UTC in the test (it was
formatting in local time and sticking on a 'Z').
-Yonik
http://www.lucidimagination.com
On Sun, Mar 15, 2009 at 3:32 AM, Shalin Shekhar Mangar
shalinman...@gmail.com wrote:
On Sat, Mar 14, 2009 at 1:49 PM,
On Sun, Mar 15, 2009 at 8:25 PM, Yonik Seeley yo...@lucidimagination.comwrote:
Fixed.
SimpleDateFormat needed it's timezone set to UTC in the test (it was
formatting in local time and sticking on a 'Z').
Thanks Yonik!
--
Regards,
Shalin Shekhar Mangar.
On Sun, Feb 22, 2009 at 10:41 AM, Ryan McKinley ryan...@gmail.com wrote:
[junit] Test
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest FAILED
How do you all feel about pulling the StreamingSolrServer out of the main
distribution until after 1.4 is released?
I currently don't
Here's the test failure:
testcase
classname=org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
name=testCommitWithin time=1.193
failure message=expected:lt;0gt; but was:lt;1gt;
type=junit.framework.AssertionFailedErrorjunit.framework.AssertionFailedError:
expected:lt;0gt; but
On Wed, Dec 3, 2008 at 3:29 PM, Ryan McKinley [EMAIL PROTECTED] wrote:
[junit] Tests run: 9, Failures: 1, Errors: 0, Time elapsed: 17.101 sec
[junit] Test org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
FAILED
Any thoughts on this?
Things are building fine on my local system
[junit] Tests run: 9, Failures: 1, Errors: 0, Time elapsed:
17.101 sec
[junit] Test
org.apache.solr.client.solrj.embedded.SolrExampleJettyTest FAILED
Any thoughts on this?
Things are building fine on my local system and on hudson:
Sorry, my bad.
I do remember running the tests but I think I forgot to check the results
before adding the jars :)
On Sun, Nov 23, 2008 at 10:19 PM, Yonik Seeley [EMAIL PROTECTED] wrote:
On Sun, Nov 23, 2008 at 3:15 AM, solr-dev@lucene.apache.org wrote:
[junit] Tests run: 2, Failures: 0,
On Sun, Nov 23, 2008 at 3:15 AM, solr-dev@lucene.apache.org wrote:
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.439 sec
[junit] Test org.apache.solr.core.ResourceLoaderTest FAILED
This started happening after the latest Lucene upgrade.
Remember ant clean test is your
On Aug 22, 2008, at 6:43 PM, Chris Hostetter wrote:
: Can you double check which ant is geting used and make changes as
appropriate?
Actually, wait a minute nightly.sh is just running ant nightly
which is the same as ant test package ... people who want to run
tests
and package
: Because the maven artifacts are part of packaging for release. People who
: don't want them can run create-package, or we could call it core-package. I
The problem i have is that up until now, anyone that wanted to
checkou the source and build it could run ant package and get a nice
zip
On Aug 25, 2008, at 1:50 PM, Chris Hostetter wrote:
: Because the maven artifacts are part of packaging for release.
People who
: don't want them can run create-package, or we could call it core-
package. I
The problem i have is that up until now, anyone that wanted to
checkou the
Yonik: is nightly.sh running in your crontab?
Can you double check which ant is geting used and make changes as appropriate?
(and update the new NightlyBuilds wiki page)
: maven.ant.tasks-check:
:
: BUILD FAILED
: /tmp/apache-solr-nightly/common-build.xml:334:
: Can you double check which ant is geting used and make changes as appropriate?
Actually, wait a minute nightly.sh is just running ant nightly
which is the same as ant test package ... people who want to run tests
and package things up shouldn't be required to have Maven ant tasks
Here's the source of the failure:
testcase classname=org.apache.solr.core.TestJmxIntegration name=testJmxUpd
ate time=1.79
error type=java.lang.NullPointerExceptionjava.lang.NullPointerException
at org.apache.solr.core.TestJmxIntegration.getObjectName(TestJmxIntegrat
ion.java:107)
Yes, I printed out the available beans on the console and searcher mbean is
missing. Looks like the main searcher is being registered *after* the test
runs. Shouldn't the test execute after Solr is completely up?
On Sat, Aug 9, 2008 at 11:58 AM, Shalin Shekhar Mangar
[EMAIL PROTECTED] wrote:
Yes, I printed out the available beans on the console and searcher mbean is
missing. Looks like the main searcher is being registered *after* the test
runs. Shouldn't the test execute after Solr is completely up?
Sounds right... I just hacked in a wait loop.
Thanks!
--
Regards,
Shalin Shekhar Mangar.
On 4-Apr-08, at 1:33 AM, solr-dev@lucene.apache.org wrote:
[junit] Running org.apache.solr.update.AutoCommitTest
[junit] response
[junit] lst name=responseHeaderint name=status0/intint
name=QTime1/int/lstresult name=response numFound=0
start=0/
[junit] /response
[junit] )
: [junit] Running org.apache.solr.client.solrj.response.QueryResponseTest
: [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.316 sec
This test seems to have been failing consistently in the nightly build
since March 18th which is when the test was added (new Date Faceting
Hi!
What is the problem here? The Hudson build is OK.
-Original Message-
From: solr-dev@lucene.apache.org [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 04, 2008 9:10 AM
To: solr-dev@lucene.apache.org
Subject: Solr nightly build failure
init-forrest-entities:
[mkdir] Created dir:
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:30 PM
To: solr-dev@lucene.apache.org
Subject: Re: Solr nightly build failure
: For the jetty based tests, perhaps we should just give a warning if it
tries
: to bind a port and can't
Has anyone taken a closer look at this?
It looks like org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
is unable to connect to the SolrServer instance. Timing out? Perhaps
increase timeout?
http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/ws/trunk/bui
On 10-Oct-07, at 2:45 PM, Yousef Ourabi wrote:
Has anyone taken a closer look at this?
It looks like
org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
is unable to connect to the SolrServer instance. Timing out? Perhaps
increase timeout?
Would it be appropriate to exclude this test, since a test that fails
every night is like the boy who cried wolf? At least until it's worked
out -- I'm not really familiar with the setup on the nightly build box.
+1! Never-working tests are worse than no tests.
I agree crying wolf is BAD
On 10-Oct-07, at 3:41 PM, Ryan McKinley wrote:
Would it be appropriate to exclude this test, since a test that
fails
every night is like the boy who cried wolf? At least until it's
worked
out -- I'm not really familiar with the setup on the nightly
build box.
+1! Never-working tests
On 8/3/07, Mike Klaas [EMAIL PROTECTED] wrote:
Yonik could you see whether it is maxDocs or maxTime that is failing?
Sorry, just got this email, and it had already been overwritten.
One advantage of the hudson builds - everyone can see the output.
-Yonik
[junit] Running org.apache.solr.update.AutoCommitTest
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed:
20.424 sec
[junit] Test org.apache.solr.update.AutoCommitTest FAILED
This is how long it takes to run on my (medium-loaded) system:
junit:
[junit] Running
[junit] Test org.apache.solr.client.solrj.embedded.TestJettySolrRunner
FAILED
Is there any way to see what error it failed with? ant test-reports
hudson seems to have built fine:
http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/112/
This is the test that starts jetty (on
I've updated the nightly build script to hopefully not proceed after
an ant failure, and kicked it off manually just now.
-Yonik
On 2/14/07, Yonik Seeley [EMAIL PROTECTED] wrote:
I've updated the nightly build script to hopefully not proceed after
an ant failure, and kicked it off manually just now.
Do you have the failure message? We could further increase the tolerances.
-Mike
On 2/14/07, Mike Klaas [EMAIL PROTECTED] wrote:
On 2/14/07, Yonik Seeley [EMAIL PROTECTED] wrote:
I've updated the nightly build script to hopefully not proceed after
an ant failure, and kicked it off manually just now.
Do you have the failure message? We could further increase the
On 2/5/07, Doug Cutting [EMAIL PROTECTED] wrote:
Yonik Seeley wrote:
lucene runs at 00:03, hadoop at 00:11, nutch at 00:17, solr at 31 after.
But looking at the dates on the log files,
lucene ended at 00:30,
hadoop ended at 00:44,
nutch ended at 00:41
Ouch! Something is going on...
Not sure why this failed. I'm kicking it off again manually.
-Yonik
On 2/1/07, solr-dev@lucene.apache.org solr-dev@lucene.apache.org wrote:
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[javac] Compiling 170 source files to
On 2/2/07, solr-dev@lucene.apache.org solr-dev@lucene.apache.org wrote:
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[junit] Running org.apache.solr.update.AutoCommitTest
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 26.557 sec
On 2/2/07, Mike Klaas [EMAIL PROTECTED] wrote:
On 2/2/07, solr-dev@lucene.apache.org solr-dev@lucene.apache.org wrote:
checkJunitPresence:
compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[junit] Running org.apache.solr.update.AutoCommitTest
[junit] Tests run: 2,
On 2/2/07, Yonik Seeley [EMAIL PROTECTED] wrote:
Does anyone know how to access the build logs? I don't know from
apache infra (except people./minotaur.)
It's on the lucene zone with restricted access.
It might be possible to set something up to copy some stuff to
minotaur on a failure
66 matches
Mail list logo
