If sent to a SocketNode , remote logging is
non-intrusive as far as the log event is concerned. In other
words, the event will be logged with the same time stamp, NDC , location info as if it were logged locally by
the client.
SocketAppenders do not use a layout. They ship a
serialized LoggingEvent object to the server side.
Remote logging uses the TCP protocol. Consequently, if
the server is reachable, then log events will eventually arrive
at the server.
If the remote server is down, the logging requests are
simply dropped. However, if and when the server comes back up,
then event transmission is resumed transparently. This
transparent reconneciton is performed by a connector
thread which periodically attempts to connect to the server.
Logging events are automatically buffered by the
native TCP implementation. This means that if the link to server
is slow but still faster than the rate of (log) event production
by the client, the client will not be affected by the slow
network connection. However, if the network connection is slower
then the rate of event production, then the client can only
progress at the network rate. In particular, if the network link
to the the server is down, the client will be blocked.
On the other hand, if the network link is up, but the server
is down, the client will not be blocked when making log requests
but the log events will be lost due to server unavailability.
Even if a SocketAppender is no longer
attached to any category, it will not be garbage collected in
the presence of a connector thread. A connector thread exists
only if the connection to the server is down. To avoid this
garbage collection problem, you should close() the the
SocketAppender explicitly. See also next item.
Long lived applications which create/destroy many
SocketAppender instances should be aware of this
garbage collection problem. Most other applications can safely
ignore it.
If the JVM hosting the SocketAppender exits
before the SocketAppender is closed either
explicitly or subsequent to garbage collection, then there might
be untransmitted data in the pipe which might be lost. This is a
common problem on Windows based systems.
To avoid lost data, it is usually sufficient to close() the SocketAppender either explicitly or by
calling the shutdown() method
before exiting the application.
The SocketAppender has the following properties:
On the other hand, if the network link is up, but the server is down, the client will not be blocked when making log requests but the log events will be lost due to server unavailability.
SocketAppenderis no longer attached to any category, it will not be garbage collected in the presence of a connector thread. A connector thread exists only if the connection to the server is down. To avoid this garbage collection problem, you should close() the theSocketAppenderexplicitly. See also next item.Long lived applications which create/destroy many
SocketAppenderinstances should be aware of this garbage collection problem. Most other applications can safely ignore it.SocketAppenderexits before theSocketAppenderis closed either explicitly or subsequent to garbage collection, then there might be untransmitted data in the pipe which might be lost. This is a common problem on Windows based systems.To avoid lost data, it is usually sufficient to close() the
SocketAppendereither explicitly or by calling the shutdown() method before exiting the application.