Logging FileHandler: static locks and hardcoded maximum number

[Daniel Fuchs]

Thanks Behrooz.

Could you log an issue for this then?
If you can attach a small reproducer it will be helpful.

There are a bunch of unit tests in the JDK that verify
that FileHandler .lck files are correctly deleted - but
these tests are all mono-process. I would like to make
sure to chase down the real issue - so a small isolated
reproducer would definitely help.

best regards,

-- daniel

On 19/02/15 15:29, Behrooz Nobakht wrote:
> Hi Daniel,
>
> Thanks for referring to this ticket.
> Here is what I did.
>
> My Java version:
>
> java version "1.8.0_40-ea"
> Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b21)
> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b24, mixed mode)
>
> So, to make this more observable.
> The p1 process invokes a command with p2: start and stop.
> So, with 50 pairs of start and stop, we should be able to see the
> problem again.
>
> I ran a script that invokes start from p1, gets the status of p2, stops
> p2 and confirms its status again.
> Here's the output from run 49:
>
> ===
> run 49
> Invoking Start
> RUNNING
> Invoking Stop
> STOPPED
> run 49 - Done
> run 50
> Invoking Start
> RUNNING
> Invoking Stop
> STOPPED
> run 50 - Done
> run 51
> Invoking Start
> RUNNING
> Invoking Stop
> RUNNING
> run 51 - Done
> run 52
> Invoking Start
> STOPPED
> Invoking Stop
> STOPPED
> run 52 - Done
> run 53
> Invoking Start
> STOPPED
> Invoking Stop
> STOPPED
> run 53 - Done
> run 54
> Invoking Start
> STOPPED
> Invoking Stop
> STOPPED
> run 54 - Done
> ===
>
> As the above shows, starting run 51, the expected status is violated.
> And, here is what I get a lsof of the log directory on the application:
>
> ===
> -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:19 app.stdouterr.100.0.log.lck
> -rw-rw-r-- 1 appuser appuser 3.0K Feb 19 15:19 app.stdouterr.100.0.log
> -rw-rw-r-- 1 appuser appuser    0 Feb 19 15:16 app.stdouterr.0.0.log.lck
> -rw-rw-r-- 1 appuser appuser  366 Feb 19 15:16 app.stdouterr.0.0.log
> ===
>
> Thanks for your time on this,
> Behrooz
>
>
>
>
>
> On Thu, Feb 19, 2015 at 3:01 PM, Daniel Fuchs <daniel.fuchs at oracle.com
> <mailto:daniel.fuchs at oracle.com>> wrote:
>
>     Hi Behrooz,
>
>     On 19/02/15 13:46, Behrooz Nobakht wrote:
>
>         The version of Java is irrelevant. We have tested our setup
>         on Java 7 and Java 8 u25/31. We observe the same exception.
>
>
>     Ok - then the version is indeed relevant ;-)
>
>     What you are observing may be a symptom of
>     https://bugs.openjdk.java.net/__browse/JDK-8048020
>     <https://bugs.openjdk.java.net/browse/JDK-8048020>
>     which was fixed in 8u40 build 6.
>
>     If you would like to verify that this bug is indeed
>     what is causing your issue, you may want to try out
>     your setup with an early access build of 8u40, and
>     see if the problem disappears.
>
>     Early access of 8u40 may be downloaded from there:
>     https://jdk8.java.net/__download.html
>     <https://jdk8.java.net/download.html>
>
>
>     best regards,
>
>     -- daniel
>
>
>
>
> --
> -- Behrooz Nobakht