Deadlock between FileHandler and ConsoleHandler when using customized formatter

[Jason Mehrens]

Shi Jun Zhang,
 
This problem is like hooking up your sink drain to your sink faucet.  Even if it you can get it to work you still would not want to use it.   In your code example you could just pre-pend the thread name to the formatter string and return it.  
 
However, if you really, really, really, want to attempt this type of trick you have to use JDK8 and create a custom Filter to generate log records.  If you use a filter, you can ditch the thread local in favor of checking the source class of the log record to determine the proper action.  Or if you are using a JDK prior to JDK8 then install the filter on the logger instead of the handler to avoid the locking.
 
Peter, Daniel,
 
An optimistic tail string would break all formatters that write out summary statistics (num of records, min millis, and max mills).  Instead of changing the formatter synchronization, I think a more useful solution would be to create an AsyncHandler that would disconnect user code from the act of publishing log records.  Then all of handler and formatter locking fall rights into the nice biased locking scenario.
 
Jason

> Hi Shi Jun Zhang,
> 
> I have looked at this, creating a prototype. It re-arranged 
> synchronization in a way so that all Formatter methods are invoked out 
> of synchronized sections. I haven't come forward with this yet, because 
> of two issues:
> - Formatter implementations would suddenly be called multi-threaded. 
> Currently they are invoked from within Handler-instance synchronized 
> sections.
> - Formatter would have to be invoked optimistically to obtain head and 
> tail strings, so it could happen that a head, for example, would be 
> requested concurrently multiple times, but only one of returned heads 
> would be written to stream then.
> 
> The 1st thing seems problematic. I can imagine there exist Formatters 
> that are not thread-safe (for example, using single instance of 
> MessageFormat, which is not multi-threaded) and now just happen to work 
> as a consequence of current StreamHandler implementation detail, but 
> would break if called multi-threaded.
> 
> One way to remedy this is to add a boolean property to Formatter API, 
> say Formatter.isMultiThreaded(), and arrange so that appropriate 
> instances return appropriate values also considering 
> backwards-compatibility...
> 
> So all-in-all this is not a simple patch and I doubt it can be made for 
> JDK8. In JDK9, I think, it will be possible to re-visit this issue, so 
> It would be good to file it as a BUG or RFI.
> 
> 
> Regards, Peter
>