On Thursday, May 28, 2015 at 1:26:28 AM UTC+3, Tim Harper wrote:
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. > > Indeed, I hadn't noticed that the retries actually re-enqueued the message. Maybe it's better to just let the downstream decide what to do with the message (retry for however many times it wants, for example), and make the AsyncAckingRabbitConsumer "stupid" - when it gets an error it rejects the message (or some other simple strategy) ? Anyway, I'll try playing around with it and see where I get... 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. > > Adding case classes for configuration would be a nice touch. What I was trying to get at, however, is the ability to load from the non-default Config (for example, fromConfig(config: Config = ConfigFactory.load() or something). 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. > > I think the more important issue here is just to make the "root" configuration element name more unique and less likely to conflict with other libraries. "rabbitmq" seems like a name that could be picked by any number of RabbitMQ-related libraries. > 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. > > Yeah, that's what I like about the Future/Promise approach... On the other hand, streams already have a similar capability in the way they report back-pressure and demand for flows that are just as complex. Maybe it's something the Akka guys should consider adding to the streams directly... 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. > Yeah, I'll start playing around with it, and see what happens. And maybe also try to get publish confirmations working - blocking commits are really painful. Tal -- >>>>>>>>>> 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.
