lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (LUCENE-5612) LockStressTest fails always with NativeFSLockFactory
Date Fri, 18 Apr 2014 10:36:15 GMT


Uwe Schindler commented on LUCENE-5612:

The latest patch should work for now, but when looking at the code, there may be more improvements.
I will do them later today, but for testing this is all fine how it is now:
- The problem with the ephemeral port allocation is a bit stupid. The problem here is that
every locking operation creates a new socket connection to the server. I would change the
server to only accept *one* connection per client and keep it open (in a separate thread).
The clients only connect one time and just pass the open socket to the VerifyingLockFactory.
- We have no McCandless like "Starting Gun". This is getting better, but still all clients
are not starting to hammer the lock dir at the same time. With the above "one socket" per
client, we can add a starting gun. The server gets the number of clients to connect on startup.
Then it accepts up to this number of connections (but do not communicate over them). Once
all clients connected, the server sends a starting gun signal through all sockets.

What do you think?

> LockStressTest fails always with NativeFSLockFactory
> ----------------------------------------------------
>                 Key: LUCENE-5612
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Robert Muir
>            Priority: Blocker
>             Fix For: 4.8
>         Attachments: LUCENE-5612-instant-crush.patch, LUCENE-5612-instant-crush.patch,
LUCENE-5612-more-sophisticated-crusher.patch, LUCENE-5612-more-sophisticated-crusher.patch,
LUCENE-5612-more-sophisticated-crusher.patch, LUCENE-5612-tester.patch, LUCENE-5612-tester.patch,
> I was looking at this, because i wanted to remove the static map inside NativeFSLockFactory
(no particular reason: it just smells bad, we require java7, and you get overlappingexception
as of java6 so its unnecessary).
> Before changing any code, i wanted to run lockstresstest first, just to ensure it works:
but it fails always. Simple works fine always.
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: lock
was double acquired at$CheckedLock.verify(

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message