If we have issues with disruptor, those issues are equally affecting GW or GW based servers for most of the real use cases. So fixing that in the proper way and continue to use the same architecture for both GW and MSF4J looks ideal to me.
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. > > On Thu, Mar 10, 2016 at 10:22 AM, Sagara Gunathunga <[email protected]> > wrote: > >> >> When we discuss last week about Carbon transports for MSF4J the main >> rational we identified was moving to Carbon transport will decouple >> transport threads from worker threads through Disruptor and provide lot of >> flexibility and manageability. If disruptor can't give better performance >> we should skip it no argument about that, but once we skip the disruptor >> the rational we made last week about thread pool decoupling become invalid >> if so why MSF4J should depend on Carbon transport ? If Carbon transport >> can't provide real advantages shouldn't MSF4J depend on vanilla Netty >> transports and make thing more lightweight ? >> >> Thanks ! >> >> On Thu, Mar 10, 2016 at 9:50 AM, Afkham Azeez <[email protected]> wrote: >> >>> We need to do this fast because this task has taken close to 3 weeks now. >>> >>> On Thu, Mar 10, 2016 at 9:29 AM, Kasun Indrasiri <[email protected]> wrote: >>> >>>> Yes, we can make the disruptor optional. Also, we should try using the >>>> native worker pool for Event Handler[1], so that the Disruptor itself runs >>>> the event handler on a worker pool. We'll implement both approaches and do >>>> a comparison. >>>> >>>> [1] >>>> https://lmax-exchange.github.io/disruptor/docs/com/lmax/disruptor/dsl/Disruptor.html#handleEventsWithWorkerPool(com.lmax.disruptor.WorkHandler.. >>>> .) >>>> >>>> On Thu, Mar 10, 2016 at 8:48 AM, Afkham Azeez <[email protected]> wrote: >>>> >>>>> After upgrading to the new transport, we are seeing a significant drop >>>>> in performance for any service that take some time to execute. We have >>>>> tried with the configuration used for the gateway which gave the best >>>>> figures on the same hardware. We have also noted that using a separate >>>>> dedicated executor thread pool, which is supported by Netty, gave much >>>>> better performance than the disruptor based implementation. Even in >>>>> theory, >>>>> disruptor cannot give better performance when used with a real service >>>>> that >>>>> does some real work, rather than doing passthrough, for example. Can we >>>>> improve the Netty transport to make going through disruptor optional? >>>>> >>>>> -- >>>>> *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* >>>>> >>>> >>>> >>>> >>>> -- >>>> Kasun Indrasiri >>>> Software Architect >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> cell: +94 77 556 5206 >>>> Blog : http://kasunpanorama.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> *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* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Architect; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services; http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> >> _______________________________________________ >> 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* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Isuru Udana* Associate Technical Lead WSO2 Inc.; http://wso2.com email: [email protected] cell: +94 77 3791887 blog: http://mytecheye.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
