Microsoft MVP성태의 닷넷 이야기
닷넷: 2196. IIS - AppPool의 "Disable Overlapped Recycle" 옵션의 부작용 [링크 복사], [링크+제목 복사],
조회: 2911
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

(시리즈 글이 6개 있습니다.)
.NET Framework: 174. 작업자 프로세스(w3wp.exe)가 재시작되는 시점을 알 수 있는 방법
; https://www.sysnet.pe.kr/2/0/841

.NET Framework: 447. w3wp.exe AppPool 재생(recycle)하는 방법 정리
; https://www.sysnet.pe.kr/2/0/1704

개발 환경 구성: 246. IIS 작업자 프로세스의 20분 자동 재생(Recycle)을 끄는 방법
; https://www.sysnet.pe.kr/2/0/1774

.NET Framework: 643. 작업자 프로세스(w3wp.exe)가 재시작되는 시점을 알 수 있는 방법 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/11145

개발 환경 구성: 702. IIS - AppPool의 "Disable Overlapped Recycle" 옵션
; https://www.sysnet.pe.kr/2/0/13514

닷넷: 2196. IIS - AppPool의 "Disable Overlapped Recycle" 옵션의 부작용
; https://www.sysnet.pe.kr/2/0/13516




IIS - AppPool의 "Disable Overlapped Recycle" 옵션의 부작용

지난 글에 설명한,

IIS - AppPool의 "Disable Overlapped Recycle" 옵션
; https://www.sysnet.pe.kr/2/0/13514

"Disable Overlapped Recycle" 옵션은 특정 상황에서 원치 않는 결과를 가져오기도 합니다. 이러한 좋은 예로, Web Application에서 별도의 TCP 서비스를 하나 추가해서 열어놨다고 가정해 보겠습니다.

아마도 이런 식으로 구현할 수 있을 것입니다.

// 닷넷 프레임워크 기준 예제
// ...[생략]...

namespace WebApplication2
{
    public class WebApiApplication : System.Web.HttpApplication
    {
        static TcpListener _tcpListener = null;

        protected void Application_Start()
        {
            Log("Application_Start (Start)");

            AreaRegistration.RegisterAllAreas();
            GlobalConfiguration.Configure(WebApiConfig.Register);
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);

            if (_tcpListener == null)
            {
                _tcpListener = new TcpListener(IPAddress.Any, 18002);
                _tcpListener.Start();
            }

            Log("Application_Start (End)");
        }

        protected virtual void Application_End()
        {
            if (_tcpListener != null)
            {
                _tcpListener.Stop();
                _tcpListener = null;
            }

            Log("Application_End");
        }

        protected virtual void Application_BeginRequest()
        {
            Log("Application_BeginRequest: " + HttpContext.Current.Request.RawUrl);
        }

        public static void Log(string message)
        {
            System.Diagnostics.Trace.WriteLine($"[{DateTime.Now}, {ValuesController.ProcessId}] WebApplication2 - {message}");
        }
    }
}


"IIS - AppPool의 "Disable Overlapped Recycle" 옵션" 글의 내용을 이해하셨다면 대충 감이 오실 텐데요, 실제로 위의 코드로 로그를 남기는 상태에서 Recycle을 해보면 다음과 같은 상황을 확인할 수 있습니다.

[6628] [2024-01-05 오후 10:11:31, 6628] WebApplication2 - Application_Start (Start) 
[6628] [2024-01-05 오후 10:11:31, 6628] WebApplication2 - Application_Start (End) 
[6628] [2024-01-05 오후 10:11:31, 6628] WebApplication2 - Application_BeginRequest: / 
[6628] [2024-01-05 오후 10:11:31, 6628] WebApplication2 - Application_BeginRequest: /api/Values 
[1740] [2024-01-05 오후 10:12:03, 1740] WebApplication2 - Application_Start (Start) 
[6628] [2024-01-05 오후 10:12:04, 6628] WebApplication2 - Application_End 
[1740] [2024-01-05 오후 10:12:13, 1740] WebApplication2 - Application_End 

6628 w3wp.exe가 뜬 상태에서 Recycle을 시도했더니 새롭게 1740 프로세스가 떠서 Application_Start 이벤트까지 진입했습니다. 하지만, 아직 6628 프로세스에서 열고 있던 TCP 서버가 종료되지 않았으므로 _tcpListener.Start(); 코드에서 예외가 발생하게 됩니다.

이 당시의 이벤트 로그를 보면 이런 항목을 보게 될 것입니다.

Exception information: 
    Exception type: HttpException 
    Exception message: Only one usage of each socket address (protocol/network address/port) is normally permitted
   at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
   at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
   at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
   at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
   at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)
   ...[생략]...

비록 예외가 발생했지만, 새롭게 뜬 w3wp.exe는 비정상 종료까지는 안 합니다. 대신 예외가 발생한 Application 인스턴스의 생성은 실패하고 Application_End 이벤트 단계로 곧바로 진행해 버립니다.

그 사이, 기존의 w3wp.exe는 새로운 프로세스가 비록 Application 개체 생성에 실패했지만 더 이상의 Recycle 단계를 미루지 않고 마찬가지로 Application_End 이벤트 단계를 실행하며 종료합니다. 즉, 이때가 되어서야 (신규 프로세스의 소켓 사용을 방해했던) TCP Listener는 자원을 해제하게 되는 것입니다.




결과적으로, 새롭게 뜬 w3wp.exe는 전체적인 초기화를 ASP.NET 런타임의 초기 부분만 진행하는 선에서 끝이 납니다. 다행인 것은, 이후 요청(예를 들어 /Home)이 들어오면 다시 새롭게 ASP.NET Pipeline을 구축하려고 시도하고, 이 과정에서 다음의 이벤트들이 찍히는 것을 볼 수 있습니다.

[1740] [2024-01-05 오후 10:12:29, 1740] WebApplication2 - Application_Start (Start) 
[1740] [2024-01-05 오후 10:12:29, 1740] WebApplication2 - Application_Start (End) 
[1740] [2024-01-05 오후 10:12:29, 1740] WebApplication2 - Application_BeginRequest: /Home 

여기서 재미있는 것은, preloadEnabled로 인해 발생했어야 할 "/" 요청과 "initializationPage"로 설정해 둔 페이지에 대한 방문 기회가 없어진다는 점입니다. 파이프라인 구축에 실패한 마당에 거기까지 바라는 것은 좀 무리겠죠. ^^

만약 이런 부작용을 원치 않는다면 1) "Disable Overlapped Recycle" 옵션을 true로 바꾸거나, 2) TCP Listener의 생성을 Application_Start 시점보다 미뤄야 합니다.

1번을 선택한다면, IIS는 Recycle 시 현재 서비스 중인 w3wp.exe를 확실히 종료시킨 다음에야 새로운 w3wp.exe를 실행시키는 식으로 동작하기 때문에 TCP 포트 충돌의 위험이 없어집니다.

비록 1번 조치는 간단하지만, 이로 인해 초기 요청에 대한 응답 지연 현상이 다시 부각될 수밖에 없습니다. 따라서, 1번은 임시 조치로만 대응하고, 천천히 시간을 들여 약간 귀찮더라도 2번 방법의 코드 수정을 하는 것이 좋습니다.

참고로, 최악의 조치는 예외를 잡는 것입니다.

protected void Application_Start()
{
    ...[생략]...

    try
    {
        if (_tcpListener == null)
        {
            _tcpListener = new TcpListener(IPAddress.Any, 18002);
            _tcpListener.Start();
        }
    } catch { }
}

만약 저렇게 했다면 _tcpListener는 다시 초기화를 할 수 있는 기회마저 잃어버리게 되고, 아마도 서버 관리자들한테서 "iisreset"을 해야만 동작한다던가, 작업 관리자에서 강제 종료를 한 경우에만 동작이 잘 되더라는... 이상한 피드백을 받게 될 것입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 1/7/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13552정성태2/13/20242703닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20243015닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20243237Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20243527개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20243228개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242985개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20242817Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20242632닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20242720오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20242762Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20242651오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20242877VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20243060Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20242986개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20243332닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20243421닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20243405닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20243371닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
13534정성태1/21/20243151닷넷: 2207. C# - SQL Server DB를 bacpac으로 Export/Import파일 다운로드1
13533정성태1/18/20243183닷넷: 2206. C# - TCP KeepAlive의 서버 측 구현파일 다운로드1
13532정성태1/17/20243210닷넷: 2205. C# - SuperSimpleTcp 사용 시 주의할 점파일 다운로드1
13531정성태1/16/20243218닷넷: 2204. C# - TCP KeepAlive에 새로 추가된 Retry 옵션파일 다운로드1
13530정성태1/15/20242842닷넷: 2203. C# - Python과의 AES 암호화 연동파일 다운로드1
13529정성태1/15/20242861닷넷: 2202. C# - PublishAot의 glibc에 대한 정적 링킹하는 방법
13528정성태1/14/20243031Linux: 68. busybox 컨테이너에서 실행 가능한 C++, Go 프로그램 빌드
13527정성태1/14/20242953오류 유형: 892. Visual Studio - Failed to launch debug adapter. Additional information may be available in the output window.
1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...