You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is not worth it adding a batch produce API. I'm not sure where this would be useful, and there exists an ugly but usable workaround. Batch produce APIs can be useful if you want to somewhat control how much goes into a batch before compression, but that's what lingering is for. The main and only use case I can think of is if you are consuming from one location and producing to another and you want the data on disk at both the source and destination to look the same -- i.e., you want to somewhat control how things are on the broker. A secondary use case is if you want to consume batches and ensure that two records are consumed together -- but, if this is the case, an alternative is to just combine those records into one single typed record that contains both.
Adding batched producing affects nearly all levels of the produce codepaths: the change is extensive, and the benefits seem week at most.
creating raw fetch calls using kmsg also isn't a terrible workaround for batch producing, assuming there was a nice way to construct a batch from some records...
Add batch produce API-- canceling, see first comment.The text was updated successfully, but these errors were encountered: