2014/02/07 - [OpenSource/log4j&slf4j] - [log4j viewer] otroslogviewer (SocketHub 사용)
<< 테스트 시작 >>
ERROR 발생!
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.7-b02 mixed mode):
"SimpleAsyncTaskExecutor-5788" prio=10 tid=0x00002aab080bd000 nid=0xbfc waiting for monitor entry [0x00002aab1c947000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.log4j.Category.callAppenders(Category.java:204)
- waiting to lock <0x00000006a05f3390> (a org.apache.log4j.spi.RootLogger)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.slf4j.impl.Log4jLoggerAdapter.debug(Log4jLoggerAdapter.java:204)
at org.apache.ibatis.logging.slf4j.Slf4jImpl.debug(Slf4jImpl.java:47)
at org.mybatis.spring.SqlSessionUtils.closeSqlSession(SqlSessionUtils.java:165)
at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:372)
at $Proxy307.insert(Unknown Source)
at org.mybatis.spring.SqlSessionTemplate.insert(SqlSessionTemplate.java:237)
at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:79)
at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:40)
쓰레드 full 발생...Block 되는 현상 발생....먹통!! OTL
SocketAppender로 SocketServer 에 log를 전달 할 때 그 갯수가 많으면...
라인별로 쓰레드가 발생하는 것 같다. 고로 full이 나면 Block이 된다..-0-
<< 조치 사항 >>
AsyncAppender 도입하여 테스트를 해보자!
log4j.xml 내용
<appender name="async" class="org.apache.log4j.AsyncAppender"> <appender-ref ref="socket" /> <param name="Blocking" value="false"/> <param name="bufferSize" value="256"/> <param name="locationInfo" value="true" /> </appender>
<appender name="socket" class="org.apache.log4j.net.SocketAppender"> <param name="RemoteHost" value="${socket.server.info}" /> <param name="Port" value="${socket.server.port}" /> <param name="ReconnectionDelay" value="10000" /> <param name="Threshold" value="ALL" /> <param name="locationInfo" value="true" /> </appender> |
테스트 코드를 짜서 테스트를 해보자!
<< 참 조 >>
아래 붉은색 참조 http://wiki.apache.org/logging-log4j/SocketHubAppender
Sends LoggingEvent objects to a set remote a log servers, usually a SocketNode. Acts just like SocketAppender except that instead of connecting to a given remote log server, SocketHubAppender accepts connections from the remote log servers as clients. It can accept more than one connection, and when a log event is handled, the event is sent to the set of currently connected remote log servers. Implemented this way it does not require any update to the configuration file to send data to another remote log server. The remote log server simple connects to the host and port the SocketHubAppender is running on. However, given the nature of accepting connections on-the-fly, it cannot be guaranteed that all events will be received while the tcp connection is in process. But once connected, it should behave the same as SocketAppender. This implementation borrows heavily from the SocketAppender implementation as an example. The SocketHubAppender has the following properties: · 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, org.apache.log4j.NDC, location info as if it were logged locally by the client. · SocketHubAppenders do not use a layout. They ship a serialized LoggingEvent object to the server side.
· 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. · If the JVM hosting the SocketHubAppender exits before the SocketHubAppender 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 SocketHubAppender either explicitly or by calling the shutdown method before exiting the application. |
http://fredpuls.com/site/softwaredevelopment/java/log4j/log4j_performance_tips.htm
- To be Continue..... -
'OpenSource > log4j&slf4j' 카테고리의 다른 글
log4j2 보안 취약성 발생! (0) | 2021.12.14 |
---|---|
log4j2 를 설정 해보자! (0) | 2014.05.29 |
[Local] 통합log 처리 방법, log4j, SocketAppender + SocketHubAppender (3) | 2014.02.18 |
[log4j viewer] otroslogviewer (SocketHub 사용) (0) | 2014.02.07 |
log4j를 알아보자 (0) | 2014.01.09 |