[PATCH #17331 etc.] SocketAppender - please read inside...

[Joern Huxhorn <jo...@gmx.de>]

Hi again.

Please ignore my last patch - it was broken and I didn't realize it 
because I checked the change with a wrong classpath :(

Things changed in this patch:
- it actually works in contrast to my last patch.....
- instead of using an ObjectOutputStream directly...
  - a ByteArrayOutputStream (initial size of 2kb) is used that's created 
once and then reused to hold the bytes of Objects written by the 
ObjectOutputStream to prevent blocking.
  - the ObjectOutputStream is created once with the 
ByteArrayOutputStream as parameter.
  - the ObjectOutputStream is reset() after every write because that's 
exactly what we want.
  - these serialized bytes are written into a BufferedOutputStream 
instead of using an ObjectOutputStream directly which should also 
prevent blocking.
  - I removed all traces of the reset-counter because we have to call 
reset() on the ObjectOutputStream anyway. We don't want/need optimized 
serialization because the serialized events should be independent.
- I synchronized all access to the BufferedOutputStream on the 
SocketAppender because it really should be synchronized ;) and I don't 
see any deadlock-problems.
- I specifically fixed a wrong synchronized(this) at line 363 which 
should've been synchronized(SocketAppender.this) instead.
- I changed all LogLog.error's and warn's. In case of 
connection-problems I now call LogLog.warn(msg) followed by a 
LogLog.debug(msg, exception) to  fix bug #17331. This way the ordinary 
user isn't bugged with the stack-trace while developers can still see it.

All in all the changes should reduce the risk of losing events as 
described in the SocketAppender-Javadocs. They do exactly that for me.
The problem is still present (especially if Chainsaw runs on the same 
machine as the logging app) but won't appear most of the time. If the 
receiver has enough CPU-time it won't lose much events if any anymore.

BTW, it helps to keep Chainsaw active while the logging app is running 
since this increases it's priority and decreases the priority of the 
logging app (in Windows).
The risk of losing events could be reduced even more if the 
SocketNode/SocketReceiver-Thread would run with a priority of 
Thread.NORM_PRIORITY+1.

I'd like to have some feedback on this if possible.

Yours, Joern.

**