We can write a simple demo to prove reactive or original netty can improve throughout using omega/alpha architecture
> On Nov 1, 2018, at 8:29 AM, Willem Jiang <[email protected]> wrote: > > I thinking to use actor to do the reactive work, but it looks like we > could make alpha more simple by implement some logic on the Omega > side, such as the timeout function. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Nov 1, 2018 at 1:57 AM wjm wjm <[email protected]> wrote: >> >> async is not enough, better to be reactive. >> >> 赵俊 <[email protected]> 于2018年10月31日周三 下午5:07写道： >> >>> Hi, Willem >>> >>> I think make the last invocation async is limitation for performance tuning >>> As block grpc invoking also use async way internal, only blocking in >>> futureTask.get(). >>> >>> >>> >>> >>>> On Oct 30, 2018, at 4:51 PM, Willem Jiang <[email protected]> >>> wrote: >>>> >>>> Thanks for feedback, >>>> I just used one participator to show the most simplest way of service >>>> interaction. >>>> I just add some words about the "initial service" and the >>>> "participant service". >>>> >>>> Now we could think about how to reduce the overheads of the >>>> distributed transaction. I think we can make the last invocation >>>> async to speed up the processing, but it could be a challenge for us >>>> to leverage the async remote invocation without introduce the risk of >>>> losing messages. >>>> >>>> Any thoughts? >>>> >>>> Willem Jiang >>>> >>>> Twitter: willemjiang >>>> Weibo: 姜宁willem >>>> On Tue, Oct 30, 2018 at 4:37 PM Zheng Feng <[email protected]> wrote: >>>>> >>>>> Great work ! It could be more clear if you can mark the invocation >>> arrows >>>>> with the step numbers. And it usual has two or more participants in a >>>>> distribute transaction. >>>>> So you need to improve the sequence diagram to show these actors. >>>>> >>>>> It also could be helpful to describe what is the "initial service" and >>> the >>>>> "participant service" ? >>>>> >>>>> Willem Jiang <[email protected]> 于2018年10月30日周二 下午4:23写道： >>>>> >>>>>> Hi Team, >>>>>> >>>>>> I wrote a page[1] to analyze the overheads that Saga or TCC could >>>>>> introduce. >>>>>> Please check it out and let me know what you think. >>>>>> You can either reply this mail or just add comment on the wiki page. >>>>>> >>>>>> [1] >>>>>> >>> https://cwiki.apache.org/confluence/display/SERVICECOMB/Distributed+Transaction+Coordinator+Overhead >>>>>> >>>>>> Willem Jiang >>>>>> >>>>>> Twitter: willemjiang >>>>>> Weibo: 姜宁willem >>>>>> >>> >>>
