2 Replies Latest reply on Jun 24, 2009 1:57 PM by brett_brettl

    Camel Jetty Component and Timeout

    brett_brettl

      Hello,

       

      I have a question about setting a timeout value when using the Jetty component of Camel. I have a Jetty endpoint that is using TLS encryption, I would like to be able to make sure that a client cannot hold onto a connection with the server beyond some time of inactivity. I tried using timeout options that I read about at http://camel.apache.org/jetty.html and tried the following:

       

       
      <ca:from uri="jetty:https://localhost:8084?httpClient.idleTimeout=1000"/>
      

       

      Even though I set the timeout above I found that I could still make a request from the server, get a response and then wait 5 minutes and still be able to make another request without having to perform a new TLS handshake. Did I format my timeout value above incorrectly? Are there different options for setting a regular timeout and a timeout for the TLS connection/session? Any help would be appreciated. Thanks.

       

      Brett

       

      Edited by: brett on Jun 23, 2009 1:07 PM

        • 1. Re: Camel Jetty Component and Timeout
          stlewis

          The client is probably just caching the SSL session so that it doesn't have to re-authenticate the server's certificate on subsequent connection attempts.  There really isn't a way you can force the client to clear it's SSL session cache from the server, though you could also require client authentication, though then every client would need a certificate for your server to verify.  You should verify though with wireshark, netstat, lsof, etc. if the client keeps it's connection open to the server or not.

          • 2. Re: Camel Jetty Component and Timeout
            brett_brettl

            Thanks for the information. From what I can gather when my client tries to make a second request with the server they just agree to change the keys being used to encrypt the SSL session. By using client authentication I can at least know that whoever is holding onto the session is authorized to. Again thanks for the information.

             

            Brett