Timeout when closing a HTTP connection

147 views
Skip to first unread message

Jaime Fernández

unread,
Jan 25, 2014, 2:12:46 PM1/25/14
to ve...@googlegroups.com
I've built a proxy using latest version of vertx. HTTP clients to the backend servers are configured with a keepAlive and maxPoolSize to build a pool of HTTP connections. However, whenever the client sends a "Connection: close" HTTP header, next requests using the same HttpClient receive a timeout in the exception handler of the 

HttpClientRequest (created from the HttpClient).

It looks like the connection is closed by the backend (that's correct due to the Connection header) but the clients try to use the same connection that is actually closed instead of creating a new one. This problem disappears if I remove the Connection header, however I'm afraid that if there is any problem with any connection of the pool (e.g. if any firewall closes a connection due to some inactivity period), then some requests will be missed.

Is there any solution for this? Or do we have to accept that some request will be lost under these circumstances?

Norman Maurer

unread,
Jan 25, 2014, 2:13:47 PM1/25/14
to ve...@googlegroups.com, Jaime Fernández
Can you show the exception ?

-- 
Norman Maurer
--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Jaime Fernández

unread,
Jan 26, 2014, 5:58:57 AM1/26/14
to ve...@googlegroups.com, Jaime Fernández, norman...@googlemail.com
The exception is raised by the exceptionHandler of HttpClientRequest when using setTimeout on the HttpClientRequest (e.g. 5 seconds):
java.util.concurrent.TimeoutException: The timeout period of 5000ms has been exceeded
  at org.vertx.java.core.http.impl.DefaultHttpClientRequest.timeout(DefaultHttpClientRequest.java:315)
  at org.vertx.java.core.http.impl.DefaultHttpClientRequest.handleTimeout(DefaultHttpClientRequest.java:300)
  at org.vertx.java.core.http.impl.DefaultHttpClientRequest.access$100(DefaultHttpClientRequest.java:36)
  at org.vertx.java.core.http.impl.DefaultHttpClientRequest$2.handle(DefaultHttpClientRequest.java:244)
  at org.vertx.java.core.http.impl.DefaultHttpClientRequest$2.handle(DefaultHttpClientRequest.java:241)
  at org.vertx.java.core.impl.DefaultVertx$InternalTimerHandler.run(DefaultVertx.java:418)
  at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:176)
  at io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38)
  at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:123)
  at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354)
  at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353)
  at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
  at java.lang.Thread.run(Thread.java:722)

javadevmtl

unread,
Jan 26, 2014, 5:12:54 PM1/26/14
to ve...@googlegroups.com, Jaime Fernández, norman...@googlemail.com
Yeah I remember experiencing similar behaviour but couldn't explain as well lol...

If the back end closes the conenction after teh keep-alive time. Some new connections would get timeout exceptions as above... We solved by constatly sending a request through to the backend server every few minutes...
Reply all
Reply to author
Forward
0 new messages