2011-01-06 23 views
10

Używamy WebClient, .NET 3.5sp1 w aplikacji WinForm. W przypadku niektórych użytkowników wynik jest następujący: w wyjątku z komunikatem:Reprodukuj "Połączenie, które miało pozostać przy życiu, zostało zamknięte przez serwer."

"Połączenie podstawowe zostało zamknięte: połączenie, które miało pozostać przy życiu, zostało zamknięte przez serwer."

Searching nieco całym Internecie sugeruje „naprawić” po prostu wyłączyć http podtrzymywanie, które tak naprawdę nie są zainteresowani w tym, niektórzy sugerują, że może to być błąd w bibliotekach .NET itp

Komunikat o błędzie sugeruje, że jest to utrzymywane połączenie HTTP, które w jakiś sposób zostało zamknięte przez serwer (lub serwer proxy) bez odpowiednich mechanizmów wykrywania przez WebClient.

Myślimy o tym konkretnym przypadku i po prostu spróbuj ponownie. Jednak nie możemy odtworzyć tego wyjątku. Więc.

  1. Jak możemy poprawnie złapać skrzynię, która daje powyższy komunikat o błędzie.

    catch (WebException ex) { if (ex.Message == "Połączenie podstawowe zostało zamknięte: połączenie, które spodziewano się być utrzymywane przy życiu zostało zamknięte przez serwer") {...}

    brzydko pachnie.

  2. Jakieś wskazówki, jak możemy odtworzyć powyższy wyjątek?

+0

'Dla niektórych users' sugeruje, że to nie wszyscy. Czy ci użytkownicy są za proxy (albo jawnie ustawione, albo przezroczyste proxy)? Zajęty serwer proxy w środowisku korporacyjnym może niespodziewanie zrzucić połączenia, stąd wyjątek. Tak czy inaczej, jest to problem sieciowy (klient, host lub bity pośredniczące), a nie błąd w .NET Framework. –

+2

Prawdopodobnie masz rację, że jest to problem z siecią. Dlatego chcemy spróbować po prostu ponowić żądanie, jeśli jest to konkretna, choć wiemy tylko, że ten tekst wywodzi się z wyjątku WebException - czy istnieje niezawodny sposób na wykrycie tego specyficznego wyjątku, jakiegoś określonego kodu błędu lub czego nie? I chcemy go odtworzyć, abyśmy mogli przetestować, że ponowienie żądania nie powoduje innej zła, gdy "połączenie zostało zamknięte". – Habalusa

+0

Otrzymuję ten sam błąd, gdy próbuję wysłać duże dane z warstwy usługi. Jakąkolwiek wskazówkę, dlaczego tak się dzieje? –

Odpowiedz

2

WebClient wykrywa to dobrze. Tak więc wyjątek. Musisz znaleźć serwer, który źle się zachowuje. Nie jestem do końca pewien, co zrobić, jeśli znajdziesz ten serwer, możesz wysłać administratorowi ładną wiadomość e-mail.

Zapisz adres URL serwera.

+0

Cóż, może to być wszystko, od przeciążonej bramy nat zamykającej połączenie przedwcześnie, do serwera pośredniczącego i działającego w górę, z którego żaden nigdy się nie pozna, nie mówiąc już o naprawie. W tym czasie cierpią użytkownicy. Oto także oczywisty stan wyścigu - np. co jeśli serwer poprawnie wysyła zamknięcie połączenia: gdy klient próbuje wysłać nowe żądanie do buforowanego połączenia, ale nie otrzymano jeszcze połączenia. W związku z tym pytanie - jakikolwiek sposób możemy odtworzyć ten wyjątek, i jak sprawdzić ten konkretny pasek przypadku porównując e.Message? – Habalusa

+1

Dostosowanie obsługi wyjątków jest przydatne tylko wtedy, gdy możesz zrobić coś w kodzie, aby rozwiązać problem.Nie można naprawić przeciążonego routera lub serwera balky. A system operacyjny nie może odróżnić. To należy do dużej kategorii WebExceptions, możesz spróbować później, później. Dlatego nie ma dedykowanej klasy wyjątków dla tego błędu. Podobne do IOException ("crap stało się") vs FileNotFoundException ("common crap, może być w stanie to naprawić"). –

1

proponuję rzucić okiem na this blogu Misrosoft: http Client Protocol Problemy

Powiązane problemy