나는 대답을 찾을 수 없다는 질문이 있습니다 ...페이지 렌더링 시간이 초과되면 어떻게됩니까?
요청 처리 시간보다 오래 걸리는 ASP.Net 페이지가있는 경우 해당 프로세스에 어떤 현상이 발생합니까? 웹 서비스가 중단합니까?
ASP.Net 페이지의 응답 스트림에 XML을 쓰고 있으며 GenerateXML 메서드를 호출하는 시간이 초과한다고 가정 해 보겠습니다. 내 메소드 호출은 어떻게됩니까? 완료되었지만 웹 서버가 시간 초과를보고합니까? 또는 그것은 중단됩니까?
아마도 내 결과를 볼 수있는 테스트를 작성할 수는 있지만 더 많은 결과가있을 수 있습니다.
명확히하자 : (1) 세션 시간 제한 (2) 요청 제한 시간에 적어도 두 개의 시간 초과가 있습니다. 가장 일반적인 시나리오는 요청 시간 초과입니다. 클라이언트는 서버가 살아있을 때까지 몇 분을 기다리지 않으려 고합니다. 평소와 마찬가지로 요청 수명은 세션보다 짧습니다. 이 경우 서버는 일반적인 방법으로 ThreadAbortException을 발생시켜 요청을 종료합니다. 이 예외는 모든 것이 정상인 경우에도 발생하며 요청 처리를 종료합니다.
세션이 끝났을 때 클라이언트는 그것에 대해 알지 않아도됩니다. 자동 화 클라이언트가있는 경우에만 로그인 페이지로 리디렉션됩니다. 그러나 서버 코드는 세션에 저장된 데이터를 잃어 버릴 수 있습니다.
렌더링 프로세스가 세션 시간 초과 그 자체 인에 대해 알지 못하기 때문에 렌더링이 아무 문제없이 완료된다고 가정합니다. 사용자가 렌더링 된 페이지에서 서버로 다시 전송 된 작업을 수행 할 때 tiemout이 실현됩니다.
지금 당장은 어떤 증거로도이를 백업 할 수 없지만 가장 논리적 인 동작입니다. 다른 방법으로는 렌더링 프로세스에서 추가 시간 초과 확인이 필요하지만 CPU 시간 (= 돈)은 들지만 어떤 방법 으로든 세션 보안을 향상시키지는 못합니다.
따라서 내 페이지 요청 (따라서 GenerateXML 메소드)이 실행되고있는 ThreadAbort로 스레드가 다운되면? 이 상황을 처리하는 가장 좋은 방법은 무엇입니까? XML을 캐싱하는 중이지만 항상 시간이 만료되면 캐시되지 않습니다. – Jeff
@Jeff : 저는 항상 이와 같은 답변을 얻는 것을 싫어합니다. 그러나 페이지 렌더러가 * 길게 걸리면 문제는 페이지 렌더링에 있으며 IIS가 세션 관리를 처리하는 방식이 아닙니다. 그래서 개선해야 할 부분입니다. – Treb
나는 많은 것을 알았다. 이 문제를 해결하기 위해서는 더 많은 작업이 필요합니다. 페이지 요청 프로세스를 통해 자신에게 증명할 수 있다고 생각했습니다. – Jeff