InputStreamReader lässt TCP-Connection offen

[Giftstachel]

Hallo liebe hardcoder

ich bin grade über eine unstimmigkeit in meinem programm gestolpert, und hoffe auf einen guten tip von euch.

mir ist aufgefallen, das aus irgendwelchen gründen meine tcp-connections nicht von meinem programm geschlossen werden, sondern vom windows system.

ich nutze folgenden code:

        URL url = new URL(urlurl);
	Reader is = new InputStreamReader( url.openStream());    
	BufferedReader in = new BufferedReader( is );

zum öffnen eines inputstreams (htlm-connection)

und dann wie üblich

	in.close();
	is.close();

zum schließen.

dabei bleiben jedoch wie es scheint, die tcp-conns offen. wie kann ich das umgehen, verbessern, abändern, damit der mist nicht erst vom windoofhandler beendet wird.

(alle tcp-conns sind im status TIME_WAIT)

danke euch.
giftie

 

[tuxedo]

Hast du denn dadurch irgend welche Performance-Probleme?

Benutze ebenfalls eine UrlConnection und hab selbst bei einigen hundert http aufrufen keine Probleme damit.

- Alex

 

[Giftstachel]

probleme habe ich noch!!! nicht, dieses kann allerdings noch kommen, wenn ich aus irgend einem grunde das programm erweitern muss, und damit dann an die windowseigenen grenzen stoße. ich habe auch keine ahnung, in wie fern es unter umständen es zu einer portkollision kommen könnte, sollte mein prog parallel mehrfach gestartet werden. das windows system hab ich schon abgeändert, das er die conns nicht 180 sec offen lässt, sondern nach 30 sec zu macht. des weiteren würde ich es halt einfach gerne sauber programmieren, und sowas nicht dem betriebssystem überlassen

 

[tuxedo]

Ich denke du musst dich fragen: Wieso ist es so wie es ist? Ich denke du bist nicht der erste der viele URL-Verbindungen benutzt die man nicht explizit schließen kann (zumindest hab ich auch noch keinen Weg gefunden). Es wird schon einen Grund haben warum es so ist wie es ist (auch wenn ich ihn nicht kenne, würd mich aber ebenfalls interessieren).

Das OS wird, so vermute ich (beweisen kann ichs nicht ;-) ), die offenen Verbindungen besser handhaben können als du. Von daher würd ich sagen: Das ist absolut unkritisch. Sonst wäre es vermutlich SUN schon aufgefallen und es gäbe ein "close()" in Verbindung mit der UrlConnection.

Nebenbei: Ich weiß nicht wie ein Browser das macht. Aber zumindest von Webservern her weiß ich, dass die die Verbindung von sich aus zumachen wenn sie nicht mehr gebraucht werden.

 

[FArt]

Annahme: Betriebssystem Linux.

Das ist ein "Feature" des Betriebsystems. Die Zeit, wie lange eine Socket im TIME_WAIT noch bestehen bleibt ist dort konfigurierbar.

Tipp und wichtig: den close in einen finally-Block, damit auch in jedem Fall die Verbindung geschlossen wird!!!!!

 

[tuxedo]

Warum ist das denn ein Feature? Was hab ich davon? *unwissend bin*

Das mit dem "close()": Bei der UrlConnection, bzw. bei dem Fall den Giftstachel beschrieben hat, gibt es kein "close()". Genau das war/ist ja der Knackpunkt.

- Alex

 

[Giftstachel]

@FArt

gibts bei windows auch.

siehe registry:

System Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
Value Name: TcpTimedWaitDelay
Data Type: REG_DWORD (DWORD Value)
Value Data: 30-300 seconds (decimal)

wenn man dort den entsprechenden schlüssel eingibt, klappt das wie bei linux.
das mit dem finally muss ich gleich mal ausprobieren. das ist ne gute idee.

@alex

das .close gibt es. schließ jedoch nur die url-connection, und den buffered-reader(wobei letzteres ein experiment ist, bei dem ich noch nicht nachweisen kann, ob das wirklich etwas bringt).
die tcp-verbindung ist vom closen jedoch vollkommen unabhängig.

von dem systembedingten closen der TCP's hast du, das du performancetechnisch in der gleichen zeit mehr verbindungen verwalten kannst, und somit systembedingt nicht so schnell an die grenzen des OS stößt.

hmm. vielleicht muss ich mich doch mal intensiver mit dem thema auseinandersetzen. prinzipiell müsste es ja auch genügen, wenn ich beim closen der verbindung den zustand time_wait in close_wait umwandel. mal nachguggen, ob ich da was finde.

 

[FArt]

Warum ist das denn ein Feature? Was hab ich davon? *unwissend bin*

Das mit dem "close()": Bei der UrlConnection, bzw. bei dem Fall den Giftstachel beschrieben hat, gibt es kein "close()". Genau das war/ist ja der Knackpunkt.

- Alex

Für den Unwissenden sei der Hinweis zu Google gestattet... es gibt eine Welt außerhalb des Forums: http://www.google.de/search?hl=de&q=socket+time_wait&btnG=Google-Suche&meta=

Prinzipiell gilt: um Probleme mit Systemressourcen zu vermeiden muss der Entwicklerdiese immer konsistent frei geben (z.B. Streams schließen) wenn sie nicht mehr benötigt werden. Dies ist besonders wichtig, wenn ich mit abstrakten Klassen oder Interfaces arbeite. Die Implementierung darunter wird richtig entscheiden, was zu tun ist (echter close, zurück in den Pool, call ignorieren usw.).
Also bearbeite den Stream konsistent, die darunterliegende Connection (hier UrlConnection) wird schon tun was zu tun ist...

 

[Giftstachel]

Naja, so wie ich das bisher recherchiert habe, müsste ich anstatt des URL-Strams, den ich aufbaue, eine komplette kommunikation mit ports, und sockets entwerfen, um wirklich effektiv damit zu arbeiten. die url.close() schließt wirklich nur den stream, und gibt das closen der sockets ans OS zurück. An sich ziemlich seltsam, aber Sun wird sich dabei schon was gedacht haben.
mal sehen, wann ich zeit habe, mir da selber nen url-stream-socket-port-handler ^^ zu basteln. werd den dann gerne hier posten.

 

[tuxedo]

Naja, so wie ich das bisher recherchiert habe, müsste ich anstatt des URL-Strams, den ich aufbaue, eine komplette kommunikation mit ports, und sockets entwerfen, um wirklich effektiv damit zu arbeiten.

Naja, implizit hab ich das ja schon am 03. 06. 2008, 9:03 geschrieben ;-)

- Alex