On Wed, 16 Apr 2025 12:12:14 GMT, David Beaumont wrote:
> Increasing timeout for deadlock detection and adjusting for the timeout
> factor in higher tiers.
This pull request has now been integrated.
Changeset: e01e33d1
Author: David Beaumont
Committer: Daniel Fuchs
URL:
> Increasing timeout for deadlock detection and adjusting for the timeout
> factor in higher tiers.
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Removing test from the problem list.
-
Changes:
- all:
Increasing timeout for deadlock detection and adjusting for the timeout factor
in higher tiers.
-
Commit messages:
- Increasing timeout for deadlock detection.
Changes: https://git.openjdk.org/jdk/pull/24687/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24687&range=00
Add null pointer guard in test formatter (since it can be called with a log
record without parameters).
-
Commit messages:
- Adding null check for test formatter.
Changes: https://git.openjdk.org/jdk/pull/24619/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24619&range=00
On Mon, 14 Apr 2025 10:56:45 GMT, David Beaumont wrote:
> Add null pointer guard in test formatter (since it can be called with a log
> record without parameters).
This pull request has now been integrated.
Changeset: 313c34ae
Author: David Beaumont
Committer: Daniel Fuch
On Tue, 8 Apr 2025 11:00:27 GMT, David Beaumont wrote:
> 8353683: j.u.l.Handler classes create deadlock risk via synchronized
> publish() method.
>
> 1. Remove synchronization of calls to publish() in Handlers in
> java.util.logging package.
> 2. Add explanatory comments t
On Tue, 8 Apr 2025 16:15:13 GMT, Chen Liang wrote:
>> 8353683: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affected
On Tue, 8 Apr 2025 11:00:27 GMT, David Beaumont wrote:
> 8353683: j.u.l.Handler classes create deadlock risk via synchronized
> publish() method.
>
> 1. Remove synchronization of calls to publish() in Handlers in
> java.util.logging package.
> 2. Add explanatory comments t
8353683: j.u.l.Handler classes create deadlock risk via synchronized publish()
method.
1. Remove synchronization of calls to publish() in Handlers in
java.util.logging package.
2. Add explanatory comments to various affected methods.
3. Add a test to ensure deadlocks no longer occur.
Note that
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Tweak wording.
-
Changes:
- all: https://
On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont wrote:
> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
> publish() method.
>
> 1. Remove synchronization of calls to publish() in Handlers in
> java.util.logging package.
> 2. Add explanatory comments t
On Wed, 2 Apr 2025 13:54:03 GMT, Daniel Fuchs wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Reworking user warnings about synchronization and deadlocking based on
>> Joe's c
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Reworking user warnings about synchronization and deadlo
On Mon, 3 Mar 2025 10:15:53 GMT, David Beaumont wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2.
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Final round of comment tweaks.
-
Changes:
- al
On Sun, 2 Mar 2025 03:16:02 GMT, Jason Mehrens wrote:
>> I'd have to disagree with the points you make.
>>
>> The fact is that loggers are never expected to modify the passed parameters.
>> To ask people to "disown" the parameters they pass to a logger requires that
>> your best advice on how
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Final round of comment tweaks.
-
Changes:
- al
On Tue, 25 Feb 2025 01:19:14 GMT, Stuart Marks wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/u
On Fri, 28 Feb 2025 09:28:29 GMT, Daniel Fuchs wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix @implNote to @apiNote.
>
> src/java.logging/share/classes/java/util/loggi
On Fri, 28 Feb 2025 01:00:49 GMT, Stuart Marks wrote:
>> src/java.logging/share/classes/java/util/logging/StreamHandler.java line 184:
>>
>>> 182: *
>>> 183: * @param record description of the log event. A null record is
>>> 184: * silently ignored and is not pub
On Fri, 28 Feb 2025 01:09:21 GMT, Stuart Marks wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix @implNote to @apiNote.
>
> src/java.logging/share/classes/java/util/loggi
On Tue, 25 Feb 2025 11:35:18 GMT, David Beaumont wrote:
>> src/java.logging/share/classes/java/util/logging/Formatter.java line 94:
>>
>>> 92: * important to avoid making callbacks to unknown user-provided
>>> arguments
>>> 93: * (e.g. log r
On Thu, 27 Feb 2025 14:07:17 GMT, Jason Mehrens wrote:
>> Need to update to have single call to getFormatter().
>
>>Keeping an unformatted log record around for any time after the log statement
>>that created it has exited would be quite problematic (it prevents GC of
>>arbitrary things).
>
>
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Fix @implNote to @apiNote.
-
Changes:
- al
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Make class level docs just docs (no annotation).
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Rewording notes and spec changes in docs.
Small ch
On Tue, 25 Feb 2025 01:27:04 GMT, Stuart Marks wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/util/
On Tue, 25 Feb 2025 01:18:35 GMT, Stuart Marks wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/util
On Tue, 25 Feb 2025 01:17:21 GMT, Stuart Marks wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/uti
On Tue, 25 Feb 2025 01:12:55 GMT, Stuart Marks wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/uti
On Mon, 24 Feb 2025 13:03:38 GMT, David Beaumont wrote:
>> src/java.logging/share/classes/java/util/logging/Handler.java line 47:
>>
>>> 45: *
>>> 46: * Subclass Implementation Notes
>>> 47: *
>>
>> Have you looked at how this is rendered
On Mon, 24 Feb 2025 12:19:19 GMT, Daniel Fuchs wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adding @implNote to new JavaDoc.
>
> src/java.logging/share/classes/java/util/logging/
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Tweaking @implNote for better rendering.
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Adding @implNote to new JavaDoc.
-
Changes:
On Fri, 21 Feb 2025 10:41:25 GMT, Daniel Fuchs wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Updating code and tests according to feedback and discussions.
>
> src/java.logging/s
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Updating code and tests according to feedback and discus
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Revert to original state (no stream hooks).
On Tue, 18 Feb 2025 02:08:58 GMT, Jason Mehrens wrote:
>> The issue with a non-JDK stream handler subclass, is that it doesn't have
>> the privilege of being able to do anything before the `super.publish(...)`
>> call has finished and the handler instance is unlocked.
>>
>> Using a package pro
On Fri, 14 Feb 2025 19:51:19 GMT, Jason Mehrens wrote:
>> The reason I'm pushing back a little here is that the idea of making a
>> "secret handshake" method between StreamHandler and FileHandler isn't a
>> solution for anyone who made their own handler (e.g. an
>> "EncryptedLogFileHandler" th
On Fri, 14 Feb 2025 15:50:20 GMT, Daniel Fuchs wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Reworking FileHandler so rotation occurs synchronously after the last log
>> entry is
e deadlocks no longer occur.
>
> Note that this change does not address issue in MemoryHandler (see
> JDK-8349208).
David Beaumont has updated the pull request incrementally with one additional
commit since the last revision:
Reworking FileHandler so rotation occurs synchronously after
On Fri, 14 Feb 2025 15:01:37 GMT, David Beaumont wrote:
>> src/java.logging/share/classes/java/util/logging/StreamHandler.java line 210:
>>
>>> 208: if (!doneHeader) {
>>> 209: writer.write(getForma
On Fri, 14 Feb 2025 06:14:34 GMT, Jason Mehrens wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affec
On Fri, 14 Feb 2025 10:39:54 GMT, David Beaumont wrote:
>>>Yes, it's certainly something you can deliberately provoke in a way that
>>>wasn't possible before.
>>
>> Setting limit to 1 byte with a large count is a way to make sure each log
>>
On Fri, 14 Feb 2025 06:04:09 GMT, Jason Mehrens wrote:
>> Yes, it's certainly something you can deliberately provoke in a way that
>> wasn't possible before.
>> However I'm not sure that the statement "Old code should only allow at most
>> 2 records ...", while true of the code itself was ever
On Thu, 13 Feb 2025 19:38:47 GMT, Jason Mehrens wrote:
>> We could, but I don't think it matters. This issue is the first one pointed
>> out in the CSR, and my current feeling is that since it's stated that the
>> limit is "best effort" and there's always the chance that the final log
>> befor
On Thu, 13 Feb 2025 09:36:08 GMT, David Beaumont wrote:
>> test/jdk/java/util/logging/LoggingDeadlock5.java line 115:
>>
>>> 113:
>>> 114: private static class DeadLocker {
>>> 115: private final static Duration JOIN_WAIT =
>>> Dura
On Wed, 12 Feb 2025 18:28:19 GMT, Daniel Fuchs wrote:
> The code changes look reasonable. WRT to detecting deadlocks a possibility is
> also to use `ManagementFactory.getThreadMXBean().findDeadlockedThreads();`
>
> See for instance
>
> https://github.com/openjdk/jdk/blob/336d0d8592aed734e7b813
On Wed, 12 Feb 2025 20:07:51 GMT, Daniel Fuchs wrote:
>> src/java.logging/share/classes/java/util/logging/FileHandler.java line 755:
>>
>>> 753: synchronized(this) {
>>> 754: flush();
>>> 755: if (limit > 0 && (meter.written >= limit || meter.written
>>> < 0)) {
On Thu, 13 Feb 2025 00:30:14 GMT, Stuart Marks wrote:
> A couple days ago the bot warned
>
> > This pull request contains merges that bring in commits not present in the
> > target repository.
>
> I'm not sure why this happened. It might be because of this commit earlier in
> this branch:
>
On Thu, 6 Feb 2025 16:27:19 GMT, Chen Liang wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affected
8349206: j.u.l.Handler classes create deadlock risk via synchronized publish()
method.
1. Remove synchronization of calls to publish() in Handlers in
java.util.logging package.
2. Add explanatory comments to various affected methods.
3. Add a test to ensure deadlocks no longer occur.
Note that
52 matches
Mail list logo
