I am using a SocketAppender to remotely log to another Java application which is using a ServerSocketReceiver. The SocketAppender is being configured programmatically. The ServerSocketReceiver is being configured using within a logback-text.xml.

I am finding that logging events are being transfer faithfully to the peer with exception of the thread name. The thread name is arriving at the receiving side carries a name in the form 'logbook-n', rather than the name of my application thread.

I find if I override SocketAppender#append() and observe the thread name (by calling #getThreadName), I can see the thread name is correct at this point, and furthermore, the problem disappears: the thread name is transfer to the peer. The act of the observation changes the outcome.

Digging into the code I notice LoggingEvent#getThreadName has a side effect; it sets the thread name if it is not already set. It looks to me like nothing is causing this side effect on the application thread, so it is picking up the thread name of the Logback's executor thread as it serialises the object before it goes down the wire.

Perhaps ch.qos.logback.core.net.AbstractSocketAppender#append be calling ch.qos.logback.classic.spi.ILoggingEvent#prepareForDeferredProcessing?

I am currently working around by calling #prepareForDeferredProcessing like so:

SocketAppender socketAppender = new SocketAppender()
                                    {
                                        @Override
                                        protected void append(final ILoggingEvent event)
                                        {
                                            event.prepareForDeferredProcessing();
                                            super.append(event);
                                        }
                                    };