You can complete such futures with a Throwable or an actual result, that's
what I meant,
in another thread you can future.get() (blocking) and as soon as the actor
executes the other thread will be able to proceed,
I know that's half actor half blocking but that's one of the hassle when
dealing
That depends on the supervisor strategy, funny thing that for one my
clients with lots of legacy code I had to use a CompletableFuture because
the framework I'm introducing there has no of ask or await.
And that's an idea you can use, send a Java's CompletableFuture to your
actor, and in such fu
Thanks for all the feedback. To be clear you seem to think my second approach
is the better of the two ideas and I souls just create a bunch of these in a
router? My only concern there is that if a single actor fails requests can
queue up in that actors mailbox. When the router restarts the fail
I totally agree with Patrik, simplicity is going to be the key.
The approach I have shown you wasn't the first instance of my code when I
started,
it is just the current state where my application has evolved to, you will
eventually evolve it when the need arises.
Also I was trying to show you
I agree that there is a performance cost involved in creating actors, but
if you don't have extreme performance requirements PerRequest actors can
make the code more clear and easier to reason about. I would start simple
and only introduce a more complex solution when I have measured and
confirmed
Even if the cost of creating new actors is low, there is still a cost, its
lifecycle for example has to be ran per actor creation,
a mailbox has to be created and that adds up to the GC, you could even use
specific mailboxes for these set of actors that are inside a router,
for example, I use two
*Correction:* is actors.size(), not value.size(), value came from the
original code which iterates over a Map, something else, which is my DDD
shard distributor:
On Wednesday, June 29, 2016 at 10:40:20 PM UTC+1, Guido Medina wrote:
>
> Here is how to create your Router programmatically:
>
> fina
Here is how to create your Router programmatically:
final List actors = ...
Router router = new Router(new RoundRobinRoutingLogic(),
actors.stream().map(ActorRefRoutee::new).
collect(toCollection(() -> new ArrayList<>(value.size(;
In this case I'm using RoundRobinRoutingLogic, yo
akka.routing.SmallestMailboxRoutingLogic
*Source:* http://doc.akka.io/docs/akka/2.4.7/java/routing.html
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives:
Interesting idea, of course that violates the principle of not sending
mutable state to an actor. I think it would only be necessary if there was
significant overhead in creating and stopping the actors and Akka says that
isn't the case. I think the only way this could work is if you sent an ask
But it can be improved; instead of creating and destroying actors per
Future why not just create a pool of actors (or workers if you will),
the recommended amount of concurrent actors you want is usually a factor of
CPUs, say CPUs x N where N in [1..4], of course,
and if these actors use legacy c
Thanks for the reply Mark. I understand where you are comming from but the
actual implementation in proprietary code is quit a bit more complex. Future a
response drives data needed for future b and c requests. The actual code with
completable futures is significantly more complex. I would rathe
Hi Kraythe
In situations such as this where the only state of your actor is a set of
future values, I prefer future composition over actors to improve
readability and avoid reinventing the wheel... afaict the sole
responsibility of your actor is to compose the result of 3 futures.
Regarding yo
13 matches
Mail list logo
