2009-04-24 4 views
2

우리는 IIS 6에서 ASP.NET 3.5의 비동기 HttpHandler를 사용하고 있습니다. 코드가 너무 많이로드되지 않으면 외부 API 호출을 수행하려고합니다. 우리는 "너무 많은로드"를 정의했습니다. 이는 X 이상의 요청이이 API를 동시에 사용하는 경우 API 호출을 건너 뛰는 것입니다.비동기 HttpHandler의 요청이 예외없이 중단 될 수 있습니까?

이 작업을 수행하기 위해 코드를 세마포 및 Try/Catch/Finally로 래핑했습니다. 세마포어를 해제하지 않고이 코드를 실행할 수있는 방법이없는 것처럼 느껴지지만 일부 추가 로깅을 사용하면 릴리스 문이 호출되지 않는 무거운로드가 있음을 알 수 있습니다.

코드는 이것이다 : 우리는 시간을 HttpWebRequest를 밖으로 않는 경우에 대한 예외를 본 적이

static Semaphore requestLimiter = new Semaphore(500, 500); 

... 

String GetResultFromAPI() { 
    if (!requestLimiter.WaitOne(0)) return null; 

    try 
    { 
     // ... code to perform API call, with a timeout specified on the HttpWebRequest 
     return result; 
    } catch { /* ignore exceptions */ } 
    finally 
    { 
     requestLimiter.Release(); 
    } 
    return null; 
} 

, 그래서 우리는이 코드가 requestLimiter 세마포어가 0까지 점점 될 수 있습니다 방법으로 당황있어 결코 회복하지 못한다.

누구에게이 문제가 발생 했습니까? 비동기 HttpHandler가 예외없이 인터럽트 요청을 가질 수있는 방법이 있습니까?

편집 분명히 ThreadAbortExceptions이 코드는 확실히에서 실패 할 더러운 짐승이다. 우리는 Thread.Abort를 명시 적으로 호출하지 않으며 HttpWebRequest가 생각하지도 않습니다. 그러나 수정 된 질문은 ASP.NET이 비동기 http 요청에 대해 Thread.Abort를 호출합니까?

+0

예외를 정말로 무시하고 있습니까? 혹시라도 잡으려고하고 로그인하지 않으시겠습니까? 그것을 ThreadAbortException이라고 두드리기 –

+0

ThreadAbortExceptions는 여전히 finally 블록을 트리거해야합니다. 나는 우리가 거기에 도착하는 것을보기 위해 예외를 로그 할 수 있다고 생각하지만 finally 블록은 항상 실행되어야합니다. – NilObject

답변

2

IIS는 ThreadAbortException을 트리거하는 작업 스레드를 종료 할 수 있으며 ThreadAbortException은 항상 마지막으로 catch되지는 않습니다. 그들은 잡기와 함께 잡힌다. 나는 IIS가 어떤 이유로 웹 요청을 죽일 때이 문제를 겪었습니다. 내 로깅 프로세스가 새 스레드에서 생성되어 오류를 기록하고 Thread.Abort가 여전히 로깅 프로세스를 종료합니다. 마지막으로 {}에 로깅 스레드 스폰을 넣으려고 시도했지만 IIS는 여전히 그것을 종료시킵니다. 나는 그것을 해결하는 방법을 결코 알 수 없었다.

어쨌든, 이벤트 뷰어에서 재활용/죽인 작업자 스레드를 확인하고 응용 프로그램 풀을 확인하고 자주 재활용하지 않거나 다시 시작하지 않도록 설정했는지 확인합니다.

+0

나는 이것이 일어났다 고 생각한다. 중단 된 요청을 설명하기 위해 카운터를 너무 자주 재설정하는 타이머를 사용하여 일부 원자 단위 증분/감소에 대한 세마포를 포기했습니다. 이 솔루션은 아주 잘 작동합니다. – NilObject

2

세마포를 가져 와서 try catch 블록에 들어가는 사이에 threadabort 예외가 발생할 수 있습니다.

그것은 당신의 finally 블록 우회 것 슬로우하는 밴드 예외의 아웃도 가능

편집. Constrained Execution Regions here에 대한 자세한 내용을 볼 수 있습니다.

+0

우리는 어떤 예외도 보이지 않기 때문에 이것은 세마포어 행동의 원인이 아닙니다. 그러나 지적했다. – NilObject