현재 로그는 본질적으로 큐이며, 해당 큐를 수신하고 실제 쓰기 작업을 모두 수행하는 자체 로깅 시스템이 있습니다. 시스템은 TON 로그 메시지를 처리하기 때문에 파일은 분 단위로 10MB 크기를 쉽게 넘을 수 있으므로 호출 스레드에서 실제 로깅을 수행하는 것은 적합하지 않습니다.Log4Net appenders를 별도의 스레드로 실행합니다.
log4net에서 스레딩이 작동하는 방법, log4net이 이러한 유형의 메시지 전달 아키텍처를 이미 지원하는지 또는 다른 유사한 기능이 스레드 환경에서 작동 하는지를 보여주는 온라인 리소스를 찾을 수 없습니다. 저를 도울 기존 기능이 있습니까?
log4net 래퍼를 만들지 않고도이 작업을 수행 할 수 있습니까?
로그 데이터가 특정 순서에 따라 달라지는 경우 스레딩 접근법을 다시 생각해보십시오. 스레딩이이를 방해하여 로그 항목을 순서가 틀린 게시로 끝낼 수 있습니다.
MSMQ (또는 다른 큐 기술)를 사용하여 다른 프로세스로 로그 메시지를 신속하게 게시하여 저장소에 실제 쓰기를 시도해보십시오. 이렇게하면 메시지가 보낸 순서와 똑같이 나타납니다.
좋은 생각은 아닙니다. 트릭은 항목을 대기열에 올려 놓고 단일 대기열에서 처리하는 것입니다. 좋은 예를 보려면 http://www.drdobbs.com/visualstudio/225700095을보십시오.
log4net의 소스 코드를 보면 이런 종류의 질문을 찾을 수 있습니다. 그것은 오픈 소스입니다.
거대한 클래스 라이브러리에서 파고 들기가 조금 더 어렵습니다. 그러나 새로운 Thread를 검색하는 것은 아무런 도움이되지 않습니다. ThreadPool을 검색하면 "일종의"일이 내 용도에 유용한 일을하지만 마크 근처에는 아무 것도 없다는 appender를 보여줍니다. 내 appender를 만들어야합니다. :( –
는 .NET 프레임 워크 4를 사용하는 경우 당신은 내가 큰 성공을 ParallelForwardingAppender 및 AsyncForwardingAppender 펜더를 사용했습니다
로그 시퀀스를 유지하기 위해 BlockingCollection를 사용할 수 있습니다. 이 어 펜더는 다음 저장소에서 사용할 수 있습니다
https://github.com/cjbhaines/Log4Net.Async
ParallelForwardingAppender는 손실없는 메시지 큐를 구현하는 BlockingCollection 및 작업 병렬 라이브러리의 다른 측면을 사용합니다.
AsyncForwardingAppender은 백그라운드 버퍼에 링 버퍼와 10ms 폴링 기간을 사용하여 로깅 충실도보다 응용 프로그램 성능에 우선 순위를 부여합니다.
MSMQ는 특히 매우 중요합니다. 메모리 내 대기열이면 충분합니다. –
메모리 내 대기열은 현재 로거의 현재 구현 방법을 나타냅니다. 나는 그것을 log4net으로 확장하고 그것을 포장해야한다고 생각한다. 또는 내 appender를 만들 수 있습니다. –
그는 대기열을 사용하기 때문에 로깅 순서가 삽입 순서와 일치하므로 문제가 발생하지 않습니다. –