Re: [DISCUSSION][PACK] About forward compensation for FSM
Hi, Willem Thanks for your advice, I order my thoughts based on your advice Time related options: 1.SagaStart.timeout 2.Compensable.timeout 3.Compensable.retires 4.Compensable.retryDelayInMilliseconds 5.Calls.timeout (Include connection timeout and request timeout between business systems, etc.) RULE1: if Calls.timeout < Compensable.timeout then Compensable.timeout > Compensable.retires * (Calls.timeout + Compensable.retryDelayInMilliseconds) RULE2: if Calls.timeout >= Compensable.timeout then Compensable.timeout > Compensable.retires * Compensable.retryDelayInMilliseconds RULE3: SagaStart.timeout > Compensable.timeout * Sub-transactions-nums NOTE: Please modify Calls.timeout with caution Best regards, Lei Zhang On January 7, 2020 at 8:19:15 AM, Willem Jiang (willem.ji...@gmail.com) wrote: I think we should not only count the retryDelay time, but also the compensable time out situation. If we got the network connection issue, the compensable timeout could be triggered and we need to deal with it. How about set the assumption like this SagaTimeout > (retryDelayInMilliseconds + CompensableTimeout)*retries Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Jan 7, 2020 at 12:14 AM Zhang Lei wrote: > > Hi, Willem > > Currently, if the timeout property of @Compensable is configured, the Omega > call thread will be interrupted and send TxAbortEvent to Alpha when Omega > call time greater than the timeout. > > No matter how many retries, the timeout is fixed. So I recommend that the > three attributes of @Compensable follow the following rules: > > timeout > retries * retryDelayInMilliseconds > > > > Best regards, > Lei Zhang > > On January 6, 2020 at 1:45:39 PM, Willem Jiang (willem.ji...@gmail.com) > wrote: > > It doesn't make sense that we keep trying of the forward recovery. > +1 to send the abort event once the forward retry is abort, and remove > the -1 option of retries. > > I just have one more question about retry timeout handling, as there > are lots of TxStartEvent there. > How can alpha server tell the timeout of the TxStartEvent when the > forward recovering is enabled? > > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Jan 2, 2020 at 1:42 AM Zhang Lei wrote: > > > > 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
Re: [DISCUSSION][PACK] About forward compensation for FSM
I think we should not only count the retryDelay time, but also the compensable time out situation. If we got the network connection issue, the compensable timeout could be triggered and we need to deal with it. How about set the assumption like this SagaTimeout > (retryDelayInMilliseconds + CompensableTimeout)*retries Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Jan 7, 2020 at 12:14 AM Zhang Lei wrote: > > Hi, Willem > > Currently, if the timeout property of @Compensable is configured, the Omega > call thread will be interrupted and send TxAbortEvent to Alpha when Omega > call time greater than the timeout. > > No matter how many retries, the timeout is fixed. So I recommend that the > three attributes of @Compensable follow the following rules: > > timeout > retries * retryDelayInMilliseconds > > > > Best regards, > Lei Zhang > > On January 6, 2020 at 1:45:39 PM, Willem Jiang (willem.ji...@gmail.com) > wrote: > > It doesn't make sense that we keep trying of the forward recovery. > +1 to send the abort event once the forward retry is abort, and remove > the -1 option of retries. > > I just have one more question about retry timeout handling, as there > are lots of TxStartEvent there. > How can alpha server tell the timeout of the TxStartEvent when the > forward recovering is enabled? > > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Thu, Jan 2, 2020 at 1:42 AM Zhang Lei wrote: > > > > 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
Re: [DISCUSSION][PACK] About forward compensation for FSM
Hi, Willem Currently, if the timeout property of @Compensable is configured, the Omega call thread will be interrupted and send TxAbortEvent to Alpha when Omega call time greater than the timeout. No matter how many retries, the timeout is fixed. So I recommend that the three attributes of @Compensable follow the following rules: timeout > retries * retryDelayInMilliseconds Best regards, Lei Zhang On January 6, 2020 at 1:45:39 PM, Willem Jiang (willem.ji...@gmail.com) wrote: It doesn't make sense that we keep trying of the forward recovery. +1 to send the abort event once the forward retry is abort, and remove the -1 option of retries. I just have one more question about retry timeout handling, as there are lots of TxStartEvent there. How can alpha server tell the timeout of the TxStartEvent when the forward recovering is enabled? Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Jan 2, 2020 at 1:42 AM Zhang Lei wrote: > > 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
Re: [DISCUSSION][PACK] About forward compensation for FSM
It doesn't make sense that we keep trying of the forward recovery. +1 to send the abort event once the forward retry is abort, and remove the -1 option of retries. I just have one more question about retry timeout handling, as there are lots of TxStartEvent there. How can alpha server tell the timeout of the TxStartEvent when the forward recovering is enabled? Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Jan 2, 2020 at 1:42 AM Zhang Lei wrote: > > 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