Am Dienstag, 7. Januar 2014 20:41:41 UTC+1 schrieb √: > > > > > On Tue, Jan 7, 2014 at 7:59 PM, Rüdiger Möller <[email protected]<javascript:> > > 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". > >
:)) i admit having had some personal experience with the "transaction of death". Gets even better in an event sourced system where restarting involves a message replay incl. the transaction of death .. > >> 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. > >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". Direct (hotspotified) method dispatch from a generated proxy still dwarfes any queue-based dispatch. Its not only the queuing, but the absense of inlining, handcraftet dispatch, allocation of queue entries, cache misses due to object allocation which hurts. Direct dispatch is allocation free. > 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. I'd consider it a bug which should be fixed pre-production. There are classes of errors which cannot and should not get "repaired" at runtime, at least not with such a high price. > 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. Valid point. Downside is, one needs to decide at programming time which work is done single threaded. If one has the "direct dispatch" option, one may do a more fine grained actor design, later on move some of the "local" actors to other dispatchers (statically by config or dynamically) in case. Additionally dynamic load balancing is applicable e.g. just do a "split" on an overloaded dispatcherthread into 2 different ones. With "always queue" actors the price for this "maybe" split is there even if it turns out your heap of actors consumes 30% of a thread only. BTW: with new config results look much better :) - ruediger -- >>>>>>>>>> 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.
