> On May 13, 2015, at 01:15, Roland Kuhn <[email protected]> wrote: > > Hi Tim, > > this looks like a very nice package, thanks for sharing! Since I am not that > deeply into RabbitMQ, I guess the “opinionated” part is about favoring > at-least-once guarantees and explicit acknowledgement over magic? This would > fit in well with the overall Akka philosophy, and that would presumably not > be coincidental ;-)
It's the consumer pattern, deserialization pattern and error-reporting pattern, bundled up into one integrated package. > How has your experience been so far with building upon Akka Streams, did you > miss anything or find anything especially great? I love Akka Streams. My only qualm currently (was going to comment on the thread in which you solicited feedback on the DSL) is the .toMat(sink)(Keep.right); I frequently use the Future from Sink.foreach and wish it were the default. > Looking at your code samples there is possibly one difficult part, which is > the Promise that gets fed into the Sink in order to signal completion—perhaps > that could be modeled more cleanly by exposing an outgoing stream of > acknowledgements (i.e. making the producer a Flow and not a Sink) so that a > feedback loop would inform upstream producers of successful ingestion. That's an interesting idea; I am using promises right now to achieve that result, and the pattern works relatively well. It allows me to pass the original upstream acknowledgement promise into the publisher sink, such that the message isn't considered "done" until any resultant messages are persisted in another message queue. I've thought about your approach and I'm not quite sure how I would do it. I could pass a tuple of the original deliveryTag (from the consumer Source) and the message to publish into the Producer flow, and have the publisher flow yield the deliveryTag; then, stream the deliveryTag back to the consumer Source so it can acknowledge it. One benefit of this is I could cross process boundaries safely. However, the consumer Source actually monitors the promises that it yields, and yells at the user if they are garbage collection (to let them know they dropped a promise without resolving it). I suppose I could do a configurable timeout, instead. Is this what you had in mind? I tend to prefer the promises, since they are simple and universal, but I admit there are issues with cross-process boundaries. Worth of mention, I must ack the message on the same AMQP channel from which it was originally delivered, so, crossing machine boundaries is already going to cause pain, and a less reliable auto-acking approach should be used, instead. Regards, Tim Harper -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
