Deadlock between FileHandler and ConsoleHandler when using customized formatter

[Peter Levart]

On 12/05/2013 07:54 AM, Shi Jun Zhang wrote:
> On 11/30/2013 12:05 AM, Daniel Fuchs wrote:
>> On 11/29/13 4:56 PM, Alan Bateman wrote:
>>> On 29/11/2013 10:08, Daniel Fuchs wrote:
>>>>
>>>> However, removing or just moving the lock around might well 
>>>> introduce new
>>>> unknown issues - so it will need to be carefully anaIyzed, and I am
>>>> not sure
>>>> it can/should be attempted in a minor JDK release.
>>>>
>>> Yes, we have to be very careful as the logging code has a history of
>>> biting the hand of those that try to improve it. For various 
>>> reasons, it
>>> seems there is a lot of code that has subtle dependencies on the
>>> implementation, on the initialization in particular. In any case, you
>>> are to be applauded for tackling the synchronization issues and it 
>>> would
>>> be a good project to re-examine all of this in JDK 9 to see how it 
>>> would
>>> be simplified.
>>>
>>> On documenting the locking details in an @implNote (which seems to be
>>> one of the suggestions here) then we also need to be careful as I think
>>> we need some flexibility to change some of this going forward.
>>
>> Yes - that's a two edged sword indeed. We certainly don't want to set
>> that in stone... On the other hand I empathizes with developers who
>> struggle to find out what they can - and can't do - when extending
>> j.u.l APIs...
>>
>> Anyway, if usage of the 'synchronized' keyword never appears in
>> the Javadoc I guess that's for good reasons...
>>
>> Thanks Alan,
>>
>> -- daniel
>>
>>>
>>> -Alan
>>
> Hi Daniel,
>
> This thread is silent for several days, do you have any finding in 
> Handler.publish?
>

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