JDK-6278014 : java.util.logging.LogRecord.getThreadID() should provide real thread id
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2005-05-31
  • Updated: 2010-05-05
  • Resolved: 2009-04-25
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 7
7 b57Fixed
Description
A DESCRIPTION OF THE REQUEST :
Currently the constructor of LogRecord uses a ThreadLocal to maintain an id for the thread which creates the record.

LogRecord should use java.lang.Thread.currentThread().getID() instead. The Thread class uses a linear incremented long value while LogRecord uses an int. However, overflow will happen nearly never, and could also happen the way LogRecord creates the id.

Additionally, for performance purposes LogRecord should not use a synchronized statement but an atomic operation to keep the internal counter (private static sequenceNumber) in sync.

JUSTIFICATION :
For debugging purposes I need the real thread id. The id provided by LogRecord is nearly useless.

E.g. seeing the real thread id I can associate the worker thread of a client-server connection with the log records without printing info about the thread each time.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Formatters displaying LogRecord.getThreadID() should show the thread id as provided by java.lang,Thread.getID()
ACTUAL -
Actually LogRecord maintains a thread counter for itself and it does it somewhat slowly.

CUSTOMER SUBMITTED WORKAROUND :
Overwrite LogRecord and do it yourself. However, there is no way to solve the (minor) performance issue of the LogRecord constructor.
###@###.### 2005-05-31 06:00:17 GMT

Comments
EVALUATION See description.
21-04-2009