> 14 maj 2015 kl. 00:43 skrev Tim Harper <[email protected]>: > > >> On May 13, 2015, at 01:15, Roland Kuhn <[email protected] >> <mailto:[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.
In that situation you can use .runWith(Sink.head) where the default is to return the Future—we use that in almost all our tests ;-) The non-running DSL methods all consistently default to the “left” side since that is obviously correct for almost all of them (like map/filter/drop/take), while the convenience runners default to their argument to provide this choice in a nicer fashion for some prominent use-cases. > >> 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? Yes, that is what I meant. > > 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. I wasn’t thinking so much about crossing machine boundaries, I’m currently more interested in learning how powerful the DSL is that we have built. By using Promises you introduce an “uncontrolled” back-channel for communicating between stream processing stages, and if that were the only way to solve this then our DSL would not be exhaustive. So, for me it is more of an aesthetic concern that the solution would be simpler in a way by just using one abstraction instead of mixing two. A working solution still is a working solution for you, of course ;-) Regards, Roland > > Regards, > > Tim Harper > > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> > >>>>>>>>>> Check the FAQ: > >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > >>>>>>>>>> <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/akka-user > <http://groups.google.com/group/akka-user>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. Dr. Roland Kuhn Akka Tech Lead Typesafe <http://typesafe.com/> – Reactive apps on the JVM. twitter: @rolandkuhn <http://twitter.com/#!/rolandkuhn> -- >>>>>>>>>> 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.
