-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b42
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8084247 | emb-9 | Daniel Fuchs | P4 | Resolved | Fixed | team |
If a handler is configured in logging.properties for an abstract node in the logger hierarchy, that is, a node for which the application doesn't keep a strong logger reference, then that node may be garbage collected before the LogManager's Cleaner thread is run - and its associated handlers will not be properly closed at system exit.
For instance, if the logging.properties files defines a handler for com.foo, and the application creates a com.foo.child logger, then com.foo will be garbage collected shortly after com.foo.child, and the handler that the LogManager created for com.foo will not be closed.
The observable symptom is that the lock file associated with any FileHandler configured for com.foo will not be deleted at system exit, since at that time the com.foo logger may have been already garbage collected.
For instance, if the logging.properties files defines a handler for com.foo, and the application creates a com.foo.child logger, then com.foo will be garbage collected shortly after com.foo.child, and the handler that the LogManager created for com.foo will not be closed.
The observable symptom is that the lock file associated with any FileHandler configured for com.foo will not be deleted at system exit, since at that time the com.foo logger may have been already garbage collected.
- backported by
-
JDK-8084247 Handlers configured on abstract nodes in logging.properties are not always properly closed
-
- Resolved
-
- relates to
-
JDK-6774110 lock file is not deleted when child logger is used
-
- Closed
-