Hello, Yes, ssl debug is enabled.
But what we are discussing now is why 'someone' is closing 8 http connections that should be already closed. I'll do what Oleg proposes, inspect the pool before shutting down tomcat. Thanks, Joan. -----Mensaje original----- De: thc...@gmail.com [mailto:thc...@gmail.com] Enviado el: lunes, 2 de diciembre de 2013 19:40 Para: HttpClient User Discussion Asunto: Re: SSL connection Hi. > That's why I though this was something related to Http pool, as if the > connections were not expired. But if you say that you don't print these > messages, then I am a bit lost (because tomcat guys also say that they don't > print these messages, and me neither). Those messages looks a lot like JSSE debugging messages [1]. Do you know if the System property "javax.net.debug" [2] is activated? [1] http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/ReadDebug.html [2] http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Debug Best regards. On 2 December 2013 17:40, Joan Balagueró <joan.balagu...@grupoventus.com> wrote: > Oleg, > > What I would mean was: > > 1. I send 8 https requests, then I have 8 connections in the pool. > > 2. I have a keep-alive of 20 seconds. Then, I wait 1 min. > > 3. After 1 min, all connections should be removed from the pool (due > to my IdleConnectionHandler, that works fine) > > 4. Then, I shutdown tomcat. > > 5. Then, I expect no messages because there are no connections in pool. But I > see exactly 8 messages like this: >> > main, called close() >> > main, called closeInternal(true) >> > main, SEND TLSv1 ALERT: warning, description = close_notify main, >> > WRITE: TLSv1 Alert, length = 18 main, called >> > closeSocket(selfInitiated) > > 6. If I repeat the process sending 5 requests, then I see 5 messages. One per > connection. > > > That's why I though this was something related to Http pool, as if the > connections were not expired. But if you say that you don't print these > messages, then I am a bit lost (because tomcat guys also say that they don't > print these messages, and me neither). > > Anyway, thanks, > > Joan. > > > -----Mensaje original----- > De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: lunes, 2 > de diciembre de 2013 16:12 > Para: HttpClient User Discussion > Asunto: Re: SSL connection > > On Mon, 2013-12-02 at 11:16 +0100, Joan Balagueró wrote: >> Oleg, >> >> I close the connection pool by using >> "this.objHttp.getConnectionManager().shutdown();" >> >> About the expired connections, I have an "idleConnectionsHandler" that every >> 5 seconds removes expired connections and those that take idle longer than 5 >> seconds: >> >> private ClientConnectionManager cm; >> (...) >> this.cm.closeExpiredConnections(); >> this.cm.closeIdleConnections(5, TimeUnit.SECONDS); >> (...) >> >> That's why I though that the pool should be empty after 1 minute. >> >> Regards, >> >> Joan. >> > > Nothing in the connection pool can survive a call to #shutdown(). Can it be > that you have some other processes connected to the same Tomcat instance? > > Oleg > >> >> -----Mensaje original----- >> De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: lunes, 2 >> de diciembre de 2013 10:36 >> Para: HttpClient User Discussion >> Asunto: Re: SSL connection >> >> On Sat, 2013-11-30 at 23:52 +0100, Joan Balagueró wrote: >> > Hello Oleg, >> > >> > Thanks for you help. Everything works fine now. >> > >> > Just one more question: when I shutdown Tomcat, I see this message in >> > catalina.out (ssl debug enabled): >> > >> > main, called close() >> > main, called closeInternal(true) >> > main, SEND TLSv1 ALERT: warning, description = close_notify main, >> > WRITE: TLSv1 Alert, length = 18 main, called >> > closeSocket(selfInitiated) >> > >> > >> > If I send 8 https requests, this message appears 8 times when shutting >> > down tomcat. It seems that HttpClient is closing the http connection pool >> > (in fact, our app closes it). But I have a keep-alive of 20 seconds, and >> > I'm waiting more than 1 minute (from the last request sent) before >> > shutting down tomcat (so I understand that all connections should be >> > expired and removed from the pool). >> > >> > I suppose I'm missing something. Could you clarify me this point, please? >> > >> > Thanks, >> > >> > Joan. >> > >> >> Joan >> >> I do not know SSL protocol that intimately, but it looks like this message >> basically means that the server had to initiate connection shutdown and >> notify the client. I do not think there is anything wrong with that. >> >> Please note that expired connections in the client connection pool do not >> get evicted automatically if the pool is inactive. One needs to explicitly >> call #closeExpired to make it happen. >> >> How exactly do you close the connection pool on the client side? >> >> Oleg >> >> > >> > -----Mensaje original----- >> > De: Oleg Kalnichevski [mailto:o...@ok2consulting.com] Enviado el: >> > jueves, 28 de noviembre de 2013 22:12 >> > Para: HttpClient User Discussion >> > Asunto: Re: SSL connection >> > >> > On Thu, 2013-11-28 at 20:11 +0100, Joan Balagueró wrote: >> > > Hello Oleg, >> > > >> > > Thanks. I've been seeing some HttpClient samples. Some of them set the >> > > trustStore/keyStore directly to the SSLSocketFactory. >> > >> > SSLSocketFactory constructors internally create an SSLContext instance and >> > initialize it with the trust / key material passed as parameters. >> > >> > > And others create an SSLContext with them and then set this SSLContext >> > > to the SSLSocketFactory. Any advantage from one respect to the other? >> > > >> > >> > No, not really. Simply a matter of convenience. >> > >> > > Furthermore, when using SSLContext we need to create an instance using >> > > the secure socket protocol. Is there any way to accept all secure >> > > protocols? >> > > >> > >> > I am not sure what you mean by that. Exactly wha >> > >> > > Thanks, >> > > >> > > Joan. >> > > >> > > -----Mensaje original----- >> > > De: Oleg Kalnichevski [mailto:ol...@apache.org] Enviado el: >> > > jueves, >> > > 28 de noviembre de 2013 10:24 >> > > Para: HttpClient User Discussion >> > > Asunto: Re: SSL connection >> > > >> > > On Wed, 2013-11-27 at 19:24 +0100, Joan Balagueró wrote: >> > > > Hello, >> > > > >> > > > >> > > > >> > > > I have an application (servlet running on tomcat) that must >> > > > send a https request to a server that requires client authentication. >> > > > >> > > > >> > > > >> > > > Tomcat has correctly installed the truststore and keystore. But >> > > > I understand that when our app sends the https request, I have >> > > > to attach the client authentication required by the server. >> > > > >> > > > >> > > > >> > > > Can anyone address to any doc where I can see how to do this? >> > > > >> > > > >> > > > >> > > > Thanks, >> > > > >> > > > >> > > > >> > > > J. >> > > > >> > > >> > > There is enough good material on SSL fundamentals on the web. Just >> > > google it out. >> > > >> > > As far as HC APIs are concerned SSLContextBuilder should help you set up >> > > the correct SSL context for your application. Most likely you will need >> > > to load the private key and add it to the context using this method [1]. >> > > >> > > Oleg >> > > >> > > [1] >> > > http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/apido >> > > c >> > > s/ >> > > or >> > > g/apache/http/conn/ssl/SSLContextBuilder.html#loadKeyMaterial%28j >> > > a >> > > va >> > > .s >> > > ecurity.KeyStore,%20char[],%20org.apache.http.conn.ssl.PrivateKey >> > > S >> > > tr >> > > at >> > > egy%29 >> > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > > ----------------------------------------------------------------- >> > > - >> > > -- >> > > - To unsubscribe, e-mail: >> > > httpclient-users-unsubscr...@hc.apache.org >> > > For additional commands, e-mail: >> > > httpclient-users-h...@hc.apache.org >> > > >> > > >> > > >> > > ----------------------------------------------------------------- >> > > - >> > > -- >> > > - To unsubscribe, e-mail: >> > > httpclient-users-unsubscr...@hc.apache.org >> > > For additional commands, e-mail: >> > > httpclient-users-h...@hc.apache.org >> > > >> > >> > >> > >> > ------------------------------------------------------------------- >> > - >> > - To unsubscribe, e-mail: >> > httpclient-users-unsubscr...@hc.apache.org >> > For additional commands, e-mail: >> > httpclient-users-h...@hc.apache.org >> > >> > >> > >> > ------------------------------------------------------------------- >> > - >> > - To unsubscribe, e-mail: >> > httpclient-users-unsubscr...@hc.apache.org >> > For additional commands, e-mail: >> > httpclient-users-h...@hc.apache.org >> > >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org >> For additional commands, e-mail: httpclient-users-h...@hc.apache.org >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org >> For additional commands, e-mail: httpclient-users-h...@hc.apache.org >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
