> On May 28, 2015, at 06:25, Tal Pressman <kir...@gmail.com> wrote: > > > > 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).
I've added this support on the master branch. > > > 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... The stream components only communicate demand, and demand, naturally, is not the same as "message made it through the entire pipe". There are some other complexities supported by the promise, such as the ability to fork them (create two new promises, and fulfill the upstream one once both new promises are completed), allowing support for patterns in which an upstream message is Acked only after it has made it fully through all the downstream pipes. Of course, this is useful only when you embrace "send at least once" (which is probably a good idea, anyways). > > > 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. Let me know how I can help! Tim > > Tal > > -- > >>>>>>>>>> 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 a topic in the Google > Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/0TONFZ0uHao/unsubscribe > <https://groups.google.com/d/topic/akka-user/0TONFZ0uHao/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > akka-user+unsubscr...@googlegroups.com > <mailto:akka-user+unsubscr...@googlegroups.com>. > To post to this group, send email to akka-user@googlegroups.com > <mailto:akka-user@googlegroups.com>. > 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>. -- >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
