TestDoubleBarrelLRUCache hangs under Java 1.5, 3.x and trunk, likely JVM bug [LUCENE-3235]

[asfimport]

Not sure what's going on yet... but under Java 1.6 it seems not to hang bug under Java 1.5 hangs fairly easily, on Linux. Java is 1.5.0_22.

I suspect this is relevant: http://stackoverflow.com/questions/3292577/is-it-possible-for-concurrenthashmap-to-deadlock which refers to this JVM bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6865591 which then refers to this one http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6822370

It looks like that last bug was fixed in Java 1.6 but not 1.5.

---

Migrated from LUCENE-3235 by Michael McCandless (@mikemccand), updated May 09 2016
Attachments: LUCENE-3235.patch (versions: 3)
Linked issues:

• Add some more constants for newer Java versions to Constants.class, remove outdated ones. [LUCENE-3574] #4648

[asfimport]

Robert Muir (@rmuir) (migrated from JIRA)

+1 to drop java 5

[asfimport]

Uwe Schindler (@uschindler) (migrated from JIRA)

LOL, no comment.

[asfimport]

Robert Muir (@rmuir) (migrated from JIRA)

i ran the test with the same version as mike (1.5.0_22) in two ways on windows:

• -Dtests.iter=100
• in a loop from a script, 100 times with its own ant run.

i can't reproduce it on windows.

in my eyes, there isn't even an argument about whether or not we should support java5: its not possible, if bugs are not getting fixed.

[asfimport]

Michael McCandless (@mikemccand) (migrated from JIRA)

Still hangs if I run -client; but it looks like -Xint prevents the hang (235 iterations so far on beast).

3.2 also hangs.

[asfimport]

Robert Muir (@rmuir) (migrated from JIRA)

Mike, i installed 1.5.0_22 (amd64) on my linux machine, and i can't reproduce there either (i ran like 500 iterations).

Maybe my hardware isn't concurrent enough? or maybe you should un-overclock? :)

[asfimport]

Michael McCandless (@mikemccand) (migrated from JIRA)

VERY interesting! Is anyone able to repro this hang besides me...?

[asfimport]

Dawid Weiss (@dweiss) (migrated from JIRA)

I don't think you can force client if it's a 64 bit release and you have tons of memory, can you? You can check by running java -client -version - this is what it tells me, for example:

dweiss@dweiss-linux:\~/work/lucene/lucene-trunk$ java -client -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)

Can you do a remote stack of all the VM (or run it from the console and send it a signal to dump all threads)?

[asfimport]

Michael McCandless (@mikemccand) (migrated from JIRA)

Yes the stack looks just like the stack overflow link I posted – several threads stuck in sun.misc.Unsafe.park ;)

java -Xint definitely does not hang... ran for like 4200 iterations.

[asfimport]

Michael McCandless (@mikemccand) (migrated from JIRA)

Indeed java client -version shows it's still using server VM - you're right!

[asfimport]

Dawid Weiss (@dweiss) (migrated from JIRA)

I'm same as Robert: +1 to drop 1.5...

[asfimport]

Mark Miller (@markrmiller) (migrated from JIRA)

+1 to drop 1.5...

+1.

[asfimport]

Simon Willnauer (@s1monw) (migrated from JIRA)

we moved to 1.6 on trunk seems we can't do much about it on 3.x - folks should run their stuff on 1.6 jvms or newer

[asfimport]

Robert Muir (@rmuir) (migrated from JIRA)

wait, this statement makes no sense.

if 1.5 is no longer supported, then 1.5 should no longer be supported, and we should be
free to use 1.6 code everywhere.

[asfimport]

Uwe Schindler (@uschindler) (migrated from JIRA)

I agree with Robert. This issue is still existent in 3.x as we officially support Java 5.

[asfimport]

Simon Willnauer (@s1monw) (migrated from JIRA)

well then we should fix it - I will mark it as 3.5