Skip to content
This repository has been archived by the owner on Nov 10, 2022. It is now read-only.

How shall we surface acknowledged Sinks in Akka Streams? #14

Open
rkuhn opened this issue Mar 11, 2016 · 5 comments
Open

How shall we surface acknowledged Sinks in Akka Streams? #14

rkuhn opened this issue Mar 11, 2016 · 5 comments

Comments

@rkuhn
Copy link
Contributor

rkuhn commented Mar 11, 2016

This is the much simpler cousin of #13. The primary proposal is to model this as a Flow:

class KafkaSink extends GraphStage[FlowShape[Message, Confirmation]]

This is fundamentally what happens: messages are sent to Kafka, to be turned into confirmations.

@13h3r
Copy link
Member

13h3r commented Mar 11, 2016

Originally I emit not Confirmation, but Future[Confirmation]. This allows client to keep order of messages and perform some actions in parallel and then join confirmed record with some other job.

Emitting just Confirmation shuffles original order.

Also Future[Confirmation] can be easily turned into Confirmation and allows client to control how many confirmation may be in progress.

@rkuhn
Copy link
Contributor Author

rkuhn commented Mar 11, 2016

Ah, my assumption was that the .mapAsync() is already included in the KafkaSink and that the confirmations are emitted in the right order.

@13h3r
Copy link
Member

13h3r commented Mar 11, 2016

I wanted to provide as minimal abstraction as possible. Then client will decide do he cares about order (and use mapAsync) or dont (and use mapAsyncUnordered)

Same for #13

@rkuhn
Copy link
Contributor Author

rkuhn commented Mar 11, 2016

Yes, this is a good point. This case is rather easy, the Source case is vastly different due to needing three ports.

@ktoso
Copy link
Member

ktoso commented Mar 12, 2016

I agree with #14 (comment) in that we'll want to expose Future[Confirmation], from which can go to Confirmation with or without order 👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants