JDK-8159877 : Release Note: A new configurable property in logging.properties: java.util.logging.FileHandler.maxLocks
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • OS: generic
  • CPU: generic
  • Submitted: 2016-06-20
  • Updated: 2022-06-17
  • Resolved: 2016-06-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Description
A new "java.util.logging.FileHandler.maxLocks" configurable property is added to java.util.logging.FileHandler.

This new logging property can be defined in the logging configuration file and makes it possible to configure the maximum number of concurrent log file locks a FileHandler can handle. The default value is 100.

In a highly concurrent environment where multiple (more than 101) standalone client applications are using the JDK Logging API with FileHandler simultaneously, it may happen that the default limit of 100 is reached, resulting in a failure to acquire FileHandler file locks and causing an IO Exception to be thrown.
In such a case, the new logging property can be used to increase the maximum number of locks before deploying the application.

If not overridden, the default value of maxLocks (100) remains unchanged.
See java.util.logging.LogManager and java.util.logging.FileHandler API documentation for more details.

Comments
JDK-8193696 covers the release notes for 7u181, 6u191, and 8u171 and has been incorporated. The description needed for those releases was different from the description provided here for 9. Hi Cliff, As mentioned in my one of previous mails, this is a rare scenario where we have two different release notes for the main bug and backport bugs respectively. Please see if the below 2 points are clear to you: JDK-8159877: This RN was applicable only to JDK 9(and above). This RN should not appear on its backports, as the backports have a different approach to fix this issue and hence warrant a different RN. JDK-8193696: This RN should appear only on backports(i.e. jdk8u, jdk7u and jdk6u releases). As mentioned in first point this RN is not applicable for jdk9. Hope this is clear now. [Since we didn’t had any proper solution to handle this scenario, we have taken this approach.] Regards, Ramanand.
24-01-2018