'메모리에있는'웹 요청에서 예외가 발생합니다.

Question

제 상황은 훨씬 복잡하지만 쉽게 재현 할 수 있습니다. 새로운 ASP.NET MVC 4 웹 응용 프로그램 프로젝트로 시작하여 웹 API를 템플릿으로 선택하면 HomeController에 두 번째 mvc 작업을 추가하기 만하면 Web API를 내부적으로 호출해야합니다.

public async Task<string> TestAPI() 
    { 
     HttpServer server = new HttpServer(GlobalConfiguration.Configuration); 
     using (HttpMessageInvoker messageInvoker = new HttpMessageInvoker(server, false)) 
     { 
      HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Get, "http://localhost:58233/api/values"); 
      request.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json")); 
      var response = messageInvoker.SendAsync(request, new CancellationToken()).Result; 
      return await response.Content.ReadAsStringAsync(); 
     } 

     //server.Dispose(); - if I do that on the second request I get a "Cannot access a disposed object." exception 
    } 

그 것은 첫 번째 요청에서만 작동합니다. 후속 요청에 그것은

'RequestMessageHandlerTracer'의 재산 'InnerHandler는'null이 아니기 때문에 'DelegatingHandler'목록이 유효로 발생합니다. 매개 변수 이름 : 핸들러 정말 내 시스템이 정말 열심히 작업 방법 (또는 다른 곳) 내에서 해당 구성을 재구성 할 수 있습니다 기반 매우 모듈/플러그인이기 때문에 여기에 GlobalConfiguration.Configuration를 사용할 필요가

.

Answer 1

두 번째 요청에서 HttpServer 인스턴스를 다시 사용하는 것이 좋습니다. 모든 요청에 ​​대해 새 서버를 만들고 구성하는 것은 예상 된 사용법이 아니므로 일부 경우에는 문제가 될 수 있습니다. DI 메커니즘을 설정하고 컨트롤러에 HttpServer의 싱글 톤을 삽입하거나 정적 속성에서 액세스하십시오.

또한 HttpMessageInvoker 대신 new HttpClient(httpServer)을 사용하는 것이 좋습니다.

Answer 2

같은 구성 객체를 사용하는 HttpServer이 여러 개 있고 구성에 위임자 핸들러 목록이 비어 있지 않은 경우 동일한 문제가 웹 API에서 발생할 수 있습니다.

MVC/Web API는 요청을 처리 할 때 모든 위임 처리기 (예 : RequestMessageHandlerTracer, 요청 추적을 사용하는 경우)를 연결하고 MVC 서버 처리기를 연결하므로 MVC/Web API가 첫 번째 요청에서 처리기의 파이프 라인을 작성하기 때문에 오류가 발생합니다.

HttpServer 같은 구성 개체를 사용하고 config 개체에 위임 처리기가 포함되어있는 경우 첫 번째 HttpServer이 파이프 라인에 성공적으로 연결됩니다. 두 번째 핸들러는 위임 핸들러가 이미 연결되어 있기 때문에 그렇지 않습니다. 대신 첫 번째 요청/초기화시이 예외가 throw됩니다. (개념적으로 동일하지만 서로 다른 클래스를 사용하고 약간 다른 수정을 할 것이다) 여기에 웹 API의 경우에

더 자세히 : 제 생각에는 webapi batching and delegating handlers

의 MVC 구성 클래스가 순수 설정해야한다, 실제 위임 처리기를 포함하지 않습니다. 대신 구성 클래스는 초기화시 새 위임 처리기를 만들어야합니다. 그렇다면이 버그는 존재하지 않을 것입니다.