Closed nmarasoiu closed 6 years ago
- The "sync" flag is commented that it is not taken into account
It is not commented out, why do you say that?
- It is mentioned that the production is async in all situations, thereby some messages can always be lost. We agree that async is performant and efficient but the question comes back to at-least-once.
Could you please point to the place where the doc says that.
By the way this not a library, but an application that is supposed to be running on the same host as your application. It can work in at-least-once mode if the following conditions are met:
Ok thanks clarified
@horkhe Apologies for jumping in an old discussion, I'm not clear what would be the behavior if multiple clients connect to the same Kafka pixy instance and ack explicitly. As far as I can see there is no explicit tracking of client IDs (that makes things easier) but if that is the case - would the second client receive the same set of messages until the first one ack's? If it gets new messages, can it ack the offset on top of the first one? (before the first one ack'd)? Tx in advance for the help!
Hi, We like this library very much however we have one question regarding the at-least-once possibility and its performance implications, but first, reading the README, I remained with the impression that it is not certain if at-least-once is indeed available at this point, because:
As a more high level view, we intend an exactly-once processing, stamping messages with an idempotence key including an uuid, sending them on an at-least-once pipe, (either REST with retries, gRPC, or kafka-client), and compensating processing in case of duplicate processing.
Please indicate if at-least-once is possible or will be, and please clarify the apparent inconsistencies identified on a first read of the README. Thank you, Please advise, Nicu Marasoiu MetroSystems Romania