Thanks Alan!
Just for the record the 'final' webrev is here:
http://cr.openjdk.java.net/~dfuchs/webrev_8048020/webrev.02
I will push this shortly...
-- daniel
On 7/4/14 8:24 PM, Alan Bateman wrote:
On 04/07/2014 19:10, Daniel Fuchs wrote:
hmmm. yes - you're right. I should catch that to and
On 04/07/2014 19:10, Daniel Fuchs wrote:
hmmm. yes - you're right. I should catch that to and break the loop in
that case.
So that would become:
465 } catch (NoSuchFileException x) {
466 // Race condition - retry once, and if
that
On 7/4/14 7:58 PM, Alan Bateman wrote:
On 04/07/2014 18:25, Daniel Fuchs wrote:
Given that nothing is going to be written to the file then maybe I
don't need APPEND.
I just don't want the call to FileChannel.open() to truncate the file.
APPEND should be harmless here, just not needed.
Als
On 04/07/2014 18:25, Daniel Fuchs wrote:
Given that nothing is going to be written to the file then maybe I
don't need APPEND.
I just don't want the call to FileChannel.open() to truncate the file.
APPEND should be harmless here, just not needed.
Also you catch FileNotFoundException (which
On 7/4/14 6:35 PM, Alan Bateman wrote:
On 01/07/2014 10:25, Daniel Fuchs wrote:
Hi Jason, Alan,
Here is an updated version of the fix that does a bounded
retry (retries once - and if it fails, proceeds with the next
name). I have also added NO_FOLLOW_LINKS - for the case where
we try to open a
On 01/07/2014 10:25, Daniel Fuchs wrote:
Hi Jason, Alan,
Here is an updated version of the fix that does a bounded
retry (retries once - and if it fails, proceeds with the next
name). I have also added NO_FOLLOW_LINKS - for the case where
we try to open an existing Lockfile, and suppressed the
---
>>> Date: Tue, 24 Jun 2014 20:34:46 +0200
>>> From: daniel.fu...@oracle.com
>>> To: core-libs-dev@openjdk.java.net
>>> CC: jason_mehr...@hotmail.com; alan.bate...@oracle.com
>>> Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
>>>
>&
Jason
Date: Tue, 24 Jun 2014 20:34:46 +0200
From: daniel.fu...@oracle.com
To: core-libs-dev@openjdk.java.net
CC: jason_mehr...@hotmail.com; alan.bate...@oracle.com
Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
Hi,
Please find below
On 25/06/2014 16:21, Daniel Fuchs wrote:
On 6/25/14 5:07 PM, Alan Bateman wrote:
Catching OverlappingFileLockException is usually a sign of a mis-use.
Can you summarize how this comes about (given the locking on "locks").
A file is just a file. So nothing prevents some other piece of code in
t
Alan,
> Catching OverlappingFileLockException is usually a sign of a mis-use.
> Can you summarize how this comes about (given the locking on "locks").
Malicious intent or ignorant mis-use by code outside of the FileHandler can
turn the FileHandler into a victim of that misuse.
===
pub
On 6/25/14 5:07 PM, Alan Bateman wrote:
On 24/06/2014 19:34, Daniel Fuchs wrote:
Hi,
Please find below a patch [1] for [2]:
8048020 - Regression on java.util.logging.FileHandler
This corresponds to the problem that was discussed on this list
in the following email thread:
"Zombie FileHandler
On 24/06/2014 19:34, Daniel Fuchs wrote:
Hi,
Please find below a patch [1] for [2]:
8048020 - Regression on java.util.logging.FileHandler
This corresponds to the problem that was discussed on this list
in the following email thread:
"Zombie FileHandler locks can exhaust all available log file
; From: daniel.fu...@oracle.com
> To: core-libs-dev@openjdk.java.net
> CC: jason_mehr...@hotmail.com; alan.bate...@oracle.com
> Subject: RFR: 8048020 - Regression on java.util.logging.FileHandler
>
> Hi,
>
> Please find below a patch [1] for [2]:
>
> 8048020 - Regression
Hi,
Please find below a patch [1] for [2]:
8048020 - Regression on java.util.logging.FileHandler
This corresponds to the problem that was discussed on this list
in the following email thread:
"Zombie FileHandler locks can exhaust all available log file locks."
http://mail.openjdk.java.net/pipe
14 matches
Mail list logo
