예외 처리

Photon 3.0 의 예외 처리는 완전하게 재설계 되었습니다.
이전 버전의 전략은 모든 예외를 Photon 프레임워크(photonsocketserver.dll) 내에서 캐치 하는 것이었고 로깅 퍼사드(facade)를 통하여 로그를 기록 하는 것 이었습니다.
이 설계에는 몇 가지 약점이 있었습니다:

• 처리되지 않은 예외 이벤트 핸들러는 호출 되지 않습니다: 개발자가 예외처리를 하지 않았을 때 처리되지 않은 예외 이벤트 핸들러로 통지 되는 것이 CLR 의 기본 행위 입니다.
• 로깅시 예외 처리 의존성: 개발자는 로깅 퍼사드를 구현 해야 했습니다. 구현 하지 않으면 "lost" 예외가 발생 될 수 있었습니다.
• 처리되지 않은 예외의 단 한가지 행위: Photon 이 캐치하는 예외 중 개발자가 처리하지 않은 예외들은 로그에 기록되고 무시됩니다. 닷넷 1.x의 "런타임 백스탑(backstop)"과 유사한 방식으로 효과적으로 수행합니다.
• 일관성 없는 동작: 개발자가 제어하고 있지 않은 스레드에서 예외가 발생하면 예외 핸들러가 발생되고 프로세스가 종료 됩니다.

Photon 3.0 의 새로운 기능:

• 처리되지 않은 예외 이벤트 핸들러는 항상 호출 됩니다: 개발자가 처리하지 않은 예외들은 처리되지 않은 예외 이벤트 핸들러를 항상 발생시킵니다.
• 비방해 로깅: 개발자가 처리되지 않은 예외 핸들러를 구현하도록 권장하지만 개발자가 처리하지 못한 예외들은 Photon 이 로그를 개별적으로 기록 합니다. 아래의 "Logging" 섹션에서 상세내용을 참고 하세요.
• 처리되지 않은 예외의 3가지 정책: 처리되지 않은 예외가 발생했을 때 Photon 은 3가지 정책을 지원 합니다 - 무시, 어플리케이션 재시작, 프로세스 종료 입니다.
• 일관된 동작

몇 가지 경우에 있어서 예외 처리 정책은 CLR에 의해 무시 될 수 있습니다. 즉, ThreadAbortException 은 프로세스를 재시작 하거나 종료 할 필요가 없습니다.
매니지드 스레드의 예외를 참고 하세요. StackOverflowException 은 무시 될 수 없습니다 - StackOverflowException Class 를 살펴 보세요.
예외 발생(exception throwing) 과 처리의 모범사례에 대해서는 다음 페이지 Exception Handling Best Practices in .NET를 참고 하세요.

UnhandledExceptionPolicies 사용 법의 제안

Microsoft는 .NET 2.0에 새로운 기본 정책으로 "Terminate Process" 를 도입하였고
다음은 매니지드 스레드에서의 예외에 대한 인용문입니다:

어플리케이션이 종료되지 않고 스레드에 오류가 발생할 수 있는 경우 심각한 프로그래밍 문제를 발견하지 못할 수 있습니다. 이것은 확장된 기간 동안 실행되는 서비스와 기타 어플리케이션의 특정 문제입니다. 스레드에 오류가 발생하면 프로그램 상태가 서서히 손상됩니다. 응용 프로그램 성능이 저하되거나 응용 프로그램이 중단될 수 있습니다.

개발과 테스트 진행 할 때는 스레드에서 처리되지 않은 예외를 허용하여 운영체제가 프로그램을 종료할 때 까지 진행할 때 발생되는 문제를 노출시킨 후 문제를 파악 하여 해결 할 수 있도록 합니다. 프로그램에 대한 오류 리포트는 디버깅을 도와 줍니다.

하지만 단계 또는 프로젝트 상황(개발, 품질검사, 가동 중인 알려진 이슈가 없는 단계)에 따라 Photon 이 지원하는 다음 정책 중 하나를 사용 해야 합니다.

• 어플리케이션 재시작(Restart Application)
• 무시(Ignore)
• 프로세스 종료(Terminate Process)

개발시에는 "프로세스 종료" 로 설정 해 놓아 프로세스가 종료 되었을 때 Visual Studio가 디버거를 실행할 수 있도록 설정 합니다.
멀티 스레드 문제를 처리하고 있다면 프로세스를 계속 실행하고 어플리케이션이 로드된 상태로 유지 하려면 "무시" 정책이 더 좋을 것 입니다.

품질검사(QA) 단계에서, 스트레스 테스트 또는 수동 테스트 과정 동안에 "프로세스 종료" 정책을 사용하면 루트-오류에서 가지 친 오류가 넘쳐나는 현상을 피할 수 있습니다.

가동중 안정화단계 - 서비스가 안정하다고 가정하면 "어플리케이션 재시작" 정책 사용을 고려 할 수 있습니다.
어플리케이션에서 처리되지 않은 예외 이벤트가 드물다면 Photon 이 어플리케이션을 재시작하는 것으로 리스크를 최소화 할 수 있을 것 입니다. -
이 방식이 정상으로 돌아오기 위한 시스템에서 가장 빠른 방식 입니다.
Photon 정책을 "프로세스 종료" 정책으로 설정 하고 윈도우 서비스에 자동 재시작 기능을 이용하는 것보다 빠릅니다.
노트 : 이런 상황이 자주 발생하는 경우에는 서비스와 로그 파일을 모니터링 해야 합니다.

알려진 이슈가 있는 가동중인 시스템 - 만약 시스템이 예상되지 않은 예외가 자주 발생하게 된다면 보완해야 합니다 - 이 예외사항에 대해서 정책을 "무시"로 설정하여도 시스템이 꽤 안정적으로 운영 될 수 있는 지 여부에 따라서 결정 합니다.

StackOverflows에 대한 노트: 일반적으로 stacktrace는 처리되지 않은 예외에 대한 로그를 기록 시에 수정해야할 부분에 대하여 기록 할 것 입니다.
StackOverflowException 은 처리되지 않은 예외 정책이 "Ignore" 또는 "RestartApplication"로 설정된 경우에 stacktrace 가 무엇을 할지 모르는 경우 입니다.

Debugging Core 에 대한 노트: 매우 드문 경우에 Photon Core 가 처리되지 않은 예외를 발생 시킬 수 있습니다."ProduceDump" 를 항상 설정하는 것을 권장합니다.
`상세 내용에 대해서는 "Photon Core Debugging" 을 보시고 저희에게 발생된 덤프파일과 로그를 보내주시면 수정에 도움을 드릴 수 있습니다.

처리되지 않은 예외 로깅

아래 그림에 표시한 대로 처리되지 않은 예외 이벤트는 커스텀 어플리케이션 컨텍스트(1)내에서 최초 발생됩니다.
여기는 개발자가 원하는 모든 곳에서 예외 로그를 기록 할 수 있는 곳 c) 입니다.
Lite , Lite Lobby 등의 샘플 코드를 참조 하시기 바랍니다.

두 번째 단계에서 CLR 은 Photon 의 경우 PhotonHostRuntime 인 디폴트 어플리케이션 도메인 (2) 에서 이벤트를 발생 시킵니다.
Photon 이 예외를 b)에 로그 기록 할 수 있기 때문 입니다.

Photon Loggingfile 디폴트 경로/파일명

a [$PhotonBaseDir]\bin_[$OS]\log\Photon-[$InstanceName]-[$date].log

b [$PhotonBaseDir]\bin_[$OS]\log\PhotonCLR.log

c [$PhotonBaseDir]\log\[$ApplicationName].log

UnhandledException 정책 설정

XML

    <Runtime
      Assembly="PhotonHostRuntime, Culture=neutral"
      Type="PhotonHostRuntime.PhotonDomainManager"
      
      UnhandledExceptionPolicy="Ignore"

UnhandledExceptionPolicy 는: ReloadAppDomain, Ignore 또는 TerminateProcess 로 설정할 수 있습니다.

Photon Core 디버깅

XML

   <!-- Instance settings -->
    <Instance1
        ...
        ProduceDumps = "TRUE"
        DumpType = "Full"
        MaxDumpsToProduce = "2"
        ...

ProduceDumps 는: TRUE 또는 FALSE , DumpType: Full, Maxi 또는 Mini 로 설정 할 수 있습니다.

Back to top