[
https://issues.apache.org/jira/browse/LUCENE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404910#comment-13404910
]
David Smiley commented on LUCENE-4157:
--
I committed "PortedSolr3Test" which is mostl
[
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404904#comment-13404904
]
Lance Norskog commented on LUCENE-2899:
---
Oops- remove
{{solr/contrib/opennlp/src/t
> Fix test failure with JDK8: The problem is undefined order of HashMaps. This
> here is more a NamedList like
Correction: it is defined as "undefined". :)
Dawid
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For a
[
https://issues.apache.org/jira/browse/LUCENE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4183:
--
Attachment: LUCENE-4183.patch
right patch, sorry.
> Simplify CompoundFileDire
[
https://issues.apache.org/jira/browse/LUCENE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4183:
--
Attachment: LUCENE-4123.patch
> Simplify CompoundFileDirectory opening in 4.x
> --
[
https://issues.apache.org/jira/browse/LUCENE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4183:
--
Attachment: (was: LUCENE-4123.patch)
> Simplify CompoundFileDirectory opening in 4.x
>
[
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lance Norskog updated LUCENE-2899:
--
Attachment: LUCENE-2899.patch
This is about finished. The Tokenizer and TokenFilters are moved
Uwe Schindler created LUCENE-4183:
-
Summary: Simplify CompoundFileDirectory opening in 4.x
Key: LUCENE-4183
URL: https://issues.apache.org/jira/browse/LUCENE-4183
Project: Lucene - Java
Issue
[
https://issues.apache.org/jira/browse/LUCENE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4183:
--
Affects Version/s: 4.0
Fix Version/s: 4.0
Assignee: Uwe Schindler
> S
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
__random
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 Trace:
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:
org
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404856#comment-13404856
]
Michael McCandless commented on LUCENE-4123:
OK thanks Uwe!
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 [mailto:u...@thetaphi.
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
ąćęłńóśźż","tokens":[{"e":128,"i":22,"p":"DQ4KDQsODg8=","s":123,"t":"one","y":"word"}
[
https://issues.apache.org/jira/browse/LUCENE-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404801#comment-13404801
]
Toke Eskildsen commented on LUCENE-4062:
The graphs are updated with data from my
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 [mailto:u...
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 wi
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
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: [
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 wrote:
> Yeah,
> The problems I have seen on my server (all cpu frozen in kernel, cores no
> longer responding) was a Linux kernel bug, affecting U
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
http://serverfault.com/questions/403732/a
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 witho
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 a
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
> :) 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 ti
Our servers took a dive too. Oh, joy.
Dawid
On Sun, Jul 1, 2012 at 5:31 PM, Mark Miller 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.
>
>
>
> Ha Ha.
>
> -
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 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 for Solr when using
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:
hudson.remoting.Request
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404747#comment-13404747
]
Uwe Schindler commented on LUCENE-4123:
---
bq. Are we sure the catch + rethrow adds n
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.
Ha Ha.
- Mark Miller
lucidimagination.com
-
T
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 li
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404742#comment-13404742
]
Michael McCandless commented on LUCENE-4123:
bq. You should make the II corre
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404743#comment-13404743
]
Michael McCandless commented on LUCENE-4123:
bq. You should make the II corre
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:
hudson.remoting.RequestAbor
LOL!
I think NTP just slows down clock?
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
Robert Muir schrieb:
is this the leapsecond bug? we should not use timestamps in tests.
On Jul 1, 2012 7:06 AM, "Uwe Schindler" wrote:
Hangs again in Stall control (this time
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: Exception
is this the leapsecond bug? we should not use timestamps in tests.
On Jul 1, 2012 7:06 AM, "Uwe Schindler" 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 cpu cores w
:) 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 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
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: dev@lucene.a
[
https://issues.apache.org/jira/browse/LUCENE-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404629#comment-13404629
]
Toke Eskildsen edited comment on LUCENE-4062 at 7/1/12 11:06 AM:
--
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
http://ww
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 except
44 matches
Mail list logo
