You can do it, but the performance trade off will be very costly. There is
no ordering guarantee between partitions, so you would have to work with
topics with only one partition. I believe you would also need to set the
batch.size in the producer to 1 to ensure the messages aren't re-ordered
within the producer buffer. As far as I'm aware, acks=all isn't necessary.

On Mon, May 15, 2017 at 10:50 AM, João Peixoto <joao.harti...@gmail.com>
wrote:

> Afaik that is not possible out of the box as that would require
> synchronization across multiple threads/instances. The throughput of such
> an approach would be terrible as the parallelism of KStreams is tightly
> coupled with the number of partitions.
>
> I'd say if you need such ordering you should reconsider the partitioning
> key, as that would be the way to do it.
>
> On Mon, May 15, 2017 at 8:22 AM Wong, Janette <janette.w...@rbc.com.invalid
> >
> wrote:
>
> > Hi,
> >
> > Is it that there is no way to guarantee strict ordering of messages
> within
> > Kafka across partitions?
> > Within a single partition, the only way for strict ordering is to set
> > max.in.flight.requests.per.connection=1 and acks=all ?
> >
> > Thanks,
> > Janette
> >
> > Janette Wong, P.Eng. | janette.w...@rbc.com | Senior Application
> > Architect - Analytics | Digital Architecture | T: 416.348.6051 | M:
> > 647.221.7836 | RBC WPP, 3rd floor
> >
> >
> >
> > _______________________________________________________________________
> > If you received this email in error, please advise the sender (by return
> > email or otherwise) immediately. You have consented to receive the
> attached
> > electronically at the above-noted email address; please retain a copy of
> > this confirmation for future reference.
> >
> > Si vous recevez ce courriel par erreur, veuillez en aviser l'expéditeur
> > immédiatement, par retour de courriel ou par un autre moyen. Vous avez
> > accepté de recevoir le(s) document(s) ci-joint(s) par voie électronique à
> > l'adresse courriel indiquée ci-dessus; veuillez conserver une copie de
> > cette confirmation pour les fins de reference future.
> >
>



-- 
Robert Quinlivan
Software Engineer, Signal

Reply via email to