Re: [Announce] New committer of ServiceComb
Welcome Willem Jiang 于2021年3月3日周三 上午10:37写道： > > Welcome aboard！ > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Mar 3, 2021 at 10:18 AM Xiaoliang Tian > wrote: > > > > Hi, > > > > I want to introduce luojianwen (Github ID: robotLJW [1]) as a new > > committer of ServiceComb.has contributed features for > > servicecomb-service-center. > > Welcome luojianwen :) > > > > [1]https://github.com/robotLJW > > > > > > Xiaoliang Tian -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [Announce] New committer of ServiceComb
Congrats and welcome! 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 -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.0.0
+1
Checks done:
- git tag and commit id is OK.
- mvn build OK
- mvn build demo OK
- staging repo OK
- asc signature of source and binary OK
- sha512 signature of source and binary OK
Bao Liu 于2020年2月19日周三 下午2:33写道：
>
> Hi Daniel,
> Thank for the information. I guest the problem to run in MAC is because the
> test code got some problem, here is the test code and hard coded the local
> host. Maybe we can change it
> to 127.0.0.1, I created a issue [1] to update this in next release.
>
> public static class TestClientVerticle extends AbstractVerticle {
> @SuppressWarnings("deprecation")
> @Override
> public void start(Future startFuture) {
> HttpClient client = vertx.createHttpClient();
> client.post(port, "127.127.127.127", "/").handler(resp -> {
> resp.bodyHandler((buffer) -> {
> startFuture.complete();
> });
> }).end(body);
> }
> }
>
> And for the demo problem, I create an issue to update the document [2], there
> are still a lot of work to be done to update official site for other parts. I
> will start this work after the voting is closed. To run demo in docker, you
> need do the following:
> -Ddemo-run-release
> Or the dependencies will not copied to docker environment and cause your
> problem.
>
> [1]https://issues.apache.org/jira/browse/SCB-1779
> [2]https://issues.apache.org/jira/browse/SCB-1778
>
> Anyway, I think this two problems are not blocking the release and the voting
> can go on.
>
> On 2020/02/19 04:07:34, Daniel Qian wrote:
> > Hi, Bao Liu
> >
> > I checked source code by method mentioned in offitial website link[1].
> > I used both `mvn clean install -Pdocker -Pit ` and `mvn clean install
> > -Pdocker -Pdemo-run-release -Pit`, and
> > `org.apache.servicecomb.metrics.core.TestVertxMetersInitializer` was
> > stucked, here is the stack trace generated by jstack[2]. BTW, the
> > issue is only reproducible on my Mac, not reproducible on a linux
> > machine, so I think it's not an issue.
> >
> > Besides, I checked Staging Repository by cd into demo and run `mvn
> > clean install -Pdocker -Pstaging ` (this method is also mentioned in
> > the official website[4]). Unfortunately, the build failed on `Java
> > Chassis::Demo::POJO::Client`, here is the error log[3]
> >
> > [1]:
> > https://servicecomb.apache.org/cn/developers/release-validation-guide/#%E9%AA%8C%E8%AF%81%E6%BA%90%E4%BB%A3%E7%A0%81%E5%8A%9F%E8%83%BD%E6%AD%A3%E7%A1%AE
> > [2]:
> > https://gist.github.com/chanjarster/614f349205ffd712b64afd041973b9a7#file-stack-txt
> > [3]:
> > https://gist.github.com/chanjarster/614f349205ffd712b64afd041973b9a7#file-demo-log
> > [4]:
> > https://servicecomb.apache.org/cn/developers/release-validation-guide/#%E9%AA%8C%E8%AF%81staging-repository%E5%86%85%E7%9A%84%E5%BA%93%E6%AD%A3%E7%A1%AE
> >
> > Bao Liu 于2020年2月18日周二 下午10:24写道：
> > >
> > > BTW, when running in profile -Ddocker, do not miss `mvn clean install
> > > -Pdocker -Pdemo-run-release -Pit` , -Ddemo-run-release is for integration
> > > tests in demo folder to execute. Check scripts/travis.sh for details.
> > >
> > > On 2020/02/18 14:21:07, Bao Liu wrote:
> > > > This is a unit test case and I run both locally and travis CI fine. Do
> > > > you have any details about the stuck?
> > > >
> > > > On 2020/02/18 12:31:27, Daniel Qian wrote:
> > > > > I got stuck on
> > > > > org.apache.servicecomb.metrics.core.TestVertxMetersInitializer
> > > > > when mvn clean install -Pdocker -Pit
> > > > > Did I miss something?
> > > > >
> > > > > yhs0092 于2020年2月18日周二 下午4:19写道：
> > > > > >
> > > > > > +1
> > > > > > Checks done:
> > > > > > - git tag and commit id is OK.
> > > > > > - mvn clean install -Pit build OK.
> > > > > > - basic function checked pass.
> > > > > > - the release candidate of source is OK.
> > > > > >
> > > > > >
> > > > > > Yours sincerely
> > > > > >
> > > > > >
> > > > > > Yao Haishi
> > > > > > yhs0...@163.com
> > > > > >
> > > > > >
> > > > > > On 2/17/2020 16:07，bismy wrote：
> > > > > > Hello All,
> > > > > >
> > > > > > This is a call for a Vote to release Apache ServiceComb
> > > > > > Jav
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.0.0
Hi, Bao Liu I checked source code by method mentioned in offitial website link[1]. I used both `mvn clean install -Pdocker -Pit ` and `mvn clean install -Pdocker -Pdemo-run-release -Pit`, and `org.apache.servicecomb.metrics.core.TestVertxMetersInitializer` was stucked, here is the stack trace generated by jstack[2]. BTW, the issue is only reproducible on my Mac, not reproducible on a linux machine, so I think it's not an issue. Besides, I checked Staging Repository by cd into demo and run `mvn clean install -Pdocker -Pstaging ` (this method is also mentioned in the official website[4]). Unfortunately, the build failed on `Java Chassis::Demo::POJO::Client`, here is the error log[3] [1]: https://servicecomb.apache.org/cn/developers/release-validation-guide/#%E9%AA%8C%E8%AF%81%E6%BA%90%E4%BB%A3%E7%A0%81%E5%8A%9F%E8%83%BD%E6%AD%A3%E7%A1%AE [2]: https://gist.github.com/chanjarster/614f349205ffd712b64afd041973b9a7#file-stack-txt [3]: https://gist.github.com/chanjarster/614f349205ffd712b64afd041973b9a7#file-demo-log [4]: https://servicecomb.apache.org/cn/developers/release-validation-guide/#%E9%AA%8C%E8%AF%81staging-repository%E5%86%85%E7%9A%84%E5%BA%93%E6%AD%A3%E7%A1%AE Bao Liu 于2020年2月18日周二 下午10:24写道： > > BTW, when running in profile -Ddocker, do not miss `mvn clean install > -Pdocker -Pdemo-run-release -Pit` , -Ddemo-run-release is for integration > tests in demo folder to execute. Check scripts/travis.sh for details. > > On 2020/02/18 14:21:07, Bao Liu wrote: > > This is a unit test case and I run both locally and travis CI fine. Do you > > have any details about the stuck? > > > > On 2020/02/18 12:31:27, Daniel Qian wrote: > > > I got stuck on > > > org.apache.servicecomb.metrics.core.TestVertxMetersInitializer > > > when mvn clean install -Pdocker -Pit > > > Did I miss something? > > > > > > yhs0092 于2020年2月18日周二 下午4:19写道： > > > > > > > > +1 > > > > Checks done: > > > > - git tag and commit id is OK. > > > > - mvn clean install -Pit build OK. > > > > - basic function checked pass. > > > > - the release candidate of source is OK. > > > > > > > > > > > > Yours sincerely > > > > > > > > > > > > Yao Haishi > > > > yhs0...@163.com > > > > > > > > > > > > On 2/17/2020 16:07，bismy wrote： > > > > Hello All, > > > > > > > > This is a call for a Vote to release Apache ServiceComb Java-Chassis > > > > version 2.0.0 > > > > > > > > Release Notes : > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12345196 > > > > > > > > Release Candidate : > > > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.0.0/rc01// > > > > > > > > Staging Repo : > > > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1420 > > > > > > > > Release Tag : > > > > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.0.0 > > > > > > > > Release CommitID : 16ee95b968e0ed8beed26bd9fdecb56376984f7d > > > > > > > > Keys to verify the Release Candidate > > > > :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > > > > > Voting will start now ( Monday, 27 February, 2020) and will remain > > > > openfor at-least 72 hours, Request all PMC members to give their vote. > > > > > > > > [ ] +1 Release this package as 2.0.0 > > > > [ ] +0 No Opinion > > > > [ ] -1 Do not release this package because > > > > > > > > On the behalf of ServiceComb Team > > > > > > > > Liu Bao > > > > > > > > > > > > -- > > > Daniel Qian > > > Apache Committer(chanjarster) > > > blog：https://chanjarster.github.io > > > github：https://github.com/chanjarster > > > segmentfault: https://segmentfault.com/u/chanjarster > > > > > -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [VOTE] Release Apache ServiceComb Java-Chassis version 2.0.0
I got stuck on org.apache.servicecomb.metrics.core.TestVertxMetersInitializer when mvn clean install -Pdocker -Pit Did I miss something? yhs0092 于2020年2月18日周二 下午4:19写道： > > +1 > Checks done: > - git tag and commit id is OK. > - mvn clean install -Pit build OK. > - basic function checked pass. > - the release candidate of source is OK. > > > Yours sincerely > > > Yao Haishi > yhs0...@163.com > > > On 2/17/2020 16:07，bismy wrote： > Hello All, > > This is a call for a Vote to release Apache ServiceComb Java-Chassis version > 2.0.0 > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12345196 > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-java-chassis/2.0.0/rc01// > > Staging Repo : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1420 > > Release Tag : > https://github.com/apache/servicecomb-java-chassis/releases/tag/2.0.0 > > Release CommitID : 16ee95b968e0ed8beed26bd9fdecb56376984f7d > > Keys to verify the Release Candidate > :https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Monday, 27 February, 2020) and will remain openfor > at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 2.0.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > > Liu Bao -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [ANNOUNCE] Apache ServiceComb Toolkit version 0.2.0 Released
Good job! sen sun 于2020年1月6日周一 下午11:58写道： > > Hi All, > > Apache ServiceComb Team is glad to announce the release of Apache > ServiceComb Toolkit 0.2.0 > > Apache ServiceComb Toolkit(https://github.com/apache/servicecomb-toolkit) > is a contract-based microservice development toolkit. It provides the > ability to convert and verify contracts, code, and documents, helping users > quickly build microservice projects based on popular microservices > frameworks and popular programming models, reducing the cost of > microservices entry, enabling users to focus on business development, > enhance refactoring and development efficiency. > > Download Links : http://servicecomb.apache.org/release/toolkit-downloads > > Release Notes : http://servicecomb.apache.org/release/toolkit-release-notes/ > > Know more about ServiceComb: http://servicecomb.apache.org/ > > ServiceComb Usefull Links : > - Mailing lists: dev@servicecomb.apache.org > - JIRA : https://issues.apache.org/jira/browse/SCB > > > Best Wishes & Regards -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [VOTE] Release Apache ServiceComb Toolkit version 0.2.0 [RC2]
+0 I've created two PRs corresponding to Willem Jiang's suggestions: https://github.com/apache/servicecomb-toolkit/pull/75 https://github.com/apache/servicecomb-toolkit/pull/76 So, I think it's better to create another RC. BTW, 1. Not all issues for toolkit 0.2.0 are closed 2. all the links above are fine. 3. git tag and commit id are OK. 4. hashes and signature are good. 5. license and Notice exist 6. scripts/test.sh build is OK 7. toolkit-maven-plugin running is OK. zhongyuan zhou 于2020年1月3日周五 上午10:41写道： > > +1 > > I checked : > - hashes and signature are good. > - mvn clean install works fine. > > Bin Ma 于2020年1月3日周五 上午9:15写道： > > > +1 binding > > > > I checked: > > 1. all issues for toolkit 0.2.0 are closed > > 2. all the links above are fine. > > 3. git tag and commit id are OK. > > 4. hashes and signature are good. > > 5. license and Notice exist > > 6. mvn clean install build OK. > > 7. toolkit-maven-plugin running is OK. > > > > > > Wishes & Regards > > --- > > Mabin > > > > > > > > Liubao (A) 于2020年1月2日周四 下午8:24写道： > > > > > +1 > > > > > > I checked the release binaries and release notes, seems good to me. > > > > > > Bug I got one small improvement for artifacts deployed by toolkit. May of > > > the artifacts have very general name and may cause conflicts easily. e.g. > > > toolkit*jar, core*jar, common*jar. Although the have unit group id, java > > > packagers will put them all in one flat folder. > > > > > > -邮件原件- > > > 发件人: sen sun [mailto:asd992825...@gmail.com] > > > 发送时间: 2019年12月31日 18:18 > > > 收件人: dev@servicecomb.apache.org > > > 主题: [VOTE] Release Apache ServiceComb Toolkit version 0.2.0 [RC2] > > > > > > Hi All, > > > > > > This is a call for Vote to release Apache ServiceComb Toolkit version > > 0.2.0 > > > > > > > > > Release Candidate : > > > > > > > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-toolkit/0.2.0/rc-02/ > > > > > > Staging Repository : > > > > > > > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1411 > > > > > > Release Tag : > > > https://github.com/apache/servicecomb-toolkit/releases/tag/0.2.0 > > > > > > Release CommitID : da3b3b6333e1c776d4e39513e39e328596d9b40f > > > > > > Release Notes : > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346158 > > > > > > Keys to verify the Release Candidate : > > > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > > > Voting will start now ( Tuesday, 31nd Dec, 2019) and will remain open for > > > at-least 72 hours, Request all PMC members to give their vote. > > > > > > [ ] +1 Release this package as 0.2.0 > > > [ ] +0 No Opinion > > > [ ] -1 Do not release this package because > > > > > > On the behalf of ServiceComb Team > > > > > > Best Wishes & Regards > > > > > -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [VOTE] Release Apache ServiceComb Toolkit version 0.2.0 [RC2]
Hi Willem, junit is introduced by oas-validator-test. I think we can exclude oas-validator-test from binary distribution. I created a JIRA for this issue[1] [1]: https://issues.apache.org/jira/browse/SCB-1702 Willem Jiang 于2020年1月2日周四 上午9:51写道： > > +1. > I checked, > > Download links are valid, git tag is OK. > Checksums and PGP signatures are valid. > DISCLAIMER is included. > LICENSE and NOTICE files are good. > No binary file in the source kit. > I can build the kit from source kit. > > BTW, the CLI help need to be clean up, I just create a JIRA[1] for it. > it's strange that we have the dependency of JUnit which is only used > for testing purposes. > It's not good practices to keep the master branch version of 0.2.0 for > very long time, please update the pom version for next release > development. > > [1]https://issues.apache.org/jira/browse/SCB-1701 > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > > On Tue, Dec 31, 2019 at 6:19 PM sen sun wrote: > > > > Hi All, > > > > This is a call for Vote to release Apache ServiceComb Toolkit version 0.2.0 > > > > > > Release Candidate : > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-toolkit/0.2.0/rc-02/ > > > > Staging Repository : > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1411 > > > > Release Tag : > > https://github.com/apache/servicecomb-toolkit/releases/tag/0.2.0 > > > > Release CommitID : da3b3b6333e1c776d4e39513e39e328596d9b40f > > > > Release Notes : > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346158 > > > > Keys to verify the Release Candidate : > > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > Voting will start now ( Tuesday, 31nd Dec, 2019) and will remain open for > > at-least 72 hours, Request all PMC members to give their vote. > > > > [ ] +1 Release this package as 0.2.0 > > [ ] +0 No Opinion > > [ ] -1 Do not release this package because > > > > On the behalf of ServiceComb Team > > > > Best Wishes & Regards -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [ANN] New ServiceComb committer:Sun Lisen(孙丽森)
Congrats! 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. -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION][Toolkit] Large OpenAPI/Swagger yaml maintenance
Hi Willem, I mean OpenAPI yaml written by hand. And yes, we need to track all the change by means of git. And large Swagger often needs to be maintained by several people, and that's the conflict happens. OpenAPI v3 provide Components[1] to reuse Schema, Response, Request, etc. But that's no enough if we have a lot of Paths and Operations. OpenAPI v3 also provide Reference Object[2], but it's like the Components and has the same problem. For example, AliPay API[3]. Another example, K8S API[4]. They are all huge API. [1]: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#components-object [2]: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md#referenceObject [3]: https://docs.open.alipay.com/api_2 [4]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.17/ Willem Jiang 于2019年12月23日周一 上午9:05写道： > > Hi Daniel > > Could you explain more about it? > If the Swagger yaml is generated from the code, it's make sense that > we don't put this yaml files into VCS. > But if we write the Swagger yaml file by hand, I think we need to keep > the track of all the changes. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sun, Dec 22, 2019 at 8:52 PM Daniel Qian wrote: > > > > Hi toolkit guys, > > > > OpenAPI/Swagger yaml is a good standard to describe the APIs, but it's > > easy to get hundreds, even thousands lines in the file. That becomes > > hard to maintain and easy to get into the VCS conflict situation. > > How do you guys solve this problem in real development? I've heard > > that some teams use template engine to merge snippets into a final > > yaml. > > May be toolkit can do something helpful to make the life easier. Any ideas? > > > > -- > > Daniel Qian > > Apache Committer(chanjarster) > > blog：https://chanjarster.github.io > > github：https://github.com/chanjarster > > segmentfault: https://segmentfault.com/u/chanjarster -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
[DISCUSSION][Toolkit] Large OpenAPI/Swagger yaml maintenance
Hi toolkit guys, OpenAPI/Swagger yaml is a good standard to describe the APIs, but it's easy to get hundreds, even thousands lines in the file. That becomes hard to maintain and easy to get into the VCS conflict situation. How do you guys solve this problem in real development? I've heard that some teams use template engine to merge snippets into a final yaml. May be toolkit can do something helpful to make the life easier. Any ideas? -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [VOTE] Release Apache ServiceComb Toolkit version 0.2.0
Every software has bugs, it's ok to release 0.2.0 Bin Ma 于2019年12月10日周二 下午9:11写道： > > The issues involve in the test code and CI, and do not affect > the functions of the binary and maven plugin. > > I suggest to go on to vote 0.2.0, the issues[1] can be fixed > in the next version. > > any thought?@PMCs > > [1] https://issues.apache.org/jira/browse/SCB-1657 > > Wishes & Regards > --- > Mabin > > > > sen sun 于2019年12月10日周二 上午11:38写道： > > > I have created the JIRA: https://issues.apache.org/jira/browse/SCB-1657 > > Whether this issue affects the current release? Can we fix it in the next > > version? > > > > Willem Jiang 于2019年12月10日周二 上午10:38写道： > > > > > Please create a JIRA to check this issue. > > > We may consider to enable the Action in Github to running the CI with > > > windows. > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Tue, Dec 10, 2019 at 9:46 AM sen sun wrote: > > > > > > > > Hi, @yhs0092 > > > > > > > > I have checked this unit test code. It uses File.size to get the size > > of > > > > the directory. > > > > In Windows, it always returns zero and causes the assertion to fail > > > > In Linux, it is ok > > > > This is because their file systems are different and Files.size only > > > > guarantee the correctness of the file > > > > > > > > yhs0092 于2019年12月10日周二 上午12:16写道： > > > > > > > > > Hello, I find that the `mvn clean install` build is not OK in my > > > > > development environment. I use a Windows computer to run it. > > > > > Here is the error log: > > > > > ``` > > > > > [INFO] Running org.apache.servicecomb.toolkit.cli.CliTest > > > > > [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0, Time > > elapsed: > > > > > 2.884 s <<< FAILURE! - in org.apache.servicecomb.toolkit.cli.CliTest > > > > > [ERROR] > > > > > > > > > > testGenerateServiceCombCodeFromSingleContract(org.apache.servicecomb.toolkit.cli.CliTest) > > > > > Time elapsed: 0.834 s <<< FAILURE! > > > > > java.lang.AssertionError > > > > > at > > > > > > > > > > org.apache.servicecomb.toolkit.cli.CliTest.lambda$testGenerateServiceCombCodeFromSingleContract$0(CliTest.java:54) > > > > > at > > > > > > > > > > org.apache.servicecomb.toolkit.cli.CliTest.testGenerateServiceCombCodeFromSingleContract(CliTest.java:36) > > > > > > > > > > > > > > > [ERROR] > > > > > > > > > > testGenerateCodeFromMultiContract(org.apache.servicecomb.toolkit.cli.CliTest) > > > > > Time elapsed: 0.602 s <<< FAILURE! > > > > > java.lang.AssertionError > > > > > at > > > > > > > > > > org.apache.servicecomb.toolkit.cli.CliTest.testGenerateCodeFromMultiContract(CliTest.java:89) > > > > > > > > > > > > > > > [INFO] > > > > > [INFO] Results: > > > > > [INFO] > > > > > [ERROR] Failures: > > > > > [ERROR] CliTest.testGenerateCodeFromMultiContract:89 > > > > > [ERROR] > > > > > > > > > > CliTest.testGenerateServiceCombCodeFromSingleContract:36->lambda$testGenerateServiceCombCodeFromSingleContract$0:54 > > > > > [INFO] > > > > > [ERROR] Tests run: 6, Failures: 2, Errors: 0, Skipped: 0 > > > > > ``` > > > > > > > > > > > > > > > Yours sincerely > > > > > > > > > > > > > > > Yao Haishi > > > > > yhs0...@163.com > > > > > > > > > > > > > > > On 12/6/2019 09:09，Bin Ma wrote： > > > > > Hi All, > > > > > > > > > > This is a call for Vote to release Apache ServiceComb Toolkit version > > > 0.2.0 > > > > > > > > > > > > > > > Release Candidate : > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-toolkit/0.2.0/rc-01/ > > > > > > > > > > Staging Repository : > > > > > > > > > > > > > > > https://repository.apache.org/content/repositories/orgapacheservicecomb-1409 > > > > > > > > > > Release Tag : > > > > > https://github.com/apache/servicecomb-toolkit/releases/tag/0.2.0 > > > > > > > > > > Release CommitID : e95ba3c7b27673ee4e360d64cc1ccce43f70f18e > > > > > > > > > > Release Notes : > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346158 > > > > > > > > > > Keys to verify the Release Candidate : > > > > > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > > > > > > > > > Voting will start now ( Friday, 6nd Dec, 2019) and will remain open > > for > > > > > at-least 72 hours, Request all PMC members to give their vote. > > > > > > > > > > [ ] +1 Release this package as 0.2.0 > > > > > [ ] +0 No Opinion > > > > > [ ] -1 Do not release this package because > > > > > > > > > > On the behalf of ServiceComb Team > > > > > > > > > > > > > > > Wishes & Regards > > > > > --- > > > > > Mabin > > > > > > > > > > -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [VOTE] Release Apache ServiceComb Toolkit version 0.2.0
+1 1. Maven build passed: mvn clean install -Pjacoco 2. SHA512 signature checked 3. PGP signature checked Bin Ma 于2019年12月6日周五 上午9:09写道： > > Hi All, > > This is a call for Vote to release Apache ServiceComb Toolkit version 0.2.0 > > > Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-toolkit/0.2.0/rc-01/ > > Staging Repository : > https://repository.apache.org/content/repositories/orgapacheservicecomb-1409 > > Release Tag : > https://github.com/apache/servicecomb-toolkit/releases/tag/0.2.0 > > Release CommitID : e95ba3c7b27673ee4e360d64cc1ccce43f70f18e > > Release Notes : > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321626=12346158 > > Keys to verify the Release Candidate : > https://dist.apache.org/repos/dist/dev/servicecomb/KEYS > > Voting will start now ( Friday, 6nd Dec, 2019) and will remain open for > at-least 72 hours, Request all PMC members to give their vote. > > [ ] +1 Release this package as 0.2.0 > [ ] +0 No Opinion > [ ] -1 Do not release this package because > > On the behalf of ServiceComb Team > > > Wishes & Regards > --- > Mabin -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION][Toolkit] Prepare to release 0.2.0
Hi Ma, would you like to point out which part doesn't match? Bin Ma 于2019年11月27日周三 下午2:53写道： > > I checked servicecomb-toolkit README[1] and found that it is not match with > the latest code. > I think we can start a vote for 0.2.0 release after the README is updated. > > [1] <https://github.com/apache/servicecomb-toolkit> > https://github.com/apache/servicecomb-toolkit/blob/master/README.md > https://github.com/apache/servicecomb-toolkit/blob/master/README-ZH.md > > > > Wishes & Regards > --- > Mabin > > > > > Shuo Chen 于2019年11月26日周二 下午3:54写道： > > > +1 looking forward to corresponding articles too > > > > Daniel Qian 于2019年11月26日周二 下午3:34写道： > > > > > +1 looking forward to toolkit 0.2.0 > > > > > > sen sun 于2019年11月26日周二 上午11:16写道： > > > > > > > > Hi toolkit team, > > > > > > > > We have developed many new features, I think it's time to release 0.2.0 > > > > Our new features are as follows: > > > > * oas-validator for compliance check > > > > * oas-validator for compatibility check > > > > * new oas-generator for generating contract from code > > > > * support openapi v3 > > > > * support generate springcloud microservice project > > > > * etc ... I may not list enough, I hope everyone can add what you > > know > > > > > > > > What do you think about releasing 0.2.0? > > > > > > > > If everyone agrees to release a new version, we may start to do some > > > work: > > > > * make sure the license is ok > > > > * make sure our features are complete > > > > * make sure our tests are complete > > > > * etc ... I may not list enough, I hope everyone can add what you know > > > > > > > > If not, maybe we need to discuss what needs to be done to get it to > > > release > > > > > > > > > > > > And I attach the information for reference. This is the roadmap for the > > > > previous community discussions： > > > > * > > > > > > > > > https://lists.apache.org/thread.html/5048ca4aa778b13952cefcd32ec25be24eb38eb8424f24c80340183b@%3Cdev.servicecomb.apache.org%3E > > > > > > > > Any ideas are welcome > > > > > > > > > > > > -- > > > Daniel Qian > > > Apache Committer(chanjarster) > > > blog：https://chanjarster.github.io > > > github：https://github.com/chanjarster > > > segmentfault: https://segmentfault.com/u/chanjarster > > > > > -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION][Toolkit] Prepare to release 0.2.0
+1 looking forward to toolkit 0.2.0 sen sun 于2019年11月26日周二 上午11:16写道： > > Hi toolkit team, > > We have developed many new features, I think it's time to release 0.2.0 > Our new features are as follows: > * oas-validator for compliance check > * oas-validator for compatibility check > * new oas-generator for generating contract from code > * support openapi v3 > * support generate springcloud microservice project > * etc ... I may not list enough, I hope everyone can add what you know > > What do you think about releasing 0.2.0? > > If everyone agrees to release a new version, we may start to do some work: > * make sure the license is ok > * make sure our features are complete > * make sure our tests are complete > * etc ... I may not list enough, I hope everyone can add what you know > > If not, maybe we need to discuss what needs to be done to get it to release > > > And I attach the information for reference. This is the roadmap for the > previous community discussions： > * > https://lists.apache.org/thread.html/5048ca4aa778b13952cefcd32ec25be24eb38eb8424f24c80340183b@%3Cdev.servicecomb.apache.org%3E > > Any ideas are welcome -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION] [Website] Add a link to the http://start.servicecomb.io/
+1 it's a good help Willem Jiang 于2019年11月20日周三 下午5:54写道： > > +1 for it. > We could add a page to specify the start website on servicecomb.apache.org. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Nov 20, 2019 at 4:43 PM victor chan wrote: > > > > http://start.servicecomb.io/ can help users easily use our projects, we > > should add an entrance on the official website to help users find it. > > Do you have any thoughts? -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION][Toolkit] Oas validator style check rule config file format
The yaml example I provided is too verbose, I wrote a properties file example: https://gist.github.com/chanjarster/1b15cb781fcc91e2cd293fcc2b1682d2#file-style-check-rules-properties Daniel Qian 于2019年11月15日周五 下午12:59写道： > > Hi toolkit team, > I'm working on SCB-1580[1] to make OAS style check configurable. > So we need a config file which can describe the check rules. > I created a config file example on gist[2], which is based on the oas > validator style check doc[3] > Any suggestions are welcome. > > [1] https://issues.apache.org/jira/projects/SCB/issues/SCB-1580 > [2] https://gist.github.com/chanjarster/1b15cb781fcc91e2cd293fcc2b1682d2 > [3] > https://github.com/apache/servicecomb-toolkit/blob/c0baf5dff7d408d414bd40238b6849302ecc5b55/oas-validator/README.md#style-check-rules > -- > Daniel Qian > Apache Committer(chanjarster) > blog：https://chanjarster.github.io > github：https://github.com/chanjarster > segmentfault: https://segmentfault.com/u/chanjarster -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION][Toolkit] Roadmap
The reasons why I suggest drop the Swagger 2.0 support are: 1. Some functions such as "contract compatibility checking" and "contract style checking" doesn't support Swagger 2.0, so that's weird we support Swagger 2.0 in some functions while don't support in other functions. 2. OpenAPI 3.0 growing and Swagger 2.0 will be replaced eventually If we really need to support Swagger 2.0, we can mark it deprecated and give plan on when to drop it entirely. About 0.2.0 release, I think we can release it now. Features could be implemented in afterward versions. sen sun 于2019年11月18日周一 上午9:44写道： > > This road map is very excellent. I agree with the above development route. > But for the "Scaffold code generation" feature, maybe we can keep the > compatibility with swagger2.0? > There are a lot of features to be implemented. > What features do we want to include in the next release (0.2.0)? > > Daniel Qian 于2019年11月17日周日 下午9:14写道： > > > Hi toolkit team, > > > > We had a short talk on wechat about what should we do next on Toolkit > > project. I think before we start we should have a discussion about the > > roadmap, because Toolkit is a project composed by different functions. > > > > Below are the main functions I can think of, and features can be > > categorized into one of them: > > > > 1. Scaffold code generation: generate scaffold code from contract > > file. Currently we support Swagger 2.0 and OpenAPI v3. > > 2. Contract generation: reverse-engineering generate contract from > > code. Currently we support Swagger 2.0 and OpenAPI v3. > > 3. Contract style checking: check contract style. Currently we support > > OpenAPI v3. > > 4. Contract compatibility checking: check whether new contract is > > compatible with the old. Currently we support OpenAPI v3. > > 5. Server side code match checking: check whether server code, such as > > @Controller, @RequestMapping, etc, matches what are described in > > contract. Already implemented, but it's based on text diff not based > > on semantics, I think there are some limitations. > > 6. Client side code match checking: check whether client code matches > > what are described in contract. Maybe we can check the client written > > in Feign. Not implemented yet. > > 7. Service side auto/semi-auto testing: auto or semi-auto generate > > legal and illegal request payloads to test whether server response > > what are described in contract. Not implemented yet. > > 8. Mock server: to help client code do unit or integration testing, > > the key is the mock server should do every request validations that > > are described in the contract and responses' schema match the > > contract. Not implemented yet. > > 9. Documentation generation: generate various documentation format > > from contract, such as docx, pdf, html, markdown, etc. Not implemented > > yet. > > 10. Helpful tools based on above functions: such as cli, maven plugin, > > gradle plugin, eclipse plugin, intellij plugin. Partially implemented. > > > > Besides, should we still supporting Swagger 2.0? I think we should > > move on to OpenAPI 3.0. > > > > Any ideas are welcome. > > > > -- > > Daniel Qian > > Apache Committer(chanjarster) > > blog：https://chanjarster.github.io > > github：https://github.com/chanjarster > > segmentfault: https://segmentfault.com/u/chanjarster > > -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION][Toolkit] toolkit-maven-plugin integrate oas-validator
+1, I've considered the integration but I found that the current plugin configuration is a little confusing to me. It tries to do different works by different parameter values and on/off different parameters, it's a little complex and easy to misuse. See this: https://github.com/apache/servicecomb-toolkit#321-configuration Considering we will integrates more functions in the future, we should find a more easy and less misuse way to configure plugin. Besides, I created SCB-1552[1] SCB-1554[1] before for oas-validator integration work. [1] https://issues.apache.org/jira/browse/SCB-1552 [2] https://issues.apache.org/jira/browse/SCB-1554 Willem Jiang 于2019年11月18日周一 上午8:32写道： > > +1， we could provide bunch of tools around the core function module. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, Nov 18, 2019 at 12:13 AM sen sun wrote: > > > > Hi toolkit team, > > > > We now have the oas-validator module. It is a very good module. > > It has two main functions: the contract style check and contract > > compatibility check. > > I think it can be integrated into toolkit-maven-plugin in order to take > > advantage of it. > > > > What do you think? -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
[DISCUSSION][Toolkit] Roadmap
Hi toolkit team, We had a short talk on wechat about what should we do next on Toolkit project. I think before we start we should have a discussion about the roadmap, because Toolkit is a project composed by different functions. Below are the main functions I can think of, and features can be categorized into one of them: 1. Scaffold code generation: generate scaffold code from contract file. Currently we support Swagger 2.0 and OpenAPI v3. 2. Contract generation: reverse-engineering generate contract from code. Currently we support Swagger 2.0 and OpenAPI v3. 3. Contract style checking: check contract style. Currently we support OpenAPI v3. 4. Contract compatibility checking: check whether new contract is compatible with the old. Currently we support OpenAPI v3. 5. Server side code match checking: check whether server code, such as @Controller, @RequestMapping, etc, matches what are described in contract. Already implemented, but it's based on text diff not based on semantics, I think there are some limitations. 6. Client side code match checking: check whether client code matches what are described in contract. Maybe we can check the client written in Feign. Not implemented yet. 7. Service side auto/semi-auto testing: auto or semi-auto generate legal and illegal request payloads to test whether server response what are described in contract. Not implemented yet. 8. Mock server: to help client code do unit or integration testing, the key is the mock server should do every request validations that are described in the contract and responses' schema match the contract. Not implemented yet. 9. Documentation generation: generate various documentation format from contract, such as docx, pdf, html, markdown, etc. Not implemented yet. 10. Helpful tools based on above functions: such as cli, maven plugin, gradle plugin, eclipse plugin, intellij plugin. Partially implemented. Besides, should we still supporting Swagger 2.0? I think we should move on to OpenAPI 3.0. Any ideas are welcome. -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION] About the static check for the source code of ServiceComb-Java-Chassis
Hey guys, I've just integrates Toolkit and Pack project with SonarCloud, which provides static code analysis. In case you wanna do it with Java Chassis project too, here is the guide: http://servicecomb.apache.org/developers/sonarcloud-how-to/ yhs0092 于2019年7月9日周二 下午4:42写道： > > Yes, it's not so urgent. I'll wait until the weak-type branch get merged. > > > Yours sincerely > > > Yao Haishi > yhs0...@163.com > > > On 7/7/2019 20:37，wjm wjm wrote： > seems not too urgent? > > yhs0092 于2019年7月7日周日 下午12:04写道： > > There are 115 problems pointed out by CheckStyle. The problem distribution > is like below: > - service-registry: 69 > - spring-boot2-starter-servlet: 9 > - spring-boot2-starter-discovery: 1 > - spring-boot-common: 3 > - spring-boot-starter-registry: 1 > - spring-boot-starter-transport: 1 > - spring-cloud-zuul-zipkin: 3 > - spring-boot-starter-discovery: 1 > - foundation-common: 27 > > > The problems are mainly about the name of consts, the constructor of > utility classes, the length of lines, redundant modifiers and magic numbers. > Other problems scanned by findbugs is not counted here. To fix these > problems , there are too many files should be modified. I've created an > issue[1] to track it and wait the weak type work finished. > > > [1]: https://issues.apache.org/jira/browse/SCB-1354 > > > Yours sincerely > > > Yao Haishi > yhs0...@163.com > > > On 7/7/2019 09:03，Willem Jiang wrote： > Hi Haishi, > > Can you list the potential problems which you find? > If they are not the blocker issues, I think we can start to fix them > after the weak type work is finished. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sat, Jul 6, 2019 at 11:46 AM wjm wjm wrote: > > ohoh, lots of source files? maybe cause very difficult to merge weak type > branch? > > yhs0092 于2019年7月5日周五 下午7:43写道： > > Hi, guys. I've run code static checks for the source code of > ServiceComb-Java-Chassis and find several potential problems. > I want to raise an issue to fix these problems. The changes may be > distributed among a lot of source code files and they are all for code > style and complexity improvement. > Cause I've never handle such kind of issues, is there any thing I should > be aware of? > > > Yours sincerely > > > Yao Haishi > yhs0...@163.com > > > -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [ANN] ServiceComb Toolkit integrates with SonarCloud.io
Sure, no problem. Willem Jiang 于2019年11月15日周五 下午4:01写道： > > Cool, thanks for Daniel's help to setup the SonarCloud。 > I think we need to move on the other servicecomb subprojects. > Let's start from ServiceComb-Pack. @Daniel Qian Do you mind help us to do > that? > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Nov 15, 2019 at 3:36 PM Daniel Qian wrote: > > > > Hi Toolkit team and all, > > > > I've finished the ServiceComb Toolkit project's SonarCloud.io > > integration work[1]. > > The SonarCloud project page could be found here[2]. > > > > SonarQube is a very useful static code analysis tools, it can find > > potential bugs and provide code quality reports. > > > > I start this thread in case any one would like to integrates > > SonarCloud too. Below are some references: > > > > 1. How Apache project use SonarCloud[3] > > 2. Jira for create ServiceComb Toolkit Project in SonarCloud[4] > > 3. Travis CI configuration could be found at ServiceComb Toolkit repo[5] > > > > Notice: travis doesn't support SonarCloud in PR build so you need some > > work in your build script, there is an example here[6]. > > > > Last but not least, I suggest every contributors and committers login > > to SonarCloud, so that it can automatically assign issues to you. > > > > [1] https://issues.apache.org/jira/projects/SCB/issues/SCB-1591 > > [2] https://sonarcloud.io/dashboard?id=servicecomb-toolkit > > [3] https://cwiki.apache.org/confluence/display/INFRA/SonarQube+Analysis > > [4] https://issues.apache.org/jira/browse/INFRA-19425 > > [5] https://github.com/apache/servicecomb-toolkit/ > > [6] > > https://github.com/apache/servicecomb-toolkit/blob/master/scripts/test.sh > > > > -- > > Daniel Qian > > Apache Committer(chanjarster) > > blog：https://chanjarster.github.io > > github：https://github.com/chanjarster > > segmentfault: https://segmentfault.com/u/chanjarster -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
[ANN] ServiceComb Toolkit integrates with SonarCloud.io
Hi Toolkit team and all, I've finished the ServiceComb Toolkit project's SonarCloud.io integration work[1]. The SonarCloud project page could be found here[2]. SonarQube is a very useful static code analysis tools, it can find potential bugs and provide code quality reports. I start this thread in case any one would like to integrates SonarCloud too. Below are some references: 1. How Apache project use SonarCloud[3] 2. Jira for create ServiceComb Toolkit Project in SonarCloud[4] 3. Travis CI configuration could be found at ServiceComb Toolkit repo[5] Notice: travis doesn't support SonarCloud in PR build so you need some work in your build script, there is an example here[6]. Last but not least, I suggest every contributors and committers login to SonarCloud, so that it can automatically assign issues to you. [1] https://issues.apache.org/jira/projects/SCB/issues/SCB-1591 [2] https://sonarcloud.io/dashboard?id=servicecomb-toolkit [3] https://cwiki.apache.org/confluence/display/INFRA/SonarQube+Analysis [4] https://issues.apache.org/jira/browse/INFRA-19425 [5] https://github.com/apache/servicecomb-toolkit/ [6] https://github.com/apache/servicecomb-toolkit/blob/master/scripts/test.sh -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
[DISCUSSION][Toolkit] Oas validator style check rule config file format
Hi toolkit team, I'm working on SCB-1580[1] to make OAS style check configurable. So we need a config file which can describe the check rules. I created a config file example on gist[2], which is based on the oas validator style check doc[3] Any suggestions are welcome. [1] https://issues.apache.org/jira/projects/SCB/issues/SCB-1580 [2] https://gist.github.com/chanjarster/1b15cb781fcc91e2cd293fcc2b1682d2 [3] https://github.com/apache/servicecomb-toolkit/blob/c0baf5dff7d408d414bd40238b6849302ecc5b55/oas-validator/README.md#style-check-rules -- Daniel Qian Apache Committer(chanjarster) blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [ANN] New ServiceComb committer: Daniel Qian (钱嘉）
Thank you guys, it's an honor to be an Apache committer, let's make ServiceComb better together. Liubao (A) 于2019年11月8日周五 上午8:57写道： > > Welcome Qian. > > -邮件原件- > 发件人: Lei Zhang [mailto:zhang...@apache.org] > 发送时间: 2019年11月8日 8:54 > 收件人: dev@servicecomb.apache.org > 主题: Re: [ANN] New ServiceComb committer: Daniel Qian (钱嘉） > > Congratulations!!! > > 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. > > -- Daniel Qian blog：https://chanjarster.github.io github：https://github.com/chanjarster segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION][Toolkit] Integrate oas-validator compability check functionality
Hi Ma, what I have done is:
1. 3rd-party LICENSE information is merged
2. connect the pom.xml together so it can be built from project root dir
3. check style functionality he integrated into cli
So from the perspective of building and distribution, it's been integrated.
But from the perspective of functionality, it's not finished yet.
So if we don't care about the functionality, I think it's good to go.
BTW, merge as early as possible is a good idea to avoid future merge conflicts
Bin Ma 于2019年11月6日周三 下午8:15写道：
>
> I found that the integration work has been completed and merged,
> so I think we can start to merge the import-oas-validator branch to
> master.
>
> Any thoughts？
>
>
> Wishes & Regards
> -------
> Mabin
>
>
>
> Daniel Qian 于2019年11月5日周二 下午1:39写道：
>
> > Hi Ma, got it.
> >
> > Bin Ma 于2019年11月5日周二 上午11:19写道：
> > >
> > > Hi Daniel,
> > >
> > > Sorry, I misread the question.
> > >
> > > I think it's better to support both checkcompatibility and cc as
> > > subcommands.
> > >
> > > Wishes & Regards
> > > ---
> > > Mabin
> > >
> > >
> > >
> > > sen sun 于2019年11月5日周二 上午9:40写道：
> > >
> > > > I think Ma just made an example of the option naming style instead of
> > the
> > > > subcommand.
> > > > I think it's a good idea to support both checkcompatibility and cc as
> > > > subcommands.
> > > >
> > > > Daniel Qian 于2019年11月5日周二 上午7:28写道：
> > > >
> > > > > Hello Ma, found current cli style is .
> > > > > So if we do --check-compatability then which subcommand should we
> > use?
> > > > >
> > > > > Bin Ma 于2019年11月5日周二 上午12:44写道：
> > > > > >
> > > > > > I recommend keeping the same as the current option naming style,
> > > > > > such as "-c", "-- check-compability "
> > > > > >
> > > > > >
> > > > > > Wishes & Regards
> > > > > > ---
> > > > > > Mabin
> > > > > >
> > > > > >
> > > > > >
> > > > > > Willem Jiang 于2019年11月1日周五 下午12:31写道：
> > > > > >
> > > > > > > I think we can support checkcompatibility and the short one cc
> > at the
> > > > > same
> > > > > > > time.
> > > > > > > Any thoughts?
> > > > > > >
> > > > > > > Willem Jiang
> > > > > > >
> > > > > > > Twitter: willemjiang
> > > > > > > Weibo: 姜宁willem
> > > > > > >
> > > > > > > On Wed, Oct 30, 2019 at 10:37 AM Daniel Qian <
> > chanjars...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > I created an issue SCB-1555[1] to integrate oas-validator
> > > > > > > > compatibility check to toolkit cli.
> > > > > > > >
> > > > > > > > I suggest usage like this:
> > > > > > > > java -jar toolkit-cli-{version}.jar checkcompability
> > > > > > > > /path/to/openapiv3-1.yaml /path/to/openapiv3-2.yaml
> > > > > > > >
> > > > > > > > But the subcommand checkcompability is too long, maybe we can
> > use a
> > > > > > > > abbr for it, such as cc?
> > > > > > > >
> > > > > > > > Any ideas?
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/SCB-1555
> > > > > > > > [2]
> > > > > > >
> > > > >
> > > >
> > https://github.com/apache/servicecomb-toolkit/blob/import-oas-validator/oas-validator/README.md#%E5%85%BC%E5%AE%B9%E6%80%A7%E6%A3%80%E6%9F%A5
> > > > > > > >
> > > > > > > > --
> > > > > > > > Daniel Qian
> > > > > > > >
> > > > > > > > 博客：https://segmentfault.com/u/chanjarster
> > > > > > > > github：https://github.com/chanjarster
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daniel Qian
> > > > >
> > > > > 博客：https://segmentfault.com/u/chanjarster
> > > > > github：https://github.com/chanjarster
> > > > >
> > > >
> >
> >
> >
> > --
> > Daniel Qian
> >
> > 博客：https://segmentfault.com/u/chanjarster
> > github：https://github.com/chanjarster
> >
--
Daniel Qian
blog：https://chanjarster.github.io
github：https://github.com/chanjarster
segmentfault: https://segmentfault.com/u/chanjarster
Re: [DISCUSSION] Suggestion about migrate to travis-pro
Got it, then let's continue to use travis. Willem Jiang 于2019年11月6日周三 下午2:07写道： > > Current we don't have the right (Infra Admin have the github admin > right) update the travis setting. > I heard that Apache pay for travis for current Apache group, and there > are hundreds project in this group. > > We may consider to use jenkins that Apache provide here[1] > > [1]https://builds.apache.org/ > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Nov 6, 2019 at 1:39 PM Daniel Qian wrote: > > > > Hi all, > > Recently I'm working on integrating oas-validator to servicecomb > > toolkit project, and created some PR for it. > > I found that the build process triggered by travis-ci.org is slow, > > there is often a long lag between the job received and job actually > > running. > > May be we can migrate to travis-pro[1], it's also free for open source > > project [2] and provide 3 concurrent jobs. > > And here is a blog about how to migrate to travis-pro [3] > > > > > > [1] https://travis-ci.com/ > > [2] https://travis-ci.com/plans > > [3] > > https://blog.travis-ci.com/2018-05-02-open-source-projects-on-travis-ci-com-with-github-apps > > > > -- > > Daniel Qian > > > > 博客：https://segmentfault.com/u/chanjarster > > github：https://github.com/chanjarster -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
[DISCUSSION] Suggestion about migrate to travis-pro
Hi all, Recently I'm working on integrating oas-validator to servicecomb toolkit project, and created some PR for it. I found that the build process triggered by travis-ci.org is slow, there is often a long lag between the job received and job actually running. May be we can migrate to travis-pro[1], it's also free for open source project [2] and provide 3 concurrent jobs. And here is a blog about how to migrate to travis-pro [3] [1] https://travis-ci.com/ [2] https://travis-ci.com/plans [3] https://blog.travis-ci.com/2018-05-02-open-source-projects-on-travis-ci-com-with-github-apps -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Re: [DISCUSSION][Toolkit] Integrate oas-validator compliance functionality
Hi Ma, since we discussed about compatibility check sub command to be:
cc / checkcompatibility .[1]
So, we can also use cs / checkstyle here.
[1]:
https://lists.apache.org/thread.html/c88cda03ec52182482679bd9be36b9ad57bc8d03ee43a4912ad38d90@%3Cdev.servicecomb.apache.org%3E
Daniel Qian 于2019年11月1日周五 下午5:11写道：
>
> PR[1] created
>
> [1] https://github.com/apache/servicecomb-toolkit/pull/42
>
> Willem Jiang 于2019年11月1日周五 下午12:26写道：
> >
> > Hi Daniel
> >
> > Yeah, I think it's a very good idea.
> > Looking forward your PR.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Oct 30, 2019 at 10:31 AM Daniel Qian wrote:
> > >
> > > I created an issue SCB-1553[1] to integrate oas-validator compliance
> > > check to toolkit cli.
> > >
> > > I suggest the usage like this:
> > >
> > > java -jar toolkit-cli-{version}.jar checkstyle /path/to/openapiv3.yaml
> > >
> > > I prefer checksytle because of it's clearer than compliance.
> > >
> > > oas-validator compliance doc could be found here[2]
> > >
> > > [1] https://issues.apache.org/jira/projects/SCB/issues/SCB-1553
> > > [2]
> > > https://github.com/apache/servicecomb-toolkit/blob/import-oas-validator/oas-validator/README.md#%E5%90%88%E8%A7%84%E6%80%A7%E6%A0%A1%E9%AA%8C
> > >
> > > --
> > > Daniel Qian
> > >
> > > 博客：https://segmentfault.com/u/chanjarster
> > > github：https://github.com/chanjarster
>
>
>
> --
> Daniel Qian
>
> 博客：https://segmentfault.com/u/chanjarster
> github：https://github.com/chanjarster
--
Daniel Qian
博客：https://segmentfault.com/u/chanjarster
github：https://github.com/chanjarster
Re: [DISCUSSION][Toolkit] Integrate oas-validator compability check functionality
Hi Ma, got it.
Bin Ma 于2019年11月5日周二 上午11:19写道：
>
> Hi Daniel,
>
> Sorry, I misread the question.
>
> I think it's better to support both checkcompatibility and cc as
> subcommands.
>
> Wishes & Regards
> ---
> Mabin
>
>
>
> sen sun 于2019年11月5日周二 上午9:40写道：
>
> > I think Ma just made an example of the option naming style instead of the
> > subcommand.
> > I think it's a good idea to support both checkcompatibility and cc as
> > subcommands.
> >
> > Daniel Qian 于2019年11月5日周二 上午7:28写道：
> >
> > > Hello Ma, found current cli style is .
> > > So if we do --check-compatability then which subcommand should we use?
> > >
> > > Bin Ma 于2019年11月5日周二 上午12:44写道：
> > > >
> > > > I recommend keeping the same as the current option naming style,
> > > > such as "-c", "-- check-compability "
> > > >
> > > >
> > > > Wishes & Regards
> > > > ---
> > > > Mabin
> > > >
> > > >
> > > >
> > > > Willem Jiang 于2019年11月1日周五 下午12:31写道：
> > > >
> > > > > I think we can support checkcompatibility and the short one cc at the
> > > same
> > > > > time.
> > > > > Any thoughts?
> > > > >
> > > > > Willem Jiang
> > > > >
> > > > > Twitter: willemjiang
> > > > > Weibo: 姜宁willem
> > > > >
> > > > > On Wed, Oct 30, 2019 at 10:37 AM Daniel Qian
> > > > > wrote:
> > > > > >
> > > > > > I created an issue SCB-1555[1] to integrate oas-validator
> > > > > > compatibility check to toolkit cli.
> > > > > >
> > > > > > I suggest usage like this:
> > > > > > java -jar toolkit-cli-{version}.jar checkcompability
> > > > > > /path/to/openapiv3-1.yaml /path/to/openapiv3-2.yaml
> > > > > >
> > > > > > But the subcommand checkcompability is too long, maybe we can use a
> > > > > > abbr for it, such as cc?
> > > > > >
> > > > > > Any ideas?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/SCB-1555
> > > > > > [2]
> > > > >
> > >
> > https://github.com/apache/servicecomb-toolkit/blob/import-oas-validator/oas-validator/README.md#%E5%85%BC%E5%AE%B9%E6%80%A7%E6%A3%80%E6%9F%A5
> > > > > >
> > > > > > --
> > > > > > Daniel Qian
> > > > > >
> > > > > > 博客：https://segmentfault.com/u/chanjarster
> > > > > > github：https://github.com/chanjarster
> > > > >
> > >
> > >
> > >
> > > --
> > > Daniel Qian
> > >
> > > 博客：https://segmentfault.com/u/chanjarster
> > > github：https://github.com/chanjarster
> > >
> >
--
Daniel Qian
博客：https://segmentfault.com/u/chanjarster
github：https://github.com/chanjarster
Re: [DISCUSSION][Toolkit] Integrate oas-validator compability check functionality
Hello Ma, found current cli style is .
So if we do --check-compatability then which subcommand should we use?
Bin Ma 于2019年11月5日周二 上午12:44写道：
>
> I recommend keeping the same as the current option naming style,
> such as "-c", "-- check-compability "
>
>
> Wishes & Regards
> ---
> Mabin
>
>
>
> Willem Jiang 于2019年11月1日周五 下午12:31写道：
>
> > I think we can support checkcompatibility and the short one cc at the same
> > time.
> > Any thoughts?
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Wed, Oct 30, 2019 at 10:37 AM Daniel Qian
> > wrote:
> > >
> > > I created an issue SCB-1555[1] to integrate oas-validator
> > > compatibility check to toolkit cli.
> > >
> > > I suggest usage like this:
> > > java -jar toolkit-cli-{version}.jar checkcompability
> > > /path/to/openapiv3-1.yaml /path/to/openapiv3-2.yaml
> > >
> > > But the subcommand checkcompability is too long, maybe we can use a
> > > abbr for it, such as cc?
> > >
> > > Any ideas?
> > >
> > > [1] https://issues.apache.org/jira/browse/SCB-1555
> > > [2]
> > https://github.com/apache/servicecomb-toolkit/blob/import-oas-validator/oas-validator/README.md#%E5%85%BC%E5%AE%B9%E6%80%A7%E6%A3%80%E6%9F%A5
> > >
> > > --
> > > Daniel Qian
> > >
> > > 博客：https://segmentfault.com/u/chanjarster
> > > github：https://github.com/chanjarster
> >
--
Daniel Qian
博客：https://segmentfault.com/u/chanjarster
github：https://github.com/chanjarster
Re: [DISCUSSION][Toolkit] Integrate oas-validator compliance functionality
PR[1] created
[1] https://github.com/apache/servicecomb-toolkit/pull/42
Willem Jiang 于2019年11月1日周五 下午12:26写道：
>
> Hi Daniel
>
> Yeah, I think it's a very good idea.
> Looking forward your PR.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, Oct 30, 2019 at 10:31 AM Daniel Qian wrote:
> >
> > I created an issue SCB-1553[1] to integrate oas-validator compliance
> > check to toolkit cli.
> >
> > I suggest the usage like this:
> >
> > java -jar toolkit-cli-{version}.jar checkstyle /path/to/openapiv3.yaml
> >
> > I prefer checksytle because of it's clearer than compliance.
> >
> > oas-validator compliance doc could be found here[2]
> >
> > [1] https://issues.apache.org/jira/projects/SCB/issues/SCB-1553
> > [2]
> > https://github.com/apache/servicecomb-toolkit/blob/import-oas-validator/oas-validator/README.md#%E5%90%88%E8%A7%84%E6%80%A7%E6%A0%A1%E9%AA%8C
> >
> > --
> > Daniel Qian
> >
> > 博客：https://segmentfault.com/u/chanjarster
> > github：https://github.com/chanjarster
--
Daniel Qian
博客：https://segmentfault.com/u/chanjarster
github：https://github.com/chanjarster
[DISCUSSION][Toolkit] Integrate oas-validator compability check functionality
I created an issue SCB-1555[1] to integrate oas-validator
compatibility check to toolkit cli.
I suggest usage like this:
java -jar toolkit-cli-{version}.jar checkcompability
/path/to/openapiv3-1.yaml /path/to/openapiv3-2.yaml
But the subcommand checkcompability is too long, maybe we can use a
abbr for it, such as cc?
Any ideas?
[1] https://issues.apache.org/jira/browse/SCB-1555
[2]
https://github.com/apache/servicecomb-toolkit/blob/import-oas-validator/oas-validator/README.md#%E5%85%BC%E5%AE%B9%E6%80%A7%E6%A3%80%E6%9F%A5
--
Daniel Qian
博客：https://segmentfault.com/u/chanjarster
github：https://github.com/chanjarster
[DISCUSSION][Toolkit] Integrate oas-validator compliance functionality
I created an issue SCB-1553[1] to integrate oas-validator compliance
check to toolkit cli.
I suggest the usage like this:
java -jar toolkit-cli-{version}.jar checkstyle /path/to/openapiv3.yaml
I prefer checksytle because of it's clearer than compliance.
oas-validator compliance doc could be found here[2]
[1] https://issues.apache.org/jira/projects/SCB/issues/SCB-1553
[2]
https://github.com/apache/servicecomb-toolkit/blob/import-oas-validator/oas-validator/README.md#%E5%90%88%E8%A7%84%E6%80%A7%E6%A0%A1%E9%AA%8C
--
Daniel Qian
博客：https://segmentfault.com/u/chanjarster
github：https://github.com/chanjarster
Re: [DISCUSSION] How to import oas-validator to toolkit project
Ok, let's do option 2. Please tell me when the branch is created, so I can make a PR for it, is suggest the branch name be import-oas-validator Willem Jiang 于2019年10月29日周二 上午8:10写道： > > +1 for Option2. > Option 2 is much better, as it won't block the development of the > master branch. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Mon, Oct 28, 2019 at 2:24 PM Daniel Qian wrote: > > > > Since oas-validator donation process is finished (see this [1]) so > > next is to decide how to import oas-validator code into toolkit > > project. > > > > IMO, the first thing is merging the code ASAP, after that we will > > discuss how to integrating. > > > > I have two options: > > > > 1. Unzip the code archive and create a directory for it, push it to > > toolkit master branch > > 2. Create a branch on toolkit repo, unzip the code archive and create > > a directory for it, push it to that branch, after integration finished > > merge that branch to master > > > > Any ideas? > > > > [1] https://issues.apache.org/jira/browse/INCUBATOR-247 > > > > > > -- > > Daniel Qian > > > > 博客：https://segmentfault.com/u/chanjarster > > github：https://github.com/chanjarster -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Re: [VOTE] Accept oas-validator to ServiceComb
Maybe that will be another discussion after donating. Currently IMO, it could be integrated into toolkit maven plugin. Liubao (A) 于2019年10月15日周二 下午4:25写道： > > +1 > > It's a good tool to me. I'd prefer more information about how to integrate > this project to toolkit or how to use it in toolkit project is provided. > 发件人：Zhang Lei > 收件人：dev ;Willem Jiang > 时 间：2019-10-15 13:33:29 > 主 题：Re: [VOTE] Accept oas-validator to ServiceComb > > +1 > > > Best regards, > Lei Zhang > > 在 2019年10月15日 上午11:08:16, Willem Jiang (willem.ji...@gmail.com) 写到: > > 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 -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Re: [PROPOSAL] Donate oas-validator to toolkit project
Hi guys, I've changed package name and did some minor changes. Check this out: https://github.com/NewCapec-Institute/oas-validator/tree/apache Willem Jiang 于2019年10月11日周五 下午10:38写道： > > Yeah, once the vote is passed, you can go for the SGA part. > We also need to go through the IP clearance in the Apache Incubator. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Oct 11, 2019 at 8:36 PM Daniel Qian wrote: > > > > So I should sending the SGA next week after the voting? > > > > Willem Jiang 于2019年10月11日周五 下午6:09写道： > > > > > > You can start a vote next week if there is no any objections on the > > > donation. > > > I think you can change the pack name at the same time. > > > > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Fri, Oct 11, 2019 at 8:44 AM Daniel Qian wrote: > > > > > > > > Hi Willem, thanks for the reply. > > > > What should I do next? For now, I'm preparing the SGA for donating. > > > > Should I change the package name to org.apache.servicecomb.toolkit ? > > > > And then start a new VOTE thread in mail list? > > > > > > > > Willem Jiang 于2019年10月10日周四 下午6:41写道： > > > > > > > > > > It's great to hear from you about donating the osa-validator to Apache > > > > > ServiceComb toolkit. > > > > > As ServiceComb Java-Chassis and Toolkit leverages the OpenAPI to > > > > > manage the Restful service contract. > > > > > From my understanding, the osa-validator project could help the user > > > > > to use Open API from a tools perspective. > > > > > Here are the full feature description[1] of the osa-validator in this > > > > > thread for the other who doesn't know about it. > > > > > > > > > > Here is my big +1 for this proposal. > > > > > > > > > > I just have quick check of the code, the license headers are already > > > > > changed to Apache but the package name is not changed. > > > > > > > > > > I think we can start a vote in PMC to decide if we accept this > > > > > donation there is on any objection on this side. > > > > > > > > > > [1]https://github.com/NewCapec-Institute/oas-validator/blob/master/README.md > > > > > > > > > > > > > > > Willem Jiang > > > > > > > > > > Twitter: willemjiang > > > > > Weibo: 姜宁willem > > > > > > > > > > On Thu, Oct 10, 2019 at 1:20 PM Daniel Qian > > > > > wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > On 2019, Sept, I had some talk with Apache Servicecomb Willem Jiang > > > > > > and Ma Bin about > > > > > > Servicecomb Toolkit project and found that our project, > > > > > > oas-validator[1], has some similar > > > > > > ideas with Servicecomb Toolkit. > > > > > > > > > > > > oas-validator is a project aimed on validating OAS V3 spec yaml > > > > > > file, > > > > > > it has two features: > > > > > > compliance check or style check and compatibility check. > > > > > > > > > > > > More information can be found on project github repository. > > > > > > > > > > > > We would like to donate oas-validator source code to be as a part of > > > > > > Servicecomb Toolkit. > > > > > > > > > > > > [1]: https://github.com/NewCapec-Institute/oas-validator > > > > > > > > > > > > -- > > > > > > Daniel Qian > > > > > > > > > > > > 博客：https://segmentfault.com/u/chanjarster > > > > > > github：https://github.com/chanjarster > > > > > > > > > > > > > > > > -- > > > > Daniel Qian > > > > > > > > 博客：https://segmentfault.com/u/chanjarster > > > > github：https://github.com/chanjarster > > > > > > > > -- > > Daniel Qian > > > > 博客：https://segmentfault.com/u/chanjarster > > github：https://github.com/chanjarster -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Re: [PROPOSAL] Donate oas-validator to toolkit project
So I should sending the SGA next week after the voting? Willem Jiang 于2019年10月11日周五 下午6:09写道： > > You can start a vote next week if there is no any objections on the donation. > I think you can change the pack name at the same time. > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Fri, Oct 11, 2019 at 8:44 AM Daniel Qian wrote: > > > > Hi Willem, thanks for the reply. > > What should I do next? For now, I'm preparing the SGA for donating. > > Should I change the package name to org.apache.servicecomb.toolkit ? > > And then start a new VOTE thread in mail list? > > > > Willem Jiang 于2019年10月10日周四 下午6:41写道： > > > > > > It's great to hear from you about donating the osa-validator to Apache > > > ServiceComb toolkit. > > > As ServiceComb Java-Chassis and Toolkit leverages the OpenAPI to > > > manage the Restful service contract. > > > From my understanding, the osa-validator project could help the user > > > to use Open API from a tools perspective. > > > Here are the full feature description[1] of the osa-validator in this > > > thread for the other who doesn't know about it. > > > > > > Here is my big +1 for this proposal. > > > > > > I just have quick check of the code, the license headers are already > > > changed to Apache but the package name is not changed. > > > > > > I think we can start a vote in PMC to decide if we accept this > > > donation there is on any objection on this side. > > > > > > [1]https://github.com/NewCapec-Institute/oas-validator/blob/master/README.md > > > > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Thu, Oct 10, 2019 at 1:20 PM Daniel Qian wrote: > > > > > > > > Hi all, > > > > > > > > On 2019, Sept, I had some talk with Apache Servicecomb Willem Jiang > > > > and Ma Bin about > > > > Servicecomb Toolkit project and found that our project, > > > > oas-validator[1], has some similar > > > > ideas with Servicecomb Toolkit. > > > > > > > > oas-validator is a project aimed on validating OAS V3 spec yaml file, > > > > it has two features: > > > > compliance check or style check and compatibility check. > > > > > > > > More information can be found on project github repository. > > > > > > > > We would like to donate oas-validator source code to be as a part of > > > > Servicecomb Toolkit. > > > > > > > > [1]: https://github.com/NewCapec-Institute/oas-validator > > > > > > > > -- > > > > Daniel Qian > > > > > > > > 博客：https://segmentfault.com/u/chanjarster > > > > github：https://github.com/chanjarster > > > > > > > > -- > > Daniel Qian > > > > 博客：https://segmentfault.com/u/chanjarster > > github：https://github.com/chanjarster -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Re: [PROPOSAL] Donate oas-validator to toolkit project
Hi Willem, thanks for the reply. What should I do next? For now, I'm preparing the SGA for donating. Should I change the package name to org.apache.servicecomb.toolkit ? And then start a new VOTE thread in mail list? Willem Jiang 于2019年10月10日周四 下午6:41写道： > > It's great to hear from you about donating the osa-validator to Apache > ServiceComb toolkit. > As ServiceComb Java-Chassis and Toolkit leverages the OpenAPI to > manage the Restful service contract. > From my understanding, the osa-validator project could help the user > to use Open API from a tools perspective. > Here are the full feature description[1] of the osa-validator in this > thread for the other who doesn't know about it. > > Here is my big +1 for this proposal. > > I just have quick check of the code, the license headers are already > changed to Apache but the package name is not changed. > > I think we can start a vote in PMC to decide if we accept this > donation there is on any objection on this side. > > [1]https://github.com/NewCapec-Institute/oas-validator/blob/master/README.md > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Oct 10, 2019 at 1:20 PM Daniel Qian wrote: > > > > Hi all, > > > > On 2019, Sept, I had some talk with Apache Servicecomb Willem Jiang > > and Ma Bin about > > Servicecomb Toolkit project and found that our project, > > oas-validator[1], has some similar > > ideas with Servicecomb Toolkit. > > > > oas-validator is a project aimed on validating OAS V3 spec yaml file, > > it has two features: > > compliance check or style check and compatibility check. > > > > More information can be found on project github repository. > > > > We would like to donate oas-validator source code to be as a part of > > Servicecomb Toolkit. > > > > [1]: https://github.com/NewCapec-Institute/oas-validator > > > > -- > > Daniel Qian > > > > 博客：https://segmentfault.com/u/chanjarster > > github：https://github.com/chanjarster -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
[PROPOSAL] Donate oas-validator to toolkit project
Hi all, On 2019, Sept, I had some talk with Apache Servicecomb Willem Jiang and Ma Bin about Servicecomb Toolkit project and found that our project, oas-validator[1], has some similar ideas with Servicecomb Toolkit. oas-validator is a project aimed on validating OAS V3 spec yaml file, it has two features: compliance check or style check and compatibility check. More information can be found on project github repository. We would like to donate oas-validator source code to be as a part of Servicecomb Toolkit. [1]: https://github.com/NewCapec-Institute/oas-validator -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Re: [PROPOSAL] ServiceComb Toolkit Support OpenApi v3
@Willem Jiang I didn't found any announce that says " OAS V3 supports all features that V2 supports". But according to the following post from Swagger Blog: https://swagger.io/blog/news/whats-new-in-openapi-3-0/ I think it does. Willem Jiang 于2019年10月8日周二 上午11:21写道： > > I just have two quick questions for this change proposal: > Does Open API v3 still support all the features that v2 supports? > What's the status of the java-chassis supports of Open API v3? > > Regards, > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Oct 8, 2019 at 10:42 AM sen sun wrote: > > > > The current project based on OpenAPI v2, But The OpenAPI specification has > > now been updated to the v3 version, so we need to follow it by update our > > project. > > > > > > Regards -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Re: [VOTE] Release Apache ServiceComb Pack version 0.5.0
+1 1. Run demo with staging repo. 2. RC dist PGP signature checked. 3. RC dist SHA signature checked. Zheng Feng 于2019年8月25日周日 上午8:40写道： > > +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 > > -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Re: [DISCUSSION] Async support for Saga
stomer tells us about it through annotation.
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Tue, Jul 30, 2019 at 2:49 PM Zheng Feng wrote:
> > >>
> > >> 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)
Re: [DISCUSSION] Async support for Saga
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.
>
> Alpha based on Actor model has implemented asynchronous processing of Omega
> and Alpha, The event sent to Alpha needs to ensure that all child
> transactions have been executed before sending SagaEndedEvent or
> SagaAbortedEvent.
>
> Lei Zhang
>
> > 在 2019年7月20日，下午9:49，Daniel Qian 写道：
> >
> > 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. So any thoughts?
> > --
> > Daniel Qian
> >
> > 博客：https://segmentfault.com/u/chanjarster
> > github：https://github.com/chanjarster
>
--
Daniel Qian
博客：https://segmentfault.com/u/chanjarster
github：https://github.com/chanjarster
Re: [DISCUSSION] Async support for Saga
Hi Willem. I did some experiment on CompensationMessageHandler.
In first case, I send a delayed TxCompensatedEvent to simulate async
TxCompensated notification:
@Override
public void onReceive(final String globalTxId, final String localTxId,
final String parentTxId, final String compensationMethod,
Object... payloads) {
context.apply(globalTxId, localTxId, compensationMethod, payloads);
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1L);
} catch (InterruptedException e) {
e.printStackTrace();
}
sender.send(new TxCompensatedEvent(globalTxId, localTxId,
parentTxId, compensationMethod));
}
}).start();
}
I watched command table and found that compensation command status
PENDING -> DONE transition.
I also watched txevent table found SagaEnded correctly:
In second case, I just remove TxCompensatedEvent sending code:
@Override
public void onReceive(final String globalTxId, final String localTxId,
final String parentTxId, final String compensationMethod,
Object... payloads) {
context.apply(globalTxId, localTxId, compensationMethod, payloads);
}
In command table compensation command remains PENDING and in txevent
table no SagaEndedEvent happens.
Zheng Feng 于2019年7月24日周三 下午4:07写道：
>
> 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:
>
Re: [DISCUSSION] Async support for Saga
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 > > > > 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, > > > > > > an
Re: [DISCUSSION] Async support for Saga
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
> > > 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
Re: [DISCUSSION] Async support for Saga
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. So any thoughts?
> > --
> > Daniel Qian
> >
> > 博客：https://segmentfault.com/u/chanjarster
> > github：https://github.com/chanjarster
--
Daniel Qian
博客：https://segmentfault.com/u/chanjarster
github：https://github.com/chanjarster
[DISCUSSION] Async support for Saga
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. So any thoughts?
--
Daniel Qian
博客：https://segmentfault.com/u/chanjarster
github：https://github.com/chanjarster
Re: Discussion about SCB-668 reuse demo's docker-compose file to start acceptance test
Hi Jiang Thanks for the suggestion. If I'm not missing anything, for issue 3, that'll be acceptable to remove wait on tcp port part in the pom.xml. right? For issue 4 I think I can make use of compose file variable substitution [1] to solve this. I'll create another PR after PR for SCB-1335 [2] is merged. [1]: https://docs.docker.com/compose/compose-file/#variable-substitution [2]: https://github.com/apache/servicecomb-pack/pull/486 Willem Jiang 于2019年6月30日周日 下午4:13写道： > > Hi Daniel > > Thanks for the heads up of SCB-668. The original thought of SCB-668 > is reuse the docker compose file. > As you have mentioned there are some issues of the maven docker plugin > we need to get around with. > > For the issue1, we could upgrade the docker plugin version to get the > latest fix. > For the issue2, we could use the new version of docker-compose file, I > saw you already submit a PR[1] for it. > > For the issue3, I saw the issue you reported, I just want to point we > use the log and tcp port as the wait conditions, the docker maven > plugin will stop wait process if any condition is satisfied. > For the issue4, I checked the alpha-server application profile, the > test profile is used to export the restful service which could be used > to verify the alpha received the events. We need to enable the > profile when running the accept test. > If we can pass the parameter into the docker-compose file, we can use > different JAVA options for different scenarios. > > [1]https://github.com/apache/servicecomb-pack/pull/486 > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sun, Jun 30, 2019 at 1:48 PM Daniel Qian wrote: > > > > Hi guys, I'm working on [SCB-668 Using docker-compose file to start > > Services from docker plugin in the Accept test] and encounter some > > problems so I start this mail thread to discuss about them: > > > > Problem 1: > > > > There is a bug in fabric8 dmp plugin version 0.28.0 (currently used) : > > > > If you define the container using external docker-compose file [1], > > the number of containers it starts will be > containers> * , > > which simply means there will be multiple duplicated containers in a > > single docker:start run and cause failure. > > > > Problem 2: > > > > fabric8 dmp plugin doesn't support conditional depends_on, see this > > issue [2]. Furthermore, conditional depends_on was add in compose file > > version 2.1 [3] but removed in compose file version 3 [4] > > > > For example fabric8 dmp doesn't support this: > > > > depends_on: > > database: > > condition: service_healthy > > > > Only support this: > > > > depends_on: > > - database > > > > Problem 3: > > > > fabric8 dmp version >= 0.29.0 solved bug mentioned in problem 1, but > > the tcp wait on port always failing (see this issue [5]) > > > > Problem 4: > > > > Compose file overwrites configurations defined in dmp plugin. > > > > For example, alpha server JAVA_OPTS env variable in demo project is: > > JAVA_OPTS=-Dspring.profiles.active=prd > > > > In Acceptance Tests pom.xml is: > > -Dspring.profiles.active=prd,test > > > > As described in dmp doc [6], configuration is used as defaults > > and are overwritten by configuration defined in docker-compose file. > > That means the final effective profile only include prd, not prd and > > test. > > > > [1]: https://dmp.fabric8.io/#docker-compose > > [2]: https://github.com/fabric8io/docker-maven-plugin/issues/888 > > [3]: > > https://docs.docker.com/compose/compose-file/compose-file-v2/#depends_on > > [4]: https://docs.docker.com/compose/compose-file/#depends_on > > [5]: https://github.com/fabric8io/docker-maven-plugin/issues/1234 > > [6]: https://dmp.fabric8.io/#docker-compose > > > > -- > > Daniel Qian > > > > 博客：https://segmentfault.com/u/chanjarster > > github：https://github.com/chanjarster -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Discussion about SCB-668 reuse demo's docker-compose file to start acceptance test
Hi guys, I'm working on [SCB-668 Using docker-compose file to start Services from docker plugin in the Accept test] and encounter some problems so I start this mail thread to discuss about them: Problem 1: There is a bug in fabric8 dmp plugin version 0.28.0 (currently used) : If you define the container using external docker-compose file [1], the number of containers it starts will be * , which simply means there will be multiple duplicated containers in a single docker:start run and cause failure. Problem 2: fabric8 dmp plugin doesn't support conditional depends_on, see this issue [2]. Furthermore, conditional depends_on was add in compose file version 2.1 [3] but removed in compose file version 3 [4] For example fabric8 dmp doesn't support this: depends_on: database: condition: service_healthy Only support this: depends_on: - database Problem 3: fabric8 dmp version >= 0.29.0 solved bug mentioned in problem 1, but the tcp wait on port always failing (see this issue [5]) Problem 4: Compose file overwrites configurations defined in dmp plugin. For example, alpha server JAVA_OPTS env variable in demo project is: JAVA_OPTS=-Dspring.profiles.active=prd In Acceptance Tests pom.xml is: -Dspring.profiles.active=prd,test As described in dmp doc [6], configuration is used as defaults and are overwritten by configuration defined in docker-compose file. That means the final effective profile only include prd, not prd and test. [1]: https://dmp.fabric8.io/#docker-compose [2]: https://github.com/fabric8io/docker-maven-plugin/issues/888 [3]: https://docs.docker.com/compose/compose-file/compose-file-v2/#depends_on [4]: https://docs.docker.com/compose/compose-file/#depends_on [5]: https://github.com/fabric8io/docker-maven-plugin/issues/1234 [6]: https://dmp.fabric8.io/#docker-compose -- Daniel Qian 博客：https://segmentfault.com/u/chanjarster github：https://github.com/chanjarster
Re: [Discussion] compatible TCC support in Saga
;> > > and >> > > > remove the temporal table. If anything goes wrong, it can execute the >> > > > cancel method to remove the temporal table. In this way, if the >> global >> > > > transaction fails, it will take no effect on the actual table. >> Besides, >> > > > when a customer visits his/her balance, we can simply return the >> value >> > in >> > > > the actual table which is the original value before this transaction >> > > > executed. >> > > > Compensation: In try phase, use a temporal table to record the >> > > compensated >> > > > value and reduce the balance in the account. In commit phase, remove >> > the >> > > > temporal table. If anything goes wrong, it can execute the cancel >> > method >> > > > to recover the balance according to the temporal table and remove the >> > > > temporal table afterward. In this way, when a customer visits his/her >> > > > balance, we can do simple calculation of the value in actual table >> and >> > > > temporal table to return the origianl value before the transaction >> > > > executed. >> > > > >> > > > Within transaction ids in the table row, each create/update/delete >> > > > operation is idempotent and it simplies a lot of work to make sure >> > > > sub-transactions are idempotent. >> > > > >> > > > >> > > > Any other ideas or suggestions on the isolation support in Saga are >> > > > welcome. Thanks. >> > > > >> > > > >> > > > [1] https://lists.apache.org/list.html?dev@servicecomb.apach >> > > > e.org:lte=1M:a%20question%20about%20acid%20 >> > > > [2] http://design.inf.usi.ch/sites/default/files/biblio/rest-tcc.pdf >> > > > >> > > > >> > > > Best Regards! >> > > > Eric Lee >> > > > >> > > >> > >> -- Daniel Qian
Re: A question about ACID guarantees Saga provides
@Willem Jiang，多谢。我回头会试试看。 2018-03-14 22:46 GMT+08:00 Willem Jiang <willem.ji...@gmail.com>: > 首先应用App启动时候，如果版本信息（应用名 + 版本号）发生变化可以通过Omega通知Alpha。 > 这样就不不会出现版本执行错误的情况。 > > 对于你举的1.0 升级到 2.0 的情况可能需要通过优雅停机的方式来解决了。 > 因为App 1.0 可能会有多个实例， Alpha在执行回滚的过程中如果只通过Omega来回调的话很难解决实例突然终止的问题， > 我现在想到的办法是让Alpha直接调用App 1.0提供的恢复服务接口。 > 如果App1.0的服务接口是幂等的且无状态的话，那我们还是能够做到事务的最终一致。 > > > > > Willem Jiang > > Blog: http://willemjiang.blogspot.com (English) > http://jnn.iteye.com (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > On Wed, Mar 14, 2018 at 9:20 AM, Daniel Qian <chanjars...@gmail.com> wrote: > >> Thanks a lot, Willem Jiang, 关于Q7我举个例子来说明我的意思： >> >> App version 1.0 里的Saga是这样的：call methodA, call methodB >> App version 2.0 里的代码是这样的：call methodA, call methodC >> >> 把App从1.0 升级到 2.0必定需要将原1.0的App进程停止，然后启动2.0的App进程。 >> 在停止1.0的App进程的时候，可能会出现Saga只执行了一半。 >> >> 那么启动2.0的App进程之后，会出现以下哪种情况： >> >> 1. 1.0 App的未执行完成的Saga永远保持未完成状态 >> 2. 会Saga Alpha会尝试使用2.0App的代码，继续执行未完成Saga >> >> 2018-03-13 22:52 GMT+08:00 Willem Jiang <willem.ji...@gmail.com>: >> > Hi Dainiel >> > >> > Here are my answer to you question， we will write an english version for >> it >> > shortly. >> > >> > 1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？ >> > 目前Saga事情的执行是同步的，后续我们会提供异步方式的实现。 >> > >> > >> > 2. Saga是并行还是顺序执行Sub-transaction的？ >> > Saga pack 是根据调用的代码来决定Saga事件，如果Saga子事件是并行方式调用的， 那Saga协调器也是采用并行方式进行处理的。 >> > >> > 3. Saga对于do、compenstation的实现有什么要求？ >> > 对服务调用要求是要支持幂等的。 >> > >> > 4. Saga保证了A、C、I、D中的哪些部分？ >> > 按照前面的回复， Saga 支持 ACD。 >> > >> > 5. Saga可以嵌套吗？ >> > Saga实现支持子事件嵌套的方式。 >> > >> > 6. 如何水平扩展Saga Alpha？ >> > Saga Alpha在设计过程中状态信息都存储到数据库，是支持水平扩展的。 >> > >> > 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？ >> > Saga omega只是通过切面编程的方式获取Saga调用事件，并触发对应的处理流程。 >> > 我不太明白你说的Saga omega处的代码重构是什么意思？解释一下吗？ >> > >> > 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？ >> > Saga协调管理的的服务调用如果支持幂等， 调用过程完成后重启Saga协调器 Alpha之后，是可以支持Saga恢复的。 >> > >> > 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？ >> > 因为omega将记录Compensable标注的方法的调用参数来调用Compensable里面提供的补偿方法， 这些参数需要能够序列化。 >> > 目前对于SagaStart没有什么特别的要求， >> > >> > >> > Willem Jiang >> > >> > Blog: http://willemjiang.blogspot.com (English) >> > http://jnn.iteye.com (Chinese) >> > Twitter: willemjiang >> > Weibo: 姜宁willem >> > >> > On Tue, Mar 13, 2018 at 2:33 PM, Daniel Qian <chanjars...@gmail.com> >> wrote: >> > >> >> Hi Willem Jiang, thanks for your reply. >> >> >> >> I'd like to help listing a FAQ for this project, but for now, I can >> >> only provide Qs not As. Here is my Qs (sorry written in Chinese to >> >> avoid poor english obscure the meaning): >> >> >> >> 1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？ >> >> 2. Saga是并行还是顺序执行Sub-transaction的？ >> >> 3. Saga对于do、compenstation的实现有什么要求？ >> >> 4. Saga保证了A、C、I、D中的哪些部分？ >> >> 5. Saga可以嵌套吗？ >> >> 6. 如何水平扩展Saga Alpha？ >> >> 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？ >> >> 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？ >> >> 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？ >> >> >> >> Hi Zheng Feng, thanks for your reply, too. >> >> >> >> I watched Richardson's presentation >> >> (https://www.infoq.com/presentations/saga-microservices) and he talked >> >> about ACD: >> >> >> >> A：all sub-transaction are executed OR all are compensated >> >> C：local consistency is handled by service. cross-service consistency >> >> is handled by application >> >> D：durability is handled by local database >> >> >> >> These definitions are a little different from which defined in >> >> traditional transactions (https://en.wikipedia.org/wiki/ACID). >> >> >> >> So I think even though "traditional transaction" and "distributed >> >> transaction" are all called "transactions", but they are different >> >> things. >> >> >> >> Unlike traditional transaction ACID are guaranteed by techs such as JTA, >> >> XA. >> >> >> >> In distributed transactions(Saga, TCC, etc) ACD are guaranteed by >> >> serv
Re: A question about ACID guarantees Saga provides
Thanks a lot, Willem Jiang, 关于Q7我举个例子来说明我的意思： App version 1.0 里的Saga是这样的：call methodA, call methodB App version 2.0 里的代码是这样的：call methodA, call methodC 把App从1.0 升级到 2.0必定需要将原1.0的App进程停止，然后启动2.0的App进程。 在停止1.0的App进程的时候，可能会出现Saga只执行了一半。 那么启动2.0的App进程之后，会出现以下哪种情况： 1. 1.0 App的未执行完成的Saga永远保持未完成状态 2. 会Saga Alpha会尝试使用2.0App的代码，继续执行未完成Saga 2018-03-13 22:52 GMT+08:00 Willem Jiang <willem.ji...@gmail.com>: > Hi Dainiel > > Here are my answer to you question， we will write an english version for it > shortly. > > 1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？ > 目前Saga事情的执行是同步的，后续我们会提供异步方式的实现。 > > > 2. Saga是并行还是顺序执行Sub-transaction的？ > Saga pack 是根据调用的代码来决定Saga事件，如果Saga子事件是并行方式调用的， 那Saga协调器也是采用并行方式进行处理的。 > > 3. Saga对于do、compenstation的实现有什么要求？ > 对服务调用要求是要支持幂等的。 > > 4. Saga保证了A、C、I、D中的哪些部分？ > 按照前面的回复， Saga 支持 ACD。 > > 5. Saga可以嵌套吗？ > Saga实现支持子事件嵌套的方式。 > > 6. 如何水平扩展Saga Alpha？ > Saga Alpha在设计过程中状态信息都存储到数据库，是支持水平扩展的。 > > 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？ > Saga omega只是通过切面编程的方式获取Saga调用事件，并触发对应的处理流程。 > 我不太明白你说的Saga omega处的代码重构是什么意思？解释一下吗？ > > 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？ > Saga协调管理的的服务调用如果支持幂等， 调用过程完成后重启Saga协调器 Alpha之后，是可以支持Saga恢复的。 > > 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？ > 因为omega将记录Compensable标注的方法的调用参数来调用Compensable里面提供的补偿方法， 这些参数需要能够序列化。 > 目前对于SagaStart没有什么特别的要求， > > > Willem Jiang > > Blog: http://willemjiang.blogspot.com (English) > http://jnn.iteye.com (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Mar 13, 2018 at 2:33 PM, Daniel Qian <chanjars...@gmail.com> wrote: > >> Hi Willem Jiang, thanks for your reply. >> >> I'd like to help listing a FAQ for this project, but for now, I can >> only provide Qs not As. Here is my Qs (sorry written in Chinese to >> avoid poor english obscure the meaning): >> >> 1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？ >> 2. Saga是并行还是顺序执行Sub-transaction的？ >> 3. Saga对于do、compenstation的实现有什么要求？ >> 4. Saga保证了A、C、I、D中的哪些部分？ >> 5. Saga可以嵌套吗？ >> 6. 如何水平扩展Saga Alpha？ >> 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？ >> 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？ >> 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？ >> >> Hi Zheng Feng, thanks for your reply, too. >> >> I watched Richardson's presentation >> (https://www.infoq.com/presentations/saga-microservices) and he talked >> about ACD: >> >> A：all sub-transaction are executed OR all are compensated >> C：local consistency is handled by service. cross-service consistency >> is handled by application >> D：durability is handled by local database >> >> These definitions are a little different from which defined in >> traditional transactions (https://en.wikipedia.org/wiki/ACID). >> >> So I think even though "traditional transaction" and "distributed >> transaction" are all called "transactions", but they are different >> things. >> >> Unlike traditional transaction ACID are guaranteed by techs such as JTA, >> XA. >> >> In distributed transactions(Saga, TCC, etc) ACD are guaranteed by >> service/application code. >> >> So this ACID is not that ACID (此ACID非彼ACID), this transaction is not >> that transaction(此事务非彼事务). >> >> I think we can clarify that in the doc. >> >> 2018-03-12 18:05 GMT+08:00 Zheng Feng <zh.f...@gmail.com>: >> > Well, that could be an interesting question. I think it depends on how >> you >> > define what is "all or nothing". For a example of booking which is often >> > used in the Saga transaction. >> > The request of the user is that "WE HAVE TO BOOKING A FLIGHT PEK-SHA AND >> > TWO NIGHTS IN SHANGHAI HOTEL" >> > >> > 1. Start a Saga transaction >> > 2. booking a flight >> > 3. booking a hotel >> > 4a. ALL bookings are OK ( We get "all") >> > 4b. booking a hotel is failed, we have to compensate to cancel the flight >> > (We get "nothing") >> > 5. End a Saga transaction >> > >> > So from the user's perspective, they get "all or nothing" and from the >> > database it could have something changed ( the status of the flight >> booking >> > order). And I think this is why the Saga pattern relax the "ISOLATION" >> > attribute from the ACID. >> > >> > I hope it could be helpful for you to understand the Saga transaction. >> > >> > 2018-03-12 16:47 GMT+08:00 Daniel Qian <chanjars...@gmail.com>: >
Re: A question about ACID guarantees Saga provides
Hi Willem Jiang, thanks for your reply. I'd like to help listing a FAQ for this project, but for now, I can only provide Qs not As. Here is my Qs (sorry written in Chinese to avoid poor english obscure the meaning): 1. Saga的执行是同步的还是异步的？发起Saga之后，是等所有Sub-transaction都完成才返回，还是立即返回？ 2. Saga是并行还是顺序执行Sub-transaction的？ 3. Saga对于do、compenstation的实现有什么要求？ 4. Saga保证了A、C、I、D中的哪些部分？ 5. Saga可以嵌套吗？ 6. 如何水平扩展Saga Alpha？ 7. Saga omega 处的代码重构时需要注意什么，以保证不会破坏原Saga/还未执行完毕的Saga？ 8. Saga omega 在执行Saga过程中如果中断，那么重启后Saga还会继续执行吗？ 9. 对于@SagaStart，@Compensable注释的方法，对其方法参数有何要求？ Hi Zheng Feng, thanks for your reply, too. I watched Richardson's presentation (https://www.infoq.com/presentations/saga-microservices) and he talked about ACD: A：all sub-transaction are executed OR all are compensated C：local consistency is handled by service. cross-service consistency is handled by application D：durability is handled by local database These definitions are a little different from which defined in traditional transactions (https://en.wikipedia.org/wiki/ACID). So I think even though "traditional transaction" and "distributed transaction" are all called "transactions", but they are different things. Unlike traditional transaction ACID are guaranteed by techs such as JTA, XA. In distributed transactions(Saga, TCC, etc) ACD are guaranteed by service/application code. So this ACID is not that ACID (此ACID非彼ACID), this transaction is not that transaction(此事务非彼事务). I think we can clarify that in the doc. 2018-03-12 18:05 GMT+08:00 Zheng Feng <zh.f...@gmail.com>: > Well, that could be an interesting question. I think it depends on how you > define what is "all or nothing". For a example of booking which is often > used in the Saga transaction. > The request of the user is that "WE HAVE TO BOOKING A FLIGHT PEK-SHA AND > TWO NIGHTS IN SHANGHAI HOTEL" > > 1. Start a Saga transaction > 2. booking a flight > 3. booking a hotel > 4a. ALL bookings are OK ( We get "all") > 4b. booking a hotel is failed, we have to compensate to cancel the flight > (We get "nothing") > 5. End a Saga transaction > > So from the user's perspective, they get "all or nothing" and from the > database it could have something changed ( the status of the flight booking > order). And I think this is why the Saga pattern relax the "ISOLATION" > attribute from the ACID. > > I hope it could be helpful for you to understand the Saga transaction. > > 2018-03-12 16:47 GMT+08:00 Daniel Qian <chanjars...@gmail.com>: > >> Thanks for reply. >> >> I'll checkout refs you give. Saga project is really really lack of docs, >> hope you guys will work on that. >> >> And 1 more question. >> >> The wiki says Atomicity: >> >> > Atomicity requires that each transaction be **"all or nothing"**: if one >> part of the transaction fails, then the entire transaction fails, and the >> database state is left **unchanged**. >> >> I think the Saga's do-compensate pattern is not "all or nothing", database >> is not left "unchanged", there is actually something changed(ie. a canceled >> order) in database (saga event log database or microservice database). >> >> 2018-03-10 10:56 GMT+08:00 Eric Lee <eric.lee@gmail.com>: >> >> > Well, Saga actually provides guarantee of ACD. You can checkout Chris >> > Richardson's >> > latest talk of saga[1] for details. In the original saga paper[2], it >> > mentions that >> > >> > > At the outer level full atomicity is not provided. That is, sagas may >> > view >> > > the partial results of other sagas. >> > > >> > According to the ACID definition[3], it shows saga does not provide >> > isolation guarantee instead of atomicity as all sub transactions within a >> > global transaction is either done or compensated. >> > >> > For each global transaction, it will have both SagaStartedEvent and >> > SagaEndedEvent while for each sub transaction, it will have >> TxStartedEvent >> > and either TxEndedEvent or TxCompensatedEvent. If the global transaction >> > succeeds, saga guarantees that all sub transactions will have both >> > TxStartedEvent and TxEndedEvent. If the global transaction fails, saga >> > guarantees that all completed sub transactions are compensated and hence >> > have all of TxStartedEvent, TxEndedEvent, TxCompensatedEvent. In this >> way, >> > we can guarantee the consistency. >> > >> > Besides, the implementation of saga coordinator is stateless, all saga >> > event logs are stored in persistent stora
Re: A question about ACID guarantees Saga provides
Thanks for reply. I'll checkout refs you give. Saga project is really really lack of docs, hope you guys will work on that. And 1 more question. The wiki says Atomicity: > Atomicity requires that each transaction be **"all or nothing"**: if one part of the transaction fails, then the entire transaction fails, and the database state is left **unchanged**. I think the Saga's do-compensate pattern is not "all or nothing", database is not left "unchanged", there is actually something changed(ie. a canceled order) in database (saga event log database or microservice database). 2018-03-10 10:56 GMT+08:00 Eric Lee <eric.lee@gmail.com>: > Well, Saga actually provides guarantee of ACD. You can checkout Chris > Richardson's > latest talk of saga[1] for details. In the original saga paper[2], it > mentions that > > > At the outer level full atomicity is not provided. That is, sagas may > view > > the partial results of other sagas. > > > According to the ACID definition[3], it shows saga does not provide > isolation guarantee instead of atomicity as all sub transactions within a > global transaction is either done or compensated. > > For each global transaction, it will have both SagaStartedEvent and > SagaEndedEvent while for each sub transaction, it will have TxStartedEvent > and either TxEndedEvent or TxCompensatedEvent. If the global transaction > succeeds, saga guarantees that all sub transactions will have both > TxStartedEvent and TxEndedEvent. If the global transaction fails, saga > guarantees that all completed sub transactions are compensated and hence > have all of TxStartedEvent, TxEndedEvent, TxCompensatedEvent. In this way, > we can guarantee the consistency. > > Besides, the implementation of saga coordinator is stateless, all saga > event logs are stored in persistent storage. In this way, we can guarantee > the durability. > > BTW, we have refactored the saga lately. The architecture in the blog you > saw is outdated. You can checkout its latest implementation from [4]. If > you have any questions or advice for our new architecture, welcome to point > them out. > > [1] https://www.infoq.com/presentations/saga-microservices > [2] https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf > [3] https://en.wikipedia.org/wiki/ACID > [4] https://github.com/apache/incubator-servicecomb-saga > > > Best Regards! > Eric Lee > > 2018-03-09 15:59 GMT+08:00 Daniel Qian <chanjars...@gmail.com>: > > > Hello guys: > > > > I read the amazing blog "Eventual Data Consistency Solution in > ServiceComb > > - part 2" and I'm kind of confused about these two statements: > > > > > Saga does not provide ACID guarantee, because atomicity and isolation > are > > not satisfied > > > > > With durable saga log, saga guarantees consistency and durability > > > > I guess the first statement is talking about how so called "Transaction" > > behaves in **Saga pattern**. > > > > And the second statement is talking about the implementation of Saga's > > state store. But that's a little strange to say "Saga provides C and D > > because it's state store provides C and D". > > > > I think Saga pattern actually does not guarantee either of A, C, I or D. > Am > > I right? > > > > > > -- > > > > > > > > Daniel Qian > > > -- Daniel Qian
A question about ACID guarantees Saga provides
Hello guys: I read the amazing blog "Eventual Data Consistency Solution in ServiceComb - part 2" and I'm kind of confused about these two statements: > Saga does not provide ACID guarantee, because atomicity and isolation are not satisfied > With durable saga log, saga guarantees consistency and durability I guess the first statement is talking about how so called "Transaction" behaves in **Saga pattern**. And the second statement is talking about the implementation of Saga's state store. But that's a little strange to say "Saga provides C and D because it's state store provides C and D". I think Saga pattern actually does not guarantee either of A, C, I or D. Am I right? -- Daniel Qian
