Hey Adam, sorry it took my a while to get to this email - been consuming the "least responded / oldest" email from the list throughout the week, not sure it this worked well or not yet... :-)
By the way - isn't dropping demand messages a problem also in the current >> remote-streams implementation? >> > There is no remote akka streams yet. If you mean tcp then the demand is just generated "by the socket" - not through passing tokens over the network. > Sure, as we move away from peer-to-peer to more actors things do get more > complex, but then, if you want to have back-pressure, you need some kind of > feedback. I'd see it as a tradeoff - either lazily started actors, or > backpressure. > If the sharded actors are aggregate roots, for example, then lazy loading > makes perfect sense. But if these are workers, of which there are a couple > per host, then this wouldn't be a problem. Just depends on the type of work > they are supposed to do. > Yeah, exactly - I wanted to point out this distinction - as because of it the current ALOD still makes sense even once we get a fully backpressure based one. > > >> I'm wondering how many more functionalities are there in the code >> undiscovered ;) But that will change when the docs are there I guess :) >> > Yeah... Soon we'll have docs, that should tremendously help in that respect :-) > > >> Right, well, originally I was wondering if Akka could replace >> Kafka+Zookeeper's message streams (which can be used to implement the >> scenario above: where there's a pool of producers, and a pool of consumers, >> all potentially on different hosts, and using Kafka they can stream >> messages reliably). With Kafka's delivery methods you bind each consumer to >> a number of partitions, so it would be as you describe, kind of >> point-to-point streams, which get re-balanced when a node goes down. >> > Going this route, there could be a cluster-singleton service which assigns >> B-actors to A-actors, and creates streams between those two. These could be >> the "reactive message streams" from above. And to solve the >> demand-splitting problem (when a B has two As assigned), there could be >> simply more consumer-actors then producer-actors. >> > This sounds like a very interesting use case. Would be awesome if you could tinker around it. Random fact is that Kafka is *so much used everywhere* that it definitely would find users/contributors I think :-) -- 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.
