You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by "TakaHiR07 (via GitHub)" <gi...@apache.org> on 2023/03/08 06:46:29 UTC

[GitHub] [pulsar] TakaHiR07 opened a new issue, #19747: [Bug] [txn] callback of commit/abort is not accurate in transaction

TakaHiR07 opened a new issue, #19747:
URL: https://github.com/apache/pulsar/issues/19747

   ### Search before asking
   
   - [X] I searched in the [issues](https://github.com/apache/pulsar/issues) and found nothing similar.
   
   
   ### Version
   
   master branch
   
   ### Minimal reproduce step
   
   When I reading the transaction code and pip-31,I found the implementation of CommandEndTxn is not as pip-31 described. Now the txn client execute commit() or abort() would wait the reponse from server until txn status become committed or aborted.
   
    ![企业微信截图_7990a84a-28a4-4f95-af32-96813d9dbf1a](https://user-images.githubusercontent.com/13505225/223634180-3f985abe-1358-4b3d-b674-051e54e22f15.png)
   
   And now the callback of commit() can not reflect the actual status of txn. For example, 2 case may occur
   1. broker may be unavailable before server update txnstatus to committing
   2. broker may be unavailable between committing and committed
   For case 2, may throw CoordinatorNotFound exception to client, then client would retry txn.commit(). But when broker recover, coordinator would firstly recover the previous transactions. Then broker process the retry-commit, may return InvalidTxnStatus or transactionNotFound to client, Which client would regard txn commit error, but actually it is success.
   
   Why we don't respond success to client  when server update txn-status to committing ?  @congbobo184 @liangyepianzhou 
   
   
   ### What did you expect to see?
   
   throw exception in commit.callback, but txn is success
   
   ### What did you see instead?
   
   commit.callback can reflect the accurate status
   
   ### Anything else?
   
   _No response_
   
   ### Are you willing to submit a PR?
   
   - [X] I'm willing to submit a PR!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] TakaHiR07 commented on issue #19747: [Bug] [txn] callback of commit/abort is not accurate in transaction

Posted by "TakaHiR07 (via GitHub)" <gi...@apache.org>.
TakaHiR07 commented on issue #19747:
URL: https://github.com/apache/pulsar/issues/19747#issuecomment-1463155418

   > @TakaHiR07 hi, let's see this step
   > 
   > 1. client sends an end request to the broker
   > 2. broker changes the status to committing or aborting status success
   > 3. broker down, can't send any response to the client
   > 4. client also doesn't know the end request success or fail(when tc reload will reprocess this txn, the client will receive `TransationNorFoundException` but we don't know it ended by timeout or by client end request)
   > 
   > I think your issue seems like #19629
   > 
   > of course, we can improve it, when txn status changes to committing or aborting status success then send the response to the client.
   
   I agree that we can improve it. When txn status successfully become committing or aborting, client can regard the transaction commit/abort successfully. Then the process of committing -> committed or aborting -> aborted is an Inevitable process, which is ensured by pulsar-server, just as kafka implemented and the pip-31 described.
   And I will try to push a pr to improve it soon. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] github-actions[bot] commented on issue #19747: [Bug] [txn] callback of commit/abort is not accurate in transaction

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on issue #19747:
URL: https://github.com/apache/pulsar/issues/19747#issuecomment-1501291914

   The issue had no activity for 30 days, mark with Stale label.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [pulsar] congbobo184 commented on issue #19747: [Bug] [txn] callback of commit/abort is not accurate in transaction

Posted by "congbobo184 (via GitHub)" <gi...@apache.org>.
congbobo184 commented on issue #19747:
URL: https://github.com/apache/pulsar/issues/19747#issuecomment-1463125042

   @TakaHiR07 hi, let's see this step
   1. client sends an end request to the broker
   2. broker changes the status to committing or aborting status success
   3. broker down, can't send any response to the client
   4. client also doesn't know the end request success or fail(when tc reload will reprocess this txn, the client will receive `TransationNorFoundException` but we don't know it ended by timeout or by client end request)
   
   I think your issue seems like https://github.com/apache/pulsar/issues/19629
   
   of course, we can improve it, when txn status changes to committing or aborting status success then send the response to the client.
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org