Build:
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java7-64/288/
All tests passed
Build Log:
[...truncated 1434 lines...]
[junit4] 2012-07-01 06:02:26
[junit4] Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.0-b21 mixed
mode):
[junit4]
[junit4]
It GC after about 10 minutes.
Bill Bell
Sent from mobile
On Jun 30, 2012, at 10:48 PM, Jack Krupansky j...@basetechnology.com wrote:
Out of curiosity, how long does your Solr instance run before you hit a GC
issue? Minutes, hours, days? If reasonably long, maybe you simply need to
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-4.x-java7/76/
All tests passed
Build Log:
[...truncated 1548 lines...]
[...truncated 1548 lines...]
[...truncated 1548 lines...]
[...truncated 1548 lines...]
[...truncated 1534 lines...]
[junit4] ERROR: Forked JVM execution
Hangs again in Stall control (this time linux, load of server was horrible: 24
!!!). Something completely strange, had to reboot (kernel announced in dmesg
that some cpu cores were completely overloaded and no longer responding).
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
[
https://issues.apache.org/jira/browse/LUCENE-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404629#comment-13404629
]
Toke Eskildsen edited comment on LUCENE-4062 at 7/1/12 11:06 AM:
This one on FreeBSD was hanging 1.5 days.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
Sent: Sunday, July 01, 2012 1:03 PM
To:
I'll take a look at adding test timeouts on Monday -- this manual
checking for hung threads consumes too much (of Uwe's...) precious
time.
I'll probably implement it the ostrich way -- if a test thread hangs
for too long (and we can assign a fairly generous timeout here) the
test will result in
:) After my shoulder surgery I have time to follow the Jenkins runs with one
hand only :)
Can we use test timing logs to automatically define large timeouts? Like 10
times normal runtime?
If a test hangs, I would use System.exit(failure) and print stack traces before
(and switch all threads
is this the leapsecond bug? we should not use timestamps in tests.
On Jul 1, 2012 7:06 AM, Uwe Schindler u...@thetaphi.de wrote:
Hangs again in Stall control (this time linux, load of server was
horrible: 24 !!!). Something completely strange, had to reboot (kernel
announced in dmesg that some
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-4.x/194/
1 tests failed.
REGRESSION:
org.apache.solr.handler.dataimport.TestSqlEntityProcessorDelta3.testCompositePk_DeltaImport_replace_nodelete
Error Message:
Exception during query
Stack Trace:
java.lang.RuntimeException:
LOL!
I think NTP just slows down clock?
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
Robert Muir rcm...@gmail.com schrieb:
is this the leapsecond bug? we should not use timestamps in tests.
On Jul 1, 2012 7:06 AM, Uwe Schindler u...@thetaphi.de wrote:
Hangs
Build:
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows-Java7-64/180/
No tests ran.
Build Log:
[...truncated 8336 lines...]
FATAL: hudson.remoting.RequestAbortedException:
hudson.remoting.Channel$OrderlyShutdown
hudson.remoting.RequestAbortedException:
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404743#comment-13404743
]
Michael McCandless commented on LUCENE-4123:
bq. You should make the II
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404742#comment-13404742
]
Michael McCandless commented on LUCENE-4123:
bq. You should make the II
Looks like there's a real Linux issue w/ last night's leapsecond ...
see the comments here:
http://news.ycombinator.com/item?id=4182642
This also took beast down last night (and the nightly bench failed to
run). Reboot seems to have fixed it ...
See also Shay's email to the ElasticSearch
On Jul 1, 2012, at 8:09 AM, Robert Muir wrote:
is this the leapsecond bug
Seems like pretty coincidental timing if not. Java software across the globe
crapped out.
insert Simpson's Nelson voice here
Ha Ha.
- Mark Miller
lucidimagination.com
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404747#comment-13404747
]
Uwe Schindler commented on LUCENE-4123:
---
bq. Are we sure the catch + rethrow adds
Build:
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/660/
No tests ran.
Build Log:
[...truncated 108 lines...]
FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException:
Connection reset
hudson.remoting.RequestAbortedException:
On 6/30/2012 7:48 PM, Bill Bell wrote:
Nothing?
Bill Bell
Sent from mobile
On Jun 29, 2012, at 9:09 PM, Bill Bell billnb...@gmail.com wrote:
We are getting large Solr pauses on Java garbage collection in 1.6 Java.
We have tried CMS. But we still have. 4 second wait on GC.
What works well
Our servers took a dive too. Oh, joy.
Dawid
On Sun, Jul 1, 2012 at 5:31 PM, Mark Miller markrmil...@gmail.com wrote:
On Jul 1, 2012, at 8:09 AM, Robert Muir wrote:
is this the leapsecond bug
Seems like pretty coincidental timing if not. Java software across the globe
crapped out.
:) After my shoulder surgery I have time to follow the Jenkins runs with one
hand only :)
Hope it's not anything serious. I had shoulder tendon reattached. It
felt like hell for three weeks until it kind of healed. Very, very
bad.
Can we use test timing logs to automatically define large
This explains somehow my problems with Linux kernel on the SDDS Jenkins. At
approx. 0:00 UTC I had messages in syslog like coreX did not respond for XX
seconds + a system load of 24.0 (as noted in mail before), most CPU spent
inside Linux kernel. This was on Ubuntu 10.04 LTS (Linux 2.6.32). Of
To me, that suggests that you simply don't have enough JVM heap memory from
the start. Maybe the nature of your schema and data results in a larger than
expected use of heap from the start. Check JVM available memory/heap right
after starting Solr, before any user queries, and then after doing
On Jul 1, 2012, at 12:32 PM, Uwe Schindler wrote:
My other Ubuntu box with 11.04 (non-LTS, 2.6.38) was responsible, but no Java
processes, so I have no idea about Java there. All three machines had NTP to
de.pool.ntp.org.
I think Linux had its own problems with the leap second even without
Yeah,
The problems I have seen on my server (all cpu frozen in kernel, cores no
longer responding) was a Linux kernel bug, affecting Ubuntu 10.04 LTS, too:
http://www.heise.de/newsticker/meldung/Verlaengertes-Wochenende-kann-Linux-e
infrieren-1629683.html
An here we are -- y2k didn't as much as touch us and a freaking second
did the bloody kill... :)
Dawid
On Sun, Jul 1, 2012 at 8:01 PM, Uwe Schindler u...@thetaphi.de wrote:
Yeah,
The problems I have seen on my server (all cpu frozen in kernel, cores no
longer responding) was a Linux kernel
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java8-64/1/
No tests ran.
Build Log:
[...truncated 7210 lines...]
[javac] Compiling 650 source files to
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux-Java8-64/checkout/lucene/build/core/classes/java
[javac] warning:
Clone URL (Committers only):
https://cms.apache.org/redirect?new=joes;action=diff;uri=http://lucene.apache.org/site-instructions.mdtext
Index: trunk/content/site-instructions.mdtext
===
--- trunk/content/site-instructions.mdtext
This one only happens with Java 8 on Lucene 4.x because of the sophisticated
backwards layer. As it compiles fine in Java 6 and 7 we should open a bug
report @ Oracle, but it is still a hint to a problem, the variable can indeed
be uninitilized, so it’s a bug in our code that we should fix. I
Correction: Our code is correct, just not easy to read. The variable can never
be uninitialized, it is a bug in Java 8's javac.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Uwe Schindler
[
https://issues.apache.org/jira/browse/LUCENE-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404801#comment-13404801
]
Toke Eskildsen commented on LUCENE-4062:
The graphs are updated with data from my
Build:
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java8-64/2/
1 tests failed.
FAILED: org.apache.solr.schema.PreAnalyzedFieldTest.testParsers
Error Message:
expected:{[v:1,str:test
I opened bug report @ Oracle. The attached code does not compile with JDK
8-ea-b45, but compiles with JDK 5,6,7!
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Uwe Schindler
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404856#comment-13404856
]
Michael McCandless commented on LUCENE-4123:
OK thanks Uwe!
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2854/
1 tests failed.
FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch
Error Message:
Timeout occured while waiting response from server at:
http://localhost:20092/solr/collection1
Stack Trace:
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2855/
1 tests failed.
FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch
Error Message:
Server at http://localhost:12851/solr/collection1 returned non ok status:500,
message:Server Error
Stack
Build:
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/1125/
1 tests failed.
REGRESSION: org.apache.solr.cloud.ZkSolrClientTest.testWatchChildren
Error Message:
expected:2 but was:1
Stack Trace:
java.lang.AssertionError: expected:2 but was:1
at
37 matches
Mail list logo
