Hi Azeez, In GW Disruptor threads are not used for make calls for backends. Backends are called by Netty worker pool and those calls are non blocking calls. So if backend responds after a delay it won't be a problem.
In MSF4J if it includes IO operations or delayed operations then it causes problems because processing happens through Disruptor threads and by occupying all the limited disruptor threads. But this should be solved by operating Disruptor Event Handlers through workerpool and now we are looking in to that why it does not provide expected results. thanks IsuruR On Sat, Mar 12, 2016 at 6:46 PM, Afkham Azeez <[email protected]> wrote: > Kasun et al, > In MSF4J, the threads from the disruptor pool itself are used for > processing in the MSF4J operation. In the case of the GW passthrough & HBR > scenarios, are those disruptor threads used to make the calls to the actual > backends? Is that a blocking call? What if the backend service is changed > so that it responds after a delay rather than instantaneously? > > On Sat, Mar 12, 2016 at 6:21 PM, Afkham Azeez <[email protected]> wrote: > >> >> >> On Sat, Mar 12, 2016 at 1:40 PM, Sanjiva Weerawarana <[email protected]> >> wrote: >> >>> On Thu, Mar 10, 2016 at 6:20 PM, Sagara Gunathunga <[email protected]> >>> wrote: >>> >>>> On Thu, Mar 10, 2016 at 10:26 AM, Afkham Azeez <[email protected]> wrote: >>>> >>>>> No from day 1, we have decided that GW & MSF4J will use the same Netty >>>>> transport component so that the config file will be the same as well as >>>>> improvements made to that transport will be automatically available for >>>>> both products. So now at least for MSF4J, we have issues in using the >>>>> Netty >>>>> transport in its current state, so we have to fix those issues. >>>>> >>>> >>>> Reuse of same config files and components provide an advantage to us as >>>> the F/W developers/maintainers but my question was what are the benefits >>>> grant to end users of MSF4J through Carbon transport ? >>>> >>> >>> We are writing MSF4J and the rest of the platform. Not someone else. As >>> such we have to keep them consistent. >>> >>> For end users our target has to be to give the best performance possible. >>> >>> >>>> I don't think we can compromise performance numbers for a reason that >>>> is more important for F/W maintainers than end users, IMHO if we continue >>>> to use Carbon transport at least it should perform as same level as vanilla >>>> Netty. >>>> >>> >>> There's no reason why that cannot be the case. >>> >>> Can't we keep Disruptor while improve performance of Carbon transport ? >>>> >>> >>> Disruptor is a technique to make things more performant not less >>> performant. We have to figure out what's wrong and fix it - not throw the >>> baby out with the bathwater. >>> >> >> Yes, we are in the process of trying to figure out why disruptor as >> opposed to the Netty executor threadpool gives better performance for the >> gateway (dispatching to a zero delay backend), while for an MSF4J service >> which has a sleep in it, it is the other way around. >> >> >>> >>> Sanjiva. >>> -- >>> Sanjiva Weerawarana, Ph.D. >>> Founder, CEO & Chief Architect; WSO2, Inc.; http://wso2.com/ >>> email: [email protected]; office: (+1 650 745 4499 | +94 11 214 5345) >>> x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650 265 8311 >>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>> Lean . Enterprise . Middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>* >> *email: **[email protected]* <[email protected]> >> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez* >> <http://twitter.com/afkham_azeez> >> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <http://lk.linkedin.com/in/afkhamazeez>* >> >> *Lean . Enterprise . Middleware* >> > > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > -- Best Regards Isuru Ranawaka M: +94714629880 Blog : http://isurur.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
