> > >> How is this failover and not "competing consumers"? (i.e. you have to > notice someone is down before failing over, death and delay is > indistinguishable in distributed systems) > >> > > > > > > Maybe I named it wrong, however one can do delayless failover this way. > It doesn't affect any client as the second instance keeps responding, so > there is no delay in processing. > > But it requires that workstealing is OK which is a subset of cases. > > How is that work stealing. Consider N receivers in identical state responding to the same requests (multicast, so requests are not sent twice). N receiver respond, but the requestor just takes the first response and ignores the other responses.
Provably untrue; You MUST have a logical proxy since it is a distributed > model. The wastefulness of said proxy is implementation dependent and as > such you cannot make any claim of efficiency of unstated implementation or > in general. > I can make the claim that it is awful slow with the only usable server java VM on the market on the most frequently used hardware platform :-). You can roll your own proxy implementation with reasonable effort. > Untyped actors on the other hand replace message dispatch with 'instancof' > chaining, which prevents any hotspot call optimization in case of direct > calls (both actors share same thread => direct method call done instead of > queuing). > > Which is what you want since otherwise you're synchronous, i.e. a > malicious or broken recipient can prevent progress of the sender's logic > leading to extremely brittle systems. See > http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous<http://www.google.com/url?q=http%3A%2F%2Fblog.ometer.com%2F2011%2F07%2F24%2Fcallbacks-synchronous-and-asynchronous&sa=D&sntz=1&usg=AFQjCNGTMrKA5wWcLGOghsowq9ZHYQyyOg> > > I think an actor framework should not support synchronous callbacks at all. You don't need them. In contradiction to the blog post above, in abstractor, callbacks do not come in a different thread, but put a message on the actors queue (except when sharing thread with caller). > Is Akka doing direct dispatch in case of typed actors on same dispatcher > thread (if not: thanks god my bench is not covering this ;-)) ) ? > > No, it doesn't, for the reasons mentioned above. Any distributed model > based on synchrony seems like a bad idea. > Uhh, that's a very academic point of view. The speed difference of a direct call and a message being queued is >1000 times. One can keep the contract on Actors, but optimize the dispatch in case they share same thread/dispatcher. As long synchronous results are forbidden, this does not affect functionality or behaviour of an Actor. Yes, it *may* happen the receiver blocks due to ill behaviour. If the same ill Actor gets messages queued, it will get a queue overflow in most cases anyway. I'd consider this a bug that needs a fix. The performance tradeoff is massive and forces coarse grained actor design, which on the other hand creates harder-to-balance apps. I see your reasons, for me this is a no go out of practical considerations. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> 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/groups/opt_out.
