Re: [VOTE] Release Apache ServiceComb Toolkit version 0.2.0 [RC2]

2020-01-01 Thread Willem Jiang
+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


[DISCUSSION][PACK] About forward compensation for FSM

2020-01-01 Thread Zhang Lei
Hi, Pack Team

I recently looked at some forward compensation processing logic and have
some questions

1. forward compensation will retry after the call fails until the maximum
number of retries is exceeded. It calls the reverse compensate applyTo
method with each retry. This will cause multiple TxStartedEvent and
TxAbortEvent to be sent. Test case [1] proves this.

For example, retries=2, the first failure and the second success, Alpha
will receive the following events

TxStartedEvent-tx1 (first)
TxAbortEvent-tx1(This will trigger the compensation operation)
TxStartedEvent-tx1 (second)
TxEndedEvent-tx1 (tx1 will be submitted)

I suggest sending the TxAbortEvent event only if the last forward retry
failed. The modified event list looks as follows

Example 1: retries=3 and retry all failed

TxStartedEvent-tx1
TxStartedEvent-tx1
TxStartedEvent-tx1
TxAbortEvent-tx1(Trigger compensation operation)

Example 2: retries=3 and and last retry succeeded

TxStartedEvent-tx1
TxStartedEvent-tx1
TxStartedEvent-tx1
TxEndedEvent-tx1

2. I suggest remove retires is -1 option, reasonable use of parameters
retries and retryDelayInMilliseconds can meet most scenarios

[1]
https://github.com/apache/servicecomb-pack/blob/133a2fa7247b2ba00a380762a38369849390560e/omega/omega-transaction/src/test/java/org/apache/servicecomb/pack/omega/transaction/TransactionAspectTest.java#L309

[2]
https://github.com/apache/servicecomb-pack/blob/a8b24100a59a8ec9c917f89b1aa6978cc81e10df/omega/omega-spring-tx/src/test/java/org/apache/servicecomb/pack/omega/transaction/spring/TransactionInterceptionTest.java#L199

[3]
https://github.com/apache/servicecomb-pack/blob/133a2fa7247b2ba00a380762a38369849390560e/omega/omega-transaction/src/test/java/org/apache/servicecomb/pack/omega/transaction/TransactionAspectTest.java#L353

Best regards,
Lei Zhang