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 3320919blog: **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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
