Re: Saga，TCC overhead
Hi Zheng I think Willem have designed recovery mechanisms like XA we have discussed last week. Omega also can write recently transactions into file system, when omega restart we can compare the omega transaction log and alpha transaction event to do the recovery. > On Nov 1, 2018, at 5:33 PM, Willem Jiang wrote: > > If we expose the transaction query interface between the Omega and > Alpha, we need to let the Omega store all the transaction, maybe we > just need to let Omega store the most recent transaction status. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Nov 1, 2018 at 3:37 PM Zheng Feng wrote: >> >> OK, that makes sense to have such status query interface and this should be >> introduced by the Java annotations ? >> >> Willem Jiang 于2018年11月1日周四 下午3:27写道： >>> >>> Hi Zheng, >>> >>> If the Omega failed to send the Saga event to the Alpha, Alpha could >>> think the transaction is failed and start the compensation process. >>> In this way we need the Omega provide the query interface for the >>> Alpha to verify the states of the transaction to avoid this kind of >>> situation. >>> >>> If we let the Omega (transaction initiator) to know about the timeout, >>> the Omega help Alpha to do more things, as the transaction initiator >>> Omega knows all the other services invocation status. In this way >>> Alpha just need to deal with the transaction initiator Omega crash >>> situation. >>> >>> >>> Willem Jiang >>> >>> Twitter: willemjiang >>> Weibo: 姜宁willem >>> >>> On Thu, Nov 1, 2018 at 12:13 PM Zheng Feng wrote: +1. I think we had some implementation codes before by using the Executors. @Willem Jiang can you recall why we move the timeout handle to the alpha server ? is there any particular reason ? I think maybe the following 1) the omega fails to send the cancel message when timeout happens due to the network error ? So the compensation will not happen. 2) the omega crashes and can not recovery to send the message when it re-starts ? Willem Jiang 于2018年11月1日周四 上午11:24写道： > > +1 to use the POC show us the fact :) > Now I'm thinking to let Omega more smart[1] by doing the timeout > monitor itself to reduce the complexity of Alpha. > In this way the Alpha just need to store the message and response the > request from Omega. > > [1]https://issues.apache.org/jira/browse/SCB-1000 > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > On Thu, Nov 1, 2018 at 11:13 AM 赵俊 wrote: >> >> 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 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 wrote: async is not enough, better to be reactive. 赵俊 于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 > 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 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 于2018年10月30日周二 下午4:23写道：
Re: [Discuss][SAGA] MicroProfile LRA
Well, it is a good idea and I will try my best to compare two of them. Willem Jiang 于2018年11月1日周四 下午5:14写道： > Hi Zheng > > Thanks for the information. As you know the specification has lots of > information. > Could you break down it into smaller section and we could do some > comparison with current Saga implementation? > For example, the LRA is based on the Restful Service and the > Transaction ID is passed through the HTTP headers. The LRA Client API > is much like our Omega API, but we don't expose much of the detail > from the client side. > > Currently we are thinking about to do some enhancement on the Saga > protocol by helping user to release the lock once the Saga transaction > is finished[1]. I think we may contribute this use case back to the > lra specification by starting the discussion first. > > [1]https://issues.apache.org/jira/browse/SCB-1006 > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > On Thu, Nov 1, 2018 at 3:56 PM Zheng Feng wrote: > > > > Hi all, > > > > I think we need to have the eyes on this specification. The LRA (Long > > Running Action) [1] tries to introduce some Saga like APIs in the micro > > services. These are similar to our omega and alpha APIs currently. Now > they > > are going to ask the community for some input [2], and I think we can > > contribute some ideas from our side especially with the coordinate > service > > design. > > > > Thanks, > > Zheng Feng > > > > [1] https://github.com/eclipse/microprofile-lra > > [2] https://groups.google.com/forum/#!topic/microprofile/vWM0eXE8gYc >
Re: Release of ServiceComb 1.1.0
I already submit a JIRA and wait for infra's response. But the document it's OK for us do the modification, please send a PR if you have time to work on it. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Nov 1, 2018 at 8:24 PM Bin Ma wrote: > > Hi all, > > Some community users plan to make courses based on ServiceComb in the near > future, like Itcast,University and so on. > So I think it may be speed up the process of renaming the git repo name and > updating the documentation. > > > Best Wishes & Regards > --- > Mabin > > > > Willem Jiang 于2018年10月29日周一 下午12:54写道： > > > FYI， I fill a JIRA[1] for renaming the git repo. > > > > [1]https://issues.apache.org/jira/browse/INFRA-17185 > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > On Sat, Oct 27, 2018 at 10:09 PM Willem Jiang > > wrote: > > > > > > Oh, I just forgot the github name issue which we faced when moving > > > the servicecomb to apache incubator. > > > I will fill a JIRA this weekend, it may take few days to do the > > > transfer. Once we changed the github name, we could consider the > > > release of ServiceCenter. > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Sat, Oct 27, 2018 at 2:25 PM Mohammad Asif Siddiqui > > > wrote: > > > > > > > > Hi Willem, > > > > > > > > In my opinion since ServiceComb has already graduated so we can change > > the repository names first and migrate the SVN for the releases and then > > plan for the ServiceComb 1.1.0 release. In Service-Center after the change > > in the repository name we need to change the import statements of each file > > and also we need to update the Travis settings for each project and make > > new encryption keys for automatic snapshot deployment, for all these > > activities it might take 2-3 days so we can plan this first in coming week > > and then we can go ahead with the Service-Center 1.1.0 release. > > > > > > > > Just my 2 cents.. > > > > > > > > Regards > > > > Asif > > > > > > > > On 2018/10/22 03:39:02, Willem Jiang wrote: > > > > > Hi, > > > > > > > > > > The last ServiceComb java-chassis，service-center 1.0.0 release is > > > > > three month ago. It's time to discuss the release of ServiceComb > > > > > 1.1.0. > > > > > > > > > > As we add the TCC implementation in the Saga 0.3.0, we may need to > > > > > create a separate git repo to support the Saga and TCC at the same > > > > > time. It may take sometime to do these change. We may do the Saga > > > > > release after the release of java-chassis and service-center. > > > > > > > > > > Regards, > > > > > > > > > > Willem Jiang > > > > > > > > > > Twitter: willemjiang > > > > > Weibo: 姜宁willem > > > > > > >
Re: [Discuss][JavaChassis] about customization of vertx org.apache.servicecomb.transport.rest.vertx.RestBodyHandler
Hi, I've tried to remove ServiceComb exceptions from RestBodyHandler today. Technically, it is feasible. In my test, I replace the ServiceComb exceptions with IllegalArgumentException in the case that upload directory is not specified and replace with 413 status code in the case that uploaded file is too large. In GlobalRestFailureHandler I recognize the exception and status code and then return corresponding response. This solution seems working well, but there are still some details need to be discussed. The first one is whether it's proper to use IllegalArgumentException in this situation. I use it because I cannot find other Exception more accurately express the meaning "upload directory is not specified". The other one is that the logic to convert the exceptions into error response is set in GlobalRestFailureHandler. It seems not elegant, but I still don't find any better solution. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 17:54，yhs0092 wrote： Hi, one of the JavaChassis exception wrapped in RestBodyHandler is added by me. I will try to remove the JavaChassis exceptions in RestBodyHandler and see whether it can works well. Yours sincerely Yao Haishi yhs0...@163.com On 10/31/2018 09:00，wjm wjm wrote： currently we customized org.apache.servicecomb.transport.rest.vertx.RestBodyHandler 1.disable upload feature when uploadDir is null, this is a general requirement 2.wrap some exceptions to JavaChassis exception， this is not a general requirement if there is only customization 1, maybe we can try to raise a PR to vertx otherwise we always forget to merge latest vertx logic to our code. maybe we can confirm if customization 2 is necessary.
Re: Release of ServiceComb 1.1.0
Hi all, Some community users plan to make courses based on ServiceComb in the near future, like Itcast,University and so on. So I think it may be speed up the process of renaming the git repo name and updating the documentation. Best Wishes & Regards --- Mabin Willem Jiang 于2018年10月29日周一 下午12:54写道： > FYI， I fill a JIRA[1] for renaming the git repo. > > [1]https://issues.apache.org/jira/browse/INFRA-17185 > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > On Sat, Oct 27, 2018 at 10:09 PM Willem Jiang > wrote: > > > > Oh, I just forgot the github name issue which we faced when moving > > the servicecomb to apache incubator. > > I will fill a JIRA this weekend, it may take few days to do the > > transfer. Once we changed the github name, we could consider the > > release of ServiceCenter. > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Sat, Oct 27, 2018 at 2:25 PM Mohammad Asif Siddiqui > > wrote: > > > > > > Hi Willem, > > > > > > In my opinion since ServiceComb has already graduated so we can change > the repository names first and migrate the SVN for the releases and then > plan for the ServiceComb 1.1.0 release. In Service-Center after the change > in the repository name we need to change the import statements of each file > and also we need to update the Travis settings for each project and make > new encryption keys for automatic snapshot deployment, for all these > activities it might take 2-3 days so we can plan this first in coming week > and then we can go ahead with the Service-Center 1.1.0 release. > > > > > > Just my 2 cents.. > > > > > > Regards > > > Asif > > > > > > On 2018/10/22 03:39:02, Willem Jiang wrote: > > > > Hi, > > > > > > > > The last ServiceComb java-chassis，service-center 1.0.0 release is > > > > three month ago. It's time to discuss the release of ServiceComb > > > > 1.1.0. > > > > > > > > As we add the TCC implementation in the Saga 0.3.0, we may need to > > > > create a separate git repo to support the Saga and TCC at the same > > > > time. It may take sometime to do these change. We may do the Saga > > > > release after the release of java-chassis and service-center. > > > > > > > > Regards, > > > > > > > > Willem Jiang > > > > > > > > Twitter: willemjiang > > > > Weibo: 姜宁willem > > > > >
Re: Saga，TCC overhead
If we expose the transaction query interface between the Omega and Alpha, we need to let the Omega store all the transaction, maybe we just need to let Omega store the most recent transaction status. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Nov 1, 2018 at 3:37 PM Zheng Feng wrote: > > OK, that makes sense to have such status query interface and this should be > introduced by the Java annotations ? > > Willem Jiang 于2018年11月1日周四 下午3:27写道： >> >> Hi Zheng, >> >> If the Omega failed to send the Saga event to the Alpha, Alpha could >> think the transaction is failed and start the compensation process. >> In this way we need the Omega provide the query interface for the >> Alpha to verify the states of the transaction to avoid this kind of >> situation. >> >> If we let the Omega (transaction initiator) to know about the timeout, >> the Omega help Alpha to do more things, as the transaction initiator >> Omega knows all the other services invocation status. In this way >> Alpha just need to deal with the transaction initiator Omega crash >> situation. >> >> >> Willem Jiang >> >> Twitter: willemjiang >> Weibo: 姜宁willem >> >> On Thu, Nov 1, 2018 at 12:13 PM Zheng Feng wrote: >> > >> > +1. I think we had some implementation codes before by using the >> > Executors. @Willem Jiang can you recall why we move the timeout handle to >> > the alpha server ? is there any particular reason ? I think maybe the >> > following >> > 1) the omega fails to send the cancel message when timeout happens due to >> > the network error ? So the compensation will not happen. >> > 2) the omega crashes and can not recovery to send the message when it >> > re-starts ? >> > >> > Willem Jiang 于2018年11月1日周四 上午11:24写道： >> >> >> >> +1 to use the POC show us the fact :) >> >> Now I'm thinking to let Omega more smart[1] by doing the timeout >> >> monitor itself to reduce the complexity of Alpha. >> >> In this way the Alpha just need to store the message and response the >> >> request from Omega. >> >> >> >> [1]https://issues.apache.org/jira/browse/SCB-1000 >> >> >> >> Willem Jiang >> >> >> >> Twitter: willemjiang >> >> Weibo: 姜宁willem >> >> On Thu, Nov 1, 2018 at 11:13 AM 赵俊 wrote: >> >> > >> >> > 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 >> >> > > 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 wrote: >> >> > >> >> >> > >> async is not enough, better to be reactive. >> >> > >> >> >> > >> 赵俊 于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 >> >> > >>> 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 >> >> > 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 于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
Re: [Discuss][SAGA] MicroProfile LRA
Hi Zheng Thanks for the information. As you know the specification has lots of information. Could you break down it into smaller section and we could do some comparison with current Saga implementation? For example, the LRA is based on the Restful Service and the Transaction ID is passed through the HTTP headers. The LRA Client API is much like our Omega API, but we don't expose much of the detail from the client side. Currently we are thinking about to do some enhancement on the Saga protocol by helping user to release the lock once the Saga transaction is finished[1]. I think we may contribute this use case back to the lra specification by starting the discussion first. [1]https://issues.apache.org/jira/browse/SCB-1006 Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Nov 1, 2018 at 3:56 PM Zheng Feng wrote: > > Hi all, > > I think we need to have the eyes on this specification. The LRA (Long > Running Action) [1] tries to introduce some Saga like APIs in the micro > services. These are similar to our omega and alpha APIs currently. Now they > are going to ask the community for some input [2], and I think we can > contribute some ideas from our side especially with the coordinate service > design. > > Thanks, > Zheng Feng > > [1] https://github.com/eclipse/microprofile-lra > [2] https://groups.google.com/forum/#!topic/microprofile/vWM0eXE8gYc
[Discuss][SAGA] MicroProfile LRA
Hi all, I think we need to have the eyes on this specification. The LRA (Long Running Action) [1] tries to introduce some Saga like APIs in the micro services. These are similar to our omega and alpha APIs currently. Now they are going to ask the community for some input [2], and I think we can contribute some ideas from our side especially with the coordinate service design. Thanks, Zheng Feng [1] https://github.com/eclipse/microprofile-lra [2] https://groups.google.com/forum/#!topic/microprofile/vWM0eXE8gYc
Re: Saga，TCC overhead
OK, that makes sense to have such status query interface and this should be introduced by the Java annotations ? Willem Jiang 于2018年11月1日周四 下午3:27写道： > Hi Zheng, > > If the Omega failed to send the Saga event to the Alpha, Alpha could > think the transaction is failed and start the compensation process. > In this way we need the Omega provide the query interface for the > Alpha to verify the states of the transaction to avoid this kind of > situation. > > If we let the Omega (transaction initiator) to know about the timeout, > the Omega help Alpha to do more things, as the transaction initiator > Omega knows all the other services invocation status. In this way > Alpha just need to deal with the transaction initiator Omega crash > situation. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Nov 1, 2018 at 12:13 PM Zheng Feng wrote: > > > > +1. I think we had some implementation codes before by using the > Executors. @Willem Jiang can you recall why we move the timeout handle to > the alpha server ? is there any particular reason ? I think maybe the > following > > 1) the omega fails to send the cancel message when timeout happens due > to the network error ? So the compensation will not happen. > > 2) the omega crashes and can not recovery to send the message when it > re-starts ? > > > > Willem Jiang 于2018年11月1日周四 上午11:24写道： > >> > >> +1 to use the POC show us the fact :) > >> Now I'm thinking to let Omega more smart[1] by doing the timeout > >> monitor itself to reduce the complexity of Alpha. > >> In this way the Alpha just need to store the message and response the > >> request from Omega. > >> > >> [1]https://issues.apache.org/jira/browse/SCB-1000 > >> > >> Willem Jiang > >> > >> Twitter: willemjiang > >> Weibo: 姜宁willem > >> On Thu, Nov 1, 2018 at 11:13 AM 赵俊 wrote: > >> > > >> > 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 > 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 wrote: > >> > >> > >> > >> async is not enough, better to be reactive. > >> > >> > >> > >> 赵俊 于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 < > willem.ji...@gmail.com> > >> > >>> 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 > 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 于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 > >> > >> > >> > >>> > >> > >>> > >> > >
Re: Saga，TCC overhead
Hi Zheng, If the Omega failed to send the Saga event to the Alpha, Alpha could think the transaction is failed and start the compensation process. In this way we need the Omega provide the query interface for the Alpha to verify the states of the transaction to avoid this kind of situation. If we let the Omega (transaction initiator) to know about the timeout, the Omega help Alpha to do more things, as the transaction initiator Omega knows all the other services invocation status. In this way Alpha just need to deal with the transaction initiator Omega crash situation. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Nov 1, 2018 at 12:13 PM Zheng Feng wrote: > > +1. I think we had some implementation codes before by using the Executors. > @Willem Jiang can you recall why we move the timeout handle to the alpha > server ? is there any particular reason ? I think maybe the following > 1) the omega fails to send the cancel message when timeout happens due to the > network error ? So the compensation will not happen. > 2) the omega crashes and can not recovery to send the message when it > re-starts ? > > Willem Jiang 于2018年11月1日周四 上午11:24写道： >> >> +1 to use the POC show us the fact :) >> Now I'm thinking to let Omega more smart[1] by doing the timeout >> monitor itself to reduce the complexity of Alpha. >> In this way the Alpha just need to store the message and response the >> request from Omega. >> >> [1]https://issues.apache.org/jira/browse/SCB-1000 >> >> Willem Jiang >> >> Twitter: willemjiang >> Weibo: 姜宁willem >> On Thu, Nov 1, 2018 at 11:13 AM 赵俊 wrote: >> > >> > 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 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 wrote: >> > >> >> > >> async is not enough, better to be reactive. >> > >> >> > >> 赵俊 于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 >> > >>> 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 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 于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 >> > >> >> > >>> >> > >>> >> >
