You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Paranoid <pa...@ukr.net> on 2006/11/03 09:57:40 UTC
InputStream.close() question
hi all!
have a little question...
code:
OutputStream out = new BufferedOutputStream(new FileOutpuStream(targetFile));
GetMethod get = new GetMethod();
HttpClient.getInstance().executeMethod(get);
InputStream in = get.getResponseBodyAsStream();
/* do some job */
out.flush();
out.close(); // works fine, takes 0 millis if testing
in.close(); // this block takes about 48 seconds!!
get.releaseConnection();
look at last 2 lines of code. may be i'm doing something wrong? using
MultiThreaded and need multi-threaded application. there was something in
documentation that i dont need to release
connections - HttpClient will try to reuse it. ok, thats good, but what to do
with inputStream.close() ? i dont need even to close inputStream?
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: encoded or not encoded ? :)
Posted by Tomm Krause <da...@gmx.net>.
OK,
that make sense for a better debugging.
Thank you for your fast help, :)
bastian
> On Thu, 2006-11-09 at 11:58 +0100, dasKleineb@gmx.net wrote:
> > Hello there,
> >
> > HttpClient connect to a server and using https.
> > For that the program use a selfimplemented
> > SSLProtocolSocketFactory().
> >
> > The server accept the certificate and the
> > handshake is fine.
> >
> > How can I figure out if the connection is
> > really encoded ?
> >
> > The logs on the client showed the password in
> > plain text. I turned of the following one :
> >
> > "httpclient.wire.content"
> >
> >
> > So maybe it will be encoded afer it is logged ?
> > How can I go sure that it is really encoded?
> >
>
> Bastian,
>
> Rest assured, the content gets logged before it is written to the
> underlying socket. Feel free to use a traffic analyzer to make sure it
> is indeed the case.
>
> Oleg
>
> > Thanks for help,
> >
> > bastian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: encoded or not encoded ? :)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2006-11-09 at 11:58 +0100, dasKleineb@gmx.net wrote:
> Hello there,
>
> HttpClient connect to a server and using https.
> For that the program use a selfimplemented
> SSLProtocolSocketFactory().
>
> The server accept the certificate and the
> handshake is fine.
>
> How can I figure out if the connection is
> really encoded ?
>
> The logs on the client showed the password in
> plain text. I turned of the following one :
>
> "httpclient.wire.content"
>
>
> So maybe it will be encoded afer it is logged ?
> How can I go sure that it is really encoded?
>
Bastian,
Rest assured, the content gets logged before it is written to the
underlying socket. Feel free to use a traffic analyzer to make sure it
is indeed the case.
Oleg
> Thanks for help,
>
> bastian
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
encoded or not encoded ? :)
Posted by da...@gmx.net.
Hello there,
HttpClient connect to a server and using https.
For that the program use a selfimplemented
SSLProtocolSocketFactory().
The server accept the certificate and the
handshake is fine.
How can I figure out if the connection is
really encoded ?
The logs on the client showed the password in
plain text. I turned of the following one :
"httpclient.wire.content"
So maybe it will be encoded afer it is logged ?
How can I go sure that it is really encoded?
Thanks for help,
bastian
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re[2]: InputStream.close() question
Posted by Paranoid <pa...@ukr.net>.
thanx alot! this will really help!!
> Hi Paranoid,
>
> > in.close(); // this block takes about 48 seconds!!
> > get.releaseConnection();
> >
> > look at last 2 lines of code. may be i'm doing something wrong? using
> > MultiThreaded and need multi-threaded application. there was something in
> > documentation that i dont need to release
> > connections - HttpClient will try to reuse it. ok, thats good, but what to do
> > with inputStream.close() ? i dont need even to close inputStream?
>
> You have to release connections. Always. No reuse unless released.
>
> If you close the input stream or release the connection, HttpClient
> will try to read data until the response has been received completely.
> That is the only way to keep the connection alive for another request.
> If the server sends a huge response, or takes very long to respond,
> then closing/releasing gracefully will be slow. If you know in advance
> that you don't want to read the full response, disable keep-alive by
> sending a "Connection: close" header with the request. If you decide
> at runtime not to read the rest of the response, you can call
> HttpMethod.abort() to shutdown the streams without reading the rest
> of the response. You still have to release the connection afterwards.
>
> Always release the connection. Do it in a finally{} block.
>
> cheers,
> Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: InputStream.close() question
Posted by Roland Weber <ht...@dubioso.net>.
Hi Paranoid,
> in.close(); // this block takes about 48 seconds!!
> get.releaseConnection();
>
> look at last 2 lines of code. may be i'm doing something wrong? using
> MultiThreaded and need multi-threaded application. there was something in
> documentation that i dont need to release
> connections - HttpClient will try to reuse it. ok, thats good, but what to do
> with inputStream.close() ? i dont need even to close inputStream?
You have to release connections. Always. No reuse unless released.
If you close the input stream or release the connection, HttpClient
will try to read data until the response has been received completely.
That is the only way to keep the connection alive for another request.
If the server sends a huge response, or takes very long to respond,
then closing/releasing gracefully will be slow. If you know in advance
that you don't want to read the full response, disable keep-alive by
sending a "Connection: close" header with the request. If you decide
at runtime not to read the rest of the response, you can call
HttpMethod.abort() to shutdown the streams without reading the rest
of the response. You still have to release the connection afterwards.
Always release the connection. Do it in a finally{} block.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org