On Tue, Jan 7, 2014 at 7:59 PM, Rüdiger Möller <[email protected]> wrote:
> >> 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. > That's called "hot standby"—which may be fine for some use cases but not all: consider a messaged called "LaunchMissiles". > > 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. > See my answer to this in my recent email. > > >> 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). > You mean enqueuing in a "thread local queue" and execute those callbacks after the current callback is done executing? We offer something for that: https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/BatchingExecutor.scala > > >> 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. > What? I'm pretty sure it's a very Real World 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. > Blanket statement. Completely depends on what type of call (the morphicity of the callsite, what invoke-instruction), the implementation of the queue, the message being enqueued etc. The Disruptor project has shown that you can get quite extreme "speed" with "message passing". > 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. > Which is not an appropriate solution for non-academic software, if I may say so. > 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. > If you want maximum single threaded performance, just use normal code. No need for multithreading at all, just use one thread per logical partition of operations. Cheers, √ > > -- > >>>>>>>>>> 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. > -- Cheers, √ *Viktor Klang* *Director of Engineering* Typesafe <http://www.typesafe.com/> Twitter: @viktorklang -- >>>>>>>>>> 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.
