Re: [VOTE] Release Apache ServiceComb Pack version 0.7.1
+1 (binding) Lei Zhang 于2022年8月4日周四 02:11写道： > Hi all, > > This is a call for Vote to release Apache ServiceComb Pack version 0.7.1 > > Release Candidate: > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-pack/0.7.1/rc1/ > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1509/ > > Release Tag: > https://github.com/apache/servicecomb-pack/releases/tag/0.7.1 > > Release CommitID: > 9edd26e2d6e246f9b11a48f646645bb610afafe6 > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12352159 > > Keys to verify the Release Candidate: > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now (Thursday, 4th Aug 2022) and will remain open for > at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 0.7.1 > [ ] +0 No Opinion > [ ] -1 Do not release this package because... > > On behalf of the ServiceComb Team > > Lei Zhang >
Re: Apache ServiceComb Pack emergency releases for wrong version
Thanks Lei and it could be very useful. Lei Zhang 于2022年8月4日周四 21:39写道： > Hi, Zheng Feng > > In version 0.7.0, I introduced Maven CI Friendly Versions and > flatten-maven-plugin to manage version numbers in pom. > > But I forgot to add flatten-maven-plugin configuration in the main pom. The > version number in the main pom was not replaced with 0.7.0 (Still > 0.7.0-SNAPSHOT) > > I have fixed this issue in the trunk and 0.7.x branch. > > I have rewritten the pack release guide[1] in my notes, which I will push a > PR to the pack repo later. > > [1] https://coolbeevip.github.io/posts/asf/apache-release-guide/ > > Zheng Feng 于2022年8月4日周四 18:27写道： > > > Is there any doc for the release processing? > > > > Willem Jiang 于2022年8月4日周四 17:00写道： > > > > > Yes, we need to cut a new release to fix this issue. > > > BTW, we also need to verify the pom project version by running some > > > verification. > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Tue, Aug 2, 2022 at 8:21 PM Lei Zhang wrote: > > > > > > > > Hello All, > > > > > > > > Our recently released 0.7.0 release contains the wrong version > > > > 0.7.0-SNAPSHOT[1] > > > > > > > > I have pushed PR[2] to fix this in the 0.7.x branch and master > > > > > > > > I will be cutting the 0.7.1 release from the branch > > > > https://github.com/apache/servicecomb-pack/tree/0.7.x > > > > > > > > @PMC/@Committers please let me know if I missed anything in this > > release. > > > > > > > > [1] https://github.com/apache/servicecomb-pack/issues/763 > > > > [2] https://github.com/apache/servicecomb-pack/pull/766 > > > > > > > > Regards > > > > > > > > Lei Zhang > > > > > >
Re: Apache ServiceComb Pack emergency releases for wrong version
Is there any doc for the release processing? Willem Jiang 于2022年8月4日周四 17:00写道： > Yes, we need to cut a new release to fix this issue. > BTW, we also need to verify the pom project version by running some > verification. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Aug 2, 2022 at 8:21 PM Lei Zhang wrote: > > > > Hello All, > > > > Our recently released 0.7.0 release contains the wrong version > > 0.7.0-SNAPSHOT[1] > > > > I have pushed PR[2] to fix this in the 0.7.x branch and master > > > > I will be cutting the 0.7.1 release from the branch > > https://github.com/apache/servicecomb-pack/tree/0.7.x > > > > @PMC/@Committers please let me know if I missed anything in this release. > > > > [1] https://github.com/apache/servicecomb-pack/issues/763 > > [2] https://github.com/apache/servicecomb-pack/pull/766 > > > > Regards > > > > Lei Zhang >
Re: [VOTE] Release Apache ServiceComb Pack version 0.7.0
+1 Lei Zhang 于2022年5月12日周四 14:24写道： > Hi all, > > This is a call for Vote to release Apache ServiceComb Pack version 0.7.0 > > Release Candidate: > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-pack/0.7.0/rc1/ > > Staging Repository: > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1490 > > Release Tag: > https://github.com/apache/servicecomb-pack/releases/tag/0.7.0 > > Release CommitID: > fae7326c0bac2b07e06ba83cf2cc284648ab1713 > > Release Notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12348307 > > Keys to verify the Release Candidate: > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now (Thursday, 12st May 2022) and will remain open for > at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 0.7.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On behalf of the ServiceComb Team > > Lei Zhang >
Re: [DISCUSSION] About Pack module refactoring
+1 and I also want to extract some SPI interfaces for alpha-server and these can help users to implement some other saga pattern in the future. I add the LRA in my todo list since the spec will be released 1.0 Final very soon. Willem Jiang 于2021年3月22日周一 上午8:59写道： > +1. We should seperate the implementations of Saga and TCC, when > starting the alpha server, users should be able to configure the > modules as they want. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sat, Mar 20, 2021 at 1:29 PM Lei Zhang wrote: > > > > Hi, Park Team > > > > Currently, Park's module division is unclear, difficult for contributors > to > > participate. > > > > I suggest dividing the modules again and use SPI to provide these > > components. > > > > The operations can be quite involved, requiring many steps to complete > the > > reconstruction. I think we can start with the division of modules for > > example: > > > > * state machine mode does not require DB, > > * state machine mode persistence layer should be easily replaced > > * non-state machine mode Saga and TCC Should be split into two modules, > etc. > > > > This is just my initial thoughts, any suggestions？ > > > > alpha-benchmark > > alpha-server-ui > > alpha-server-core > > alpha-server-saga-db > > alpha-server-saga-fsm > > alpha-server-tcc-db > > alpha-server-tcc-fsm (maybe) > > alpha-server-bootstrap (I expect that only this module depends on the > > framework infrastructure in the future) > > alpha-server-discovery-plugin-consul > > alpha-server-discovery-plugin-eureka > > alpha-server-discovery-plugin-nacos > > alpha-server-discovery-plugin-zookeeper > > > > Best regards, > > Lei Zhang >
Re: Apply to Contribute to ServiceComb Pack
Welcome and feel free to ask questions here ! Cheers, Zheng Feng song Sylvia 于2020年6月18日周四 下午2:05写道： > Hi everyone, > > I’m Xinwei Song, a student studying in a joint program of Beihang > University and Beijing University of Technology, majoring in software > engineering. I saw the project: ServiceComb Pack on an open-source coding > related activity, and I’m quite interested in it. Therefore, I apply to > learn more about this project and eventually contribute to it. > > Hopefully I can get some technical help from the community and make this > project better as a return. > > Best wishes, > Xinwei Song > > > 发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用 > >
Re: [VOTE] Release Apache ServiceComb Pack version 0.6.0
+1 (binding) I checked the source building and running the tests. Willem Jiang 于2020年5月24日周日 下午9:29写道： > +1（binding) > > I checked the demo with staging repo. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, May 22, 2020 at 12:40 AM Mohammad Asif Siddiqui > wrote: > > > > Hi All, > > > > This is a call for Vote to release Apache ServiceComb Pack version 0.6.0 > > > > Release Candidate : > > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-pack/0.6.0/rc-01/ > > > > > > Staging Repository : > > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1444 > > > > > > Release Tag : > https://github.com/apache/servicecomb-pack/releases/tag/0.6.0 > > > > > > Release CommitID : d315a88027e278c473b7c257c45dead970b02694 > > > > Release Notes : > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346057 > > > > > > Keys to verify the Release Candidate : > > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > Voting will start now ( Thursday, 21st May, 2020) and will remain open > for > > at-least 72 hours, Request all PMC members to give their vote. > > > > [ ] +1 Release this package as 0.6.0 > > [ ] +0 No Opinion > > [ ] -1 Do not release this package because > > > > On the behalf of ServiceComb Team > > Mohammad Asif Siddiqui >
Re: [VOTE] Release Apache ServiceComb Pack version 0.6.0
Hi Willem, The staging repo looks good now. Willem Jiang 于2020年5月22日周五 上午10:32写道： > Hi, Zheng > Thanks to go through this release candidate. > The Open issue will be updated once we release pack-0.6.0 in JIRA. > For the Staging repo, I can access the url > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1444 > without any error. > Could you double check it? > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, May 22, 2020 at 8:33 AM Zheng Feng wrote: > > > > It looks like the "Release Notes" has some issues which the status are > > still "OPEN" or "In Progress". > > And the link of Staging Repository can not be access which returns 503 > > > > Mohammad Asif Siddiqui 于2020年5月22日周五 上午12:40写道： > > > > > Hi All, > > > > > > This is a call for Vote to release Apache ServiceComb Pack version > 0.6.0 > > > > > > Release Candidate : > > > > > > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-pack/0.6.0/rc-01/ > > > > > > > > > Staging Repository : > > > > > > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1444 > > > > > > > > > Release Tag : > > > https://github.com/apache/servicecomb-pack/releases/tag/0.6.0 > > > > > > > > > Release CommitID : d315a88027e278c473b7c257c45dead970b02694 > > > > > > Release Notes : > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346057 > > > > > > > > > Keys to verify the Release Candidate : > > > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > > > Voting will start now ( Thursday, 21st May, 2020) and will remain open > for > > > at-least 72 hours, Request all PMC members to give their vote. > > > > > > [ ] +1 Release this package as 0.6.0 > > > [ ] +0 No Opinion > > > [ ] -1 Do not release this package because > > > > > > On the behalf of ServiceComb Team > > > Mohammad Asif Siddiqui > > > >
Re: [VOTE] Release Apache ServiceComb Pack version 0.6.0
It looks like the "Release Notes" has some issues which the status are still "OPEN" or "In Progress". And the link of Staging Repository can not be access which returns 503 Mohammad Asif Siddiqui 于2020年5月22日周五 上午12:40写道： > Hi All, > > This is a call for Vote to release Apache ServiceComb Pack version 0.6.0 > > Release Candidate : > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-pack/0.6.0/rc-01/ > > > Staging Repository : > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1444 > > > Release Tag : > https://github.com/apache/servicecomb-pack/releases/tag/0.6.0 > > > Release CommitID : d315a88027e278c473b7c257c45dead970b02694 > > Release Notes : > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346057 > > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Thursday, 21st May, 2020) and will remain open for > at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 0.6.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > Mohammad Asif Siddiqui >
Re: [Announce] New committer of ServiceComb
Congratulations ! Willem Jiang 于2020年5月9日周六 下午6:39写道： > Hi, > > I want to introduce humingcheng (Github ID: humingcheng[1]) as a new > committer of ServiceComb. He is one of the main author of > servicecomb-mesher and has been around the ServiceComb almost a year > by contributing patches for servicecomb-service-center, > servicecomb-mesher and servicecomb-kie. > Welcome humingcheng :) > > [1]http://github.com/humingcheng > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [ANN] New ServiceComb committer:Sun Lisen(孙丽森)
Welcome aboard ! Bin Ma 于2019年12月23日周一 下午2:32写道： > Please join me and the rest of the ServiceComb PMC members in welcoming our > new ServiceComb committer: Sun Lisen(孙丽森). > > Sun Lisen has been around the ServiceComb almost a year by > contributing patches for servicecomb-toolkit, > servicecomb-java-chassis,servicecomb-website and > discussion techniques issue in the mailing list. Recently > he contributed key features such as OAIV3 and SpringCloud to > servicecomb-toolkit and commit on it frequently. > > Congratulations to Sun Lisen! Welcome! > > The Apache ServiceComb PMC. >
Re: [DISCUSS][PACK] Compensation with combination of forward and reverse
So you want to introduce a new policy for recovering ? "try forward recovering at first in retries times, if it fails then following with the reverse to compensate." This makes sense but this could add a new attribute with the @Compensable. I'm not sure if it could be incompatible. Anyway, try to raise a JIRA and record this idea. Zhang Lei 于2019年12月12日周四 上午9:47写道： > Hi, Pack Team > > I noticed that forward and reverse cannot be used in combination. If > retries == 0 then reverse otherwise forward. I never paid attention to it > before until I started thinking about how to define retry and timeout rules > for reverse recovery. > > The purpose of all of this? maybe there ’s something I don’t know. > > Can I try to use a combination of the two recovery mode? I want to try to > send TxAbortedEvent to Alpha even after the forward recovery fails. > > Best regards, > Lei Zhang >
Re: Fw: [DISCUSSION] Rsocket
At first glance, it looks like another gPRC but I just find this article [1] to discuss the differences between gRPC and RSocket. I think we need to keep eye on it. [1] https://medium.com/netifi/differences-between-grpc-and-rsocket-e736c954e60 yhs0092 于2019年12月4日周三 下午5:57写道： > This is the content of the mail "[DISCUSSION] Rsocket is hot now" from > gylgeek . > There seems some problem with his mailbox : ) > > > Yours sincerely > > > Yao Haishi > yhs0...@163.com > > > > - Forwarded Message - > > From： gylg...@gmail.com > Date： 12/4/2019 17:50 > To： > Subject： [DISCUSSION] Rsocket > RSocket is a binary protocol for use on byte stream transports such as > TCP, WebSockets, and Aeron. It enables the following symmetric interaction > models via async message passing over a single connection: > > request/response (stream of 1) > request/stream (finite stream of many) > fire-and-forget (no response) > event subscription (infinite stream of many) > Learn more at: > http://rsocket.io > https://github.com/rsocket/rsocket-java > Dubbo and SpringCloud already support Rsocket, and take Rsocketas a future > development trend. > In spring 5, spring marks asynchronous interfaces such as > asyncRestTemplate as @Deprecated , instead to recommend webflux(based on > Rsocket). > Dubbo 3.0.0-snapshot also supports responsive programming based on Rsocket. > Reactive should consist of two parts: asynchronous functional programming > and streaming programming. But service-comb don't have streaming > programming. > Rsocket can also be used in service mesh. Learn more at: > https://www.netifi.com/solutions-servicemesh > > > Best regards, > Guo YongLiang. > > > > > > > >
Re: Improve the transaction compensation mechanism for FSM
Hi, I wonder how we can diff the "Omega compensation failure" from the "Business compensation failure" ? the different exception classes ? Zhang Lei 于2019年11月25日周一 下午5:32写道： > Hi, Pack Team > > Currently, Alpha compensation mechanism has some defects [1], I plan to > solve this problem step by step [2] > > Step1: Modify the OnConnected method to bidirectional streaming RPC > >This will be needed for the Step2 > > Step2: Custom compensation exception rules to distinguish between business > compensation exceptions and framework compensation exceptions for FSM. > >After calling the compensation method, Alpha needs to wait for > Omega to send a compensation result message. The message type is as > follows: > >Successful compensation: >Business compensation failure：business code throws an exception, > Do not switch Omega instance and retry（Retry rule is implemented in the > Step3） >Omega compensation failure: omega code throws an exception, > switch other Omega instance and retry（Retry rule is implemented in the > Step3） > > > Step3. Added retry and timeout rule to compensate for failures > >Exceeded the number of retries or timeout will change state to > suspended > > Any Suggestion? > > [1] https://github.com/apache/servicecomb-pack/issues/590 > [2] https://github.com/apache/servicecomb-pack/pull/607 > > Best regards, > Lei Zhang > > > Best regards, > Lei Zhang >
Re: [Pack] Use Netty native transport improve performance
It looks good to and can you confirm which license these native libraries are using ? especially they are not the part of the netty core. Thanks, Zheng Feng Zhang Lei 于2019年11月14日周四 下午9:50写道： > Hi, Pack Team > > Netty provides native socket transport[1] for Linux and macOS, In order to > support it, I need to upgrade Netty to the new version. But there are some > problems[2] with the SSL test case after the upgrade. > > Boringssl does not support cipher ECDHE-ECDSA-AES128-SHA256, You can see it > in this commit [3] > > ECDHE-ECDSA-AES128-SHA256 is openssl cipher name and > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 is RFC cipher name, they are the > same > > So I recommend removing cipher ECDHE-ECDSA-AES128-SHA256 from the file > below. > > https://github.com/apache/servicecomb-pack/blob/master/omega/omega-connector/omega-connector-grpc/src/main/resources/ssl.properties > > https://github.com/apache/servicecomb-pack/blob/master/omega/omega-connector/omega-connector-grpc/src/test/java/org/apache/servicecomb/pack/omega/connector/grpc/saga/SagaLoadBalanceSenderWithTLSTest.java > > https://github.com/apache/servicecomb-pack/blob/master/alpha/alpha-server/src/main/resources/ssl.properties > > https://github.com/apache/servicecomb-pack/blob/master/alpha/alpha-server/src/test/java/org/apache/servicecomb/pack/alpha/server/AlphaIntegrationWithSSLTest.java > > > [1] https://netty.io/wiki/native-transports.html > [2] https://github.com/netty/netty/issues/9775 > [3] > > https://github.com/google/boringssl/commit/6e678eeb6e76171712ae00d467321b6fe196152d > > > Best regards, > Lei Zhang >
Re: Simplify user usage if the OmegaContext parameter is defined in the @SagaStart or @Compensable annotation method
OK, I get it. So the HttpServletRequest request has been injected
automatically just when we declare it in the method signatures.
Is there any difference between this declaration and the @Autowired ?
Do we need to guarantee that this is thread-safe ?
anyway, these should be documented very well and make sure the users
understand the usages.
Zhang Lei 于2019年11月14日周四 上午10:51写道：
> We can refer to the method annotation of spring MVC. The parameter
> HttpServletRequest is optional
>
> @RequestMapping()
> public void do(HttpServletRequest request){
>
> }
>
> Best regards,
> Lei Zhang
>
> On November 14, 2019 at 10:06:57 AM, Zheng Feng (zh.f...@gmail.com) wrote:
>
> But how can we reference this parameter in the method ? I don't think the
> Java support this kind of syntax.
>
> Willem Jiang 于2019年11月14日周四 上午9:43写道：
>
> > Can I invoke the booking method like this ?
> > booking().
> >
> > Then, the OmegaContext would be inject as a parameter?
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Nov 14, 2019 at 9:34 AM Zheng Feng wrote:
> > >
> > > So it could introduce an annotation or use the @Resource just like
> > > @SagaStart
> > > public void booking(@Resource OmegaContext context) {
> > > ...
> > > }
> > >
> > > and we also can inject the OmegaContext during invoking the method.
> > >
> > > Zhang Lei 于2019年11月13日周三 下午11:42写道：
> > >
> > > > Hi, Zheng Feng
> > > >
> > > > Both are ok.
> > > >
> > > > I saw in [1] that the TransactionContext is passed using parameters.
> I
> > just
> > > > recommend passing some parameters in a consistent way.
> > > >
> > > > [1]
> > > >
> > > >
> >
>
> https://issues.apache.org/jira/browse/SCB-785?focusedCommentId=16561332=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16561332
> > > >
> > > > Best regards,
> > > > Lei Zhang
> > > >
> > > > On November 13, 2019 at 9:45:58 PM, Zheng Feng (zh.f...@gmail.com)
> > wrote:
> > > >
> > > > I'm not very clear what could be benefited from these changes ? with
> > > > declaring the OmegaContext explicitly ?
> > > >
> > > > Willem Jiang 于2019年11月13日周三 下午3:47写道：
> > > >
> > > > > If it is optional, we need to inject the OmegaContext dynamically
> and
> > > > > provide a wrap method for it.
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > > > > On Wed, Nov 13, 2019 at 3:42 PM Zhang Lei
> > wrote:
> > > > > >
> > > > > > Hi, Willem Jiang
> > > > > >
> > > > > > I think OmegaContext is an optional parameter in the method
> > > > > >
> > > > > >
> > > > > > Best regards,
> > > > > > Lei Zhang
> > > > > >
> > > > > > On November 13, 2019 at 2:48:08 PM, Willem Jiang (
> > > > willem.ji...@gmail.com
> > > > > )
> > > > > > wrote:
> > > > > >
> > > > > > Just a quick question, if user call the booking() method, he need
> > to
> > > > > > pass the OmegaContext as a parameter.
> > > > > > What if the invoker doesn't know anything about the OmegaContext.
> > > > > >
> > > > > >
> > > > > > Willem Jiang
> > > > > >
> > > > > > Twitter: willemjiang
> > > > > > Weibo: 姜宁willem
> > > > > >
> > > > > > On Tue, Nov 12, 2019 at 11:34 PM Zhang Lei >
> > > > wrote:
> > > > > > >
> > > > > > > Hi, Pack Team
> > > > > > >
> > > > > > > Currently, the @Autowired annotation is required to get the
> > > > > OmegaContext
> > > > > > on
> > > > > > > the Omega side, but most of the early use does not know the
> > existence
> > > > > of
> > > > > > > the OmegaContext object.
> > > > > > >
> > > > > > > @Autowired
> > > > > > > OmegaContext omegaContext;
> > > > > > >
> > > > > > > @SagaStart
> > > > > > > public void booking() {
> > > > > > > omegaContext.globalTxId()
> > > > > > > ...
> > > > > > > }
> > > > > > >
> > > > > > > @Compensable(compensationMethod="cancel")
> > > > > > > public void car(String from, int amount) {
> > > > > > > omegaContext.globalTxId()
> > > > > > > ...
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > > Maybe we should allow the user to get the OmegaContext via
> method
> > > > > > > parameters. Use the method below to define the OmegaContext
> > > > parameter.
> > > > > > >
> > > > > > > @SagaStart
> > > > > > > public void booking(OmegaContext omegaContext) {
> > > > > > > omegaContext.globalTxId()
> > > > > > > ...
> > > > > > > }
> > > > > > >
> > > > > > > @Compensable(compensationMethod="cancel")
> > > > > > > public void car(OmegaContext omegaContext, String from, int
> > amount) {
> > > > > > > omegaContext.globalTxId()
> > > > > > > ...
> > > > > > > }
> > > > > > >
> > > > > > > Any suggestion？
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Lei Zhang
> > > > >
> > > >
> >
>
Re: Simplify user usage if the OmegaContext parameter is defined in the @SagaStart or @Compensable annotation method
But how can we reference this parameter in the method ? I don't think the
Java support this kind of syntax.
Willem Jiang 于2019年11月14日周四 上午9:43写道：
> Can I invoke the booking method like this ?
> booking().
>
> Then, the OmegaContext would be inject as a parameter?
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Thu, Nov 14, 2019 at 9:34 AM Zheng Feng wrote:
> >
> > So it could introduce an annotation or use the @Resource just like
> > @SagaStart
> > public void booking(@Resource OmegaContext context) {
> > ...
> > }
> >
> > and we also can inject the OmegaContext during invoking the method.
> >
> > Zhang Lei 于2019年11月13日周三 下午11:42写道：
> >
> > > Hi, Zheng Feng
> > >
> > > Both are ok.
> > >
> > > I saw in [1] that the TransactionContext is passed using parameters. I
> just
> > > recommend passing some parameters in a consistent way.
> > >
> > > [1]
> > >
> > >
> https://issues.apache.org/jira/browse/SCB-785?focusedCommentId=16561332=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16561332
> > >
> > > Best regards,
> > > Lei Zhang
> > >
> > > On November 13, 2019 at 9:45:58 PM, Zheng Feng (zh.f...@gmail.com)
> wrote:
> > >
> > > I'm not very clear what could be benefited from these changes ? with
> > > declaring the OmegaContext explicitly ?
> > >
> > > Willem Jiang 于2019年11月13日周三 下午3:47写道：
> > >
> > > > If it is optional, we need to inject the OmegaContext dynamically and
> > > > provide a wrap method for it.
> > > >
> > > > Willem Jiang
> > > >
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Wed, Nov 13, 2019 at 3:42 PM Zhang Lei
> wrote:
> > > > >
> > > > > Hi, Willem Jiang
> > > > >
> > > > > I think OmegaContext is an optional parameter in the method
> > > > >
> > > > >
> > > > > Best regards,
> > > > > Lei Zhang
> > > > >
> > > > > On November 13, 2019 at 2:48:08 PM, Willem Jiang (
> > > willem.ji...@gmail.com
> > > > )
> > > > > wrote:
> > > > >
> > > > > Just a quick question, if user call the booking() method, he need
> to
> > > > > pass the OmegaContext as a parameter.
> > > > > What if the invoker doesn't know anything about the OmegaContext.
> > > > >
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > > > > On Tue, Nov 12, 2019 at 11:34 PM Zhang Lei
> > > wrote:
> > > > > >
> > > > > > Hi, Pack Team
> > > > > >
> > > > > > Currently, the @Autowired annotation is required to get the
> > > > OmegaContext
> > > > > on
> > > > > > the Omega side, but most of the early use does not know the
> existence
> > > > of
> > > > > > the OmegaContext object.
> > > > > >
> > > > > > @Autowired
> > > > > > OmegaContext omegaContext;
> > > > > >
> > > > > > @SagaStart
> > > > > > public void booking() {
> > > > > > omegaContext.globalTxId()
> > > > > > ...
> > > > > > }
> > > > > >
> > > > > > @Compensable(compensationMethod="cancel")
> > > > > > public void car(String from, int amount) {
> > > > > > omegaContext.globalTxId()
> > > > > > ...
> > > > > > }
> > > > > >
> > > > > >
> > > > > > Maybe we should allow the user to get the OmegaContext via method
> > > > > > parameters. Use the method below to define the OmegaContext
> > > parameter.
> > > > > >
> > > > > > @SagaStart
> > > > > > public void booking(OmegaContext omegaContext) {
> > > > > > omegaContext.globalTxId()
> > > > > > ...
> > > > > > }
> > > > > >
> > > > > > @Compensable(compensationMethod="cancel")
> > > > > > public void car(OmegaContext omegaContext, String from, int
> amount) {
> > > > > > omegaContext.globalTxId()
> > > > > > ...
> > > > > > }
> > > > > >
> > > > > > Any suggestion？
> > > > > >
> > > > > > Best regards,
> > > > > > Lei Zhang
> > > >
> > >
>
Re: Simplify user usage if the OmegaContext parameter is defined in the @SagaStart or @Compensable annotation method
So it could introduce an annotation or use the @Resource just like
@SagaStart
public void booking(@Resource OmegaContext context) {
...
}
and we also can inject the OmegaContext during invoking the method.
Zhang Lei 于2019年11月13日周三 下午11:42写道：
> Hi, Zheng Feng
>
> Both are ok.
>
> I saw in [1] that the TransactionContext is passed using parameters. I just
> recommend passing some parameters in a consistent way.
>
> [1]
>
> https://issues.apache.org/jira/browse/SCB-785?focusedCommentId=16561332=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16561332
>
> Best regards,
> Lei Zhang
>
> On November 13, 2019 at 9:45:58 PM, Zheng Feng (zh.f...@gmail.com) wrote:
>
> I'm not very clear what could be benefited from these changes ? with
> declaring the OmegaContext explicitly ?
>
> Willem Jiang 于2019年11月13日周三 下午3:47写道：
>
> > If it is optional, we need to inject the OmegaContext dynamically and
> > provide a wrap method for it.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Nov 13, 2019 at 3:42 PM Zhang Lei wrote:
> > >
> > > Hi, Willem Jiang
> > >
> > > I think OmegaContext is an optional parameter in the method
> > >
> > >
> > > Best regards,
> > > Lei Zhang
> > >
> > > On November 13, 2019 at 2:48:08 PM, Willem Jiang (
> willem.ji...@gmail.com
> > )
> > > wrote:
> > >
> > > Just a quick question, if user call the booking() method, he need to
> > > pass the OmegaContext as a parameter.
> > > What if the invoker doesn't know anything about the OmegaContext.
> > >
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Tue, Nov 12, 2019 at 11:34 PM Zhang Lei
> wrote:
> > > >
> > > > Hi, Pack Team
> > > >
> > > > Currently, the @Autowired annotation is required to get the
> > OmegaContext
> > > on
> > > > the Omega side, but most of the early use does not know the existence
> > of
> > > > the OmegaContext object.
> > > >
> > > > @Autowired
> > > > OmegaContext omegaContext;
> > > >
> > > > @SagaStart
> > > > public void booking() {
> > > > omegaContext.globalTxId()
> > > > ...
> > > > }
> > > >
> > > > @Compensable(compensationMethod="cancel")
> > > > public void car(String from, int amount) {
> > > > omegaContext.globalTxId()
> > > > ...
> > > > }
> > > >
> > > >
> > > > Maybe we should allow the user to get the OmegaContext via method
> > > > parameters. Use the method below to define the OmegaContext
> parameter.
> > > >
> > > > @SagaStart
> > > > public void booking(OmegaContext omegaContext) {
> > > > omegaContext.globalTxId()
> > > > ...
> > > > }
> > > >
> > > > @Compensable(compensationMethod="cancel")
> > > > public void car(OmegaContext omegaContext, String from, int amount) {
> > > > omegaContext.globalTxId()
> > > > ...
> > > > }
> > > >
> > > > Any suggestion？
> > > >
> > > > Best regards,
> > > > Lei Zhang
> >
>
Re: [DISCUSSION][Samples] E-commerce sample project want to merge into servicecomb-samples
+1 and feel free to raise the PR. 郑志鹏 于2019年11月12日周二 上午11:16写道： > Hi, All > > I have created e-commerce project as a ServiceComb sample project for user > guiding purpose with two other passionate guys. It's not perfect but it's > working. I want merge it into servicecomb-samples first, so there maybe > have more people would want to work with us to optimize it together. We > can merge it into a non-master branch first. > > -- > Best Wishes & Regards > ——— > Alec Zheng >
Re: Simplify user usage if the OmegaContext parameter is defined in the @SagaStart or @Compensable annotation method
I'm not very clear what could be benefited from these changes ? with
declaring the OmegaContext explicitly ?
Willem Jiang 于2019年11月13日周三 下午3:47写道：
> If it is optional, we need to inject the OmegaContext dynamically and
> provide a wrap method for it.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Nov 13, 2019 at 3:42 PM Zhang Lei wrote:
> >
> > Hi, Willem Jiang
> >
> > I think OmegaContext is an optional parameter in the method
> >
> >
> > Best regards,
> > Lei Zhang
> >
> > On November 13, 2019 at 2:48:08 PM, Willem Jiang (willem.ji...@gmail.com
> )
> > wrote:
> >
> > Just a quick question, if user call the booking() method, he need to
> > pass the OmegaContext as a parameter.
> > What if the invoker doesn't know anything about the OmegaContext.
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Tue, Nov 12, 2019 at 11:34 PM Zhang Lei wrote:
> > >
> > > Hi, Pack Team
> > >
> > > Currently, the @Autowired annotation is required to get the
> OmegaContext
> > on
> > > the Omega side, but most of the early use does not know the existence
> of
> > > the OmegaContext object.
> > >
> > > @Autowired
> > > OmegaContext omegaContext;
> > >
> > > @SagaStart
> > > public void booking() {
> > > omegaContext.globalTxId()
> > > ...
> > > }
> > >
> > > @Compensable(compensationMethod="cancel")
> > > public void car(String from, int amount) {
> > > omegaContext.globalTxId()
> > > ...
> > > }
> > >
> > >
> > > Maybe we should allow the user to get the OmegaContext via method
> > > parameters. Use the method below to define the OmegaContext parameter.
> > >
> > > @SagaStart
> > > public void booking(OmegaContext omegaContext) {
> > > omegaContext.globalTxId()
> > > ...
> > > }
> > >
> > > @Compensable(compensationMethod="cancel")
> > > public void car(OmegaContext omegaContext, String from, int amount) {
> > > omegaContext.globalTxId()
> > > ...
> > > }
> > >
> > > Any suggestion？
> > >
> > > Best regards,
> > > Lei Zhang
>
Re: [ANN] New ServiceComb committer: Daniel Qian (钱嘉）
Congrats and welcome on board ! Willem Jiang 于2019年11月8日周五 上午8:03写道： > Please join me and the rest of the ServiceComb PMC members in welcoming our > new ServiceComb committer: Daniel Qian (钱嘉） > > Daniel Qian has been around the ServiceComb for more than one years by > contributing patches to servicecomb-pack and discussion techniques > issue in the mailing list. Recently he just contributed the > osa-validator tool to ServiceComb. > > Congratulations to Daniel Qian! Welcome! > > The Apache ServiceComb PMC. >
Re: [VOTE] Accept oas-validator to ServiceComb
/thanks! It looks great and very helpful ! +1 Regards, Zheng Feng Willem Jiang 于2019年10月15日周二 上午11:08写道： > Hi Team, > > This is a call for vote Accept oas-validator into > Apache Software Foundation (ASF) as a part of ServiceComb Toolkit. > There is the discussion thread[1] about the donation. > > Voting will start now ( Tuesday, 15th Oct, 2019) and will > remain open for at-least 72 hours, Request all PMC members to > give their vote. > [ ] +1 Accept > [ ] +0 No Opinion > [ ] -1 Reject because... > > [1] > https://lists.apache.org/thread.html/3fc8dae6faa2055dd59d600c9da8508360766ec361d81ec0ceefa8db@%3Cdev.servicecomb.apache.org%3E > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [PROPOSAL] Update the website homepage to make it easier for users to use ServiceComb
+1 for updating the website and it looks like we have many sub-projects under the umbrella of servicecomb. It could be important to provide a clearer category and make the customer to find them. Regards, Zheng Feng victor chan 于2019年9月7日周六 上午12:31写道： > Hello,all > Recently, I have made a return visit to some users in the community, many > of whom reported that the documents on our website were unfriendly and > imperfect. They are looking forward to our improvement. I checked the > relevant documents and found that our documentation is relatively complete, > but there are still some problems, that is, we did not perform a good > indexing and classification, and some of the valuable things were placed in > a very secret place,the users are very hard to find it. So we need to > modify it. Here are some proposals: > 1 Add a list of items to display projects. > 2 Add the banner page, display the latest activities and release noties > dynamically. > 3 Adjust the navigation bar to provide a clearer classification and > highlight the content that is useful for users. > 4 Sort and constitution documents. > > Best Wishes & Regards >
Re: Integration of Skywalking agent with ServiceComb Pack.
Thanks a lot and I think these could be very helpful ! Sheng Wu 于2019年9月5日周四 下午10:30写道： > We have a service comb RPC plugin, provided by you before. > For pack and transaction, we need another plugin. > > There are a lot of plugins you could ref, and Seata plugin is WIP too, > https://github.com/apache/skywalking/pulls. Wait for new protocol stable > at > Seata side. > > Sheng Wu 吴晟 > > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin > Twitter, wusheng1108 > > > Zheng Feng 于2019年9月5日周四 上午7:28写道： > > > So we have to dev a new plugin for the servicecomb-pack or there is a > > plugin we could leverage with ? > > > > Sheng Wu 于2019年9月5日周四 下午10:08写道： > > > > > Then SkyWalking has a toolkit lib[1], you could use > > > `TraceContext.traceId()` in any place, if there is sw agent attached, > and > > > current context has been traced, you could have the trace id. > > > > > > [1] > > > > > > > > > https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md > > > > > > Sheng Wu 吴晟 > > > > > > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin > > > Twitter, wusheng1108 > > > > > > > > > Zheng Feng 于2019年9月5日周四 上午5:46写道： > > > > > > > Sheng Wu 于2019年9月4日周三 上午11:31写道： > > > > > > > > > Willem Jiang 于2019年9月3日周二 下午6:25写道： > > > > > > > > > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei > > > > > wrote: > > > > > > > > > > > > > > Hi Willem, > > > > > > > > > > > > > > I agree to integrate a transaction tracking service, I used > > > Zipkin, > > > > > but > > > > > > I don't know much about Skywalking. > > > > > > > > > > > > > > I have some questions: > > > > > > > > > > > > > > 1. Skywalking agent just working on the Omega side? > > > > > > Yep, but we can also let the agent do the instrumentation on the > > > Alpha > > > > > > side. > > > > > > > > > > > > > > > > > 2. Use @Trace in the same location as @SagaStart and > > @Compensable, > > > Or > > > > > > Combined annotation? And use TraceContext.traceId() to generate > > > > > globalTxId > > > > > > or localTxId ? > > > > > > This is the detail thing we need to think about. > > > > > > I think you are just proposing a way to integrate the Zipkin, am > I > > > > right? > > > > > > > > > > > > > > > > @Trace is SkyWalking annotation, which SkyWalking agent could > > identify > > > > and > > > > > instrument as a local span(Not RPC related) > > > > > > > > > > > > > > > > > > > > > > > 3. Will Omega users have conflicts if they already use Zipkin? > > > > > > We need to do some end to end verification, currently I think > it's > > > > > > fine if we can find a way to generate a correlation id between > > > tracing > > > > > > system and pack, we don't need to deeply combine these two system > > > > > > together, they can work separately. > > > > > > > > > > > > > > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to > use > > > > both > > > > > at the same time, because it is pointless. > > > > > > > > > > > > > > > > > > > > > > > 4. About provides a service to bridge the Trace information > that > > > > > > Skywalking collects with ServiceComb Pack Transaction events > > > > information. > > > > > > Do you mean that Alpha sends service chain information directly > to > > > > > > Skywalking via API? > > > > > > It's more like a portal integration. We can still leverage the > old > > > API > > > > > > provide by Skywalking and ServiceComb Pack. > > > > > > > > > > > > > > > > In this way, we need to have a deeper discussion about what > > ServiceComb > > > > > wants and requires. > > > > > > > > > Basically, I think we need to track the saga transa
Re: Integration of Skywalking agent with ServiceComb Pack.
So we have to dev a new plugin for the servicecomb-pack or there is a plugin we could leverage with ? Sheng Wu 于2019年9月5日周四 下午10:08写道： > Then SkyWalking has a toolkit lib[1], you could use > `TraceContext.traceId()` in any place, if there is sw agent attached, and > current context has been traced, you could have the trace id. > > [1] > > https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Application-toolkit-trace.md > > Sheng Wu 吴晟 > > Apache SkyWalking, Apache ShardingSphere(Incubating), Zipkin > Twitter, wusheng1108 > > > Zheng Feng 于2019年9月5日周四 上午5:46写道： > > > Sheng Wu 于2019年9月4日周三 上午11:31写道： > > > > > Willem Jiang 于2019年9月3日周二 下午6:25写道： > > > > > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei > > wrote: > > > > > > > > > > Hi Willem, > > > > > > > > > > I agree to integrate a transaction tracking service, I used > Zipkin, > > > but > > > > I don't know much about Skywalking. > > > > > > > > > > I have some questions: > > > > > > > > > > 1. Skywalking agent just working on the Omega side? > > > > Yep, but we can also let the agent do the instrumentation on the > Alpha > > > > side. > > > > > > > > > > > 2. Use @Trace in the same location as @SagaStart and @Compensable, > Or > > > > Combined annotation? And use TraceContext.traceId() to generate > > > globalTxId > > > > or localTxId ? > > > > This is the detail thing we need to think about. > > > > I think you are just proposing a way to integrate the Zipkin, am I > > right? > > > > > > > > > > @Trace is SkyWalking annotation, which SkyWalking agent could identify > > and > > > instrument as a local span(Not RPC related) > > > > > > > > > > > > > > > 3. Will Omega users have conflicts if they already use Zipkin? > > > > We need to do some end to end verification, currently I think it's > > > > fine if we can find a way to generate a correlation id between > tracing > > > > system and pack, we don't need to deeply combine these two system > > > > together, they can work separately. > > > > > > > > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use > > both > > > at the same time, because it is pointless. > > > > > > > > > > > > > > > 4. About provides a service to bridge the Trace information that > > > > Skywalking collects with ServiceComb Pack Transaction events > > information. > > > > Do you mean that Alpha sends service chain information directly to > > > > Skywalking via API? > > > > It's more like a portal integration. We can still leverage the old > API > > > > provide by Skywalking and ServiceComb Pack. > > > > > > > > > > In this way, we need to have a deeper discussion about what ServiceComb > > > wants and requires. > > > > > Basically, I think we need to track the saga transaction status by the > > global id. > > > > > > > > > > > > > > > > > > > > > > > > > > Lei Zhang > > > > > > > > > > > 在 2019年9月3日，下午7:22，Willem Jiang 写道： > > > > > > > > > > > > Hi, > > > > > > > > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the > > > > > > distributed transactions, it's make sense that let the > ServiceComb > > > > > > Pack and Skywalking share the same Id for tracing. > > > > > > In this way, we can bring the APM feature into Distribution > > > > > > Transaction managemet world. > > > > > > > > > > > > Current ServiceComb has Interface IdGenerator[1], which is used > for > > > > > > the generate the GlobalTransactionId in OmegaContext[2]. I think > if > > > we > > > > > > can reuse the transaction implementation with the Skywalking > agent > > to > > > > > > generate the GlobalTransactionId. In this way we can search the > > trace > > > > > > information and transactions with same correlation ID. > > > > > > > > > > > > The missing part is LocalTransactionId, we need to figure a way > to > > > > > > bring the LocalTransactionId with the trace information. > > > > > > > > > > > > BTW, ServiceComb Pack is using ES to store the Transaction > related > > > > > > event[3]. I think we can provide a service to bridge the Trace > > > > > > information that Skywalking collects with ServiceComb Pack > > > Transaction > > > > > > events information. > > > > > > > > > > > > Any thoughts? > > > > > > > > > > > > [1] > > > > > > > > > > https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java > > > > > > [2] > > > > > > > > > > https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java > > > > > > [3] > > > > > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm > > > > > > > > > > > > Willem Jiang > > > > > > > > > > > > Twitter: willemjiang > > > > > > Weibo: 姜宁willem > > > > > > > > > > > > > > >
Re: Integration of Skywalking agent with ServiceComb Pack.
Sheng Wu 于2019年9月4日周三 上午11:31写道： > Willem Jiang 于2019年9月3日周二 下午6:25写道： > > > On Tue, Sep 3, 2019 at 10:52 PM Zhang Lei wrote: > > > > > > Hi Willem, > > > > > > I agree to integrate a transaction tracking service, I used Zipkin, > but > > I don't know much about Skywalking. > > > > > > I have some questions: > > > > > > 1. Skywalking agent just working on the Omega side? > > Yep, but we can also let the agent do the instrumentation on the Alpha > > side. > > > > > 2. Use @Trace in the same location as @SagaStart and @Compensable, Or > > Combined annotation? And use TraceContext.traceId() to generate > globalTxId > > or localTxId ? > > This is the detail thing we need to think about. > > I think you are just proposing a way to integrate the Zipkin, am I right? > > > > @Trace is SkyWalking annotation, which SkyWalking agent could identify and > instrument as a local span(Not RPC related) > > > > > > > 3. Will Omega users have conflicts if they already use Zipkin? > > We need to do some end to end verification, currently I think it's > > fine if we can find a way to generate a correlation id between tracing > > system and pack, we don't need to deeply combine these two system > > together, they can work separately. > > > > SkyWalking doesn't conflict with Zipkin, but I don't recommend to use both > at the same time, because it is pointless. > > > > > > > 4. About provides a service to bridge the Trace information that > > Skywalking collects with ServiceComb Pack Transaction events information. > > Do you mean that Alpha sends service chain information directly to > > Skywalking via API? > > It's more like a portal integration. We can still leverage the old API > > provide by Skywalking and ServiceComb Pack. > > > > In this way, we need to have a deeper discussion about what ServiceComb > wants and requires. > Basically, I think we need to track the saga transaction status by the global id. > > > > > > > > > > > > Lei Zhang > > > > > > > 在 2019年9月3日，下午7:22，Willem Jiang 写道： > > > > > > > > Hi, > > > > > > > > As ServiceComb Pack use the GlobalTransactionId to trace the > > > > distributed transactions, it's make sense that let the ServiceComb > > > > Pack and Skywalking share the same Id for tracing. > > > > In this way, we can bring the APM feature into Distribution > > > > Transaction managemet world. > > > > > > > > Current ServiceComb has Interface IdGenerator[1], which is used for > > > > the generate the GlobalTransactionId in OmegaContext[2]. I think if > we > > > > can reuse the transaction implementation with the Skywalking agent to > > > > generate the GlobalTransactionId. In this way we can search the trace > > > > information and transactions with same correlation ID. > > > > > > > > The missing part is LocalTransactionId, we need to figure a way to > > > > bring the LocalTransactionId with the trace information. > > > > > > > > BTW, ServiceComb Pack is using ES to store the Transaction related > > > > event[3]. I think we can provide a service to bridge the Trace > > > > information that Skywalking collects with ServiceComb Pack > Transaction > > > > events information. > > > > > > > > Any thoughts? > > > > > > > > [1] > > > https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/IdGenerator.java > > > > [2] > > > https://github.com/apache/servicecomb-pack/blob/master/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/OmegaContext.java > > > > [3] > > https://github.com/apache/servicecomb-pack/tree/master/alpha/alpha-fsm > > > > > > > > Willem Jiang > > > > > > > > Twitter: willemjiang > > > > Weibo: 姜宁willem > > > > > >
Re: [ANN] New ServiceComb PMC member: Tian Xiaoliang, Zhang Lei
welcome on-board ! Willem Jiang 于2019年8月24日周六 下午6:14写道： > Hi Team, > > I'd be happy to announce that we have two new members on behalf of > ServiceComb PMC. > > * Tian Xiaoliang(田晓亮） > He has been worked with ServiceComb project two years ago, > He is leading ServiceComb Mesher, ServiceComb Kie projects of > ServiceComb. He helped the new > contributors by reviewing code and joining the discussion. > > * Zhang Lei(张磊） > He has been work on ServiceComb Pack since Jan 2019, he drove > the recent state machine change of Alpha, and contributed a very handy > admin UI for Alpha. He was quite active on the mailing list and always > helps new contributors and answers the questions from the users. > > Please join me to welcome them. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [VOTE] Release Apache ServiceComb Pack version 0.5.0
+1 binding I just checked the local building of the release and the tag on the github. Regards, Zheng Feng Mohammad Asif Siddiqui 于2019年8月22日周四 下午6:48写道： > Hi All, > > This is a call for Vote to release Apache ServiceComb Pack version 0.5.0 > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-pack/0.5.0/rc-01/ > > > Staging Repository : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1401 > > > Release Tag : > https://github.com/apache/servicecomb-pack/releases/tag/0.5.0 > > Release CommitID : 6de784700934b5fb8a961ff5a6a16856957f35d7 > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12345242 > > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Thursday, 22nd August, 2019) and will remain open > for at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 0.5.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > Mohammad Asif Siddiqui >
Re: Alpha Web manage UI
Wow, that's great and do we have a plan to release the 0.5.0 which includes some incredible features ? Willem Jiang 于2019年8月15日周四 下午3:49写道： > The code was merged into master last week :) > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Aug 15, 2019 at 3:35 PM Zheng Feng wrote: > > > > yeah, it looks fantastic and did you get chance to create a PR with this > > new UI ? > > > > Willem Jiang 于2019年8月15日周四 上午11:33写道： > > > > > Hi ZhangLei, > > > > > > It's great to see we finally get a new UI for Alpha Server. I think > > > this is a big step for ServiceComb Pack to move to production. > > > > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Fri, Aug 9, 2019 at 7:22 PM Zhang Lei > wrote: > > > > > > > > Hi, Team > > > > > > > > I added a simple front-end web manage UI to AlPHA, I wrote a > manual[1] > > > and Screencast[2]. > > > > > > > > I can't wait to tell everyone. > > > > > > > > Please let me know if you have any suggestions. > > > > > > > > [1] > > > > https://github.com/coolbeevip/servicecomb-pack/blob/SCB-1411/docs/fsm/how_to_use_fsm.md > > > < > > > > https://github.com/coolbeevip/servicecomb-pack/blob/SCB-1411/docs/fsm/how_to_use_fsm.md > > > > > > > > [2] https://www.youtube.com/watch?v=ORoRkZeg8gA < > > > https://www.youtube.com/watch?v=ORoRkZeg8gA> > > > >
Re: Alpha Web manage UI
yeah, it looks fantastic and did you get chance to create a PR with this new UI ? Willem Jiang 于2019年8月15日周四 上午11:33写道： > Hi ZhangLei, > > It's great to see we finally get a new UI for Alpha Server. I think > this is a big step for ServiceComb Pack to move to production. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Aug 9, 2019 at 7:22 PM Zhang Lei wrote: > > > > Hi, Team > > > > I added a simple front-end web manage UI to AlPHA, I wrote a manual[1] > and Screencast[2]. > > > > I can't wait to tell everyone. > > > > Please let me know if you have any suggestions. > > > > [1] > https://github.com/coolbeevip/servicecomb-pack/blob/SCB-1411/docs/fsm/how_to_use_fsm.md > < > https://github.com/coolbeevip/servicecomb-pack/blob/SCB-1411/docs/fsm/how_to_use_fsm.md > > > > [2] https://www.youtube.com/watch?v=ORoRkZeg8gA < > https://www.youtube.com/watch?v=ORoRkZeg8gA> >
Re: [DISCUSSION] Async support for Saga
Hi Willem,
I am not very clear about the TxAsyncStart event ? what's the difference
between the TxAyncStart and TxStarted Event. How does the alpha process the
async events ?
Thanks,
Zheng Feng
Willem Jiang 于2019年7月30日周二 上午8:41写道：
> According to the feedback for PR, I think we need to rethink about the
> SagaEnd implementation in the Async invocation scenario. Normally it's
> harmless we close the Saga transaction later, but we need to make sure
> all the ongoing local transaction are finished.
>
> In the old way, Alpha can know nothing about the start of Async
> Componseable transaction if the TxStartedEvent is not sent, so my
> propose that we introduce a new event TxAsyncStart to tell Alpha there
> is new Async invocation, so Alpha can keep tracking this Async
> invocation event the Componseable transaction is not started yet. In
> this way we could block the Async invocation if the Saga transaction
> is timeout or close the Saga transaction if all the TxAsyncStart
> transaction is finished.
>
> Any thoughts?
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jul 29, 2019 at 5:32 PM Willem Jiang
> wrote:
> >
> > Export the low level API could introduce some error if the user
> > doesn't use the API rightly.
> > My suggestion is we just
> > BTW, I submit a PR[1] to address this issue in a simple way (But we
> > still need to tell user what's the right way to configure the
> > annotation attribute).
> >
> > [1]https://github.com/apache/servicecomb-pack/pull/517
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Thu, Jul 25, 2019 at 8:44 PM Daniel Qian
> wrote:
> > >
> > > Hi Zhang Lei,
> > >
> > > What I'm trying to say is to provide a way for user to send
> > > TxEndedEvent, TxAbortedEvent, TxCompensatedEvent, SagaEndedEvent ...
> > > explicitly on Omega side.
> > > Because current implementation doesn't support following
> situation(async):
> > >
> > > @Compensable(compensationMethod="rollbackFoo")
> > > public void foo() {
> > > new Thread(() -> /* local tx goes here */).start();
> > > // TxEndedEvent sent when returns, it's too early
> > > }
> > >
> > > public void rollbackFoo() {
> > > new Thread(() -> /* compensation goes here*/).start();
> > > // TxCompensatedEvent sent when returns, it's too early
> > > }
> > >
> > > @SagaStart
> > > public void bar() {
> > > new Thread(() -> /* call other service goes here */).start();
> > > // SagaEndedEvent sent when returns, it's too early
> > > }
> > >
> > > I suggest providing a helper class, called omega or something else,
> > > user can use it to send TxEndedEvent, TxAbortedEvent,
> > > TxCompensatedEvent, SagaEndedEvent, etc. So the code goes like this:
> > >
> > > @Compensable(async=true, compensationMethod="rollbackFoo",
> > > compensationAsync=true)
> > > public void foo() {
> > > TransactionContext txContext = omegaContext.getTransactionContext();
> > > new Thread(() -> {
> > > try {
> > > /* local tx goes here */
> > > omega.txEnded(txContext);
> > > } catch(Exception e) {
> > > omega.txAborted(txContext);
> > > }
> > > }).start();
> > > }
> > >
> > > public void rollbackFoo() {
> > > TransactionContext txContext = omegaContext.getTransactionContext();
> > > new Thread(() -> {
> > > /*compensation goes here*/
> > > omega.txCompensated()
> > > }).start();
> > > }
> > >
> > > @SagaStart(async=true)
> > > public void bar() {
> > > TransactionContext txContext = omegaContext.getTransactionContext();
> > > new Thread(() -> {
> > > /* call other service goes here */
> > > try {
> > > omega.sagaEnded(txContext);
> > > } catch (Exception e) {
> > > omega.sagaAborted(txContext);
> > > }
> > > }).start();
> > > }
> > >
> > >
> > > Zhang Lei 于2019年7月25日周四 下午4:46写道：
> > >
> > >
> > > Zhang Lei 于2019年7月25日周四 下午4:46写道：
> > > >
> > > > Hi, Daniel Qian
> > > >
> > > > Are you talking about the asynchronous problem with the @SagaStart
> and @Compensable methods on the Omega side? I think this is a typical long
> transaction scene.
> >
Re: [VOTE] Drop the support of Spring Boot 1.x for ServiceComb-Pack
+1 Willem Jiang 于2019年7月29日周一 下午5:41写道： > Hi Team, > > As we discussed in the this thread[1]. I propose that we drop the > Spring Boot 1.x support both Alpha and Omega side to save some > development resources. > > This voting ends 72 hours from today. > > [1] > https://lists.apache.org/thread.html/545f554a6ebd3ff195c9038c65418f02b5b7b439b179cd10d390e7ba@%3Cdev.servicecomb.apache.org%3E > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [DISCUSSION] Async support for Saga
So the grpc could support the async invoking ? Willem Jiang 于2019年7月24日周三 下午2:31写道： > Hi Daniel, > > If you take a look at the Omega side, the CompensationMessageHandler > is called in onNext() method of GrpcCompensateStreamObserver. > If there is something wrong with CompensationMessageHandler > onReceive() method, the Stream could be broken and Alpha can now about > it immediately. (You can write a simple test case to verify it). > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Jul 24, 2019 at 12:27 PM Daniel Qian > wrote: > > > > Thanks for sharing your thoughts, Willem. But I didn't really get your > > point. > > > > I read the code and found that compensation action works like this: > > > > 1. Alpha GrpcOmegaCallback send GrpcCompensateCommand to Omega > > 2. Omega CompensationMessageHandler handle the command, execute > > compensation logic and send TxCompensatedEvent to Alpha > > > > In this progress, Alpha doesn't wait for compensation success message > > after sending compensation command, it just returns. So the progress is > > already async. > > > > If what I said above is correct, please read the following, if not, > please > > correct me. > > > > As to the current implementation, it's possible that compensation command > > is sent but no compensation success message received. I think what you > > said is Alpha should have a mechanism to handle compensation timeout, > > retry or just log it. But I think this an improvement should be done on > the > > Alpha side. Am I right? > > > > In my opinion, to support async compensation, the only thing need to do > is > > providing a way to let user code send TxCompensatedEvent. Sure I don't > mean > > that we should expose the underly communication, > > GrpcSagaClientMessageSender > > for example, to user code. Providing a encapsulated interface will be > > better, > > just like what I mentioned before. > > > > Zheng Feng 于2019年7月23日周二 下午2:10写道： > > > > > > OK, I understand and with my prev experiences with the JTA and XA, it > > looks > > > similar with the XA.recovery() to get the in-doubt transactions. So the > > > omega side or the application have to keep the records of the pending > > > transactions, is it right ? > > > > > > Willem Jiang 于2019年7月22日周一 下午11:51写道： > > > > > > > Yes, We can kick off the recovery process or status verify process in > > > > Alpha if the distribute transaction is in suspend status, but in > this > > > > case we need Alpha talk to customer Application to tell if we need to > > > > do the recovery again or just do some auditing there. It depends on > > > > the customer's configuration. > > > > > > > > Willem Jiang > > > > > > > > Twitter: willemjiang > > > > Weibo: 姜宁willem > > > > > > > > On Mon, Jul 22, 2019 at 11:38 PM Zheng Feng > wrote: > > > > > > > > > > Hi Willem, > > > > > > > > > > In the term of providing some further processing extension, you > mean > > that > > > > > the customer could help the state machine to recovery from the > > suspension > > > > > states ? > > > > > > > > > > Willem Jiang 于2019年7月22日周一 下午11:28写道： > > > > > > > > > > > If we provide the async compensation call, we need to do lots of > > thing > > > > > > on Alpha and Omega side. My suggestion we just use provide sync > way > > to > > > > > > get the feedback of compensation immediately to keep the design > > > > > > simpler. > > > > > > > > > > > > As we are reimplementing the Alpha with state machine, there are > > some > > > > > > suspension state which could be caused by the timeout or the > missing > > > > > > event message. > > > > > > I had a long talk with ZhangLei, we are agree that we could leave > > the > > > > > > status check or recovery to the customer by providing some > further > > > > > > processing extension, as there are too many detail things in > > customer > > > > > > code to think about. > > > > > > > > > > > > Anyway, it's my pleasure to have this kind of discussion with the > > > > > > team, it's the beauty of Open Source project development, we are > &
Re: [DISCUSSION] Async support for Saga
OK, I understand and with my prev experiences with the JTA and XA, it looks
similar with the XA.recovery() to get the in-doubt transactions. So the
omega side or the application have to keep the records of the pending
transactions, is it right ?
Willem Jiang 于2019年7月22日周一 下午11:51写道：
> Yes, We can kick off the recovery process or status verify process in
> Alpha if the distribute transaction is in suspend status, but in this
> case we need Alpha talk to customer Application to tell if we need to
> do the recovery again or just do some auditing there. It depends on
> the customer's configuration.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jul 22, 2019 at 11:38 PM Zheng Feng wrote:
> >
> > Hi Willem,
> >
> > In the term of providing some further processing extension, you mean that
> > the customer could help the state machine to recovery from the suspension
> > states ?
> >
> > Willem Jiang 于2019年7月22日周一 下午11:28写道：
> >
> > > If we provide the async compensation call, we need to do lots of thing
> > > on Alpha and Omega side. My suggestion we just use provide sync way to
> > > get the feedback of compensation immediately to keep the design
> > > simpler.
> > >
> > > As we are reimplementing the Alpha with state machine, there are some
> > > suspension state which could be caused by the timeout or the missing
> > > event message.
> > > I had a long talk with ZhangLei, we are agree that we could leave the
> > > status check or recovery to the customer by providing some further
> > > processing extension, as there are too many detail things in customer
> > > code to think about.
> > >
> > > Anyway, it's my pleasure to have this kind of discussion with the
> > > team, it's the beauty of Open Source project development, we are
> > > tackling the interesting problem by working together from different
> > > company :)
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Mon, Jul 22, 2019 at 5:14 PM Zheng Feng wrote:
> > > >
> > > > In term of the compensation method, I think I had discussed with
> Willem
> > > > before that it could introduce the @Status annotation for the alpha
> > > server
> > > > to query the compensation status. When the compensation method is
> async
> > > > which means it can not response immediately, it would return the
> > > > COMPENSATING result and the alpha server could query the @Status
> method
> > > to
> > > > check the compensation status, if this method returns COMPENSATE_OK,
> the
> > > > alpha server will mark the local transaction is compensated otherwise
> > > will
> > > > mark it with compensate_failed.
> > > >
> > > > Daniel Qian 于2019年7月21日周日 下午8:37写道：
> > > >
> > > > > I rethink the idea I proposed, yes, provide low level apis is a bad
> > > idea,
> > > > > and I also don't suggest that let user code use omega-xxx-transport
> > > api.
> > > > >
> > > > > I think the essential issues are three:
> > > > >
> > > > >1. How to pass tx context info across threads
> > > > >2. How to asynchronously tell Alpha that Saga is ended or
> aborted,
> > > which
> > > > >means not triggered on @SagaStart method returns.
> > > > >3. How to asynchronously tell Alpha that LocalTx is ended or
> > > aborted,
> > > > >which means not triggered on @Compensable method returns.
> > > > >
> > > > > I think we can keep using @SagaStart @Compensable for the
> > > XXXStartedEvent,
> > > > > and provide a helper to manually end/abort Saga/LocalTx. Thanks
> for PR
> > > #506
> > > > > (SCB-1385) we can use TransactionContext to achieve that. Below is
> a
> > > code
> > > > > sample:
> > > > >
> > > > >
> > > > > @SagaStart(async=true)
> > > > > public void foo() {
> > > > >TransactionContext txContext =
> OmegaContext.getTransactionContext();
> > > > >someAsyncCall()
> > > > > .onSuccess(Callback() {
> > > > > omega.endSaga(txContext);
> > > > > })
> > > > > .onException(Callback() {
> > > > > omega.abortSaga(txContext);
> > >
Re: [DISCUSSION] Async support for Saga
Hi Willem,
In the term of providing some further processing extension, you mean that
the customer could help the state machine to recovery from the suspension
states ?
Willem Jiang 于2019年7月22日周一 下午11:28写道：
> If we provide the async compensation call, we need to do lots of thing
> on Alpha and Omega side. My suggestion we just use provide sync way to
> get the feedback of compensation immediately to keep the design
> simpler.
>
> As we are reimplementing the Alpha with state machine, there are some
> suspension state which could be caused by the timeout or the missing
> event message.
> I had a long talk with ZhangLei, we are agree that we could leave the
> status check or recovery to the customer by providing some further
> processing extension, as there are too many detail things in customer
> code to think about.
>
> Anyway, it's my pleasure to have this kind of discussion with the
> team, it's the beauty of Open Source project development, we are
> tackling the interesting problem by working together from different
> company :)
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Mon, Jul 22, 2019 at 5:14 PM Zheng Feng wrote:
> >
> > In term of the compensation method, I think I had discussed with Willem
> > before that it could introduce the @Status annotation for the alpha
> server
> > to query the compensation status. When the compensation method is async
> > which means it can not response immediately, it would return the
> > COMPENSATING result and the alpha server could query the @Status method
> to
> > check the compensation status, if this method returns COMPENSATE_OK, the
> > alpha server will mark the local transaction is compensated otherwise
> will
> > mark it with compensate_failed.
> >
> > Daniel Qian 于2019年7月21日周日 下午8:37写道：
> >
> > > I rethink the idea I proposed, yes, provide low level apis is a bad
> idea,
> > > and I also don't suggest that let user code use omega-xxx-transport
> api.
> > >
> > > I think the essential issues are three:
> > >
> > >1. How to pass tx context info across threads
> > >2. How to asynchronously tell Alpha that Saga is ended or aborted,
> which
> > >means not triggered on @SagaStart method returns.
> > >3. How to asynchronously tell Alpha that LocalTx is ended or
> aborted,
> > >which means not triggered on @Compensable method returns.
> > >
> > > I think we can keep using @SagaStart @Compensable for the
> XXXStartedEvent,
> > > and provide a helper to manually end/abort Saga/LocalTx. Thanks for PR
> #506
> > > (SCB-1385) we can use TransactionContext to achieve that. Below is a
> code
> > > sample:
> > >
> > >
> > > @SagaStart(async=true)
> > > public void foo() {
> > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > >someAsyncCall()
> > > .onSuccess(Callback() {
> > > omega.endSaga(txContext);
> > > })
> > > .onException(Callback() {
> > > omega.abortSaga(txContext);
> > > })
> > > }
> > >
> > > @Compensable(async=true, compensationMethod="rollbackBar")
> > > public void bar() {
> > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > >someAsyncCall()
> > > .onSuccess(Callback() {
> > > omega.endTx(txContext);
> > > })
> > > .onException(Callback() {
> > > omega.abortTx(txContext);
> > > })
> > > }
> > >
> > > The async attribute on @SagaStart and @Compensable prevents
> Saga/LocalTx
> > > ended when method returns.
> > > TransactionContext object can be passed around safely because it's
> > > immutable.
> > > What I have not considered clearly is that how to deal with
> compensation
> > > method if it's also async.
> > >
> > >
> > > Willem Jiang 于2019年7月20日周六 下午10:30写道：
> > > >
> > > > Yeah, I agree we need provide some low level API for the user to
> pass.
> > > > In the recent change of SCB-1386, I introduce the TransactionContext
> > > > object which holds the reference of GID and LID, we may add some
> other
> > > > transaction context information there too.
> > > > If the sub transaction is happened in other JVM, we need to pass the
> > > > TxContext across the JVM with help of omega-xxx-transport.
> > > >
> > > > We already have
Re: [DISCUSSION] Async support for Saga
I think in current implementation of the alpha server, the compensate
invoking is sync and does not pass the transaction context. The other
question is the omega variable should be associated to a thread, I am not
very sure that your proposal could be fine in the multi threads environment.
Daniel Qian 于2019年7月22日周一 下午10:34写道：
> Thanks for the suggestion, Feng.
>
> Did you mean Alpha check if the compensation method finished by
> periodically query @Status method?
>
> If I'm not misunderstanding the code, Alpha doesn't wait for the
> TxCompensatedEvent after
> CompensateCommand sent. That means, the
> CompensateCommand-TxCompensatedEvent
> communication is already async in nature.
>
> So we can take advantage of this async nature and no need to add more event
> types and statuses.
> I think we can add an attribute to indicate compensation method is async on
> @Compensable like this:
>
> @Compensale(compensationMethod="rollbackBar", compensationAsync=true)
> public void bar(arg1, arg2, arg3) {
>// ...
> }
>
> public void rollbackBar(arg1, arg2, arg3, TransactionContextWithParent
> localTx) {
> rollbackAsync()
> .onsuccess(() -> {
>omega.txCompensated(localTx);
> })
> }
>
> Zheng Feng 于2019年7月22日周一 下午5:14写道：
>
> > In term of the compensation method, I think I had discussed with Willem
> > before that it could introduce the @Status annotation for the alpha
> server
> > to query the compensation status. When the compensation method is async
> > which means it can not response immediately, it would return the
> > COMPENSATING result and the alpha server could query the @Status method
> to
> > check the compensation status, if this method returns COMPENSATE_OK, the
> > alpha server will mark the local transaction is compensated otherwise
> will
> > mark it with compensate_failed.
> >
> > Daniel Qian 于2019年7月21日周日 下午8:37写道：
> >
> > > I rethink the idea I proposed, yes, provide low level apis is a bad
> idea,
> > > and I also don't suggest that let user code use omega-xxx-transport
> api.
> > >
> > > I think the essential issues are three:
> > >
> > >1. How to pass tx context info across threads
> > >2. How to asynchronously tell Alpha that Saga is ended or aborted,
> > which
> > >means not triggered on @SagaStart method returns.
> > >3. How to asynchronously tell Alpha that LocalTx is ended or
> aborted,
> > >which means not triggered on @Compensable method returns.
> > >
> > > I think we can keep using @SagaStart @Compensable for the
> > XXXStartedEvent,
> > > and provide a helper to manually end/abort Saga/LocalTx. Thanks for PR
> > #506
> > > (SCB-1385) we can use TransactionContext to achieve that. Below is a
> code
> > > sample:
> > >
> > >
> > > @SagaStart(async=true)
> > > public void foo() {
> > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > >someAsyncCall()
> > > .onSuccess(Callback() {
> > > omega.endSaga(txContext);
> > > })
> > > .onException(Callback() {
> > > omega.abortSaga(txContext);
> > > })
> > > }
> > >
> > > @Compensable(async=true, compensationMethod="rollbackBar")
> > > public void bar() {
> > >TransactionContext txContext = OmegaContext.getTransactionContext();
> > >someAsyncCall()
> > > .onSuccess(Callback() {
> > > omega.endTx(txContext);
> > > })
> > > .onException(Callback() {
> > > omega.abortTx(txContext);
> > > })
> > > }
> > >
> > > The async attribute on @SagaStart and @Compensable prevents
> Saga/LocalTx
> > > ended when method returns.
> > > TransactionContext object can be passed around safely because it's
> > > immutable.
> > > What I have not considered clearly is that how to deal with
> compensation
> > > method if it's also async.
> > >
> > >
> > > Willem Jiang 于2019年7月20日周六 下午10:30写道：
> > > >
> > > > Yeah, I agree we need provide some low level API for the user to
> pass.
> > > > In the recent change of SCB-1386, I introduce the TransactionContext
> > > > object which holds the reference of GID and LID, we may add some
> other
> > > > transaction context information there too.
> > > > If the sub transaction is happened in other JVM, we need to pass the
> > &g
Re: [PROPOSAL] create e-commerce project as a ServiceComb sample project for user guiding purpose.
I agree with Willem that the example should be simple enough for the first using the ServiceComb. Willem Jiang 于2019年7月22日周一 上午11:17写道： > I think we need to focus on how to use ServiceComb instead of write > another application which only has few audience. > My suggestion is we just break down the requirements and show user > how to do authentication with ServiceComb java-chassis, how to server > the front-end pages with ServiceComb java-chassis, how to interact > with edge service. The example should be simple enough which could be > the start point for user who is first use ServiceComb. > > BTW, ZhengYangYong already write a tutorial[1] about how to use > ServiceComb last year, you may need to consider to build something on > top of that. > > [1]https://github.com/zhengyangyong/scaffold > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, Jul 22, 2019 at 10:57 AM Bin Ma wrote: > > > > It sounds a good idea : ) > > > > Can you briefly show us the design how to use ServiceComb to build > > an e-commerce? thks > > > > > > Best Wishes & Regards > > --- > > Mabin > > > > > > > > 郑志鹏 于2019年7月22日周一 上午10:26写道： > > > > > Thanks for you suggestions. I will make sure the is licensed under > Apache > > > License and the libraries it uses is compatible. And I will make the > > > document as detailed as possible. > > > > > > Liubao (A) 于2019年7月20日周六 下午10:55写道： > > > > > > > Any samples to use ServiceComb is preferred. I have some questions > before > > > > you contribute the code: > > > > > > > >* Make sure the project is licensed under Apache License and the > > > > libraries it uses is compatible. > > > >* Samples are intended to help users how to program. I'd prefer > the > > > > e-commerce project have some documents to describe the project and > the > > > > techniches and best proctics. > > > > > > > > -邮件原件- > > > > 发件人: 郑志鹏 [mailto:aleczhen...@gmail.com] > > > > 发送时间: 2019年7月19日 17:01 > > > > 收件人: dev@servicecomb.apache.org > > > > 主题: [PROPOSAL] create e-commerce project as a ServiceComb sample > project > > > > for user guiding purpose. > > > > > > > > Hi, All > > > > > > > > Recently, I communicated with some ServiceComb new users, they want > an > > > > e-commerce system ServiceComb sample project with real business > > > background. > > > > They think with this demo they can learn ServiceComb’s abilities and > > > > usages *more efficiently*. > > > > > > > > Then I found this project > https://github.com/apache/servicecomb-samples. > > > > So I want to develop an e-commerce system demo and *devote* it to > this > > > > project as this project’s sub-project. > > > > -- > > > > The business background of my planing project: > > > > > > > > Traditionally, a real estate developer in china will show their > nearing > > > > completion buildings to the customers for a couple of days, then > > > determine > > > > an open sale time for all customers to make real deal offline. Those > > > > customers have to get to sale place long before the open sale time > and > > > > queue up,because only in this way they get the chances to pick the > > > > apartment which they like mostly. So recently, more and more real > estate > > > > developers begin to build an online apartments/houses open sale > system. > > > The > > > > e-commerce system help their customer to pick the houses more easily > and > > > > more fairly. This is the system which I plan to build with > ServiceComb. > > > > Why I choose this project as a guiding sample of ServiceComb? > > > > > > > > Real estate developers use this system to make a deal with their > customer > > > > online. So, yes! This is a real e-commerce system with real > commercial > > > > value. But this is also a real simple e-commerce system which has no > > > > payment and shipping module. So Its simplicity is good for the > guiding > > > > purpose. Meanwhile, because these trading subjects of this system are > > > very > > > > expensive，and there will be high QPS when the open sale time just > > > arrives. > > > > So There are high requirements for the system’s scalability, > availability > > > > and robustness.It’s an applicable project to show ServiceComb’s > > > abilities. > > > > Any questions and suggestions? > > > > > > > > -- > > > > Best Wishes & Regards > > > > ——— > > > > Alec Zheng > > > > > > > > > > > > > -- > > > Best Wishes & Regards > > > ——— > > > Alec Zheng > > > >
Re: [DISCUSSION] Async support for Saga
In term of the compensation method, I think I had discussed with Willem
before that it could introduce the @Status annotation for the alpha server
to query the compensation status. When the compensation method is async
which means it can not response immediately, it would return the
COMPENSATING result and the alpha server could query the @Status method to
check the compensation status, if this method returns COMPENSATE_OK, the
alpha server will mark the local transaction is compensated otherwise will
mark it with compensate_failed.
Daniel Qian 于2019年7月21日周日 下午8:37写道：
> I rethink the idea I proposed, yes, provide low level apis is a bad idea,
> and I also don't suggest that let user code use omega-xxx-transport api.
>
> I think the essential issues are three:
>
>1. How to pass tx context info across threads
>2. How to asynchronously tell Alpha that Saga is ended or aborted, which
>means not triggered on @SagaStart method returns.
>3. How to asynchronously tell Alpha that LocalTx is ended or aborted,
>which means not triggered on @Compensable method returns.
>
> I think we can keep using @SagaStart @Compensable for the XXXStartedEvent,
> and provide a helper to manually end/abort Saga/LocalTx. Thanks for PR #506
> (SCB-1385) we can use TransactionContext to achieve that. Below is a code
> sample:
>
>
> @SagaStart(async=true)
> public void foo() {
>TransactionContext txContext = OmegaContext.getTransactionContext();
>someAsyncCall()
> .onSuccess(Callback() {
> omega.endSaga(txContext);
> })
> .onException(Callback() {
> omega.abortSaga(txContext);
> })
> }
>
> @Compensable(async=true, compensationMethod="rollbackBar")
> public void bar() {
>TransactionContext txContext = OmegaContext.getTransactionContext();
>someAsyncCall()
> .onSuccess(Callback() {
> omega.endTx(txContext);
> })
> .onException(Callback() {
> omega.abortTx(txContext);
> })
> }
>
> The async attribute on @SagaStart and @Compensable prevents Saga/LocalTx
> ended when method returns.
> TransactionContext object can be passed around safely because it's
> immutable.
> What I have not considered clearly is that how to deal with compensation
> method if it's also async.
>
>
> Willem Jiang 于2019年7月20日周六 下午10:30写道：
> >
> > Yeah, I agree we need provide some low level API for the user to pass.
> > In the recent change of SCB-1386, I introduce the TransactionContext
> > object which holds the reference of GID and LID, we may add some other
> > transaction context information there too.
> > If the sub transaction is happened in other JVM, we need to pass the
> > TxContext across the JVM with help of omega-xxx-transport.
> >
> > We already have some internal API to send the message from Omega to
> > Alpha, I prefer to use annotation instead of expose low level API to
> > the user.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Sat, Jul 20, 2019 at 9:50 PM Daniel Qian
> wrote:
> > >
> > > After look into SCB-163, SCB-1385 and SCB-1386 I have some thoughts on
> Saga
> > > involved in async invocation.
> > > Current implementation is basically based on sync invocation, there are
> > > some assumption:
> > >
> > >1. When @SagaStart method returns, the Saga finished.
> > >2. When @Compensable method returns/throws exception, the Local Tx
> > >succeeds/failed.
> > >3. When compensationMethod returns, the Local Tx is compensated.
> > >
> > > Even if considering what SCB-100 provided:
> > >
> > >1. Add @OmegaContextAware annotation enabling
> > >java.util.concurrent.Executor inject OmegaConext into threads it
> > >manages/spawns
> > >2. Make OmegaContext use InheritableThreadLocal field let child
> thread
> > >inherit parent thread's Local Tx info
> > >
> > > There are still some limitations:
> > >
> > >1. @OmegaContextAware is only viable if you use spring framework
> > >2. @OmegaContextAware and OmegaContext's InheritableThreadLocal
> field
> > >assuming that the calling thread or initator thread has Local Tx
> info.
> > >
> > >
> > > What if user code use producer-consumer pattern in which
> > > InheritableThreadLocal can't work?
> > > What if user code use a thread scheduling library which we cannot use
> > > @OmegaContextAware,RxJava and Reactor, for example?
> > > I think we could provide some low-level APIs that user code can manualy
> > > starts/ends Saga and Local Tx, something like below:
> > >
> > > TxContext context = omega.startSaga();
> > > TxContext subTxContext = omega.startTx(TxContext parentTxContext);
> > > omega.endTx(TxContext);
> > > omega.abortTx(TxContext);
> > > omega.abortSaga(TxContext);
> > > omega.endSaga(TxContext);
> > >
> > > TxContext is just a immutable dto like this:
> > >
> > > public class TxContext {
> > > private final String globalTxId;
> > > private final String localTxId;
> > > }
> > >
> > > Above is a just a rough idea.
Re: [DISCUSSION] Alpha Saga transactional data persistence to ElasticSearch
+1 and which version of the ElasticSearch should we use ? Willem Jiang 于2019年7月17日周三 上午10:49写道： > big +1 on it. > > I think we need to let the user know about this change, as this state > machine part is in experimental status, I'm proposing that we list > the features which we want do in this release cycle at the end of this > August to make sure we can provide a basic runnable Saga coordinator > on top of state machine solution. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Jul 17, 2019 at 10:26 AM Zhang Lei wrote: > > > > Hi, all > > > > After reimplementing Saga with a state machine, we no longer need to > perform complex table scans, so we can use ElasticSearch to persist > transaction data. And use the ElasticSearch RESTful API to provide external > query capabilities for terminating transactions. > > > > 1. Improve the performance of Alpha data persistence > > 2. This will reduce the performance impact of the query on Alpha > > 3. Users extend their monitoring capabilities based on ElasticSearch > rich RESTful API > > > > Lei Zhang >
Re: About alpha-fsm progress
ust cared about the recovery scan thread design. > >>>>>> Kafka can ensure event message can be consumed by alpha exactly, > but recovery need know all the participated transaction response to decide > rollback or commit, so I think scan thread is also necessary. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Jun 23, 2019, at 1:04 PM, Zhang Lei > wrote: > >>>>>>> > >>>>>>> Hi, Zhao Jun > >>>>>>> > >>>>>>> Thank you for your reply！ > >>>>>>> > >>>>>>> This design document does not elaborate on reliability aspects. > >>>>>>> > >>>>>>> My initial thought is this > >>>>>>> > >>>>>>> Q1 : It seems that omega should hold on after consuming the event > message from Kafka instead of completing pushing message > >>>>>>> A2 : I think we only need to ensure that the message can be > reliably delivered to the state machine, The state machine is only a > synchronous record state transition when the transaction is executed > normally. At present, the compensation method based on table scan is also > asynchronous. I am not sure if I have answered your question, or you can > give me more information. > >>>>>>> > >>>>>>> Q2 : Also we should consider about recovery, it seems that > recovery is as same as before based on database. > >>>>>>> A2 : I think the question you care about is how to recover when > the alpha is down, this is a little different from the current version. > >>>>>>> 1. We can base on Kafka's reliability and control the offset of > the topic, one message at a time > >>>>>>> 2. Of course, we can also do some extra design for it, such as > logging the data log file locally after receiving the Kafka message. Resume > the message by reading the data log file when the alpha machine restarts > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Lei Zhang > >>>>>>> > >>>>>>>> 在 2019年6月23日，上午7:08，zhaojun 写道： > >>>>>>>> > >>>>>>>> I have some questions about the design. > >>>>>>>> 1. It seems that omega should hold on after consuming the event > message from Kafka instead of completing pushing message. > >>>>>>>> 2. Also we should consider about recovery, it seems that recovery > is as same as before based on database. > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Zhao Jun > >>>>>>>> Apache Sharding-Sphere & ServiceComb > >>>>>>>> > >>>>>>>>> On Jun 21, 2019, at 6:41 PM, Zhang Lei > wrote: > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I have created the alpha-fsm module on branch SCB-1321 and > submitted the design documentation, state machine prototype and test cases. > >>>>>>>>> If there is any problem, please let me know. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Lei Zhang > >>>>>>>>> > >>>>>>>>> [1] > https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm < > https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm> > >>>>>>>>> > >>>>>>>>>> 在 2019年6月20日，下午3:25，Zheng Feng 写道： > >>>>>>>>>> > >>>>>>>>>> Yeah, I think Willem has create one [1] before and do you mind > I assign > >>>>>>>>>> this issue to you ? > >>>>>>>>>> > >>>>>>>>>> [1] https://issues.apache.org/jira/browse/SCB-1258 > >>>>>>>>>> > >>>>>>>>>> Zhang Lei 于2019年6月20日周四 下午2:34写道： > >>>>>>>>>> > >>>>>>>>>>> Hi, Zheng Feng > >>>>>>>>>>> > >>>>>>>>>>> Thanks for your advice, I will create a JIRA first and start > with the > >>>>>>>>>>> design documentation. > >>>>>>>>>>> > >>>>>>>>>>> Lei Zhang > >>>>>>>>>>> > >>>>>>>>>>>> 在 2019年6月19日，下午8:09，Zheng Feng 写道： > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks a lot for sharing these information ! I think this > state machine > >>>>>>>>>>>> could be very experimental so it would helpful to create an > experimental > >>>>>>>>>>>> branch to add this module but not in the master branch. > >>>>>>>>>>>> > >>>>>>>>>>>> Zhang Lei 于2019年6月19日周三 下午5:42写道： > >>>>>>>>>>>> > >>>>>>>>>>>>> I have completed some of the design and prototype in my > github. > >>>>>>>>>>>>> > >>>>>>>>>>>>> In the design document [1] my original idea was that a > transaction > >>>>>>>>>>>>> consisted of a SagaActor and several TxActors, and later > TxAcotr was > >>>>>>>>>>>>> removed to reduce implementation complexity. > >>>>>>>>>>>>> I haven't had time to modify the documentation yet, but the > SagaActor > >>>>>>>>>>>>> state machine [2] is up to date. > >>>>>>>>>>>>> Here you can see the test cases of SagaActor [3] > >>>>>>>>>>>>> > >>>>>>>>>>>>> [1] > >>>>>>>>>>>>> > >>>>>>>>>>> > https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm > >>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm > >>>>>>>>>>>>>> > >>>>>>>>>>>>> [2] > >>>>>>>>>>>>> > >>>>>>>>>>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png > >>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png > >>>>>>>>>>>>>> > >>>>>>>>>>>>> [3] > >>>>>>>>>>>>> > >>>>>>>>>>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java > >>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Lei Zhang > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> 在 2019年6月19日，下午2:34，zhaojun 写道： > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> If we use AKKA, how can we design the actors, and how can > we guarantee > >>>>>>>>>>>>> omega will receive the message synchronize. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>>> > >>> > >> > >
Re: About alpha-fsm progress
;> > >>>> This design document does not elaborate on reliability aspects. > >>>> > >>>> My initial thought is this > >>>> > >>>> Q1 : It seems that omega should hold on after consuming the event > message from Kafka instead of completing pushing message > >>>> A2 : I think we only need to ensure that the message can be reliably > delivered to the state machine, The state machine is only a synchronous > record state transition when the transaction is executed normally. At > present, the compensation method based on table scan is also asynchronous. > I am not sure if I have answered your question, or you can give me more > information. > >>>> > >>>> Q2 : Also we should consider about recovery, it seems that recovery > is as same as before based on database. > >>>> A2 : I think the question you care about is how to recover when the > alpha is down, this is a little different from the current version. > >>>> 1. We can base on Kafka's reliability and control the offset of the > topic, one message at a time > >>>> 2. Of course, we can also do some extra design for it, such as > logging the data log file locally after receiving the Kafka message. Resume > the message by reading the data log file when the alpha machine restarts > >>>> > >>>> > >>>> Thanks, > >>>> Lei Zhang > >>>> > >>>>> 在 2019年6月23日，上午7:08，zhaojun 写道： > >>>>> > >>>>> I have some questions about the design. > >>>>> 1. It seems that omega should hold on after consuming the event > message from Kafka instead of completing pushing message. > >>>>> 2. Also we should consider about recovery, it seems that recovery is > as same as before based on database. > >>>>> > >>>>> ------ > >>>>> Zhao Jun > >>>>> Apache Sharding-Sphere & ServiceComb > >>>>> > >>>>>> On Jun 21, 2019, at 6:41 PM, Zhang Lei > wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I have created the alpha-fsm module on branch SCB-1321 and > submitted the design documentation, state machine prototype and test cases. > >>>>>> If there is any problem, please let me know. > >>>>>> > >>>>>> Thanks, > >>>>>> Lei Zhang > >>>>>> > >>>>>> [1] > https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm < > https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm> > >>>>>> > >>>>>>> 在 2019年6月20日，下午3:25，Zheng Feng 写道： > >>>>>>> > >>>>>>> Yeah, I think Willem has create one [1] before and do you mind I > assign > >>>>>>> this issue to you ? > >>>>>>> > >>>>>>> [1] https://issues.apache.org/jira/browse/SCB-1258 > >>>>>>> > >>>>>>> Zhang Lei 于2019年6月20日周四 下午2:34写道： > >>>>>>> > >>>>>>>> Hi, Zheng Feng > >>>>>>>> > >>>>>>>> Thanks for your advice, I will create a JIRA first and start with > the > >>>>>>>> design documentation. > >>>>>>>> > >>>>>>>> Lei Zhang > >>>>>>>> > >>>>>>>>> 在 2019年6月19日，下午8:09，Zheng Feng 写道： > >>>>>>>>> > >>>>>>>>> Thanks a lot for sharing these information ! I think this state > machine > >>>>>>>>> could be very experimental so it would helpful to create an > experimental > >>>>>>>>> branch to add this module but not in the master branch. > >>>>>>>>> > >>>>>>>>> Zhang Lei 于2019年6月19日周三 下午5:42写道： > >>>>>>>>> > >>>>>>>>>> I have completed some of the design and prototype in my github. > >>>>>>>>>> > >>>>>>>>>> In the design document [1] my original idea was that a > transaction > >>>>>>>>>> consisted of a SagaActor and several TxActors, and later > TxAcotr was > >>>>>>>>>> removed to reduce implementation complexity. > >>>>>>>>>> I haven't had time to modify the documentation yet, but the > SagaActor > >>>>>>>>>> state machine [2] is up to date. > >>>>>>>>>> Here you can see the test cases of SagaActor [3] > >>>>>>>>>> > >>>>>>>>>> [1] > >>>>>>>>>> > >>>>>>>> > https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm > >>>>>>>>>> < > >>>>>>>>>> > >>>>>>>> > https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm > >>>>>>>>>>> > >>>>>>>>>> [2] > >>>>>>>>>> > >>>>>>>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png > >>>>>>>>>> < > >>>>>>>>>> > >>>>>>>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png > >>>>>>>>>>> > >>>>>>>>>> [3] > >>>>>>>>>> > >>>>>>>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java > >>>>>>>>>> < > >>>>>>>>>> > >>>>>>>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Lei Zhang > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> 在 2019年6月19日，下午2:34，zhaojun 写道： > >>>>>>>>>>> > >>>>>>>>>>> If we use AKKA, how can we design the actors, and how can we > guarantee > >>>>>>>>>> omega will receive the message synchronize. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>>> > >>> > >> > >
Re: [VOTE]Service mesh proposal
+1 binding Xiaoliang Tian 于2019年6月21日周五 下午4:41写道： > Hi All, >this is a call for vote to bring service mesh called "mesher" into > Apache Software Foundation (ASF) as ServiceComb's sub-project. > > > Voting will start now ( Wednesday, 5th June, 2019) and will > remain open for at-least 72 hours, Request all PMC members to > give their vote. > [ ] +1 Accept > [ ] +0 No Opinion > [ ] -1 Reject because... >
Re: [PROPOSAL] create an alpha-fsm moduleI for servicecomb pack
yeah, I just convert the SCB-1321 to the sub task of the SCB-1258. Willem Jiang 于2019年6月21日周五 上午8:10写道： > We could break down the SCB-1258 with state transfer design, > prototyping and implementation. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Jun 20, 2019 at 7:30 PM Zhang Lei wrote: > > > > Hi，Feng Zheng > > > > Oh!! I created another JIRA SCB-1321, I saw that you are already > associated with SCB-1258, Thank you for it. > > > > Lei Zhang > > > > > 在 2019年6月20日，下午3:25，Zheng Feng 写道： > > > > > > Yeah, I think Willem has create one [1] before and do you mind I assign > > > this issue to you ? > > >
Re: [PROPOSAL] create an alpha-fsm moduleI for servicecomb pack
Yeah, I think Willem has create one [1] before and do you mind I assign this issue to you ? [1] https://issues.apache.org/jira/browse/SCB-1258 Zhang Lei 于2019年6月20日周四 下午2:34写道： > Hi, Zheng Feng > > Thanks for your advice, I will create a JIRA first and start with the > design documentation. > > Lei Zhang > > > 在 2019年6月19日，下午8:09，Zheng Feng 写道： > > > > Thanks a lot for sharing these information ! I think this state machine > > could be very experimental so it would helpful to create an experimental > > branch to add this module but not in the master branch. > > > > Zhang Lei 于2019年6月19日周三 下午5:42写道： > > > >> I have completed some of the design and prototype in my github. > >> > >> In the design document [1] my original idea was that a transaction > >> consisted of a SagaActor and several TxActors, and later TxAcotr was > >> removed to reduce implementation complexity. > >> I haven't had time to modify the documentation yet, but the SagaActor > >> state machine [2] is up to date. > >> Here you can see the test cases of SagaActor [3] > >> > >> [1] > >> > https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm > >> < > >> > https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm > >>> > >> [2] > >> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png > >> < > >> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png > >>> > >> [3] > >> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java > >> < > >> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java > >>> > >> > >> Lei Zhang > >> > >> > >>> 在 2019年6月19日，下午2:34，zhaojun 写道： > >>> > >>> If we use AKKA, how can we design the actors, and how can we guarantee > >> omega will receive the message synchronize. > >> > >> > >
Re: [ANN] New ServiceComb committer:Tian XiaoLiang (田晓亮)
Welcome to the team ! Willem Jiang 于2019年6月20日周四 上午9:25写道： > Please join me and the rest of the ServiceComb PMC members in welcoming our > new ServiceComb committer: Tian Xiaoliang (田晓亮). > > Tian Xiaoliang has been with Apache ServiceComb for more than one > years by reviewing the code of servicecomb-service-center and > discussing techniques questions in the mailing list. Recently he is a > very active key developer of the new subproject serivcecomb-kie. > > Congratulations to Tian Xiaoliang! Welcome! > > The Apache ServiceComb PMC. >
Re: [PROPOSAL] create an alpha-fsm moduleI for servicecomb pack
Thanks a lot for sharing these information ! I think this state machine could be very experimental so it would helpful to create an experimental branch to add this module but not in the master branch. Zhang Lei 于2019年6月19日周三 下午5:42写道： > I have completed some of the design and prototype in my github. > > In the design document [1] my original idea was that a transaction > consisted of a SagaActor and several TxActors, and later TxAcotr was > removed to reduce implementation complexity. > I haven't had time to modify the documentation yet, but the SagaActor > state machine [2] is up to date. > Here you can see the test cases of SagaActor [3] > > [1] > https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm > < > https://github.com/coolbeevip/playground/tree/master/state_machine_demo/saga-akkafsm > > > [2] > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png > < > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/assets/saga_state_diagram.png > > > [3] > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java > < > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/src/test/java/coolbeevip/playgroud/statemachine/saga/SagaActorTest.java > > > > Lei Zhang > > > > 在 2019年6月19日，下午2:34，zhaojun 写道： > > > > If we use AKKA, how can we design the actors, and how can we guarantee > omega will receive the message synchronize. > >
Re: [VOTE]Have a booth and Holding an Apache ServiceComb Meetup as a Co-located Event, in KubeCon & CloudNativeCon Summit China 2019
+1 binding Zen Lin 于2019年6月11日周二 上午9:53写道： > Hi All, > This is a call for Vote to have a Apache ServiceComb booth and hold an > Apache ServiceComb Meetup as a Co-located Event , in KubeCon & > CloudNativeCon Summit China 2019, as discussed in the proposal [1]. > > Voting will start now (Tuesday, 11th June, 2019) and will remain open for > at-least 72 hours, Request PMC members and contributors to give their vote. > > [ ] +1 Accept > [ ] +0 No Opinion > [ ] -1 Reject because... > > [1] > > http://mail-archives.apache.org/mod_mbox/servicecomb-dev/201906.mbox/%3CCAH9eK8QEtrgPF9jqwZO%2BKRk9gEMd_U2DYMe2wAgBC30gD-Sc%2Bg%40mail.gmail.com%3E > > > Best Regards, > --- > Zen Lin > zenlintechnofr...@gmail.com > Focused on Micro Service and Apache ServiceComb >
Re: [VOTE] Toolkit donation proposal
+1 binding Bin Ma 于2019年6月6日周四 下午6:57写道： > Hi All, > > This is a call for a Vote to bring Toolkit[1] codebase into the > Apache Software Foundation (ASF) as ServiceComb's sub-project. > > Reference: the mail thread link for the previous discussion[2]. > > Voting will start now ( Wednesday, 5th June, 2019) and will > remain open for at-least 72 hours, Request all PMC members to > give their vote. > > [ ] +1 Accept > [ ] +0 No Opinion > [ ] -1 Reject because... > > [1] https://github.com/MabinGo/toolkit > [2] > > https://lists.apache.org/thread.html/bba43e0116160dbdc7d1443c995a2b6fdc72f5e4e91f1e5208afc230@%3Cdev.servicecomb.apache.org%3E# > > > Best Wishes & Regards > --- > Mabin >
Re: Proposal for Holding an Apache ServiceComb Meetup as a Co-located Event in KubeCon & CloudNativeCon Summit China 2019
+1 for holding this meetup ! Zen Lin 于2019年6月10日周一 上午10:08写道： > This is a Proposal for holding a Co-Located Event in KubeCon & > CloudNativeCon Summit China 2019 to help building ServiceComb's community. > > My suggestion is to hold a Meetup named "Apache ServiceComb Meetup Hosted > by Huawei", to share technologies and user cases of ServiceComb. > Because the time is tight, I have already talked to Huawei to get free > resources and sposorship for the meetup. > > Details of the plan is listed below, > - What is the topic focus of the event? > Topics are focused on Apache Way related topics, user-practices > /technologies topics of Apache ServiceComb . > - Who is organising the event? > PMCs of ServiceComb (incubating) are the organizer > - When is the event? > June 24 > - How many attendees are expected? > 60~100 > - How much PMC involvement is there already? > 3 > - Which marks are requested? > Two marks are requested, > 1. Name of "Apache ServiceComb Meetup " > 2. "Powered By" Apache logo of Apache ServiceComb > - Is this for profit or non-profit? (See "Event Profits And Donations")? > non-profit. > > By the way, I also suggest to have a booth about Apache ServiceComb in > KubeCon & CloudNativeCon Summit China 2019. > > Now, I would like to get suggestions from you guys, If it is agreed , I am > going to create a vote for it. > > > Best Regards, > --- > Zen Lin > zenlintechnofr...@gmail.com > Focused on Micro Service and Apache ServiceComb >
Re: Announce of new ServiceComb PMC member
Congratulations ! Zheng Feng Willem Jiang 于2019年6月10日周一 上午10:54写道： > It is very rewarding to see that most of the contributors who became > committers continue to stay involved. Therefore, in recognition of > their continued contribution, the Apache ServiceComb PMC invited > recently a committer to join the PMC, be even more involved and take a > greater responsibility in shaping the future of the ServiceComb > project. > > Please join me to welcome Yao Haishi as new Apache ServiceComb PMC > member. Many thanks for your past contributions and we look forward to > the same commitment in the future. > > Willem Jiang > > On behalf of the ServiceComb PMC >
Re: [Saga] A little thought about Using StateMachine for tracing the transaction states
+1 for using the message broker. Willem Jiang 于2019年5月15日周三 上午10:04写道： > Sure，as the omega can tell if the service invocation is timeout, we > could simplify timeout handling on the Alpha side. > But there still long way to go, I will ping you this afternoon for > more discussion. > BTW, I'm thinking using the message broker to pass the invocation > event between Omega and Alpha > > Regards, > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, May 14, 2019 at 11:07 PM Zhang Lei wrote: > > > > Hi Willem > > > > Thanks for your kind words > > Can you give me some tips about other cases of timeout? Or indicate the > possible action number in the success scene timing diagram > > > > Thanks, > > Lei Zhang > > > > > 在 2019年5月14日，下午6:55，Willem Jiang 写道： > > > > > > If we want to tell the timeout issue, it still need to add more states. > > > But ZhangLei showed us a fantastical document for checking the states > > > of Saga use case. > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Tue, May 14, 2019 at 3:49 PM Zheng Feng wrote: > > >> > > >> Thanks Zhang Lei - it is really great work ! > > >> > > >> I think we could describe every event and state with more details, > e.g. > > >> SagaStartedEvent: it is the event to start a global transaction > > >> SagaEnededEvent: it is the event to close a global transaction > > >> SagaAbortedEvent: it is the event to abort a global transaction and > cause > > >> the sub-transactions to do the compensate > > >> SagaTimeoutEvent: it is the event to indicate the global transaction > is > > >> timeout and need the checking manually ? (I am not very if I > understand > > >> this event correctly) > > >> > > >> Also we could add the similar descriptions with the states. > > >> SUSPEND, COMMITTED, COMPENSATED are the three final states, right ? > > >> > > >> Thanks again ! > > >> Zheng Feng > > >> > > >> > > >> Zhang Lei 于2019年5月13日周一 下午11:50写道： > > >> > > >>> I wrote a preliminary design [1] based on wiki [2], , Maybe not > perfect or > > >>> something I don't know. > > >>> > > >>> Any suggestions? > > >>> > > >>> [1] > > >>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/README.md > > >>> < > > >>> > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/README.md > > >>>> > > >>> [2] > > >>> > https://cwiki.apache.org/confluence/display/SERVICECOMB/Using+StateMachine+for+tracing+the+transaction+states > > >>> < > > >>> > https://cwiki.apache.org/confluence/display/SERVICECOMB/Using+StateMachine+for+tracing+the+transaction+states > > >>>> > > >>> > > >>> Lei Zhang > > >
Re: [Saga] A little thought about Using StateMachine for tracing the transaction states
Thanks Zhang Lei - it is really great work ! I think we could describe every event and state with more details, e.g. SagaStartedEvent: it is the event to start a global transaction SagaEnededEvent: it is the event to close a global transaction SagaAbortedEvent: it is the event to abort a global transaction and cause the sub-transactions to do the compensate SagaTimeoutEvent: it is the event to indicate the global transaction is timeout and need the checking manually ? (I am not very if I understand this event correctly) Also we could add the similar descriptions with the states. SUSPEND, COMMITTED, COMPENSATED are the three final states, right ? Thanks again ! Zheng Feng Zhang Lei 于2019年5月13日周一 下午11:50写道： > I wrote a preliminary design [1] based on wiki [2], , Maybe not perfect or > something I don't know. > > Any suggestions? > > [1] > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/README.md > < > https://github.com/coolbeevip/playground/blob/master/state_machine_demo/saga-akkafsm/README.md > > > [2] > https://cwiki.apache.org/confluence/display/SERVICECOMB/Using+StateMachine+for+tracing+the+transaction+states > < > https://cwiki.apache.org/confluence/display/SERVICECOMB/Using+StateMachine+for+tracing+the+transaction+states > > > > Lei Zhang
Re: [saga-actuator]consider about adding StreamBasedSaga engine to integrate with shardingsphere
Hi Zhao Jun, It looks good to me and it could have the revert SQL in the compensate method automatically ? Regards, Zheng Feng zhaojun 于2019年4月26日周五 下午6:41写道： > Hi, all > > currently, we have integrated with saga using graph based engine in > shardingsphere[1] > it need us to collect all participated actual SQL, then submit to saga > actuator in commit/rollback phase. > if application crashed before invoking saga actuator, undo log of branch > transaction SQL will not be saved, > so recovery thread will not be executed correctly. > > it's better that encapsulating every actual SQL as a saga task in > shardingsphere side, > then submit to saga actuator realtime instead of batch processing all the > SQLs at commit/rollback phase. > this architecture will make the boundary more clear between shardingsphre > and saga, currently we have done some additional works for integrating saga. > > any thought? > > [1]: > https://github.com/sharding-sphere/shardingsphere-spi-impl/tree/master/sharding-transaction-spi-impl/sharding-transaction-base-spi-impl/sharding-transaction-base-saga > < > https://github.com/sharding-sphere/shardingsphere-spi-impl/tree/master/sharding-transaction-spi-impl/sharding-transaction-base-spi-impl/sharding-transaction-base-saga > > > > > > -- > Zhao Jun > Apache Sharding-Sphere & ServiceComb > >
Re: [Saga] About Omega's timeout process
Why does this happen I mean that Thread.interrupt causes the ThreadLocal variables lost the value ? It should be running in the same thread. Also it does not mention in the Java API docs [1]. I do agree that the compensate method could have this issue since it has been invoking in the different thread. But for the Zhang Lei's proposal for the timeout solution, I don't think this could happen or maybe I misunderstand something else. Regards, Zheng Feng [1] https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt() Willem Jiang 于2019年4月26日周五 下午6:41写道： > Yeah, that's exactly what want to say. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Apr 26, 2019 at 4:14 PM Zhang Lei wrote: > > > > Hi, Willem Jiang > > > > You mean that Thread.interrupt will cause the variables in the thread to > be lost, so we need to provide a way for the user to restore the thread > variables? > > > > Lei Zhang > > > > > 在 2019年4月26日，上午8:36，Willem Jiang 写道： > > > > > > We could introduce a Context object to let the user copy the thread > > > local variable across the thread. > > > The context can be inject into the method which is annotated with > > > Compasiable. We may need to inject the Context object into the remote > > > service caller. > > >
Re: [Saga] About Omega's timeout process
I'm not sure if the Thread.interrupt() could be working as you expect. From the Java doc [1] Unless the current thread is interrupting itself, which is always permitted, the checkAccess method of this thread is invoked, which may cause a SecurityException to be thrown. - If this thread is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(), join(long), join(long, int), sleep(long), or sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException. - If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException. - If this thread is blocked in a Selector then the thread's interrupt status will be set and it will return immediately from the selection operation, possibly with a non-zero value, just as if the selector's wakeup method were invoked. - If none of the previous conditions hold then this thread's interrupt status will be set. - Interrupting a thread that is not alive need not have any effect. So I think we have to catch the SecurityException when the thread is can not been interrupted. Also ClosedByInterruptException could be thrown if the thread is doing some I/O operations especially by the socket. Anyway, we could understand the interrupt() could be no effect in some cases, e.g. if the thread is busy with the CPU times, just while(true); I think we had similar timeout handling before but removed it at [2] and the SCB-239 [3]. I can recall that we store the timeout setting in the alpha side rather than the omega side just because the alpha can persistent into the back end database and could resume the compensate operations when recovery from the crash scenario or the omega side is failed. Thanks, Zheng Feng [1] https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt() [2] https://github.com/apache/servicecomb-pack/commit/46096fe2f0f0d3d03fb256ed2fd5f221c0b9e851 [3] https://issues.apache.org/jira/browse/SCB-239 Zhang Lei 于2019年4月24日周三 下午7:09写道： > At present, Omega's timeout only stores to the database, find timeout Tx > transactions and compensation through database scans. This may cause the > commit of the Tx transaction after the compensation. > I think it can be improved TransactionAspect class, Terminates the > execution of the method when the timeout and throws a custom exception > > So we can control the rollback of the transaction within the method when > timeout. I wrote an example to show my thoughts > https://github.com/coolbeevip/playground/tree/master/timeoutaspect-demo < > https://github.com/coolbeevip/playground/tree/master/timeoutaspect-demo> > > You can use ApplicationTest to quickly verify > > Any suggestion? > > > Lei Zhang
Re: Any Ideas for ServiceComb projects for GSOC 2019???
Hi all, I had one from the servicecomb-pack [1] which needs to implement the LRA spec. I think the student could learn 1. cooperate with the open source community. The LRA spec [2] is under the microprofile currently. 2. strong programming skill. The other question is we have to be the mentor to work with the student ? I'm not sure how much time it could spent on the GSOC project. Regards, Zheng Feng [1] https://issues.apache.org/jira/browse/SCB-1123 [2] https://github.com/eclipse/microprofile-lra/blob/master/spec/src/main/asciidoc/microprofile-lra-spec.adoc Mohammad Asif Siddiqui 于2019年4月3日周三 下午9:14写道： > Hello All, > > As we know that Apache is an approved organization for GSOC 2019 so > ServiceComb being an Apache project also has an opportunity to engage in > this program. > > Currently we have not listed any ideas for GSOC 2019 for ServiceComb so if > someone from Java-Chassis, Service-Center, Saga & Pack has any ideas which > university students can implement it that would be great to list the > ideas. > > Mostly we will have lot of ideas which can be good for project but because > of the time constraints we are not able to implement it, so I think it's a > good time to list those ideas and see if some university student is > interested in implementing it so that it will be good for them as well as > good for community. > > We have discuss all the ideas in this mail thread and if everyone agrees to > some particular ideas then we can raise a Jira for the same. > > Regards > Asif >
[DISCUSS] Require the review before merging the PR
Hi, I just wonder if we can enable this setting [1] on servicecomb-pack [2] and it could be helpful when reviewing the PR. I think at least one people review the changes and approve before merging it. We have to raise a JIRA for the infra team to do this setting. So I post this message here to see if the others have any thought. Regards, Zheng Feng [1] https://help.github.com/en/articles/enabling-required-reviews-for-pull-requests [2] https://github.com/apache/servicecomb-pack
Re: [VOTE] Release Apache ServiceComb Pack version 0.4.0 (RC-02)
+1 Release this package as 0.4.0 I checked * The release tag is OK * The release candidate can be download and the signature is OK * Building and running the tests of the source codes is OK * Release notes is OK Mohammad Asif Siddiqui 于2019年4月2日周二 上午6:23写道： > Hi All, > > This is a call for Vote to release Apache ServiceComb Pack version 0.4.0 > (RC-02) > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-pack/0.4.0/rc-02/ > > Staging Repository : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1380 > > Release Tag : > https://github.com/apache/servicecomb-pack/releases/tag/0.4.0 > > Release CommitID : c2b1a6d603b0fb3d658a495da29d6f864995b538 > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344102 > > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Tuesday, 2nd April, 2019) and will remain open for > at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 0.4.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > Mohammad Asif Siddiqui >
Re: [ANN] New ServiceComb committer: Zhang Lei (张磊）
I just think it was the April fools Day message :) Willem Jiang 于2019年4月1日周一 下午11:19写道： > Sorry, there is a typo in the first mail. The first sentence should be: > > Please join me and the rest of the ServiceComb PPMC members in welcoming > our > new ServiceComb committer: Zhang Lei (张磊). > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, Apr 1, 2019 at 10:53 PM Willem Jiang > wrote: > > > > Please join me and the rest of the ServiceComb PPMC members in welcoming > our > > new ServiceComb committer: Zhang Lei (赵俊). > > > > Zhang Lei contribute the ServiceComb earlier this year， he is active > > contributor on pack project and the mailing list, and we look > > forward to many more contributions in the future. > > > > Congratulations to Zhang Lei! Welcome! > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem >
Re: [ANN] New ServiceComb committer: Zhang Lei (张磊）
Welcome on-board ! Willem Jiang 于2019年4月1日周一 下午10:53写道： > Please join me and the rest of the ServiceComb PPMC members in welcoming > our > new ServiceComb committer: Zhang Lei (赵俊). > > Zhang Lei contribute the ServiceComb earlier this year， he is active > contributor on pack project and the mailing list, and we look > forward to many more contributions in the future. > > Congratulations to Zhang Lei! Welcome! > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [VOTE] Release Apache ServiceComb Pack version 0.4.0
So do we have to do the license checking by using the license-maven-plugin ? Willem Jiang 于2019年4月1日周一 下午3:10写道： > I checked the staging repo by running the demo against it. > But I found Alpha introduced a (LGPL 3.0 license) Compact HashMap > (com.github.vlsi.compactmap:compactmap:1.2.1 - > https://github.com/vlsi/compactmap/compactmap) , we need to exclude it > from our apache release. > > So I have to vote -1 for it. > Now I'm working on the generate the third party license file to avoid > this kind of error in the future. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sat, Mar 30, 2019 at 9:25 AM Mohammad Asif Siddiqui > wrote: > > > > Hi All, > > > > This is a call for Vote to release Apache ServiceComb Pack version 0.4.0 > > > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-pack/0.4.0/rc-01/ > > > > Staging Repository : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1379 > > > > Release Tag : > https://github.com/apache/servicecomb-pack/releases/tag/0.4.0 > > > > Release CommitID : 32588a3253d5e4573ade849c37eedd371580b1fd > > > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344102 > > > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > Voting will start now ( Saturday, 30th March, 2019) and will remain open > for at-least 72 hours, Request all PMC members to give their vote. > > > > [ ] +1 Release this package as 0.4.0 > > [ ] +0 No Opinion > > [ ] -1 Do not release this package because > > > > On the behalf of ServiceComb Team > > Mohammad Asif Siddiqui >
Re: [Saga] Ask questions about the Saga transaction process
It looks like you try to mix the success scenario, failure and compensate scenario, timeout scenario in the one picture ? I think it could be better to separate into the different scenarios. As Willem mentioned, the timeout scenario is much more complicated. Anyway, this is a good idea to find out how we handle the saga events. Btw, I think this could be very helpful for us to define the state machine of the alpha server. Thanks for your contributions ! Regards, Zheng Feng zhang_...@boco.com.cn 于2019年3月21日周四 下午3:25写道： > This is a light version > > > https://raw.githubusercontent.com/coolbeevip/servicecomb-pack-notes/master/ServiceComb%20Alpha%20Saga/assets/sequence-booking-request-hotel-timeout.png > > 张 磊 > > 部门: 亿阳信通IT运维支撑产品线 > 地址: 北京市海淀区杏石口路99号西山赢府商务中心2410 > 邮编: 100093 > 手机: 18610099300 > 移邮：zhang_...@boco.com.cn > > > 在 2019年3月21日，上午11:47，zhang_...@boco.com.cn 写道： > > > > The following link is a sequence diagram, step 4 cannot be compensated. > Will this happen? > > > > > https://github.com/coolbeevip/servicecomb-pack-notes/blob/master/ServiceComb%20Alpha%20EventScanner/assets/sequence-booking-request-hotel-timeout.png?raw=true > > > > coolbeevip > > > > BOCO > > > > > > > >
Re: Release of ServiceComb
I have to get a chance to work on the nested saga support [1]. I'm not very sure it can be fixed in this week and it should be fine to defer to the next relase. Regards, Zheng Feng [1] https://github.com/apache/servicecomb-pack/pull/432 Willem Jiang 于2019年3月19日周二 下午4:54写道： > As we talked, it's time to prepare the release. > There is only ten days to the end of this month, we need to make sure > the branches are ready to go. > Please reply this mail if you have any other big patch need to go with > this release, otherwise we will start the release process shortly. > > @Asif Do you mind start the release check? > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Mar 6, 2019 at 2:29 PM Willem Jiang > wrote: > > > > It's time for us to think about ServiceComb release now. > > > > As usual, we will release ServiceComb Java-Chassis 1.2.0, ServiceComb > > ServiceCenter 1.2.0 at the end of this month, then we will release > > ServiceComb Pack 0.4.0. > > > > Please reply the mail if you have any questions about the release plan. > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem >
Microsoft Orleans Brings Distributed Transactions to Cloud
https://thenewstack.io/microsoft-orleans-brings-distributed-transactions-to-cloud/ It could be interesting and they used Phil's paper [1]. Regards, Zheng Feng [1] https://www.amazon.com/Concurrency-Control-Recovery-Database-Systems/dp/0201107155
Re: [DISCUSSION] create a new project servicecomb-samples
+1 bismy 于2019年1月21日周一 下午3:34写道： > Hello all, > > > I suggest the create a new project servicecomb-samples to hosting code of > servicecomb examples. Currently we have samples in each project, but is not > enough for reasons: > > > 1. Create new examples will make project huge and hard to distribute. > 2. We can not create examples based on released version. > 3. Lack of examples to show integrated features use both of java-chassis > and saga features. > > > Any ideas?
Re: [Discuss]Business exception cannot be rollbacked in ShardingSphere with saga transaction.
I think it could be be resolved in ShardingSphere and catch the business exception and mark the cached result "ROLLBACK_ONLY". Anyway, this should be done before submitting to the saga actor. tsubasaotl 于2019年1月16日周三 下午8:06写道： > Hi, everyone. > > > In ShardingSphere, SQL and their execution result will be cached in saga > transaction manager. > When users call `commit` or `rollback` method, the cached SQL will > generate `SagaDefinition` > and submit it to the saga actuator. > > > Saga actuator do `Transaction` first and get execution result from cached. > When the result is successful, the actuator will directly judge that the > Transaction is successful > and execute the next Transaction. > When the result not found in cached or the result is failed, the actuator > will do retry or compensation > according to configuration. > > > But there is a problem that saga actuator cannot rollback when business > exception happened. > The situation will happen in following workflow. > > >---multiple times--- > begin transaction --> | execute SQL --> cached result | --> throw business > exception --> call rollback >-- > | > > | > > | > but all SQL success, saga actuator don't run compensation <-- get result > from cache <-- saga actuator > > > All SQL is executed successfully, but the business program throws an > exception. So the actuator will judge > transaction is successful, and not to do compensation, which makes users > confused. > > > On this issue, I would like to ask for advice, should resolved in Saga > actuator or ShardingSphere? > And how to resolve better? > > > -- > Yi Yang (Sion) > Apache ShardingSphere contributor
Re: [VOTE]Tracking the Github issue discussions to dev@servicecomb.apache.org
I wonder if it can only watch the github issues by using the dev mailing list or we can reply the thread and it could be posted to the github issue automatically ? Zen Lin 于2019年1月14日周一 下午8:38写道： > How about to create a new proposal discussion for split github issue track > from commits mailing list to dev mailing list? > I think discussion in github issue is quite different from commits, they > are similar to the contents in the dev list. > > Best Regards, > --- > Zen Lin > zenlintechnofr...@gmail.com > Focused on Micro Service and Apache ServiceComb > > > Willem Jiang 于2019年1月14日周一 下午8:20写道： > > > Actually we already had the vote[1] of moving the github notifications > > into the commits mailing list to avoiding flooding the dev mailing > > list . Here is the discussion of it[2]. Now the user questions in the > > github issue are tracked in the commits mailing list. > > > > [1] > > > https://lists.apache.org/thread.html/833356d5dd8901f5d51e94b12d48f9dcb816d29f50b38d46915f8e9e@%3Cdev.servicecomb.apache.org%3E > > [2] > > > https://lists.apache.org/thread.html/95f538f676326bd2cb1a06cf278c4076352b987bfbabad6c6ae247bc@%3Cdev.servicecomb.apache.org%3E > > > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Mon, Jan 14, 2019 at 8:05 PM Willem Jiang > > wrote: > > > > > > First we need to know the common process of building the consensus[1] > in > > Apache. > > > Normally if we have some proposal, we discuss it first to build a > > > common consensus, then we start the vote[2]. > > > > > > So let's discuss about this proposal first. > > > > > > [1]https://community.apache.org/committers/consensusBuilding.html > > > [2]https://community.apache.org/committers/voting.html > > > > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Mon, Jan 14, 2019 at 7:03 PM Zen Lin > > wrote: > > > > > > > > Hi Community, > > > > > > > > Although we have proposed to use JIRA as many times as possible, > there > > are > > > > still many people using our Github issue. > > > > Many users have been hoping to use the Github issue. > > > > > > > > So I propose to track the contents of the Github issue to our dev > > mail so > > > > that the community can better coordinate and discuss, so as not to > > miss the > > > > management of the Github issue. > > > > This is a call for vote of tracking Github issue to > > > > dev@servicecomb.apache.org mail list. > > > > > > > > Voting is starting now ( 14th Jan, 2018) and will remain open for > next > > 72 > > > > hours. > > > > > > > > [ ] +1 Track Github issue discussions to mail list > > > > dev@servicecomb.apache.org > > > > [ ] +0 No Opinion > > > > [ ] -1 Do not track Github issue discussions to the mail list > > > > dev@servicecomb.apache.org > > > > > > > > > > > > Best Regards, > > > > --- > > > > Zen Lin > > > > zenlintechnofr...@gmail.com > > > > Focused on Micro Service and Apache ServiceComb > > >
Re: [Discuss]Make omega and alpha decouple with spring-boot
That is a good idea and I think this should be called the client API ? OmegaClient.init(); OmegaClient.beginSaga(); OmegaCleint.endSaga(); ... zhaojun 于2019年1月14日周一 下午3:09写道： > Hi, all > > I think we should provide api way to bootstrap omega and alpha. > Now our code was tightly coupled with spring-boot, it is not possible for > integrated with other middleware. > We should provide Omega.init(), Alpha.init() api, spring-boot was just one > implementation for Pack. > > Any thought? > > -- > Zhao Jun > Apache Sharding-Sphere & ServiceComb > >
Re: Garbage may be left when the omega crashed before sending participate request
I have a little bit confuse with the Participate-End-Event. How will the alpha do when receiving this event ? As these resources are in the local transaction, I think the alpha does not need to know the detail of these information. Although the omega could crash before registering the participant in the try phase, as Willem mentioned, if we have the @Transactional annotation the transaction manager will rollback them during the recovering after the application start again. In the term of using with no transaction manager support (I assume), I think the omega should provide the similar capability to recovery the resources. The alpha server runs as the coordinator to make a decision to confirm/cancel the global the transaction. So I think it is not very clear to introduce the participate events here to resolve this issue. It's just my two cents. zhaojun 于2019年1月8日周二 下午8:04写道： > I have got it, it’s necessary to build a pre-write mechanism for these > scenario. > > > On Jan 8, 2019, at 7:14 PM, Longchun Zhang wrote: > > > > Hi Zhao Jun, > > > > If the omega didn't send any request to Alpha server, the Alpha server > > would not send any compensation command to it later because Alpha > > don't know the crashed participate omega. > > > > Best, > > > > Longchun Zhang > > > > > > > > > > > > > > On Tue, Jan 8, 2019 at 5:33 PM Willem Jiang > wrote: > > > >> FYI, I just created a JIRA[1] to track this issue. > >> > >> [1]https://issues.apache.org/jira/browse/SCB-1103 > >> > >> Willem Jiang > >> > >> Twitter: willemjiang > >> Weibo: 姜宁willem > >> > >> On Tue, Jan 8, 2019 at 5:19 PM Willem Jiang > >> wrote: > >>> > >>> Oh， I just found another sceniro that current ParticipatedEvent cannot > >>> handle. It's timeout, > >>> if we don't have the StartedEvent, we cannot tell if the invocation > >>> is timeout or not. > >>> > >>> Willem Jiang > >>> > >>> Twitter: willemjiang > >>> Weibo: 姜宁willem > >>> > >>> On Tue, Jan 8, 2019 at 5:00 PM Longchun Zhang > >> wrote: > > Sure, You are right, I mean the none transaction resource operations. > > The framework should support most general condition. We can't assume > all the micro-service do have local transactions supporting. > and sometimes micro-service will leverage DB transaction and other > None transaction > resource related operations in the same time. > > As you said We can send a Participate-Start-Event to Alpha > >> 'Synchronously' > before do any business operations, > A sub_transaction_id can be generated in the same time and send with > Participate-Start-Event to Alpha. > Alpha can recorded it and use it in the confirm or cancel phases. and > >> in > the omega side sub_transaction_id should be > recorded with every followed business operations in order to cancel or > confirm those operations with this id. > > After the business operation we can send a Participate-End-Event to > >> Alpha > with status 'Asynchronously'. > > Best, > > Longchun Zhang > > > > > On Tue, Jan 8, 2019 at 4:27 PM Willem Jiang > >> wrote: > > > Hi Longchun, > > > > Thanks for reporting this issue. The ParticipatedEvent is designed to > > track the success transaction which means if the transaction is > > failed, we could leverage the local transactional API (Spring > > Transactional AOP）to do the clean up work instead of waiting for > >> Omega > > invoke cancel method. > > You may argue what if there are some other resource allocation in the > > try method and it cannot be cleaned even with the @Tranactional > > annotation. I think we could consider to add ParticipateStartedEvent > > and ParticipateEndedEvent to fix this kind of problem. > > > > Any thoughts on this? > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Tue, Jan 8, 2019 at 3:58 PM Longchun Zhang > >> wrote: > >> > >> Hi guys, > >> > >> > >> > >> Recently I am reading the TCC implementation. > >> > >> > >> > >> Current implementation is: In the try phase, embedded Omega agent > >> will > > send > >> a try participate request to alpha server ‘after’ done the try > >> operation. > >> And then in the final phase Alpha will use the participate > >> information to > >> do confirm or cancel operation. > >> > >> > >> > >> There is a race condition here: If the omega crashed ‘before’ > >> sending > >> participate request, and left garbage in the system, Alpha server > >> will do > >> nothing about this Omega agent because Alpha server haven’t any > > information > >> about this participate Omega. > >> > >> > >> > >> To avoid this condition, I suggest that Omega agent send > >> participate > >> request ‘before’ do the business operation. Alpha will get enough >
Re: Saga transaction performance test with Sharding-JDBC
Thanks for sharing these performance tests and is it possible to share the source codes if you are happy to open these tests ? In term of the XA tests, I think the default transaction manager is Atomikos ? I'm interested with running with the Narayana [1] So it could be very useful to share the source codes with the community ! Thanks, Zheng Feng [1] https://github.com/zhfeng/narayana-sharding-sphere 新道场开张了 于2018年12月25日周二 上午10:51写道： > Saga Tx is slower than No Tx. > TPS of saga is 1700 and No Tx is 2000 in test environment. > > > About the load and memory usage, we will record in next performance. > > > > > -- Original -- > From: "Zhang Yonglun"; > Date: Mon, Dec 24, 2018 08:56 PM > To: "dev"; > Cc: "dev"; > Subject: Re: Saga transaction performance test with Sharding-JDBC > > > > Impressive! > I am focused on the performance issue of ShardingSphere for a long time, > and have done a little saga work before. But I still can't understand why > saga Tx faster than No Tx. Is there something I missed? > > BTW, I noticed that second nice machine, and wonder what's the load and > memory usage on it when testing. > > > 新道场开张了 于2018年12月24日周一 下午6:28写道： > > > Hi, everyone. > > > > > > The feature of saga transaction in ShardingSphere has been basically > > completed > > by integrating servicecomb-saga-actuator. > > Recently, we used Sharding-JDBC to test the performance of Saga > > transactions. > > > > > > There are results for two kinds of environments. > > > > > > First result comes from local environment which including 2 cores and 16G > > RAM > > The connection pool size, thread pool size of saga-actuator and thread > > pool size of Sharding-JDBC all are 50. > > > > > > result for local environment > > |Tx Type|Thread Number|Average response(ms)| TPS | > > | No Tx | 50 | 337| 140 | > > | saga | 50 | 395| 120 | > > | local | 50 | 323 |143| > > | xa | 50 | 301 |154| > > | No Tx | 100 | 605| 158 | > > | saga | 100 | 789| 120 | > > > > result for local environment > > > > > > Second result comes from test environment which 256cores and 300+G RAM > > The connection pool size, thread pool size of saga-actuator and thread > > pool size of Sharding-JDBC all are 200. > > > > > > result for test environment > > |Tx Type|Thread Number|Average response(ms)| TPS | > > | No Tx | 200 | 95 |2002| > > | saga | 200 | 351 |1700| > > > > | local | 200 | 64 |2868| > > | xa | 200 | 98 |2012| > > result for test environment > > > > > > And I do echo test with emptyTransport which do not execute SQL in saga, > > the result is TPS 457 in local and 3200 in test environment. > > > > > > if saga do persistence to log file, the TPS of saga will nose dive to 70 > > in local and 600+ in test environment > > > > -- > Zhang Yonglun > Apache ShardingSphere
Re: Switch the default Spring Boot version to 2.x in saga-pack
+1 and what is the benefit we will be got from the Spring Boot 2 ? Willem Jiang 于2018年12月17日周一 下午5:49写道： > Hi team, > > Current saga-pack is using Spring Boot 1.5.x by default, as Spring > Boot 2.x is widely adopted, I propose to switch the default Spring > Boot version to 2.x. > > Any thoughts? > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [VOTE] Release Apache ServiceComb Saga Actuator version 0.3.0
+1 binding - LICENSE is fine - NOTICE is OK - can build the kit from the source without errors Mohammad Asif Siddiqui 于2018年12月15日周六 下午10:31写道： > Hi All, > > This is a call for Vote to release Apache ServiceComb Saga Actuator > version 0.3.0 > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-saga-actuator/0.3.0/ > > > Staging Repository : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1353 > > Release Tag : > https://github.com/apache/servicecomb-saga-actuator/releases/tag/0.3.0 > > Release CommitID : 649445d32956277f3492f1b0ae69213c82b95f10 > > Release Notes : This is the first release of Saga Actuator so no change > log is available. > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Saturday, 15th December, 2018) and will remain > open for at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 0.3.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > Mohammad Asif Siddiqui >
Re: [VOTE] Rename of Saga repository
+1 binding Willem Jiang 于2018年11月28日周三 下午4:23写道： > As we discussion before[1], I'd like call for a vote to rename > servicecomb-saga git repo to servicecomb-pack. > > servicecomb-pack is used to provide the TCC and Saga support in the > pack architecture, we also need to update the artifact group id to > replace saga to pack at the meantime. > > Voting will start now ( Wednesday, 28th November, 2018) and will > remain open for at-least 72 hours, Request all PMC members to give > their vote. > > [ ] +1 Rename of servicecomb-service-saga repository to > servicecomb-service-pack > [ ] +0 No Opinion > [ ] -1 Do not Rename the repository because > > [1] > https://lists.apache.org/thread.html/e7468de26b5c956d615fc7c7dbbf03dbde5aef6ac92f5ef843db1dcb@%3Cdev.servicecomb.apache.org%3E > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [VOTE] Release Apache ServiceComb Saga version 0.2.1
Hi Willem, I just wonder if there is a CHECK LIST for the release ? or is it possible to do some verification automatically ? Thanks, Zheng Feng Willem Jiang 于2018年11月23日周五 上午8:42写道： > +1 binding. > > I checked: > - incubating in binary and src kit name > - signatures and hashes correct > - LICENSE is fine > - NOTICE is OK > - no unexpected binary files > - source files have headers > - can build the kit from source with any error > - can run the demo with the instruction of README > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Nov 20, 2018 at 11:36 PM Mohammad Asif Siddiqui > wrote: > > > > Hi All, > > > > This is a call for Vote to release Apache ServiceComb Saga version 0.2.1 > > > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344453 > > > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-saga/0.2.1/rc-01/ > > > > Staging Repository : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1346/ > > > > Release Tag : > https://github.com/apache/servicecomb-saga/releases/tag/0.2.1 > > > > Release CommitID : 1484592d6fc84a33ffb7510969437ba448277e82 > > > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > Voting will start now ( Tuesday, 20th November, 2018) and will remain > open for at-least 72 hours, Request all PMC members to give their vote. > > > > [ ] +1 Release this package as 0.2.1 > > [ ] +0 No Opinion > > [ ] -1 Do not release this package because > > > > On the behalf of ServiceComb Team > > Mohammad Asif Siddiqui >
Re: [VOTE] Release Apache ServiceComb Saga version 0.2.1
+1 binding I checked: - LICENSE is fine - NOTICE is OK - Success to build the source and run the tests Zheng Feng Willem Jiang 于2018年11月23日周五 上午8:42写道： > +1 binding. > > I checked: > - incubating in binary and src kit name > - signatures and hashes correct > - LICENSE is fine > - NOTICE is OK > - no unexpected binary files > - source files have headers > - can build the kit from source with any error > - can run the demo with the instruction of README > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Nov 20, 2018 at 11:36 PM Mohammad Asif Siddiqui > wrote: > > > > Hi All, > > > > This is a call for Vote to release Apache ServiceComb Saga version 0.2.1 > > > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344453 > > > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-saga/0.2.1/rc-01/ > > > > Staging Repository : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1346/ > > > > Release Tag : > https://github.com/apache/servicecomb-saga/releases/tag/0.2.1 > > > > Release CommitID : 1484592d6fc84a33ffb7510969437ba448277e82 > > > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > Voting will start now ( Tuesday, 20th November, 2018) and will remain > open for at-least 72 hours, Request all PMC members to give their vote. > > > > [ ] +1 Release this package as 0.2.1 > > [ ] +0 No Opinion > > [ ] -1 Do not release this package because > > > > On the behalf of ServiceComb Team > > Mohammad Asif Siddiqui >
Re: ServiceComb Community Meeting
yeah. exactly but I think if the google document could be access in China without the OpenVPN ? Willem Jiang 于2018年11月20日周二 上午10:11写道： > Yeah, I agree with you. I think we can setup the agenda in the Google > document just like the MicroProfile LRA Hangout Agenda[1] to talk > about the detail development plan of ServiceComb with the community. > > [1] > https://docs.google.com/document/d/1HBPiXpsXcQp9T8JeoT-IDs-EblZX1SxuTV5qjUPzwrM/edit?ouid=101568241178421126357=docs_home=true > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > On Tue, Nov 20, 2018 at 3:43 PM Zheng Feng wrote: > > > > Thanks Zen Lin, I think you might be missing the link for the itcast ? > > > > I agree it is very important to let the more committers to know what we > are > > doing and what we will do. So the monthly online meeting sounds helpful > and > > we should prepare the agenda before the meeting and to know what the > > community is concerned. Maybe we could share this agenda online and > anyone > > could be able to add the items to discuss. > > > > Thanks, > > Zheng Feng > > > > Zen Lin 于2018年11月20日周二 上午7:16写道： > > > > > I am preparing a Apache ServiceComb Meetup about on Dec 23th. > > > The Meetup will be held with itcast [1]. > > > We are just doing a discussion of draft plan last week. > > > Maybe we can have a 1 hour conference to meet F2F with our committers > to > > > discuss about how to develop the community and carrying out the > Roadmap. > > > > > > Besides, I think we can have a online meetup with committers each > month, > > > anyone who are concerning about Apache ServiceComb can join the meetup > to > > > discuss the Roadmap. Thus we can always update the Roadmap. We have no > need > > > to care how many committers will join the meetup, but just let us start > > > it. I believe that as long as we keep doing it, more and more > developers > > > will join in. > > > > > > Anyway, What I concern is that many developers want to know what can I > do > > > and what will the community want the next, that is what we called > roadmap. > > > > > > Any thoughts? > > > > > > Best Regards, > > > --- > > > Zen Lin > > > zenlintechnofr...@gmail.com > > > Focused on Micro Service and Apache ServiceComb > > > > > > > > > cherrylzhao 于2018年11月20日周二 上午11:38写道： > > > > > > > If we can post the time, face to face meeting(skype) is better. > > > > Also we can send the meeting summary to the mailing list. > > > > > > > > > On Nov 20, 2018, at 10:07 AM, Willem Jiang > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > I had a talk with Asif recently about the community meeting > recently. > > > > > I think it's a great idea which could help us get touch with the > > > > > community contributor and help them to know better about our > project > > > > > development plan. In this way we could help more developer or user > to > > > > > know better about our code and we can know better about the user > case > > > > > at the same time. > > > > > > > > > > It could be a simple meeting in the Gitter (we just need to post > the > > > > > time to let everyone know we are online for it) or even face to > face > > > > > meeting for the meetup. > > > > > > > > > > Any thoughts? I'm really appreciate the effort that everyone put on > > > > > the community. > > > > > > > > > > > > > > > Willem Jiang > > > > > > > > > > Twitter: willemjiang > > > > > Weibo: 姜宁willem > > > > > > > > > > > >
Re: Is saga named right?
Well, this is the first time I hear about the story of the PACK name. I like the meaning of a group of wild animals and it is really cool ! Willem Jiang 于2018年11月20日周二 上午6:02写道： > Pack has two means as a noun, we could tell a good story with it :) > 1. a group of wild animals, especially wolves, living and hunting together. > 2. a small cardboard or paper container and the items contained within it. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > On Tue, Nov 20, 2018 at 12:09 PM 赵俊 wrote: > > > > I have’t understand pack meaning before, thanks for explain. > > I think pack which represents feature enhance like windows service pack > at first time. > > > > > > > On Nov 20, 2018, at 11:32 AM, Willem Jiang > wrote: > > > > > > Hi Cherry， > > > > > > servicecomb-saga-actuator is just for the centrical saga > implementation. > > > We will rename the servicecomb-saga to servicecomb-pack, as I prefer > > > the name of pack which shows the spirit of DTS (Distributed > > > Transaction Service), Omega report the status, and the Alpha take the > > > control of everything. > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Tue, Nov 20, 2018 at 11:21 AM cherrylzhao > wrote: > > >> > > >> Hi, Willem > > >> > > >> I think servicecomb-dts or servicecomb-dtx is better. > > >> And we can keep the old saga package same as before. > > >> > > >>> On Nov 20, 2018, at 9:59 AM, Willem Jiang > wrote: > > >>> > > >>> Please let me know what your think about this. Either way I will > > >>> start a vote for the repository change shortly this week. > > >>> > > >>> Willem Jiang > > >>> > > >>> Twitter: willemjiang > > >>> Weibo: 姜宁willem > > >>> > > >>> On Tue, Nov 20, 2018 at 9:57 AM Willem Jiang > wrote: > > >>>> > > >>>> Now the Saga 0.2.x branch is ready for the release, we will start > the > > >>>> rename process after the release. > > >>>> At the meantime I planning to create new git repo > > >>>> servicecomb-saga-actuator to host the old saga implementation. > > >>>> > > >>>> Willem Jiang > > >>>> > > >>>> Twitter: willemjiang > > >>>> Weibo: 姜宁willem > > >>>> > > >>>> On Wed, Nov 14, 2018 at 5:32 PM Willem Jiang < > willem.ji...@gmail.com> wrote: > > >>>>> > > >>>>> Agree we need the migration document for it. > > >>>>> > > >>>>> There are lots change in the 0.3.0-SNAPSHOT, if we want the user > use > > >>>>> the new added transports, we may need to back port those patch to > > >>>>> 0.2.0 branch. > > >>>>> > > >>>>> Willem Jiang > > >>>>> > > >>>>> Twitter: willemjiang > > >>>>> Weibo: 姜宁willem > > >>>>> > > >>>>> On Wed, Nov 14, 2018 at 5:29 PM Zheng Feng > wrote: > > >>>>>> > > >>>>>> Willem Jiang 于2018年11月14日周三 下午5:13写道： > > >>>>>> > > >>>>>>> I think we can keep the annotation there , but mark it as > deprecated > > >>>>>>> and add the new annotation there. So there could be a very big > change > > >>>>>>> on the customer project. > > >>>>>>> > > >>>>>> I agree that could be a problem with upgrading from the old > version and > > >>>>>> should be very clear explain in the documentation. > > >>>>>> > > >>>>>> We could consider to remove the old implementation in the Pack > 0.4.0 > > >>>>>>> release. Beside the the package rename, we also need to rename > the > > >>>>>>> artifacts group id. > > >>>>>>> > > >>>>>> I think we need to change the major version if we rename the > package and > > >>>>>> group id. > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> Or we can do the 0.2.x release for n
Re: Release of ServiceComb Saga 0.2.1
yeah, it looks good to me and let's vote it ! Willem Jiang 于2018年11月15日周四 下午6:54写道： > It has been a while for the ServiceComb released Saga 0.2.0. > As we are in the middle of rename of git repo, and some user wants to > use the Saga into their production environment. I just merged some > bug patches and new added feign component into the 0.2.x branch. > > Here is the change log of Saga 0.2.1 > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12344453 > > Can we start the release of ServiceComb Saga 0.2.1 at the end of this week? > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: Is saga named right?
OK, that makes sense. Willem Jiang 于2018年11月14日周三 下午5:32写道： > Agree we need the migration document for it. > > There are lots change in the 0.3.0-SNAPSHOT, if we want the user use > the new added transports, we may need to back port those patch to > 0.2.0 branch. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Nov 14, 2018 at 5:29 PM Zheng Feng wrote: > > > > Willem Jiang 于2018年11月14日周三 下午5:13写道： > > > > > I think we can keep the annotation there , but mark it as deprecated > > > and add the new annotation there. So there could be a very big change > > > on the customer project. > > > > > I agree that could be a problem with upgrading from the old version and > > should be very clear explain in the documentation. > > > > We could consider to remove the old implementation in the Pack 0.4.0 > > > release. Beside the the package rename, we also need to rename the > > > artifacts group id. > > > > > I think we need to change the major version if we rename the package and > > group id. > > > > > > > > > > Or we can do the 0.2.x release for new added transport components. > > > > > 0.2.x ? sorry, I think we are in 0.3.0-SNAPSHOT currently. > > > > > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > On Wed, Nov 14, 2018 at 2:22 PM Zheng Feng wrote: > > > > > > > > comments inline, > > > > > > > > Willem Jiang 于2018年11月14日周三 上午10:39写道： > > > > > > > > > As we discussed, Here is the proposal of the github rename for the > > > > > distribute transaction > > > > > 1. Rename servicecomb-saga -> servicecomb-pack to keep all the > starts, > > > > > and we need to rename the package name to pack. > > > > > If the user use the old link of saga, it will be redirect to > > > > > servicecomb-pack > > > > > > > > > If we rename the package, it will break the compatible of the java > > > > annotations ? How about the next release plan ? > > > > > > > > 2. Create a new github repo servicecomb-saga-engine to remain the old > > > saga > > > > > stuff > > > > > > > > > It looks good to me. > > > > > > > > > > > > > > > > > > Any thought? If it is OK , I will start a vote for it at the end of > > > this > > > > > week. > > > > > > > > > > Willem Jiang > > > > > > > > > > Twitter: willemjiang > > > > > Weibo: 姜宁willem > > > > > > > > > > On Wed, Oct 24, 2018 at 2:22 PM Willem Jiang < > willem.ji...@gmail.com> > > > > > wrote: > > > > > > > > > > > > Sure, I just create a JIRA[1] for it. > > > > > > [1]https://issues.apache.org/jira/browse/SCB-976 > > > > > > > > > > > > Willem Jiang > > > > > > > > > > > > Twitter: willemjiang > > > > > > Weibo: 姜宁willem > > > > > > On Tue, Oct 23, 2018 at 9:34 PM Zheng Feng > > > wrote: > > > > > > > > > > > > > > Hi Willem, > > > > > > > > > > > > > > Can you create a JIRA for this moving and it could make it much > > > clear > > > > > in > > > > > > > the description ? > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Willem Jiang 于2018年10月23日周二 下午9:04写道： > > > > > > > > > > > > > > > If we put them all together, we cannot name it as Saga. It > could > > > > > > > > confuse the user. > > > > > > > > But I don't want to rename the Saga repo, as lot of people > > > already > > > > > > > > know about it. > > > > > > > > > > > > > > > > > > > > > > > > Willem Jiang > > > > > > > > > > > > > > > > Twitter: willemjiang > > > > > > > > Weibo: 姜宁willem > > > > > > > > > > > > > > > > On Tue, Oct 23, 2018 at 8:45 PM bismy wrote: > > > > > > > > > > > > > > &
Re: Is saga named right?
Willem Jiang 于2018年11月14日周三 下午5:13写道： > I think we can keep the annotation there , but mark it as deprecated > and add the new annotation there. So there could be a very big change > on the customer project. > I agree that could be a problem with upgrading from the old version and should be very clear explain in the documentation. We could consider to remove the old implementation in the Pack 0.4.0 > release. Beside the the package rename, we also need to rename the > artifacts group id. > I think we need to change the major version if we rename the package and group id. > > Or we can do the 0.2.x release for new added transport components. > 0.2.x ? sorry, I think we are in 0.3.0-SNAPSHOT currently. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > On Wed, Nov 14, 2018 at 2:22 PM Zheng Feng wrote: > > > > comments inline, > > > > Willem Jiang 于2018年11月14日周三 上午10:39写道： > > > > > As we discussed, Here is the proposal of the github rename for the > > > distribute transaction > > > 1. Rename servicecomb-saga -> servicecomb-pack to keep all the starts, > > > and we need to rename the package name to pack. > > > If the user use the old link of saga, it will be redirect to > > > servicecomb-pack > > > > > If we rename the package, it will break the compatible of the java > > annotations ? How about the next release plan ? > > > > 2. Create a new github repo servicecomb-saga-engine to remain the old > saga > > > stuff > > > > > It looks good to me. > > > > > > > > > > Any thought? If it is OK , I will start a vote for it at the end of > this > > > week. > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Wed, Oct 24, 2018 at 2:22 PM Willem Jiang > > > wrote: > > > > > > > > Sure, I just create a JIRA[1] for it. > > > > [1]https://issues.apache.org/jira/browse/SCB-976 > > > > > > > > Willem Jiang > > > > > > > > Twitter: willemjiang > > > > Weibo: 姜宁willem > > > > On Tue, Oct 23, 2018 at 9:34 PM Zheng Feng > wrote: > > > > > > > > > > Hi Willem, > > > > > > > > > > Can you create a JIRA for this moving and it could make it much > clear > > > in > > > > > the description ? > > > > > > > > > > Thanks, > > > > > > > > > > Willem Jiang 于2018年10月23日周二 下午9:04写道： > > > > > > > > > > > If we put them all together, we cannot name it as Saga. It could > > > > > > confuse the user. > > > > > > But I don't want to rename the Saga repo, as lot of people > already > > > > > > know about it. > > > > > > > > > > > > > > > > > > Willem Jiang > > > > > > > > > > > > Twitter: willemjiang > > > > > > Weibo: 姜宁willem > > > > > > > > > > > > On Tue, Oct 23, 2018 at 8:45 PM bismy wrote: > > > > > > > > > > > > > > Can we put them all in one project so that we can release all > > > components > > > > > > together? > > > > > > > > > > > > > > > > > > > > > We can separate them in different modules in saga project. > > > > > > > > > > > > > > > > > > > > > I think we can use SAGA as the name for this project which > > > implements > > > > > > BASE transactions(saga, tcc, etc. ) although saga is one of > them in > > > > > > history. > > > > > > > > > > > > > > > > > > > > > -- 原始邮件 -- > > > > > > > 发件人: "willem.jiang"; > > > > > > > 发送时间: 2018年10月23日(星期二) 晚上7:31 > > > > > > > 收件人: "dev"; > > > > > > > > > > > > > > 主题: Re: Is saga named right? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yeah, that is exactly what I'm thinking about. > > > > > > > The new git repo could be Pack, we can implement different > > > Transaction > > > > > > > protocal there. >
Re: Is saga named right?
comments inline, Willem Jiang 于2018年11月14日周三 上午10:39写道： > As we discussed, Here is the proposal of the github rename for the > distribute transaction > 1. Rename servicecomb-saga -> servicecomb-pack to keep all the starts, > and we need to rename the package name to pack. > If the user use the old link of saga, it will be redirect to > servicecomb-pack > If we rename the package, it will break the compatible of the java annotations ? How about the next release plan ? 2. Create a new github repo servicecomb-saga-engine to remain the old saga > stuff > It looks good to me. > > Any thought? If it is OK , I will start a vote for it at the end of this > week. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Oct 24, 2018 at 2:22 PM Willem Jiang > wrote: > > > > Sure, I just create a JIRA[1] for it. > > [1]https://issues.apache.org/jira/browse/SCB-976 > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > On Tue, Oct 23, 2018 at 9:34 PM Zheng Feng wrote: > > > > > > Hi Willem, > > > > > > Can you create a JIRA for this moving and it could make it much clear > in > > > the description ? > > > > > > Thanks, > > > > > > Willem Jiang 于2018年10月23日周二 下午9:04写道： > > > > > > > If we put them all together, we cannot name it as Saga. It could > > > > confuse the user. > > > > But I don't want to rename the Saga repo, as lot of people already > > > > know about it. > > > > > > > > > > > > Willem Jiang > > > > > > > > Twitter: willemjiang > > > > Weibo: 姜宁willem > > > > > > > > On Tue, Oct 23, 2018 at 8:45 PM bismy wrote: > > > > > > > > > > Can we put them all in one project so that we can release all > components > > > > together? > > > > > > > > > > > > > > > We can separate them in different modules in saga project. > > > > > > > > > > > > > > > I think we can use SAGA as the name for this project which > implements > > > > BASE transactions(saga, tcc, etc. ) although saga is one of them in > > > > history. > > > > > > > > > > > > > > > -- 原始邮件 -- > > > > > 发件人: "willem.jiang"; > > > > > 发送时间: 2018年10月23日(星期二) 晚上7:31 > > > > > 收件人: "dev"; > > > > > > > > > > 主题: Re: Is saga named right? > > > > > > > > > > > > > > > > > > > > Yeah, that is exactly what I'm thinking about. > > > > > The new git repo could be Pack, we can implement different > Transaction > > > > > protocal there. > > > > > And the current Saga code could have a dependency of it or we just > > > > > move the Pack related code to Pack repo. > > > > > > > > > > > > > > > Willem Jiang > > > > > > > > > > Twitter: willemjiang > > > > > Weibo: 姜宁willem > > > > > > > > > > On Tue, Oct 23, 2018 at 3:28 PM Zheng Feng > wrote: > > > > > > > > > > > > I think the core implementation of TCC and Saga (Pack) have the > same > > > > > > things, such as the similar annotations and the event names. So > does it > > > > > > make sense to have the common core module to implement the > transaction > > > > > > context, transaction event and the grpc communication protocol ? > > > > > > And we could provide the different APIs or annotations for both > the > > > > TCC and > > > > > > the Saga or maybe the other distribute transaction protocol. > Also we > > > > could > > > > > > make a new roadmap to make it as a framework used in the > microservice > > > > to > > > > > > resolve the transaction things. > > > > > > > > > > > > Anyway, I totally agree with Willem to separate the TCC and the > Saga > > > > codes > > > > > > at the first step. And what is the next ? Maybe we need a new > name for > > > > the > > > > > > repo ? > > > > > > > > > > > > Regards, > > > > > > Zheng Feng > > > > > > > > > >
Re: [ANN] New ServiceComb committer: Yao Haishi (姚海石)
welcome on board ! Willem Jiang 于2018年11月13日周二 上午10:47写道： > Please join me and the rest of the ServiceComb PPMC members in welcoming > our > new ServiceComb committer: Yao Haishi (姚海石). > > Yao Haishi contribute the ServiceComb more than a year, he is active > contributor on java-chassis, doc and the mailing list, and we look > forward to many more > contributions in the future. > > Congratulations to Yao Haishi ! Welcome! > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [DISCUSS]Discovery API support filter instances by properties
So the question is how the server knows the differences with the client request from the last time ? there are snapshots in the SC with every instance status changes ? Yang Bo 于2018年11月9日周五 上午9:39写道： > How about add some patching mechanisms. The server only send information of > changed instances in the query response. > This will drastically reduce the response size when only a few instances > changes in a huge cluster. > > On Fri, Nov 9, 2018 at 9:15 AM bismy wrote: > > > I think we need take more considerations on how users use this API. > > According to what we have done, server side need to cache all query > > results. We can't just say 'We just let the client to find out what they > > want to know' and leave all things to users, because the most important > > part of instance management is how to keep data consistence both on > server > > side and client side. > > > > > > For this problem, I intend to agree with @zzzwjm. We didn't see any > > critical problem for the current solution to query all possible > instances. > > Maybe current solution will have problem with two conditions met: 1. > > instances is huge; 2. instances up/down very frequently. At this > > conditions, the provided solution seems not work very good too. > > > > > > -- 原始邮件 -- > > 发件人: "willem.jiang"; > > 发送时间: 2018年11月9日(星期五) 上午8:50 > > 收件人: "dev"; > > > > 主题: Re: [DISCUSS]Discovery API support filter instances by properties > > > > > > > > I think Sure is just want SC provide some filtering query on the > > server side, we don't need to let the server cached all the query > > result. > > We just let the client to find out what they want to know, server > > don't need to send all the data to the client unless the client wants > > them. > > > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Fri, Nov 9, 2018 at 5:47 AM wjm wjm wrote: > > > > > > that will cause SC cache results by different query parameters, is it > too > > > heavy? > > > > > > even has 2k instances , but client query by data version, if not > > changed, > > > only response 304 NOT MODIFIED > > > if instances changed, and response size is big, then can response with > > > compress > > > so there is no problem? > > > > > > Sure 于2018年11月7日周三 下午11:36写道： > > > > > > > > > > https://github.com/apache/incubator-servicecomb-service-center/issues/482 > > > > > > > > Hi guys, > > > > > > > > Our system has 20+ services, and each service has 2k instances at > most. > > > > All the instances are grouped by some labels(in Properties). > > > > > > > > We are now querying all the instances from SC, and then filtering > > them by > > > > labels on the client side. This wastes a lot of bandwidth and has > poor > > > > performance. Can SC's API provide the filtering function? > > > > > > > > Thx. > > > > -- > Best Regards, > Yang. >
Re: [Heads Up ]Git repository names are changed
Nice work ! I just open the PR to fix in the saga [1] [1] https://github.com/apache/servicecomb-saga/pull/332 Willem Jiang 于2018年11月9日周五 上午10:02写道： > I did some clean up on java-chassis, saga, service-center README file > and removed the DISCLAIM file. > I also updated some documents of saga reference in the doc site. > There may still have some place need to updated. > Please check out the documents and feel free to submit fix for that. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Nov 9, 2018 at 8:59 AM Willem Jiang > wrote: > > > > Hi Team, > > > > As part of way to the Apache TLP, we need to rename the github repo name. > > Now it's done. Please let me know if something is broken. > > I just checked travis CI, it's OK. I'll update the status bage link > shortly. > > > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem >
Re: [Heads Up ]Git repository names are changed
Thanks Willem and it is great ! Willem Jiang 于2018年11月9日周五 上午8:59写道： > Hi Team, > > As part of way to the Apache TLP, we need to rename the github repo name. > Now it's done. Please let me know if something is broken. > I just checked travis CI, it's OK. I'll update the status bage link > shortly. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [Discuss][SAGA] MicroProfile LRA
There is a pdf file for the LRA specification [1] for reviewing. [1] https://github.com/eclipse/microprofile-lra/files/2546285/microprofile-lra-spec.pdf Zheng Feng 于2018年11月2日周五 上午9:30写道： > 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: [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 >
[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
+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 > > >>>>>> > > >>> > > >>> > > >
Re: Saga，TCC overhead
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: Is saga named right?
Hi Willem, Can you create a JIRA for this moving and it could make it much clear in the description ? Thanks, Willem Jiang 于2018年10月23日周二 下午9:04写道： > If we put them all together, we cannot name it as Saga. It could > confuse the user. > But I don't want to rename the Saga repo, as lot of people already > know about it. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Oct 23, 2018 at 8:45 PM bismy wrote: > > > > Can we put them all in one project so that we can release all components > together? > > > > > > We can separate them in different modules in saga project. > > > > > > I think we can use SAGA as the name for this project which implements > BASE transactions(saga, tcc, etc. ) although saga is one of them in > history. > > > > > > -- 原始邮件 -- > > 发件人: "willem.jiang"; > > 发送时间: 2018年10月23日(星期二) 晚上7:31 > > 收件人: "dev"; > > > > 主题: Re: Is saga named right? > > > > > > > > Yeah, that is exactly what I'm thinking about. > > The new git repo could be Pack, we can implement different Transaction > > protocal there. > > And the current Saga code could have a dependency of it or we just > > move the Pack related code to Pack repo. > > > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Tue, Oct 23, 2018 at 3:28 PM Zheng Feng wrote: > > > > > > I think the core implementation of TCC and Saga (Pack) have the same > > > things, such as the similar annotations and the event names. So does it > > > make sense to have the common core module to implement the transaction > > > context, transaction event and the grpc communication protocol ? > > > And we could provide the different APIs or annotations for both the > TCC and > > > the Saga or maybe the other distribute transaction protocol. Also we > could > > > make a new roadmap to make it as a framework used in the microservice > to > > > resolve the transaction things. > > > > > > Anyway, I totally agree with Willem to separate the TCC and the Saga > codes > > > at the first step. And what is the next ? Maybe we need a new name for > the > > > repo ? > > > > > > Regards, > > > Zheng Feng > > > > > > Willem Jiang 于2018年10月23日周二 下午2:54写道： > > > > > > > Hi Team， > > > > > > > > As TCC is quite different with the Saga implementation. > > > > I'm planning to move the Pack code and TCC related code out of Saga > repo. > > > > In this way we can just keep Saga repo to have the implementation > for Saga. > > > > > > > > Any thought？ > > > > > > > > > > > > Willem Jiang > > > > > > > > Twitter: willemjiang > > > > Weibo: 姜宁willem > > > > > > > > On Wed, Aug 29, 2018 at 5:27 PM Willem Jiang > > > > > wrote: > > > > > > > > > > Yeah, once we plan to support the TCC in the Saga project , we > need to > > > > consider to rename the project name. > > > > > Current we have two different implementation of Saga, one is > centric > > > > Saga, the other is based the Pack (Omega/Alpha). > > > > > Now we implement the TCC protocol on top of Pack architecture. > > > > > > > > > > Maybe we can rearrange the package name base on this Architecture > and > > > > move the Pack code to another repo. > > > > > Any thought? > > > > > > > > > > Willem Jiang > > > > > > > > > > Twitter: willemjiang > > > > > Weibo: 姜宁willem > > > > > > > > > > > > > > > On Wed, Aug 29, 2018 at 5:09 PM fu chengeng > > > > wrote: > > > > >> > > > > >> Hi all. > > > > >> as we all knows that,saga is a kind of transaction > agreement,And we > > > > named this project as saga because we support only this kind of > agreement. > > > > >> But now,we are going to support tcc, and maybe many other > > > > transaction agreement like xa will be supported. > > > > >> Whether we should change saga to other name to prevent > confused > > > > when it is in incubating? > > > > >> > > > > >> > > > > >
Re: Is saga named right?
I think the core implementation of TCC and Saga (Pack) have the same things, such as the similar annotations and the event names. So does it make sense to have the common core module to implement the transaction context, transaction event and the grpc communication protocol ? And we could provide the different APIs or annotations for both the TCC and the Saga or maybe the other distribute transaction protocol. Also we could make a new roadmap to make it as a framework used in the microservice to resolve the transaction things. Anyway, I totally agree with Willem to separate the TCC and the Saga codes at the first step. And what is the next ? Maybe we need a new name for the repo ? Regards, Zheng Feng Willem Jiang 于2018年10月23日周二 下午2:54写道： > Hi Team， > > As TCC is quite different with the Saga implementation. > I'm planning to move the Pack code and TCC related code out of Saga repo. > In this way we can just keep Saga repo to have the implementation for Saga. > > Any thought？ > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Aug 29, 2018 at 5:27 PM Willem Jiang > wrote: > > > > Yeah, once we plan to support the TCC in the Saga project , we need to > consider to rename the project name. > > Current we have two different implementation of Saga, one is centric > Saga, the other is based the Pack (Omega/Alpha). > > Now we implement the TCC protocol on top of Pack architecture. > > > > Maybe we can rearrange the package name base on this Architecture and > move the Pack code to another repo. > > Any thought? > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > > > On Wed, Aug 29, 2018 at 5:09 PM fu chengeng > wrote: > >> > >> Hi all. > >> as we all knows that,saga is a kind of transaction agreement,And we > named this project as saga because we support only this kind of agreement. > >> But now,we are going to support tcc, and maybe many other > transaction agreement like xa will be supported. > >> Whether we should change saga to other name to prevent confused > when it is in incubating? > >> > >> >
Re: [DISCUSS] Saga Dashboard
Thanks for building these APIs and I just want to add some comments on the cwiki.apache.org but I can not find the button to post the comment (maybe I don't have the permission). Anyway, I have to add some comments here: 1. /recent which returns the list of recent transactions, is it ordered by the transaction start time or the end time ? 2. In the term of the type parameter, I think the type of transaction is not success or fail. I assume you means this is the status of the transactions. So it could be better to change to use the "status" parameter. 3. For the status of the transactions, I think it could be 1) PENDING: the transaction is started and ongoing 2) COMMITTED: the transaction is committed and the result is successful 3) COMPENSATING: the transaction is rollbacked and the compensating is ongoing 4) ROLLBACKED: the transaction is rollbacked and all the compensate methods are invoked. 4. /findtransactions I think it might be helpful to add the serviceName parameter to find the transactions which are associated to the service Mohammad Asif Siddiqui 于2018年10月18日周四 下午4:43写道： > Hi All, > > Currently there is a PR[1] open for this Saga Management Console > implementation but this PR is using '/events' from the alpha server which > is just open for test profiles + the events api gives a lot of information > which might not be relevant to the Saga Console and will result in lot of > processing of data on the client browser. > > So I propose to add a few api's[2] in alpha server for Saga Mangament > Console which will be used by the UI to display the relevant data. These > API's can also be used by third party to implement their of own > UI/Console/CLI for Saga. > > The complete proposal for the API is available here [3], please review and > provide your feedback. > > [1] https://github.com/apache/incubator-servicecomb-saga/pull/317 > [2] > https://app.swaggerhub.com/apis/ServiceComb/SagaManagamentConsole/1.0.0 > [3] > https://cwiki.apache.org/confluence/display/SERVICECOMB/Saga+Management+Console+API%27s > > > Regards > Asif > > On 2018/09/19 03:17:12, Willem Jiang wrote: > > On Wed, Sep 19, 2018 at 12:21 AM Mohammad Asif Siddiqui > > wrote: > > > > > > Hi All, > > > > > > Recently I was exploring Saga and I came across Saga Web[1] module > which helps to create Saga Request and View the Results but I was not able > to find any web based UI where I can see the list of all the transactions > or view the transactions based on the status, microservices or tx-id. > > > > > > So I want to propose a Saga Dashboard which can list all the > transactions and analyse the success and failure transactions which can be > helpful for Users/Developers both in development as well as production env. > > > > > > The informations which can be shown in the UI is listed below : > > > 1. Recent Transactions Trends( Last 7 Days) > > > 2. Recent Successful Transactions( Last 7 Days) > > > 3. Recent Failed Transactions( Last 7 Days) > > > > We don't know how much transactions there, I'd like to be able to do > > some configuration for the time. > > > > > 4. Total Transactions > > > > It could be count by Saga or TCC transaction. > > Each Saga/ TCC may have different MicroServiceName, admin may need to > > find out the highest failure rate of MicroSerivce. > > We can let the admin drill down to the sub transactions. > > > > > 5. Total Failed Transactions > > > 6. Total Successful Transactions > > > 7. Preview of Successful Transaction (Last 24 Hours) > > > > Not sure if it OK, maybe we can add last 5 mins? > > > > > 8. Preview of Failed Transaction (Last 24 Hours) > > > 9. List of All Successful Transactions > > > > The could be lots of Transactions there, we need to let the user search > it > > > > > 10. List of All Failed Transactions > > > > This is most important thing that we want to show to the admin, it > > should be easy for the admin find out the which subtrancation is > > failed and the failed reason. > > > > > 11. Search Transactions based on MicroService Name > > > 12. Search Transactions based on Tx ID > > > 13. See the Transaction hierarchy based on Tx ID > > > > > > A draft proposal for this dashboard is available here[2]. > > > > > > Please feel free to give a feedback/comments to make this UI better > and useful to the Users. > > > > > > [1] > https://github.com/apache/incubator-servicecomb-saga/tree/master/saga-web > > > [2] https://github.com/asifdxtreme/Docs/blob/master/Saga-Dashboard.md > > > > > > Regards > > > Asif > > > > > >
Re: [VOTE] Graduate Apache ServiceComb (incubating)
+1 (binding) Willem Jiang 于 2018年9月14日周五 15:58写道： > Please vote on the proposal for ServiceComb graduation to TLP to submit to > the Incubator PMC. > > Vote: > [ ] +1 - Recommend Graduation of Apache ServiceComb as a TLP > [ ] -1 - Do not recommend graduation of Apache ServiceComb because …. > > This vote will stay open for at least 72 hours. > > > > Establish the Apache ServiceComb Project > > WHEREAS, the Board of Directors deems it to be in the best interests of > the Foundation and consistent with the Foundation's purpose to establish > a Project Management Committee charged with the creation and maintenance > of open-source software, for distribution at no charge to the public, > related to a microservice framework that provides a set of tools and > components to make development and deployment of cloud applications > easier. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > (PMC), to be known as the "Apache ServiceComb Project", be and hereby is > established pursuant to Bylaws of the Foundation; and be it further > > RESOLVED, that the Apache ServiceComb Project be and hereby is > responsible for the creation and maintenance of software related to a > microservice framework that provides a set of tools and components to > make development and deployment of cloud applications easier; and be it > further > > RESOLVED, that the office of "Vice President, Apache ServiceComb" be and > hereby is created, the person holding such office to serve at the > direction of the Board of Directors as the chair of the Apache > ServiceComb Project, and to have primary responsibility for management > of the projects within the scope of responsibility of the Apache > ServiceComb Project; and be it further > > RESOLVED, that the persons listed immediately below be and hereby are > appointed to serve as the initial members of the Apache ServiceComb > Project: > > * Aray Chenchu Sukesh > * Bao Liu > * Eric Lee > * Jean-Baptiste Onofré > * Jimin Wu > * Linzhinan > * Mohammad Asif Siddiqui > * Qi Zhang > * Roman Shaposhnik > * Timothy Chen > * Willem Ning Jiang > * Yang Bo > * Yihua Cui > * Yin Xiang > * Zheng Feng > * zhengyangyong > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Willem Ning Jiang be > appointed to the office of Vice President, Apache ServiceComb, to serve > in accordance with and subject to the direction of the Board of > Directors and the Bylaws of the Foundation until death, resignation, > retirement, removal or disqualification, or until a successor is > appointed; and be it further > > RESOLVED, that the Apache ServiceComb Project be and hereby is tasked > with the migration and rationalization of the Apache Incubator > ServiceComb podling; and be it further > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > ServiceComb podling encumbered upon the Apache Incubator PMC are > hereafter discharged. > > Regards, > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: Invitation of the ServiceComb PMC
Yes Willem Jiang 于 2018年9月6日周四 09:00写道： > Hi Committers > > As the discussion of "Heading to graduation" [1], we want to setup > the PMC as part of ServiceComb graduation resolution. So we'd like to > confirm whether you want to remain as a Project Management Committees > (PMC) member of Apache ServiceComb project? > > I just quote some roles description of PMC from How it works of Apache[2]. > If you just heard about PMC, please spend some time to read about the > role of PMC and understand the responsibilities, and let me know if > you have any question about it. > > " The role of the PMC from a Foundation perspective is oversight. The > main role of the PMC is not code and not coding - but to ensure that > all legal issues are addressed, that procedure is followed, and that > each and every release is the product of the community as a whole. > That is key to our litigation protection mechanisms. > > Secondly the role of the PMC is to further the long term development > and health of the community as a whole, and to ensure that balanced > and wide scale peer review and collaboration does happen. Within the > ASF we worry about any community which centers around a few > individuals who are working virtually uncontested. We believe that > this is detrimental to quality, stability, and robustness of both code > and long term social structures." > > If you'd like to be the member of ServiceComb PMC, it's welcome and > please *respond** 'Yes'* in this thread, or *respond 'No'* if you are > not interested in any more. > > This thread will be available for at least 72 hours, after that, we > will send individual confirm emails. > > [1] > https://lists.apache.org/thread.html/3753af01adc9f0db65949565851f66816e1932dde028b99ee7a7c14e@%3Cdev.servicecomb.apache.org%3E > [2]http://www.apache.org/foundation/how-it-works.html#pmc > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [DISCUSS] Heading to graduation
+1 Yang Bo 于2018年9月4日周二 下午2:51写道： > +1 > > On Tue, Sep 4, 2018 at 2:37 PM Zen Lin > wrote: > > > Willem Jiang are doing lots of works on technical guide and Apache Way > > guide, I would like to recommend he to be the PMC Chair. > > > > Best Regards, > > --- > > Zen Lin > > zenlintechnofr...@gmail.com > > Focused on Micro Service and Apache ServiceComb > > > > > > Kirin Wang 于2018年9月4日周二 下午2:29写道： > > > > > +1 > > > Willem did a lot in building the community > > > > > > Lance Ju 于2018年9月4日周二 下午2:26写道： > > > > > > > +1 > > > > > > > > Mohammad Asif Siddiqui 于2018年9月4日周二 > 下午1:42写道： > > > > > > > > > +1 > > > > > > > > > > On Tue, Sep 4, 2018 at 8:59 AM Sure wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > -- Original -- > > > > > > From: wjm wjm > > > > > > Date: Tue,Sep 4,2018 11:20 AM > > > > > > To: dev > > > > > > Subject: Re: [DISCUSS] Heading to graduation > > > > > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > 郑扬勇 <342906...@qq.com> 于2018年9月4日周二 上午10:54写道： > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- 原始邮件 -- > > > > > > > 发件人: "bismy"; > > > > > > > 发送时间: 2018年9月4日(星期二) 上午9:26 > > > > > > > 收件人: "willem.jiang"; > > > > > > > > > > > > > > 主题: 回复： [DISCUSS] Heading to graduation > > > > > > > > > > > > > > > > > > > > > > > > > > > > I recommend Willem Jiang to be the PMC Chair. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- 原始邮件 -- > > > > > > > 发件人: "willem.jiang"; > > > > > > > 发送时间: 2018年9月3日(星期一) 下午4:10 > > > > > > > 收件人: "dev"; > > > > > > > > > > > > > > 主题: Re: [DISCUSS] Heading to graduation > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Team, > > > > > > > > > > > > > > For the resolution proposal[1], we need to figure out PMC and > > PMC > > > > > Chair > > > > > > of > > > > > > > the ServiceComb for the board. > > > > > > > Normally we just move our PPMC member to the PMC, and we need > to > > > > figure > > > > > > out > > > > > > > the PMC Chair. > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://incubator.apache.org/guides/graduation.html#preparing_a_charter > > > > > > > > > > > > > > > > > > > > > > > > > > > > Willem Jiang > > > > > > > > > > > > > > Twitter: willemjiang > > > > > > > Weibo: 姜宁willem > > > > > > > > > > > > > > On Thu, Aug 16, 2018 at 12:32 PM, Jean-Baptiste Onofré < > > > > > j...@nanthrax.net> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Willem, > > > > > > > > > > > > > > > > thanks for the update. > > > > > > > > > > > > > > > > The maturity model assessment draft looks overall good to me. > > > > > > > > > > > > > > > > I will add the resolution proposal draft on the wiki as well. > > > > > > > > > > > > > > > > Regards > > > > > > > > JB > > > > > > > > > > > > > > > > On 15/08/2018 11:09, Willem Jiang wrote: > > > > > > > > > With the ServiceComb java-chassis 1.0.0-incubating and > > > > > service-center > > > > > > > > > 1.0.0-incubating release officially out. > > > > > > > > > We believe it is time to discuss what requirements remains > to > > > > > > consider > > > > > > > > > graduation to the TLP. > > > > > > > > > > > > > > > > > > I just updated the ServiceComb Project Status for it: > > > > > > > > > > > > > > > > > > http://servicecomb.incubator.apache.org/ > > > > > > > > > > > > > > > > > > Apache ServiceComb entered incubation in November of 2017, > > > > > > ServiceComb > > > > > > > > > community learned a lot about how to do things in Apache > > ways. > > > > > > > > > Now we are a very helpful and engaged community, ready to > > help > > > on > > > > > all > > > > > > > > > questions from the ServiceComb Community. > > > > > > > > > We are making consensus decisions through the discussion in > > the > > > > > > mailing > > > > > > > > > list and voted 3 new committers. > > > > > > > > > We managed delivered three round released include 5 > different > > > > > binary > > > > > > > > > release, now we can do self-driving releases in good > cadence. > > > > > > > > > > > > > > > > > > Please check out the maturity assessment doc[1] for more > > > > > information. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/SERVICECOMB/Apache+Maturity+ > > > > > > > > > Model+Assessment+for+ServiceComb > > > > > > > > > > > > > > > > > > Any thoughts? And welcome advice from ServiceComb Mentors? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Willem Jiang > > > > > > > > > > > > > > > > > > Twitter: willemjiang > > > > > > > > > Weibo: 姜宁willem > > > > > > > > > > > > > > > > > > On Fri, Jul 13, 2018 at 4:16 PM, Jean-Baptiste Onofré < > > > > > > j...@nanthrax.net > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > >> It sounds good ! > > > >
Re: [ANN] New ServiceComb committer: Yang Bo (杨波)
Congratulations ! Willem Ning Jiang 于2018年8月24日周五 上午11:27写道： > Please join me and the rest of the ServiceComb PPMC members in welcoming > our > new ServiceComb committer: Yang Bo (杨波). > > Yang Bo starts to contribute on ServiceComb project earlier this > year. He help us fix lots of License related issues in, and updates > the website with his new ideas. He is also active in the mailing list, > and we look forward to many more contributions in the future. > > Congratulations to Yang Bo! Welcome! > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem >
Re: [DISCUSS]Add a local or embedded interface to call Saga
Nice work and I think you could raise the JIRA on
https://issues.apache.org/jira/browse/SCB for this new feature.
Good luck with the implementation !
2018-08-22 15:49 GMT+08:00 新道场开张了 :
> SCSagaSQLFormatDesign.png
>
>
> This picture is my design for embedded interface to call Saga.
> In the design, we need to extend TYPE_SQL=sql in Operation interface and
> JsonSubTypes in JsonSagaRequest interface.
> And we need to add some classes to match the new json we defined before.
> we also can reuse SagaRequestImpl during JsonSagaDefinition building and
> Saga workflow after JsonSagaDefinition
> built.
>
>
> -- 原始邮件 --
> 发件人: "新道场开张了";
> 发送时间: 2018年8月21日(星期二) 上午10:40
> 收件人: "dev";
>
> 主题: Re： [DISCUSS]Add a local or embedded interface to call Saga
>
>
>
> sorry, the picture is a simple UML of SQLTransport
>
>
> https://github.com/KomachiSion/incubator-servicecomb-saga/blob/master/
> docs/static_files/Transport.jpg
>
>
> -- 原始邮件 --
> 发件人: "Willem Jiang";
> 发送时间: 2018年8月21日(星期二) 上午10:20
> 收件人: "dev";
>
> 主题: Re: [DISCUSS]Add a local or embedded interface to call Saga
>
>
>
> Yeah, the json format of SQL Transport sounds good.
> As we normally use the text in the mailing list, so please draw asiis
> picture or put a permanent link in the mail for us to review.
>
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Tue, Aug 21, 2018 at 10:11 AM, 新道场开张了 wrote:
>
> > I think we can extend Transport interface to a new interface named
> > SQLTransport.
> > the SQLTransport also include 'with' function, but the parameters only
> > requires datasource/serviceName, sql and parameters.
> > Users can decide how to execute the sql of the datasource/serviceName in
> > their own SQLTransport implements.
> >
> >
> > In order to invoke SQLTransport successfully, we need to modify the
> > Operation, Transaction and Compensation setions of Format for matching
> new
> > json requests.
> > the new json structure is:
> > {
> > "policy":"",
> > "requests":[
> > {
> > "id":"",
> > "type":"SQL",
> > "serviceName(or datasource)":"",
> > "parents":[],
> > "transaction":{
> > "sql":"",
> > "params":[] (or {})
> > },
> > "compensation":{
> > "sql":"",
> > "params":[] (or {})
> > }
> > }
> > ]
> > }
> >
> >
> >
> > -- 原始邮件 --
> > *发件人:* "Willem Jiang";
> > *发送时间:* 2018年8月21日(星期二) 上午8:34
> > *收件人:* "dev";
> > *主题:* Re: [DISCUSS]Add a local or embedded interface to call Saga
> >
> > The saga patten is quite simple, if call is failed, the compensation
> method
> > should be called.
> > I know someone already provide the framework[1] with Scala to simplify
> the
> > complex if else check.
> > The PersonService and EmailService can be the remote service or local
> > service.
> >
> > val persistInvoiceAndSendEmail: Future[Email :: Person :: HNil] = saga
> > .part[Person](PersonService.addInvoice(person, invoice), p =>
> > PersonService.deleteInvoice(p, invoice))
> > .part[Email](EmailService.sendInvoice(person.email, invoice), letter
> > => EmailService.sendExcuse(letter.email,
> > EmailService.createExcuse(letter)))
> > .run
> >
> > persistInvoiceAndSendEmail.onComplete {
> > case Success(email :: person :: HNil) =>
> > logger.debug("There you can manage process results")
> > case Failure(SagaFailed(message, _)) =>
> > logger.error(s"One saga part has been failed due to $message")
> > }
> >
> >
> >
> > [1]https://github.com/dobrynya/saga
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Mon, Aug 20, 2018 at 10:26 PM, Zheng Feng wrote:
> >
> > > Thanks Willem and it is a good point here. Also I'm interesting how it
> > > could be used in the local or the embedded interface ? I wonder if you
> > can
> > > consider the ACID transaction in this situation.
> > > The Saga in my options could
Re: About introduce Lombok to service comb
It looks good to me and the lombok supports the JDK 9 ? 2018-08-22 12:21 GMT+08:00 赵俊 : > Hi, Willem > > Lombok would not package into our service-comb jar, so there is no license > issue. > We can set the maven scope is “provide”, it just enhance the java code > byte in compile step. > > > > > On 21 Aug 2018, at 10:57 PM, wjm wjm wrote: > > > > in fact, getter / setter and so on can be generated by IDE(IntelliJ / > > Eclipse) simply > > > > 2018-08-21 22:34 GMT+08:00 Willem Jiang : > > > >> Hi Cherry, > >> > >> Thanks for proposal, it can save us lot of time when we write the java > bean > >> class. > >> As lombok is using MIT license, I don't think we could have the license > >> issue here. > >> > >> I think we can start it from saga project, it's up to java-chassis to > check > >> if it want to use it. > >> > >> @Team Any thought? > >> > >> > >> > >> Willem Jiang > >> > >> Twitter: willemjiang > >> Weibo: 姜宁willem > >> > >> On Tue, Aug 21, 2018 at 12:58 PM, cherrylzhao > wrote: > >> > >>> Hi, all > >>> > >>> Lombok can simplify our work for creating java entity. > >>> Using Lombok annotation, it will enhance java byte code within compile > >>> step. > >>> We can use @Getter @Setter @Log @RequiredArgsConstructor to define our > >>> model simplify. > >>> See more detail from https://projectlombok.org < > >> https://projectlombok.org/ > > >>> > >>> any thought? > >> > >
