Hi Adam, It would be more complicated to "replace" AtLeastOnceDelivery with your demand-driven proposal - the entire point of ALOD is that it fights back the fact that messages can get lost and nodes can go down. Effectively what you're proposing is to switch from "re-sending until I get confirmations" (push) to "pulling all the time" (pull), the catch here is – "*what if the demand messages get lost?*", so you'd have to add re-delivery of the demand tokens themselves anyway.
Also imagine that you're trying to send M1 to A1, the A node goes down, it restarts. You could keep redelivering the M1 message, which would trigger the *starting* of the A1 actor (it could be persistent actor, in a shard, which starts when it gets a message), then the push mode of ALOD will revive this A1 guy and deliver the M1 message. This would not work in a just pull based model - you'd have to revive *everyone* on A after a restart just in order to start asking around in the cluster if someone didn't have a message they wanted to send to these A# actor – where as with the "retry (push)" model, they are just started whenever there really is some message to be delivered to them, no need to start them and "ask around". I'd also like to make sure what you mean by "reactive" when you use it in this proposal – I assume you mean the *reactive*-streams "reactive", as in "abides to the reactive streams protocol", and akka-streams of course drive those using messaging (in most cases). If so, then yes – we do plan to support reactive-streams over the network, in our case those will be actor's and messages of course, and yes, we'll need to implement a reliable redelivery transport for those messages. We're not there yet, but we definitely will cross that bridge when we get there :-) Let's move on to the Router example; Well, this is pretty much what we deal with nowadays with elements like Broadcast <https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/javadsl/FlowGraph.scala#L165> / Balance <https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/javadsl/FlowGraph.scala#L209> and *FlexiRoute* <https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/javadsl/FlexiRoute.scala> . Especially FlexiRoute should be of interest for you (in this example). As for the last proposal... I think it's either missing some details, or is wishful thinking. How would you without a central entity be able to guarantee that you're properly balancing values among all the B side actors? If you can just peer to peer between then you could simply just use point-to-point streams, and if that's not doable, there will be some form of router anyway doing the routing between A and B actors. Hope this helps to clarify some of the differences. -- Cheers, Konrad 'ktoso' Malawski hAkker @ Typesafe -- >>>>>>>>>> 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.
