You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by ce...@apache.org on 2005/01/05 19:37:54 UTC
cvs commit: logging-log4j/src/java/org/apache/log4j/net SocketAppender.java
ceki 2005/01/05 10:37:54
Modified: src/java/org/apache/log4j/net SocketAppender.java
Log:
Making SocketAppender to the log4j internal logging guidelines.
Revision Changes Path
1.25 +63 -71 logging-log4j/src/java/org/apache/log4j/net/SocketAppender.java
Index: SocketAppender.java
===================================================================
RCS file: /home/cvs/logging-log4j/src/java/org/apache/log4j/net/SocketAppender.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- SocketAppender.java 20 Nov 2004 15:27:05 -0000 1.24
+++ SocketAppender.java 5 Jan 2005 18:37:54 -0000 1.25
@@ -19,7 +19,6 @@
package org.apache.log4j.net;
import org.apache.log4j.AppenderSkeleton;
-import org.apache.log4j.LogManager;
import org.apache.log4j.helpers.Constants;
import org.apache.log4j.spi.LoggingEvent;
@@ -32,73 +31,67 @@
/**
- Sends {@link LoggingEvent} objects to a remote a log server,
- usually a {@link SocketNode}.
-
- <p>The SocketAppender has the following properties:
-
- <ul>
-
- <p><li>If sent to a {@link 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, {@link
- org.apache.log4j.NDC}, location info as if it were logged locally by
- the client.
-
- <p><li>SocketAppenders do not use a layout. They ship a
- serialized {@link LoggingEvent} object to the server side.
-
- <p><li>Remote logging uses the TCP protocol. Consequently, if
- the server is reachable, then log events will eventually arrive
- at the server.
-
- <p><li>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 <em>connector</em>
- thread which periodically attempts to connect to the server.
-
- <p><li>Logging events are automatically <em>buffered</em> 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.
-
- <p>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.
-
- <p><li>Even if a <code>SocketAppender</code> 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 {@link #close} the the
- <code>SocketAppender</code> explicitly. See also next item.
-
- <p>Long lived applications which create/destroy many
- <code>SocketAppender</code> instances should be aware of this
- garbage collection problem. Most other applications can safely
- ignore it.
-
- <p><li>If the JVM hosting the <code>SocketAppender</code> exits
- before the <code>SocketAppender</code> 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.
-
- <p>To avoid lost data, it is usually sufficient to {@link
- #close} the <code>SocketAppender</code> either explicitly or by
- calling the {@link org.apache.log4j.LogManager#shutdown} method
- before exiting the application.
-
-
- </ul>
-
- @author Ceki Gülcü
- @since 0.8.4 */
+ * Sends {@link LoggingEvent} objects to a remote a log server, usually a
+ * {@link SocketNode}.
+ * <p>
+ * The SocketAppender has the following properties:
+ *
+ * <ul>
+ * <li>If sent to a {@link 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, {@link org.apache.log4j.NDC}, location info as if
+ * it were logged locally by the client.
+ * </li>
+ *
+ * <li>SocketAppenders do not use a layout. They ship a serialized
+ * {@link LoggingEvent} object to the server side.</li>
+ *
+ * <li>Remote logging uses the TCP protocol. Consequently, if the server is
+ * reachable, then log events will eventually arrive at the server.
+ *
+ * <p><li>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
+ * <em>connector</em> thread which periodically attempts to connect to
+ * the server.
+ *
+ * <p><li>Logging events are automatically <em>buffered</em> 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.
+ *
+ * <p>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.
+ *
+ * <p><li>Even if a <code>SocketAppender</code> 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 {@link #close}
+ * the the <code>SocketAppender</code> explicitly. See also next item.
+ *
+ * <p>Long lived applications which create/destroy many
+ * <code>SocketAppender</code> instances should be aware of this garbage
+ * collection problem. Most other applications can safely ignore it.
+ *
+ * <p><li>If the JVM hosting the <code>SocketAppender</code> exits before the
+ * <code>SocketAppender</code> 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.
+ *
+ * <p>To avoid lost data, it is usually sufficient to {@link #close} the
+ * <code>SocketAppender</code> either explicitly or by calling the
+ * {@link org.apache.log4j.LogManager#shutdown} method before exiting the
+ * application.
+ *
+ * </ul>
+ *
+ * @author Ceki Gülcü
+ * @since 0.8.4
+ * */
public class SocketAppender extends AppenderSkeleton {
/**
* The default port number of remote logging server (4560).
@@ -294,12 +287,11 @@
}
}
- static InetAddress getAddressByName(String host) {
+ InetAddress getAddressByName(String host) {
try {
return InetAddress.getByName(host);
} catch (Exception e) {
- LogManager.getLogger(SocketAppender.class).error("Could not find address of [" + host + "].", e);
-
+ getLogger().error("Could not find address of [" + host + "].", e);
return null;
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org