> On May 27, 2015, at 07:47, Tal Pressman <[email protected]> wrote: > > Hi Tim, > > This looks great - I was just thinking of implementing something like this > myself, so the timing couldn't have been better. ^_^
Glad to hear it! > I do have a couple of questions, though. > > From what I see in AsyncAckingConsumer, the default error handling strategy > is to acknowledge the message once the retry limit has been reached. This > means that some messages could, theoretically, be lost (no > at-least-once-delivery). Have you considered rejecting the message instead as > a default, or providing another built-in strategy that does that? It's not a > problem to implement it independently, but it could be a bit surprising for > the user. You're right; after the retry amount, the messages are lost. Also, worse, is that message order is not maintained. This makes the recovery strategy good only when message order does not matter. I had to do this because I use message headers to count retries. If you'll look at impl/AsyncAckingConsumer.scala <https://github.com/SpinGo/op-rabbit/blob/master/core/src/main/scala/com/spingo/op_rabbit/AsyncAckingConsumer.scala> you'll find the implementation for the RecoveryStrategy withRetry. I'd be open to an alternative recovery strategy. If the future returned by the RecoveryStrategy is a failure, then the original delivery gets Nacked. > > Regarding configuration, is there any way of configuring the connection > dynamically? I couldn't find anywhere in the code that overrides the settings > read from the default config file. For example, in my use case I have to be > able to open connections to several different RabbitMQ clusters, and it > doesn't seem to be possible with the current implementation. This is doable; we could model the configuration values available with a case class, then create a method fromConfig to pull it from typesafe configuration; make it the default. > As a side note, is it possible to change the configuration element to > something a little less general (maybe rabbit-op.rabbitmq)? That may be a good idea, especially if op-rabbit begins adding more configuration options other than just how to connect to rabbitmq; however, I'd hope to avoid adding more configuration if possible. > Finally, a couple of things regarding the stream module: > > From my understanding of streams, creating a Source and creating a flow > should not depend on the actual RabbitMQ connection/subscription. Instead, > the subscription (and possible the connection/channel as well?) should only > be created once the flow gets materialized. Have you considered using > Source.actorPublisher(Props) to create the actor and subscribe in the actor's > preStart or something? I just about went down this route originally, but due to code constraints I didn't. I've since refactored the code however to make that feasible. This would be a simpler approach. > The other thing about streams ties in with Roland's comments (I think) about > the use of Futures with streams. It means that the entire flow must now be > aware of the fact that it's a RabbitMQ flow (or at the very least, that its > messages contain the Future), so it is not as composable as it might have > been otherwise. Also, I don't see how it plays with streams' error handling > mechanism / strategies. At the same time, the use of Futures to "track" > messages is very elegant, and I don't see any easy way of achieving something > similar with streams (maybe something using BidiFlow?). I've considered Roland's comments deeply. I started down the route of implementing his suggestion and abandoned it as complexity grew. We have cases where the messages will be routed to different message sinks, or perhaps delivered to two different sinks. Passing along a promise allows us to fork this promise, such that the upstream promise is fulfilled only after the two forked downstream promises are (that way, enabling us to declare "the work is done" once the byproduct messages have all been confirmed to be persisted. > > In any case, like I already said, this looks like a very nice library. If you > need any help with it, please let me know - I would love to contribute to it. If you'd like to toy with alternative recovery strategies, that would be most helpful. I can work on switching the streams over to your suggestion of having them handle allocating and subscription to the subscription. > > Tal Thanks! Tim -- >>>>>>>>>> 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.
