>
> KAL has the lowest latency on both the client and the server and in case
> of high request rate, it will be the fastest one. [1]


So it seems we should aim for "keep alive" and fix the issues. Maybe you
can try with [2] as it suggests.

[1] https://www.haproxy.com/doc/aloha/7.0/haproxy/http_modes.html
[2] https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option
prefer-last-server

On Mon, May 16, 2016 at 11:41 AM, Danushka Fernando <[email protected]>
wrote:

> Currently with HA proxy fronting microservice we are facing a connection
> reset exception [1]. Seems like this is a common issue with netty +
> haproxy. According to HA proxy manual[2] there are 5 connection modes. With
> connection mode "*httpclose*" I managed to get rid of the exception.
>
> From manual
> "In HTTP mode, the processing applied to requests and responses flowing
> over
>
> a connection depends in the combination of the frontend's HTTP options and
> the backend's. HAProxy supports 5 connection modes :
>
>   - KAL : keep alive ("option http-keep-alive 
> <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20http-keep-alive>")
>  which is the default mode : all
>     requests and responses are processed, and connections remain open but idle
>     between responses and new requests.
>
>   - TUN: tunnel ("option http-tunnel 
> <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20http-tunnel>")
>  : this was the default mode for versions
>     1.0 to 1.5-dev21 : only the first request and response are processed, and
>     everything else is forwarded with no analysis at all. This mode should not
>     be used as it creates lots of trouble with logging and HTTP processing.
> *  - PCL: passive close ("option httpclose 
> <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20httpclose>")
>  : exactly the same as tunnel mode,
>     but with "Connection: close" appended in both directions to try to make
>     both ends close after the first request/response exchange.
> *
>   - SCL: server close ("option http-server-close 
> <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20http-server-close>")
>  : the server-facing
>     connection is closed after the end of the response is received, but the
>     client-facing connection remains open.
>
>   - FCL: forced close ("option forceclose 
> <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20forceclose>")
>  : the connection is actively closed
>
>     after the end of the response."
>
> But there are few questions in hand.
>
>
>    1. Is this the correct approach to solve the issue?
>    2. If its correct then can we use the same connection mode for other
>    app types like tomcat and php as well?
>    3. Are there any better approaches we can take?
>
>
> Any input would be appriciated.
>
> [1] https://wso2.org/jira/browse/APPCLOUD-79
> [2] https://cbonte.github.io/haproxy-dconv/configuration-1.5.html
>
> Thanks & Regards
> Danushka Fernando
> Senior Software Engineer
> WSO2 inc. http://wso2.com/
> Mobile : +94716332729
>
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : [email protected]
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to