Timer behaviour (Timeout) in routes

Roman Pierson

unread,

Oct 14, 2015, 7:11:06 PM10/14/15

to vert.x

Hi

I am relatively new to vert.x and I started to try out the web part, using routes etc.

So far everything works really nice....

Now what I wanted to do is use the TimeoutHandler that comes with 3.1.0, basically I did that by defining it as first route (so its timer gets started as first action), and afterwards I add my other routes, e.g. like:

final HttpServer httpServer = vertx.createHttpServer();

Router router = Router.router(vertx);

router.route().handler(TimeoutHandler.create(1000));

router.route().handler(routingContext -> {

System.out.println("Standard Route");

HttpServerResponse response = routingContext.response();

...... other logic here...

response.end("<html><body><h1>Hello</h1></body></html>");

});

httpServer.requestHandler(router::accept);

httpServer.listen(8080);

So my expectation was that all RoutingContexts not being responded in 1 seconds should return HTTP Status 408 triggered when the timer started in TimeoutHandler times out.

If I add some business logic that causes the second route handler to take longer then the 1 second timeout I don't get the expected effect, the response is still sent back to the client as if no timeout occurs.

However when I for example don't end the response in the second route handler the timeout is returned successfully - that is working as expected.

When running the second route handler in a blocking handler (and sending a response as in code above) then the timer works as expected and returns the 408 Status.

So my question would be if that is the to be expected behavior having that timeout not triggered for a non blocking handler that exceeds the timeout period?

Thanks

Roman

Tim Fox

unread,

Oct 15, 2015, 3:34:50 AM10/15/15

to ve...@googlegroups.com

On 15/10/15 00:11, Roman Pierson wrote:

Hi

I am relatively new to vert.x and I started to try out the web part, using routes etc.

So far everything works really nice....

Now what I wanted to do is use the TimeoutHandler that comes with 3.1.0, basically I did that by defining it as first route (so its timer gets started as first action), and afterwards I add my other routes, e.g. like:

final HttpServer httpServer = vertx.createHttpServer();

Router router = Router.router(vertx);

router.route().handler(TimeoutHandler.create(1000));

router.route().handler(routingContext -> {

System.out.println("Standard Route");

HttpServerResponse response = routingContext.response();

...... other logic here...

response.end("<html><body><h1>Hello</h1></body></html>");

});

httpServer.requestHandler(router::accept);

httpServer.listen(8080);

So my expectation was that all RoutingContexts not being responded in 1 seconds should return HTTP Status 408 triggered when the timer started in TimeoutHandler times out.

If I add some business logic that causes the second route handler to take longer then the 1 second timeout

By this, I assume you are blocking the event loop. Don't do this, you are breaking the Golden Rule (see docs). When you break the golden rule all bets are off - kittens spontaneously combust and apples drop upwards into space ;)

I don't get the expected effect, the response is still sent back to the client as if no timeout occurs.

However when I for example don't end the response in the second route handler the timeout is returned successfully - that is working as expected.

When running the second route handler in a blocking handler (and sending a response as in code above) then the timer works as expected and returns the 408 Status.

So my question would be if that is the to be expected behavior having that timeout not triggered for a non blocking handler that exceeds the timeout period?

Thanks

Roman

--
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.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/613c6beb-146d-4fb5-8529-4da5672a465c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Roman Pierson

unread,

Oct 17, 2015, 4:16:49 PM10/17/15

to vert.x

Hi Tim

Thanks a lot for your response. Indeed I am aware that blocking should be avoided and e.g. if its known that some business logic will tend to block I would use a blocking handler. I was more wondering about the impact of using timers in vert.x. As if like in my example I define a timeout handler that is e.g. 1s and then the next handler for some stupid reason passes that 1s but actually ends the response or steps to the next handler with routingContext.next() and that next handler ends the response successfully my timeout timer has actually no effect as it is not evaluated (as it gets cancelled because the routingContext gets ended in a proper way).

So if I understand it correct in the execution of route handlers timers get only evaluated and have an effect if you either use blockingHandlers or e.g. would delay the switch to next handler with a pseudo timer that calls routingContext.next() by an artificial minimum delay of 1 ms - but that might be a weird solution ;-)

Does that sound technically correct so far?

So if I really need a (strict) timeout functionality I would have to run the handlers explicitly as blockingHandlers or with the artificial minimum timer delaying the next call.

Would there be a way to have a timer scheduling that would be independent from the executed verticle, or would this be nonsense in the sense of vert.x architecture?