I believe you problem has to do with a UNIX network (tcp) configuration
setting. We've seen this often in volume testing. The socket is left
in this state for re-use...
Not sure how the configuration is handled on Linux, but on Solaris you
can see all the configuration options with the following:
ndd -get /dev/tcp ?
tcp_time_wait_interval (read and write)
tcp_conn_req_max_q (read and write)
tcp_conn_req_max_q0 (read and write)
tcp_conn_req_min (read and write)
tcp_conn_grace_period (read and write)
tcp_cwnd_max (read and write)
tcp_debug (read and write)
tcp_smallest_nonpriv_port (read and write)
tcp_ip_abort_cinterval (read and write)
tcp_ip_abort_linterval (read and write)
tcp_ip_abort_interval (read and write)
tcp_ip_notify_cinterval (read and write)
tcp_ip_notify_interval (read and write)
tcp_ipv4_ttl (read and write)
tcp_keepalive_interval (read and write)
tcp_maxpsz_multiplier (read and write)
tcp_mss_def_ipv4 (read and write)
tcp_mss_max_ipv4 (read and write)
tcp_mss_min (read and write)
tcp_naglim_def (read and write)
tcp_rexmit_interval_initial (read and write)
tcp_rexmit_interval_max (read and write)
tcp_rexmit_interval_min (read and write)
tcp_deferred_ack_interval (read and write)
tcp_snd_lowat_fraction (read and write)
tcp_sth_rcv_hiwat (read and write)
tcp_sth_rcv_lowat (read and write)
tcp_dupack_fast_retransmit (read and write)
tcp_ignore_path_mtu (read and write)
tcp_rcv_push_wait (read and write)
tcp_smallest_anon_port (read and write)
tcp_largest_anon_port (read and write)
tcp_xmit_hiwat (read and write)
tcp_xmit_lowat (read and write)
tcp_recv_hiwat (read and write)
tcp_recv_hiwat_minmss (read and write)
tcp_fin_wait_2_flush_interval (read and write)
tcp_co_min (read and write)
tcp_max_buf (read and write)
tcp_strong_iss (read and write)
tcp_rtt_updates (read and write)
tcp_wscale_always (read and write)
tcp_tstamp_always (read and write)
tcp_tstamp_if_wscale (read and write)
tcp_rexmit_interval_extra (read and write)
tcp_deferred_acks_max (read and write)
tcp_slow_start_after_idle (read and write)
tcp_slow_start_initial (read and write)
tcp_co_timer_interval (read and write)
tcp_sack_permitted (read and write)
tcp_trace (read and write)
tcp_compression_enabled (read and write)
tcp_ipv6_hoplimit (read and write)
tcp_mss_def_ipv6 (read and write)
tcp_mss_max_ipv6 (read and write)
tcp_rev_src_routes (read and write)
tcp_ndd_get_info_interval (read and write)
tcp_rst_sent_rate_enabled (read and write)
tcp_rst_sent_rate (read and write)
tcp_use_smss_as_mss_opt (read and write)
tcp_wroff_xtra (read and write)
tcp_extra_priv_ports (read only)
tcp_extra_priv_ports_add (write only)
tcp_extra_priv_ports_del (write only)
tcp_status (read only)
tcp_bind_hash (read only)
tcp_listen_hash (read only)
tcp_conn_hash (read only)
tcp_acceptor_hash (read only)
tcp_host_param (read and write)
tcp_time_wait_stats (read only)
tcp_host_param_ipv6 (read and write)
tcp_1948_phrase (write only)
tcp_reserved_port_list (read only)
tcp_close_wait_interval(obsoleted- use tcp_time_wait_interval) (no read
or write)
...Pete
Starbucks Coffee Co. - MS IT-5
2401 Utah Ave S
Seattle, WA. 98134
(w) 206-318-5933
-----Original Message-----
From: Wittmann Armin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 04, 2007 4:23 AM
To: HttpClient User Discussion
Subject: after 60000 requests more than 700 sockets in CLOSE_WAIT
Hi httpclient-Team
over the last 4 days I made a long term test for
our new software release.
This software ist integrated into an Apache Tomcat 5.5
(as a servlet receiving requests, transform them and
sending out other GET-requests through http-client) and should
run very reliable and without any resource leaks.
After finishing this test cycle I noticed that there
remained over 700 sockets in CLOSE_WAIT state
(Linux -> netstat -a -p).
Due to the identified PID and the destination ip number it is
obvious that these sockets have been caused/used
by the program part using http-client-3.0.1.
I am not a real network crack so I don't know if I need
to bother about this. Since the software/tomcat is itended
to run months (7x24) without necessarily rebooting it
I am not shure if I will run out of network resources.
Can somebody help in this subject?
By the way: all 60000 http-GET-requests worked well and there
were no other problems at all.
Regards
Armin
--------------------------------------------------------------------
My Code (simplified):
this code ist executed for every single request
HttpConnectionManager connectionManager = new
SimpleHttpConnectionManager();
HttpClient client = new HttpClient(clientParams, connectionManager);
client.setHostConfiguration(hostConfiguration);
HttpMethod method = = new GetMethod();
method.setQueryString(pairs);
method.setPath(pUrl.getPath());
method.setParams(methodParams);
try {
client.executeMethod(method);
} catch (Exception e) {
failed = true;
throw new Exception(...);
} finally {
if (failed) method.abort();
method.releaseConnection();
client.setHttpConnectionManager(null);
client = null;
}
try {
responseString = method.getResponseBodyAsString();
} catch (Exception e) {
throw new Exception(...);
} finally {
method.releaseConnection();
method = null;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
