Sofya,
"Connection: close" in HTTP request is merely a hint which a
not-so-very-well-bred server may choose to ignore. Apparently this is
what WMS does. I am afraid your last option now is to implement a custom
HTTP connection manager that always closes connections upon release.
Oleg
On Fri, 2004-05-14 at 19:02, Preygel, Sofya wrote:
> Oleg,
>
> I have added the "Connection: close" to the HTTPPostMethod headers:
> PostMethod post = new PostMethod(m_URL);
> post.setRequestHeader("Connection", "close");
>
> It did not solve the problem, but what I cannot explain is why even
> after I added this line, I do not see the HTTPConnection.close() method
> being called. Am I doing something correctly? Or is the response
> "keep-alive" option stops the HTTPClient from closing the connection. I
> see the following lines in the log: "Should NOT close connection in
> response to Connection: Keep-Alive". Can it be that the keep-alive
> option on the response header prevents the connection from being closed?
>
> Thank you,
> Sofya
>
> -----Original Message-----
> From: Kalnichevski, Oleg [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 14, 2004 10:35 AM
> To: Commons HttpClient Project
> Subject: RE: 'Socket closed' exception using
>
>
>
> Sofya,
>
> It does sound dubious. There's no way a new instance of
> SimpleHttpConnectionManager can obtain an existing instance of
> HttpConnection. SimpleHttpConnectionManager *always* creates a new
> instance of HttpConnection. It is perfectly possible, though, that an
> open connection lingers in memory for some time until garbage collected,
> since SimpleHttpConnectionManager makes no attempts to close
> connections. However, I do not see how this may prompt the WMS to drop
> another connection used by a totally different instance of
> SimpleHttpConnectionManager, unless there's a bug in the WMS server-side
> connection pool code which causes the pool manager to drop active
> connections when MAX TOTAL is reached. This is a just wild guess on
> part, though
>
> Since your application makes no attempt to re-use connections, you may
> want to send "Connection: close" directive with HTTP requests to ensure
> that the connection is immediately closed once the response is consumed.
> See if that helps circumvent the problem.
>
> Hope this helps a little
>
> Oleg
>
> -----Original Message-----
> From: Preygel, Sofya [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 14, 2004 16:03
> To: Commons HttpClient Project
> Subject: RE: 'Socket closed' exception using
>
>
>
> Good morning,
>
> I am still working on the 'socket connection' problem. According to the
> Connotate tech support a possible reason of getting this exception is
> that the connection is not being closed on the client, but instead,
> released to the pool:
>
> "The socket closure is happening on the WMS side. That is, since the
> connection is not being closed on the client side between each
> invocation, the server eventually enters an invalid state and forcibly
> closes the connection. When that happens depends on a number of things
> and would appear to be almost random from the client point of view... A
> verification of the connection pooling behavior or a test run with code
> that guarantees closure of the connection would be needed to eliminate
> it. "
>
> I am doubtful of this explanation. I create a new HTTPClient object for
> each request (using the SimpleHttpConnectionManager object), and looking
> through the HTTPClient code I do not see how the connection can be
> re-used in such situation. Yet you guys and the guys at Connotate
> certainly know this subject better than I do, and I an eager to try
> everything. My question is: does this explanation seem plausible to you?
> If yes, what would be the way to force-close the connection after the
> request? Can I do this using the "connection: close" header params?
>
> Thank you,
> Sofya
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
> ************************************************************************
> ***************************
> The information in this email is confidential and may be legally
> privileged. Access to this email by anyone other than the intended
> addressee is unauthorized. If you are not the intended recipient of
> this message, any review, disclosure, copying, distribution, retention,
> or any action taken or omitted to be taken in reliance on it is
> prohibited and may be unlawful. If you are not the intended recipient,
> please reply to or forward a copy of this message to the sender and
> delete the message, any attachments, and any copies thereof from your
> system.
> ************************************************************************
> ***************************
>
> ---------------------------------------------------------------------
> 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]
