Hi Venkat, Good progress. I will schedule a call or code review within this week.
thanks On Mon, Jun 20, 2016 at 9:18 AM, Venkat Raman <[email protected]> wrote: > Hi Isuru, > > Good morning. Kindly find the 4th week's progress. > > 1) Algorithm : a) Least Response Time > > Response time of endpoints is calculated by Running Average of > response time. By this value, load will be balanced in such a way that, > endpoints high Running average of response time will have less load > directed to it and vice versa. However, persistence will be maintained. > > b) Random > Endpoints will be chosen Randomly. Persistence will be maintained > though. > > > 2) Health Checking : Healthy Endpoint detection. > > Once an Endpoint is back from unHealthy to Healthy state, LB will be > able to detect it and direct further incoming traffic to it. > > Kindly note that there is a small deviation from my proposal. In proposal > I have mentioned that I'll also be implementing Least Connections > Algorithm. It is possible if we are load balancing on per service basis. > With load balancing based on per endpoint basis, it will not be possible to > implement it because, we will not have context outside of a specific iFlow > file. Instead, I have implemented Strict IP Hashing and Random algorithms > which I have mentioned in IF TIME PERMITS section of my proposal. > > This week, I am planning to implement Weighted Round Robin. > > As mentioned earlier, I am waiting for HTTPS support to be included in > carbon-gateway-framework repo. > > I'll also be sending you a document that has consolidated list of all the > work that I have done so far, so that it'll be easier for you during > mid-term evaluations. > > > > > > *Thanks,* > *Venkat.* > > On Mon, Jun 13, 2016 at 11:03 AM, Venkat Raman <[email protected]> > wrote: > >> Hi Isusu, >> >> Good morning. Kindly find the 3rd weeks progress. >> >> 1) Algorithm : StrictClientIPHashing >> >> This algorithm uses Client's IP address hashing technique to determine >> OutboundEndpoint. If Client's IP address is not available in request >> header, request will be discarded. >> >> 2) Persistence policy : ClientIPHahsing. >> >> Same as algorithm. But if Client's IP address is not available in >> header, instead of discarding the request, OutboundEndpoint will be chosen >> based on specified algorithm. >> >> 3) Implemented LBOutboundEndpoint. (as we discussed in call) >> >> It'll be used inside LB. It will have reference for OutboundEndpoint >> (HTTP or HTTPS) along with other attributes like healthyFlag, >> unHealthyRetriesCount, healthyRetriesCount and weights (will be added in >> future) for weighted implementations of certain algorithms. >> >> 4) UnHealthy endpoint detection. >> >> I'm using ConcurrentHashMap to store RequestCallBacks (CallBackPool). >> If response is received from OutboundEndpoint within specified timeOut, the >> corresponding callBack will be removed from pool. If callBack object is >> still available in callBack pool, it means that it has been timed out. A >> separate handler will be periodically checking for this. In such cases >> HTTP Error Code 504 : "Gateway Timeout" will be sent back to client. If >> unHealthyRetries count has been reached, that endpoint will be marked as >> unHealthy and it will not be chosen by algorithms till it is back to >> healthy. Kindly note that any other error response from BackEnd will be >> directly sent back to client. LB will not handle those errors as it'll be >> application specific. >> >> Now, I'm working Healthy Endpoint detection. i.e., when an endpoint is >> back from unHealthy to Healthy state, LB should detect it automatically and >> choose that endpoint for further requests. >> >> Also, I'm expecting this to be completed by this week. It would be great >> if you could add HTTPS support in Carbon-Gateway-Framework by next week so >> that I can proceed with that. >> >> >> >> >> >> >> *Thanks,* >> *Venkat.* >> >> On Tue, Jun 7, 2016 at 12:14 PM, Venkat Raman <[email protected]> >> wrote: >> >>> Hi Isuru, >>> >>> I've completed client IP hashing based persistence. Now I'm working on >>> HealthCheck Implementation. Kindly find the here. >>> <https://github.com/Venkat2811/product-http-load-balancer> >>> >>> >>> >>> >>> *Thanks,* >>> *Venkat.* >>> >>> On Mon, Jun 6, 2016 at 11:18 AM, Venkat Raman <[email protected]> >>> wrote: >>> >>>> Hi Isuru, >>>> >>>> Good morning. Kindly find the 2nd week's progress >>>> >>>> 1) Implementation of Cookie based persistence >>>> a) LB cookie will be appended with the cookie in response to >>>> maintain persistence. So this has the same timeout and other properties of >>>> that cookie. >>>> b) There won't be any cookie in response from backend. So, LB will >>>> insert its own cookie (session cookie). It will be valid till client >>>> browser is closed. >>>> >>>> 2) Laid ground work for Client IP Hashing based persistence. >>>> >>>> This week I'll be continuing to work on Client IP hashing. >>>> >>>> Your feedback would be very valuable and critical at this point. Will >>>> be looking forward to hear from you. >>>> >>>> >>>> >>>> >>>> *Thanks,* >>>> *Venkat.* >>>> >>>> On Thu, Jun 2, 2016 at 12:02 PM, Venkat Raman <[email protected]> >>>> wrote: >>>> >>>>> Hi IsuruR, >>>>> >>>>> I've added session persistence support Application & LB specific >>>>> cookie. Kindly find it in the repo here >>>>> <https://github.com/Venkat2811/product-http-load-balancer>. >>>>> >>>>> Now, I am planning to start with Client IP hashing based persistence. >>>>> >>>>> Will be looking forward for your feedback. :) >>>>> >>>>> >>>>> >>>>> >>>>> *Thanks,* >>>>> *Venkat.* >>>>> >>>>> On Tue, May 31, 2016 at 3:21 PM, Venkat Raman <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I'm implementing cookie based persistence. I have found various JAVA >>>>>> libriaries that support HTTP Cookies. >>>>>> >>>>>> 1) Netty Cookie link >>>>>> <http://netty.io/4.0/api/io/netty/handler/codec/http/cookie/Cookie.html#name()> >>>>>> >>>>>> Expiration date is not supported. Not supporting toString() >>>>>> method, so, I have to write my custom toString conversion method so that >>>>>> I >>>>>> can add it to carbonMessage header. >>>>>> >>>>>> 2) Javax Cookie link >>>>>> <http://docs.oracle.com/javaee/6/api/javax/servlet/http/Cookie.html> >>>>>> >>>>>> Expiration date is not supported. Javax is not supporting >>>>>> toString() method so same case as Netty >>>>>> >>>>>> 3) java.net.HttpCookie link >>>>>> <https://docs.oracle.com/javase/7/docs/api/java/net/HttpCookie.html>. >>>>>> >>>>>> Supports toString(). But HTTPOnly has to appended manually. >>>>>> Expiration date is not supported. >>>>>> >>>>>> 4) Apache commons http client Cookie link >>>>>> <http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/Cookie.html> >>>>>> >>>>>> Supports RFC Date for specifying expiration and toString() is >>>>>> also supported. >>>>>> >>>>>> So shall I use Apache Commons http Client cookie..?? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Thanks,* >>>>>> *Venkat.* >>>>>> >>>>>> On Mon, May 30, 2016 at 10:42 AM, Venkat Raman <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Ok Isuru. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Thanks,* >>>>>>> *Venkat.* >>>>>>> >>>>>>> On Mon, May 30, 2016 at 10:34 AM, Isuru Ranawaka <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Venkat. >>>>>>>> >>>>>>>> Good.I will look at the implementation and setup a call for discuss >>>>>>>> next steps. >>>>>>>> >>>>>>>> thanks >>>>>>>> >>>>>>>> On Mon, May 30, 2016 at 10:27 AM, Venkat Raman < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Isuru, >>>>>>>>> >>>>>>>>> Good morning :) . Kindly find the 1st week's progress. >>>>>>>>> >>>>>>>>> 1) Implementation of Round-Robin algorithm for Outbound Endpoints. >>>>>>>>> 2) Round-Robin algorithm with group support, but one .iflow config >>>>>>>>> file can have only one group as of now as mentioned earlier. >>>>>>>>> 3) Few input validations. >>>>>>>>> >>>>>>>>> Kindly find the repo here. >>>>>>>>> <https://github.com/Venkat2811/product-http-load-balancer> >>>>>>>>> >>>>>>>>> In proposal I've mentioned that I'll be covering HTTPS 2nd >>>>>>>>> week,since it'll be made available later in carbon-gateway-framework >>>>>>>>> repo, >>>>>>>>> I'm planning to proceed with adding session persistence. >>>>>>>>> >>>>>>>>> Will be looking forward for your feedback. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *Thanks,* >>>>>>>>> *Venkat.* >>>>>>>>> >>>>>>>>> On Wed, May 25, 2016 at 8:57 PM, Venkat Raman < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Ravi, >>>>>>>>>> >>>>>>>>>> Thank you for the clear explanation :) . Yes, I added >>>>>>>>>> appropriate log statements and I was able to understand the flow and >>>>>>>>>> I am >>>>>>>>>> clear with it now. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Thanks,* >>>>>>>>>> *Venkat.* >>>>>>>>>> >>>>>>>>>> On Wed, May 25, 2016 at 8:09 PM, Ravi Undupitiya <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Venkat, >>>>>>>>>>> >>>>>>>>>>> Please find answers inline below. >>>>>>>>>>> >>>>>>>>>>> On Tue, May 24, 2016 at 9:29 PM, Venkat Raman < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1) Why are we pushing variables in carbon message variables >>>>>>>>>>>> stack..?? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> One of the features of the language is to have variables we can >>>>>>>>>>> declare and use throughout the mediation flow. We are able to >>>>>>>>>>> populate >>>>>>>>>>> variables during loading and during runtime and so variable stack >>>>>>>>>>> is kept >>>>>>>>>>> inside the carbon message so each thread has its own variable >>>>>>>>>>> stack. Hope >>>>>>>>>>> that clarifies. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 2) Also could you kindly explain how AbstractFlowController and >>>>>>>>>>>> FlowControllerCallback are working together. My understanding is >>>>>>>>>>>> not quite >>>>>>>>>>>> clear on this. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> AbstractFlowControllers are mediators that require controlling >>>>>>>>>>> the flow (like filter mediator) where we the mediation flow >>>>>>>>>>> branching out, >>>>>>>>>>> in which case we want to mediate only the branch we're in and >>>>>>>>>>> FlowControllerCallback is a CarbonCallback that we pass on to >>>>>>>>>>> receive >>>>>>>>>>> method of mediators of a particular branch. This allows us to >>>>>>>>>>> continue >>>>>>>>>>> mediation from the parent once a branch is complete. You can test >>>>>>>>>>> this out >>>>>>>>>>> by debugging the FilterMediator, try passing on the usual callback >>>>>>>>>>> and then >>>>>>>>>>> check by passing on a FlowControllerCallback. >>>>>>>>>>> >>>>>>>>>>> @IsuruR, please correct me if I'm wrong. :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> -- >>>>>>>>>>> *Ravi Undupitiya* >>>>>>>>>>> Senior Software Engineer; WSO2 http://wso2.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *E-mail: [email protected] <http://wso2.com>**M: **+94 772 930 712 >>>>>>>>>>> <%2B94%C2%A0772%20930%20712>* >>>>>>>>>>> >>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best Regards >>>>>>>> Isuru Ranawaka >>>>>>>> M: +94714629880 >>>>>>>> Blog : http://isurur.blogspot.com/ >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Best Regards Isuru Ranawaka M: +94714629880 Blog : http://isurur.blogspot.com/
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
