[2] https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20prefer-last-server
On Mon, May 16, 2016 at 1:59 PM, Manuranga Perera <[email protected]> wrote: > 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] > -- 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
