title: Tomcat 6: HTTPS times out but HTTP works (Maybe GWT issue?)
body: <p>We have a Linux server running tomcat6  (6.0.36).  We have a GWT-based web-app.  It has been running fine for 2 years, until twice in 5 days it developed a problem:  HTTPS ceased to work even though HTTP works fine.  Both times, a simple restart solved the problem.  </p>
  
  <ul>
  <li>The certificates are not close to expiry and indeed are fine after the restart</li>
  <li>There was no significant load on the server at the time of the fault, CPU and %MEM were fine</li>
  <li>HTTP responds instantly</li>
  <li>HTTPS just times out without giving us any clues</li>
  <li>There's nothing in the 'catalina.out' file but there are SocketTimeoutException's in the localhost.*log file, see below</li>
  <li>A thread dump (kill -3) shows nothing out of the ordinary</li>
  </ul>
  
  <p>Any ideas, anyone?</p>
  
  <pre><code>SEVERE: Exception while dispatching incoming RPC call
  java.net.SocketTimeoutException
      at org.apache.coyote.http11.InternalAprInputBuffer.fill(InternalAprInputBuffer.java:796)
      at org.apache.coyote.http11.InternalAprInputBuffer$SocketInputBuffer.doRead(InternalAprInputBuffer.java:830)
      at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:116)
      at org.apache.coyote.http11.InternalAprInputBuffer.doRead(InternalAprInputBuffer.java:738)
      at org.apache.coyote.Request.doRead(Request.java:427)
      at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:304)
      at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:419)
      at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:327)
      at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:162)
      at com.google.gwt.user.server.rpc.RPCServletUtils.readContent(RPCServletUtils.java:222)
      at com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsGwtRpc(RPCServletUtils.java:250)
      at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.readContent(AbstractRemoteServiceServlet.java:182)
      at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:239)
      at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at au.com.edval.timetable.server.filter.LoginFilter.doFilter(LoginFilter.java:27)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
      at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:615)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
      at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:879)
      at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:600)
      at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1703)
      at java.lang.Thread.run(Thread.java:679)
  Jul 30, 2013 10:27:31 AM org.apache.catalina.core.ApplicationContext log
  </code></pre>
  
  <p>Note that a couple of years ago I had a similar problem - HTTPS was working but was very slow.  It turns out there was a configuration option that says that HTTPS should do reverse DNS lookups on each page request.  And this naturally slowed everything down heaps. But this is still disabled now so it can't be the cause, I don't think.</p>