On Tuesday, January 7, 2014 12:16:18 PM UTC-8, Rüdiger Möller wrote: > > > > 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]> 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. > Direct dispatch is fraught with problems. What happens if an actor message itself? It sees the partial results of a receive invocation because there was a second invocation before the first one was complete. Even if an actor doesn't msg itself cyclical communication patterns will cause the same problems with direct dispatch. If Actor A msgs Actor B we call Actor B's receive function, now if Actor B msgs Actor A in response to this "msg" we call Actor A's receive function while it was still processing the previous msg - i.e. actor contract violated again. I encountered this in my prototypes. It seemed like a great idea in the beginning. Maybe you are talking about something else though. An enqueue on a thread local queue for every send to an actor on the same dispatcher, followed by serial invocation of callbacks till the queue is empty worked out fine ... for now. I don't know what hidden problems lie with that approach either.
> > >> 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.
