Configurable timeout on routes

[tomason]

We have started to work with Drools execution server on OpenShift recently and immediately hit an issue with session timeout (Drools execution server executes rule sets on given set of facts). The communication with execution server is synchronous and operations (create new session, execute rules) can take significant amount of time.

Could you, please, add timeout configuration per route? I have checked the HAproxy documentation and 'timeout server' can be specified in backend, so there could be a default (currently 30s) and if there is another value specified in route, it will override the default.

[rettori]

Adding more details.
Drools Execution Server process the execution of rules that can cate longer than the default 30s the router is configured to timeout.
The longer execution time can be related, for example, to the number of rules executed, the number of facts that will be evaluated for rule, or the combination of both.
The timeout needs to be configurable to handle requests that will take more than the default timeout. This is a blocker for the http based endpoint for the Drools Execution Server.

[pweil-]

@ramr - we probably want to see how/if this fits into ingress upstream as well.

That said, the router can be customized with a new haproxy template if this is blocking https://docs.openshift.com/enterprise/3.0/install_config/install/deploy_router.html#deploying-a-customized-haproxy-router

[tomason]

The customization of the haproxy template is possible, but wouldn't that change the configuration for the whole cluster? That might not be desirable.

I proposed adding timeout attribute to the route that could be used on per route basis. According to haproxy documentation, the 'timeout server' directive can be used in backend definition, so it should not be a problem.

https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-timeout%20server

[pweil-]

The customization of the haproxy template is possible, but wouldn't that change the configuration for the whole cluster? That might not be desirable.

Yep, definitely agree. Just offering a work around if you needed it to unblock something.

I think it bears discussion around how we can send "hints" about routes for router implementations to implement or ignore without adding a configuration knob for every possible backend implementation. Annotations seem like a good candidate.

[ramr]

@pweil- yeah that take the haproxy-template.config and modify it and create a new router image was my initial workaround to @tomason over email. Though, it could well be extended a bit more if needed - meaning add a custom timeout on a backend as @tomason wanted in the template code on the basis of some custom criteria.

I like the annotations idea 👍 - its generic enough to add other custom knobs if needed + in this specific case for haproxy, we could pass down the annotations via the ServiceAliasConfig and let the template code figure out what it wants to do for a specific timeout annotation.

[rettori]

Is is possible to have more than one router per installation?

[pweil-]

Is is possible to have more than one router per installation?

Yes. Other than an HA setup the other use case would be when routers are configured to listen to a subset of events so they only handle certain routes.

[rettori]

1- the adequate solution would consider the ability to tell the router what is the expected timeout for a certain request.
2- workaround would be to deploy more than one router per installation and direct drools execution server traffic through that route.

[adietish]

I believe that we face thid issue when we connect an Eclipse debugger to a nodejs pod. The debugging session gets terminated without obvious reason: https://issues.jboss.org/browse/JBIDE-23422.
Looks very much like this is caused by the router timeout that's the topic in this issue.

[knobunc]

There's a doc PR to describe all the knobs the router already exposes:
https://github.com/openshift/openshift-docs/pull/3090/files