You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2019/09/26 11:29:01 UTC

[GitHub] [pulsar] ivankelly commented on issue #5271: Improve error handling logic for effectively once

ivankelly commented on issue #5271: Improve error handling logic for effectively once
URL: https://github.com/apache/pulsar/pull/5271#issuecomment-535461373
 
 
   > > What if the client produces [M1, seq:1],[M2, seq:2],[M3, seq:3] asynchronously. M1 succeeds, M2 fails with a BK error, the managed ledger recovers from the error, then M3 hits the broker and is persisted. At this point, M2 can retry, but the message is lost because seq:2 is lower than seq:3.
   > 
   > The current guard against this scenario is that managed ledger will reject all the writes for a period of 10sec. In practical terms, this should avoid all races between threads (for non-blocking ops), though of course it does not give 100% proof.
   > 
   > The next step is to have managed ledger to stay in "error mode" after write failure, until we manually set it back into normal mode, after all the pending ops are done and we got the chance of resetting the topic.
   
   Maybe we need to rebrand our "exactly-once" again from "effectively-once" to "probably-once". 
   I think there needs to be some cooperation with the client w.r.t. failures. A client could have a write pending during the time that the error occurs on a previous write and that error being handled, so when the write hits the broker it proceeds as normal, losing the previous write forever. 
   
   Maybe we should have some sort of epoch to represent the client <-> producer relationship? When an error occurs on a write, all subsequent writes from that epoch should fail. The error should be kicked back to the client, which should then have to reestablish it's current position before preceeding.

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services