2011-01-10 17 views
7

Używam klasy Jersey 1.4, ApacheHttpClient i Apache MultiThreadedHttpConnectionManager do zarządzania połączeniami. W przypadku HttpConnectionManager ustawię staleCheckingEnabled na true, maxConnectionsPerHost na 1000, a maxTotalConnections na 1000. Cała reszta jest domyślna. Pracujemy w Tomcat i tworzymy połączenia z wieloma hostami zewnętrznymi za pomocą klienta z Jersey.Gniazda w CLOSE_WAIT z Jersey Client

Zauważyłem, że po krótkim czasie zacznę widzieć gniazda w stanie CLOSE_WAIT, które są powiązane z procesem Tomcat. Niektóre monitorowanie za pomocą tcpdump pokazuje, że hosty zewnętrzne prawdopodobnie zamykają połączenie po pewnym czasie, ale nie zamykają się na naszym końcu. Zwykle jest kilka danych w kolejce odczytu gniazda, często 24 bajty. Połączenia używają protokołu https, a dane wydają się być zaszyfrowane, więc nie jestem pewien, co to jest.

Sprawdziłem, aby upewnić się, że utworzone obiekty ClientRequest zostaną zamknięte. Gniazda CLOSE_WAIT wydają się być poddawane recyklingowi, a tym razem nie brakuje nam żadnych zasobów. Nie jestem pewien, co dzieje się na zewnętrznych serwerach.

Moje pytanie brzmi, czy to normalne i czy powinienem się tym przejmować?

Dzięki,

John

+0

Czy mogę zobaczyć kod? Właśnie o tym słyszałem i chciałbym zobaczyć, jak skonfigurowałeś MultiThreadedHttpConnectionManager na Jersey ... – markthegrea

+0

Niestety, nie mogę opublikować kodu. –

Odpowiedz

1

Może to być urządzenie, takie jak firewall lub zdalnym serwerze limit czasu sesji TCP. Można analizować przechwytuje paczkę HTTPS z wykorzystaniem Wireshark jak opisano na ich stronie SSL:

http://wiki.wireshark.org/SSL

Flaga staleCheckingEnabled emituje tylko sprawdzanie, gdy idziesz do faktycznie korzystać z połączenia, dzięki czemu nie korzysta z zasobów sieciowych (TCP sesje), kiedy nie są potrzebne.