By analyzing it further what I understand is netty server closes connection while ha proxy trying to keep it alive. So best option for netty server is option http-server-close <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20http-server-close> AFAIU by looking at descriptions. If no obligations we would use that as the solution.
Thanks & Regards Danushka Fernando Senior Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Wed, May 18, 2016 at 1:33 PM, Danushka Fernando <[email protected]> wrote: > Sorry its option httpclose > <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20httpclose>. > But seems option http-server-close > <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20http-server-close> > and option forceclose > <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20forceclose> > also > works but I didnt tried them since we are focusing on keepalivee. I couldnt > get keep alive working with any of the options. > > Thanks & Regards > Danushka Fernando > Senior Software Engineer > WSO2 inc. http://wso2.com/ > Mobile : +94716332729 > > On Wed, May 18, 2016 at 1:29 PM, Danushka Fernando <[email protected]> > wrote: > >> I tried several combination of options by looking at the descriptions. >> But only thing worked for me for microservices is option >> http-server-close >> <https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20http-server-close>. >> As mentioned before this seems a common issue when haproxy and netty are >> together. >> >> Thanks & Regards >> Danushka Fernando >> Senior Software Engineer >> WSO2 inc. http://wso2.com/ >> Mobile : +94716332729 >> >> On Mon, May 16, 2016 at 11:32 PM, Manuranga Perera <[email protected]> wrote: >> >>> [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
