Re: About alpha-fsm progress

[Zheng Feng]

Thanks Lei - it looks very very incredible for the performance results !
Also it could be very helpful to describe how the akka improves the
performance. I think it maybe related to the concurrency of the state
machine and persistence of the transaction status.

Looking forward to the new release of the sevicecomb-pack !

Zhang Lei  于2019年7月9日周二 下午10:10写道：

> Hi, all
>
> State machine-based Alpha improves performance by an order of magnitude. I
> have pushed Alpha's benchmark report [1] and added the stress test tool
> module alpha-benchmark [2].
> Next I will merge branch SCB-1321 to master branch.
>
> Any questions please tell me.
>
> [1]
> https://github.com/apache/servicecomb-pack/blob/SCB-1321/alpha/alpha-fsm/Benchmark.md
> <
> https://github.com/apache/servicecomb-pack/blob/SCB-1321/alpha/alpha-fsm/Benchmark.md
> >
> [2]
> https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-benchmark
> <
> https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-benchmark
> >
>
> Lei Zhang
>
> > 在 2019年7月9日，上午8:50，Willem Jiang  写道：
> >
> > Hi Zhanglei,
> >
> > I agree with you, in the timeout scenario, it's hard to tell if the
> > transaction is finished successfully or not.
> > I think we could provide an extension or plugin to let the user do
> > some extra actions to do the compensation work after verifying the
> > transaction states.
> >
> > BTW,  as there are some changes happening in the master, maybe you can
> > consider to merge the SCB-1321 branch to master branch.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Tue, Jul 9, 2019 at 8:21 AM Zhang Lei  wrote:
> >>
> >> Hi  All
> >>
> >> I have completed the acceptance test for the state machine and pushed
> to branch SCB-1321 and CI pass. See more feature progress here[1].
> >>
> >> In the acceptance test, the timeout is different from the previous one.
> When the timeout occurs, the transaction will enter the suspended state
> because we are not sure whether the sub-transaction is completed and when
> it is completed.
> >>
> >> For example:
> >> when booking timeout, we are not sure about the execution status of car
> or hotel. If car or hotel sends TxEndedEvent after compensation, they will
> not be compensated.
> >>
> >> Alpha
> >>  [x]  State machine design document
> >>  [x]  State machine prototype
> >>  [x]  State machine prototype unit test
> >>  [x]  Receive saga events using the internal message bus
> >>  [x]  State machine integration test
> >>  [x]  Enable state machine support via parameters
> >>  [x]  Verify Akka persistent
> >>  [ ]  Verify Akka cluster reliability
> >>  [ ]  Save the terminated transaction data to the database
> >>  [ ]  Support for in-process nested global transactions
> >>  [ ]  Support for cross-process nested global transactions
> >>  [ ]  Support for query terminated transaction data by RESTful API
> >>  [ ]  Support for query running transaction data by RESTful API
> >>  [ ]  Support for query running transaction data by RESTful API
> >>  [ ]  Support for query suspended global transaction by RESTful API
> >>  [ ]  Support for compensate failed sub-transaction by RESTful API
> >>
> >> Omega Components
> >>  [x]  Enable state machine support via parameters
> >>  [x]  State machine calls omega side compensation
> >>  [x]  @SagaStart supports thread termination after the timeout
> >>
> >> Alpha & Omega
> >>  [x]  Acceptance-pack-akka-spring-demo pass
> >>  [ ]  Add sub-transaction timeout exception for akka acceptance test
> >>  [ ]  Add compensation failure for akka acceptance test
> >>  [ ]  Add compensation retry success for akka acceptance test
> >>  [ ]  Alpha single node benchmark performance test
> >>  [ ]  Alpha cluster benchmark performance test
> >>
> >> Tools
> >>  [ ]  Alpha Benchmark tools
> >>
> >> Do Next:
> >> 1. State machine metrics collection
> >> 2. Alpha Benchmark tools
> >> 3. Single alpha benchmark performance test
> >> 4. Verify Akka cluster reliability
> >>
> >> [1]
> https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm <
> https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm>
> >>
> >> Lei Zhang
> >>
> >>
> >>> 在 2019年6月28日，下午5:50，Zhang Lei  写道：
> >>>
> >>> Hi, All
> >>>
> >>> alpha-fsm has been pushed to the branch SCB-1321
> >>>
> >>> Completed:
> >>> 1. State machine design document[1]
> >>> 2. State machine prototype
> >>> 3. State machine test case
> >>> 4. Receive saga events using the internal message bus
> >>>
> >>> Key emphasis of next stage in work:
> >>> In order to carry out the feasibility verification as soon as
> possible, I will not consider the reliability issue for the time being.
> >>> 1. Refactor Omega components, add SagaAbortedEvent, SagaTimeoutEvent,
> TxComponsitedEvent
> >>> 2. Save compensation method parameters in Actor and trigger
> compensation in Actor
> >>> 3. Do not use Kafka and only verify single node alpha, The Alpha
> server receives the saga event and puts it 

Re: About alpha-fsm progress

[Willem Jiang]

Hi ZhangLei，

Thx for the update, the test result looks very good, we get 10x
performance improvement on the Alpha side.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Jul 9, 2019 at 10:10 PM Zhang Lei  wrote:
>
> Hi, all
>
> State machine-based Alpha improves performance by an order of magnitude. I 
> have pushed Alpha's benchmark report [1] and added the stress test tool 
> module alpha-benchmark [2].
> Next I will merge branch SCB-1321 to master branch.
>
> Any questions please tell me.
>
> [1] 
> https://github.com/apache/servicecomb-pack/blob/SCB-1321/alpha/alpha-fsm/Benchmark.md
>  
> 
> [2] 
> https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-benchmark
>  
> 
>
> Lei Zhang
>
> > 在 2019年7月9日，上午8:50，Willem Jiang  写道：
> >
> > Hi Zhanglei,
> >
> > I agree with you, in the timeout scenario, it's hard to tell if the
> > transaction is finished successfully or not.
> > I think we could provide an extension or plugin to let the user do
> > some extra actions to do the compensation work after verifying the
> > transaction states.
> >
> > BTW,  as there are some changes happening in the master, maybe you can
> > consider to merge the SCB-1321 branch to master branch.
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Tue, Jul 9, 2019 at 8:21 AM Zhang Lei  wrote:
> >>
> >> Hi  All
> >>
> >> I have completed the acceptance test for the state machine and pushed to 
> >> branch SCB-1321 and CI pass. See more feature progress here[1].
> >>
> >> In the acceptance test, the timeout is different from the previous one. 
> >> When the timeout occurs, the transaction will enter the suspended state 
> >> because we are not sure whether the sub-transaction is completed and when 
> >> it is completed.
> >>
> >> For example:
> >> when booking timeout, we are not sure about the execution status of car or 
> >> hotel. If car or hotel sends TxEndedEvent after compensation, they will 
> >> not be compensated.
> >>
> >> Alpha
> >>  [x]  State machine design document
> >>  [x]  State machine prototype
> >>  [x]  State machine prototype unit test
> >>  [x]  Receive saga events using the internal message bus
> >>  [x]  State machine integration test
> >>  [x]  Enable state machine support via parameters
> >>  [x]  Verify Akka persistent
> >>  [ ]  Verify Akka cluster reliability
> >>  [ ]  Save the terminated transaction data to the database
> >>  [ ]  Support for in-process nested global transactions
> >>  [ ]  Support for cross-process nested global transactions
> >>  [ ]  Support for query terminated transaction data by RESTful API
> >>  [ ]  Support for query running transaction data by RESTful API
> >>  [ ]  Support for query running transaction data by RESTful API
> >>  [ ]  Support for query suspended global transaction by RESTful API
> >>  [ ]  Support for compensate failed sub-transaction by RESTful API
> >>
> >> Omega Components
> >>  [x]  Enable state machine support via parameters
> >>  [x]  State machine calls omega side compensation
> >>  [x]  @SagaStart supports thread termination after the timeout
> >>
> >> Alpha & Omega
> >>  [x]  Acceptance-pack-akka-spring-demo pass
> >>  [ ]  Add sub-transaction timeout exception for akka acceptance test
> >>  [ ]  Add compensation failure for akka acceptance test
> >>  [ ]  Add compensation retry success for akka acceptance test
> >>  [ ]  Alpha single node benchmark performance test
> >>  [ ]  Alpha cluster benchmark performance test
> >>
> >> Tools
> >>  [ ]  Alpha Benchmark tools
> >>
> >> Do Next:
> >> 1. State machine metrics collection
> >> 2. Alpha Benchmark tools
> >> 3. Single alpha benchmark performance test
> >> 4. Verify Akka cluster reliability
> >>
> >> [1] 
> >> https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm 
> >> 
> >>
> >> Lei Zhang
> >>
> >>
> >>> 在 2019年6月28日，下午5:50，Zhang Lei  写道：
> >>>
> >>> Hi, All
> >>>
> >>> alpha-fsm has been pushed to the branch SCB-1321
> >>>
> >>> Completed:
> >>> 1. State machine design document[1]
> >>> 2. State machine prototype
> >>> 3. State machine test case
> >>> 4. Receive saga events using the internal message bus
> >>>
> >>> Key emphasis of next stage in work:
> >>> In order to carry out the feasibility verification as soon as possible, I 
> >>> will not consider the reliability issue for the time being.
> >>> 1. Refactor Omega components, add SagaAbortedEvent, SagaTimeoutEvent, 
> >>> TxComponsitedEvent
> >>> 2. Save compensation method parameters in Actor and trigger compensation 
> >>> in Actor
> >>> 3. Do not use Kafka and only verify single node alpha, The Alpha server 
> >>> receives the saga event and puts it into the internal message bus.
> >>>
> >>> Planning:
> >>> 1. Persist actor data to 

Re: About alpha-fsm progress

[Zhang Lei]

Hi, all

State machine-based Alpha improves performance by an order of magnitude. I have 
pushed Alpha's benchmark report [1] and added the stress test tool module 
alpha-benchmark [2]. 
Next I will merge branch SCB-1321 to master branch.

Any questions please tell me.

[1] 
https://github.com/apache/servicecomb-pack/blob/SCB-1321/alpha/alpha-fsm/Benchmark.md
 

[2] 
https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-benchmark 


Lei Zhang

> 在 2019年7月9日，上午8:50，Willem Jiang  写道：
> 
> Hi Zhanglei,
> 
> I agree with you, in the timeout scenario, it's hard to tell if the
> transaction is finished successfully or not.
> I think we could provide an extension or plugin to let the user do
> some extra actions to do the compensation work after verifying the
> transaction states.
> 
> BTW,  as there are some changes happening in the master, maybe you can
> consider to merge the SCB-1321 branch to master branch.
> 
> Willem Jiang
> 
> Twitter: willemjiang
> Weibo: 姜宁willem
> 
> On Tue, Jul 9, 2019 at 8:21 AM Zhang Lei  wrote:
>> 
>> Hi  All
>> 
>> I have completed the acceptance test for the state machine and pushed to 
>> branch SCB-1321 and CI pass. See more feature progress here[1].
>> 
>> In the acceptance test, the timeout is different from the previous one. When 
>> the timeout occurs, the transaction will enter the suspended state because 
>> we are not sure whether the sub-transaction is completed and when it is 
>> completed.
>> 
>> For example:
>> when booking timeout, we are not sure about the execution status of car or 
>> hotel. If car or hotel sends TxEndedEvent after compensation, they will not 
>> be compensated.
>> 
>> Alpha
>>  [x]  State machine design document
>>  [x]  State machine prototype
>>  [x]  State machine prototype unit test
>>  [x]  Receive saga events using the internal message bus
>>  [x]  State machine integration test
>>  [x]  Enable state machine support via parameters
>>  [x]  Verify Akka persistent
>>  [ ]  Verify Akka cluster reliability
>>  [ ]  Save the terminated transaction data to the database
>>  [ ]  Support for in-process nested global transactions
>>  [ ]  Support for cross-process nested global transactions
>>  [ ]  Support for query terminated transaction data by RESTful API
>>  [ ]  Support for query running transaction data by RESTful API
>>  [ ]  Support for query running transaction data by RESTful API
>>  [ ]  Support for query suspended global transaction by RESTful API
>>  [ ]  Support for compensate failed sub-transaction by RESTful API
>> 
>> Omega Components
>>  [x]  Enable state machine support via parameters
>>  [x]  State machine calls omega side compensation
>>  [x]  @SagaStart supports thread termination after the timeout
>> 
>> Alpha & Omega
>>  [x]  Acceptance-pack-akka-spring-demo pass
>>  [ ]  Add sub-transaction timeout exception for akka acceptance test
>>  [ ]  Add compensation failure for akka acceptance test
>>  [ ]  Add compensation retry success for akka acceptance test
>>  [ ]  Alpha single node benchmark performance test
>>  [ ]  Alpha cluster benchmark performance test
>> 
>> Tools
>>  [ ]  Alpha Benchmark tools
>> 
>> Do Next:
>> 1. State machine metrics collection
>> 2. Alpha Benchmark tools
>> 3. Single alpha benchmark performance test
>> 4. Verify Akka cluster reliability
>> 
>> [1] https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm 
>> 
>> 
>> Lei Zhang
>> 
>> 
>>> 在 2019年6月28日，下午5:50，Zhang Lei  写道：
>>> 
>>> Hi, All
>>> 
>>> alpha-fsm has been pushed to the branch SCB-1321
>>> 
>>> Completed:
>>> 1. State machine design document[1]
>>> 2. State machine prototype
>>> 3. State machine test case
>>> 4. Receive saga events using the internal message bus
>>> 
>>> Key emphasis of next stage in work:
>>> In order to carry out the feasibility verification as soon as possible, I 
>>> will not consider the reliability issue for the time being.
>>> 1. Refactor Omega components, add SagaAbortedEvent, SagaTimeoutEvent, 
>>> TxComponsitedEvent
>>> 2. Save compensation method parameters in Actor and trigger compensation in 
>>> Actor
>>> 3. Do not use Kafka and only verify single node alpha, The Alpha server 
>>> receives the saga event and puts it into the internal message bus.
>>> 
>>> Planning:
>>> 1. Persist actor data to the database when it terminates
>>> 2. Integration Kafka
>>> 3. Support WAL[2] recovery mode
>>> 4. Verify Akka cluster reliability
>>> 
>>> [1] 
>>> https://github.com/apache/servicecomb-pack/tree/SCB-1321/alpha/alpha-fsm 
>>> 
>>> [2] https://en.wikipedia.org/wiki/Write-ahead_logging 
>>> 
>>> 
>>> if you have other comments, 

Re: [DISCUSSION] About the static check for the source code of ServiceComb-Java-Chassis

[yhs0092]

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

ServiceComb Board Report for July 2019

[Willem Jiang]

Hi Team,

I just create a ServiceComb Board report for July 2019, please let me
know if you have any questions about it.

## Description:
 - a microservice framework that provides a set of tools and components to
  make development and deployment of cloud applications easier.

## Issues:

 - there are no issues requiring board attention at this time

## Activity:

 - ServiceComb PMC accepted the donation of servicecomb-toolkit, and
servicecomb-mesher to subproject.
 -  We just add a new PMC and a new Committer last month.

## Health report:

- The mails and development activity are as good as usual.

## PMC changes:

 - Currently 17 PMC members.
 - Haishi Yao was added to the PMC on Mon Jun 10 2019

## Committer base changes:

 - Currently 20 committers.
 - Xiaoliang Tian was added as a committer on Thu Jun 20 2019

## Releases:

 - ServiceComb Java Chassis 1.2.0 was released on Sat Apr 13 2019
 - ServiceComb Java-Chassis 1.2.1 was released on Sun May 19 2019

## Mailing list activity:

 - This month there are 972 emails sent by 38 people, divided into 535
topics.Top 5 member: GitBox: 406 email(s), ningji...@apache.org: 114
email(s), liu...@apache.org: 65 email(s)
, zhang...@apache.org: 49 email(s), wujimin (JIRA): 36 email(s).

 - dev@servicecomb.apache.org:
- 119 subscribers (down -33 in the last 3 months):
- 258 emails sent to list (261 in previous quarter)

 - iss...@servicecomb.apache.org:
- 8 subscribers (up 0 in the last 3 months):
- 440 emails sent to list (509 in previous quarter)


## JIRA activity:

 - 111 JIRA tickets created in the last 3 months
 - 89 JIRA tickets closed/resolved in the last 3 months



Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem