Now that ActorPool supports maximum size, I would like to re-open my request for having a single queue for a given ActorPool.
I would like to explain the need for a single queue for an ActorPool in the context of coalescing. Let us assume that there is a web service implementation, which makes use of an ActorPool to process each of the incoming requests. So there is a single listener, which dispatches the incoming requests to the Actors in the ActorPool.
I don't want to process the same request twice, under conditions like the user double clicks on a link (people do that!) and submits the same request twice in succession. Coalescing comes to the rescue. If the requested resource is already in the queue, the second request will be coalesced with the first one (Coalescing might possibly drop the first request).
But there is a catch to implementing this: that the coalescing is not at the ActorPool level, but at the Actor level. Typically, the code creates an Actor for processing the request, and sends the request as a message.
That is exactly the kind of problem we will be able to address if we have a single queue to a pool of Actors, instead of maintaining a queue per Actor.
maxActiveActors := 10
actorService := ActorPool(maxActiveActors, keyComputingFunc, coalescingFunc)
// When a new work is created, instead of creating a new Actor,
// hide that complexity from the user and let the user submit the work
// to the service itself.
actorService.send(work).get
// When the pool needs to be shutdown, call shutdown and
// *optionally* wait for all actors to terminate.
actorService.shutdown.join
brianSat 13 Nov 2010
First off, the robustness of the Actor code is critical to how well Fantom's concurrency works. And if we are to add complexity to that API it has be extremely well justified.
In this case I am not convinced that this case justifies complicating that API. First off coalescing is only a performance optimization - you would never actually want to design that things will be coalesced. Although if you really did want to implement things that way you could still achieve your desired behavior with the existing API:
front things with one actor who accepts/coalesces messages
have the "fronting" actor dispatch to a pool of worker actors
rosarinjroy Fri 12 Nov 2010
Now that ActorPool supports maximum size, I would like to re-open my request for having a single queue for a given ActorPool.
I would like to explain the need for a single queue for an ActorPool in the context of coalescing. Let us assume that there is a web service implementation, which makes use of an ActorPool to process each of the incoming requests. So there is a single listener, which dispatches the incoming requests to the Actors in the ActorPool.
I don't want to process the same request twice, under conditions like the user double clicks on a link (people do that!) and submits the same request twice in succession. Coalescing comes to the rescue. If the requested resource is already in the queue, the second request will be coalesced with the first one (Coalescing might possibly drop the first request).
But there is a catch to implementing this: that the coalescing is not at the ActorPool level, but at the Actor level. Typically, the code creates an Actor for processing the request, and sends the request as a message.
That is exactly the kind of problem we will be able to address if we have a single queue to a pool of Actors, instead of maintaining a queue per Actor.
brian Sat 13 Nov 2010
First off, the robustness of the Actor code is critical to how well Fantom's concurrency works. And if we are to add complexity to that API it has be extremely well justified.
In this case I am not convinced that this case justifies complicating that API. First off coalescing is only a performance optimization - you would never actually want to design that things will be coalesced. Although if you really did want to implement things that way you could still achieve your desired behavior with the existing API: