15 초 요청시 연결이 강제로 닫힘

Question

서비스를 완료하는 데 15 초가 걸린 자체 서비스 요청이 있습니다. 문제가 아니겠습니까? 실제로는 서비스 측 타이머가 있으므로 을 최대로 15 초가 걸릴 수 있습니다. 그러나 클라이언트는 "연결이 강제로 닫혔습니다."라는 메시지를보고 자동으로 GET 요청을 두 번 다시 시도하면서 System.Net 계층에서 자동으로 진단을 실행합니다.

아, BTW, 이것은 SOAP이 아닌 상황 (WCF 4 REST Service)이므로 중간에 SOAP 물건이 없습니다. 또한 클라이언트는 브라우저가 아니라 프로그램입니다.

시간을 5 초 (인위적으로 할 수 있음)로 줄이면 재시도가 중지되지만 연결 속도가 너무 빨라지는 것을 설명하기가 어려울 것입니다. HttpWebRequest.KeepAlive 플래그는 기본적으로 true이며 수정되지 않으므로 연결을 유지해야합니다.

재 시도의 타이밍은 흥미 롭습니다. 그들은 우리가 선택한 타임 아웃 (예 : 10, 15 초 또는 기타)이 끝나면 클라이언트 측이 첫 번째 응답을받은 후에 만 ​​반응하는 것처럼 보입니다.

또 다른 한 가지 : 서비스 측면에서 아니요 표시가 없습니다. 그것은 잘 작동하지만 클라이언트에서 요청 재시도의 놀라운 (나에게) 몇 가지를 본다.

나는이 문제를 끈적 거리며 비어 있습니다. keep-alive의 표준은 AFAIK가 100 초를 넘었으므로 클라이언트가 현재와 같은 방식으로 작동하는 이유가 여전히 의아해하고 있습니다. 또한 동작이 System.Net 레이어 내에 있으므로 단계를 밟을 수 없습니다.

여기에 도움을 주시면 매우 감사하겠습니다. 이 연결을 닫기 전에 클라이언트 시간 제한 표시를 보내도록

== Tevya의 ==

Answer 1

답변을 찾았는데 거의 시간 초과와 관련이 없습니다. 오히려이 문제는 응답 데이터의 사용자 지정 직렬화 사용과 관련됩니다. respose 데이터 구조에는 동적으로 나타나는 형식이 있으므로 일반 ASP.NET 메커니즘으로 직렬화 할 수 없습니다.

이 문제를 해결하기 위해 XmlObjectSerializer 개체를 만든 다음 더하기 개체를 System.ServiceModel.Channels.Message.CreateMessage()에 직렬화하여 전달합니다. 여기에 두 가지 잘못된 :

1. 예기치 않은 유형은 메시지에 추가 된 실패 직렬화를 일으킨 [어떻게 여기에 가지 않을 이유]와
2. IT는 CreateMessage() 방법은하지 않는 것으로 나타났다 내용을 즉시 직렬화하지만 은 언젠가 나중에 (아마도 just-in-time)까지 직렬화를 연기합니다.

사용자 작성 서비스 코드가 WCF 인프라로 컨트롤을 반환 할 때까지 개체를 serialize하려는 실제 시도가 발생하지 않았기 때문에이 두 사실이 함께 서버 측에서 검색 할 수없는 serialization 오류를 일으켰습니다.

이제 왜 타임 아웃이 된 것입니까?자, 이 아님이 밝혀졌습니다. 반환되는 개체에 예기치 않은 개체 유형이 있습니다. 특히 처음 N 개의 객체는 그렇지 않습니다. 따라서 제한 시간이 5 초 이상으로 길어지면 N + 1 번째 개체가 알 수없는 형식을 참조했으며 다운로드에 직렬화가 중단되었습니다. 나중에 테스트 한 결과 객체가 하나만 반환 된 경우에도 오류가 발생할 수 있음이 확인되었습니다.

해결 방법은 개체를 사전 처리하여 예기치 않은 형식이 참조되지 않도록하는 것이 었습니다. 그러면 모두 잘됩니다.

== Tevya ==

Answer 2

는 서비스를 변경

.

Answer 3

하드웨어 (라우터, 방화벽,로드 밸런서 등)와 같은 사운드는 구성 선택의 여지가 있기 때문에 RST를 전송합니다.