I am trying to keep CLOSE_WAIT close to 0. I also noticed that apache
libs threw error when I was using one instance of HttpClient accross
threads, that's the reason I started using one Httpclient per thread
and then releaseConnection, closeIdleConnection and deleteConnection
after every invocation of doGet in below code.
On Wed, Oct 15, 2008 at 10:03 AM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-10-14 at 17:12 -0700, Mohit Anchlia wrote:
>> So what should be the protocol of shutting down cleanely: Below is the
>> sample code, does the below code look ok?
>>
>
> It all depends on what you are trying to achieve.
>
> Oleg
>
>
>> public class Test {
>> private static MultiThreadedHttpConnectionManager con = new
>> MultiThreadedHttpConnectionManager();
>> private static void doGet(HttpClient client) {
>> System.out.println("CONN POOL " + con.getConnectionsInPool());
>> //System.out.println("DEF CON "
>> +client.getHttpConnectionManager().getParams().getDefaultMaxConnectionsPerHost());
>> //System.out.println("MAX CON " +
>> client.getHttpConnectionManager().getParams().getMaxTotalConnections()
>> );
>>
>> GetMethod get = new GetMethod("http://localhost:8080/s/e";);
>> get.setQueryString("version=V07.08&request_type=1");
>> get.addRequestHeader( "Connection", "close");
>> try {
>> long statusCode = client.executeMethod(get);
>>
>> System.out.println(IOUtils.toString(get.getResponseBodyAsStream()));
>> if (statusCode != HttpStatus.SC_OK) {
>> }
>> Thread.sleep(1000);
>> } catch(IOException ioe){
>> ioe.printStackTrace();
>> }catch (Exception e){} finally {
>> if (get != null) get.releaseConnection();
>> }
>> }
>> public static void main(String []a) throws Exception{
>>
>> HttpConnectionManagerParams params = new
>> HttpConnectionManagerParams();
>> params.setDefaultMaxConnectionsPerHost(2);
>> //params.setMaxConnectionsPerHost(2);
>> params.setMaxTotalConnections(2);
>> con.setParams(params);
>>
>> HttpClient client = new HttpClient();
>> client.getParams().setParameter("http.connection.timeout", new
>> Integer(1000));
>> int i = 0;
>> while ( i++ < 500){
>> client = new HttpClient(con);
>> doGet(client);
>> client = null;
>> con.closeIdleConnections(1000l);
>> //con.deleteClosedConnections();
>> }
>> /////////////
>>
>> Is using HttpClient for entire life span of servlet thread safe? I
>> still don't understand the part where you said HttpClient will not be
>> closed properly, would ".closeIndleConnections" or
>> "deleteClosedConnections" along with "releaseConnections" take care of
>> it.
>>
>> On Tue, Oct 14, 2008 at 3:07 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
>> > On Tue, 2008-10-14 at 23:51 +0200, Christine wrote:
>> >> On Tue, 2008-10-14 at 23:44 +0200, Oleg Kalnichevski wrote:
>> >>
>> >> > > What is the tradeoff between using the same httpClient instance again
>> >> > > and again, or creating a new one on each request? Can you create a
>> >> > > memory leak by using one instance and not closing connections
>> >> > > properly?
>> >> > >
>> >> > It very much depends on what you are trying to accomplish. Generally it
>> >> > is recommended to reuse the HttpClient instance in order to utilize
>> >> > persistent connections more efficiently.
>> >> >
>> >> > What is very important that the connection manager associated with the
>> >> > HttpClient instance is shut down when it is no longer needed. Otherwise,
>> >> > connections will stay open until garbage collected by the JVM, which may
>> >> > take a while. If too many instances of HttpClient are created in a tight
>> >> > loop without being correctly shut down, there will be too many
>> >> > connections kept alive needlessly and the system can run out of
>> >> > resources.
>> >>
>> >> Oleg,
>> >> thanks for the reply. I am reusing one instance, but I was just
>> >> wondering. Using one instance I don't have to shut down connection
>> >> managers, right?
>> >>
>> >
>> > It is a little more complex than that. You do not, as long as that
>> > instance is used for the entire lifespan of the application. One really
>> > ought to shut down the connection manager before it goes out of scope /
>> > becomes garbage. This is especially important for managed environments
>> > such as servlet containers where applications can be undeployed and
>> > redeployed.
>> >
>> >> btw, I'm still a bit confused after switching from 3.x to 4.0, but you
>> >> guys have the documentation right, now. I think you did a good job.
>> >>
>> >
>> > I know the documentation is still lacking. We happily take
>> > contributions.
>> >
>> > Oleg
>> >
>> >
>> >> Christine
>> >>
>> >> >
>> >> > Hope this helps
>> >> >
>> >> > Oleg
>> >> >
>> >> >
>> >> > > >
>> >> > > > Oleg
>> >> > > >
>> >> > > > > ---------------------------------------------------------------------
>> >> > > > > 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]
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > 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]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
