So, what we have that resolves this issue, is a fixed pool of worker actors
that each start an actor per request and then wait for it to reply or
otherwise die (and up to a certain amount of time).
This pool effectively limits the total amount of work that can be done
within a single JVM.
If I
Does a variable sized pool really have any advantage?
Or maybe you meant the size varies according to number of nodes.
Within the same JVM I would assume that a fixed size pool is good enough as
messages can be buffered and back pressure can be applied when the load
increases beyond what this pool
Adam,
We have some operations that run very quickly and on a limited circumstance
and a fixed pool would be no problem. However, we have other operations
that take a domain object, find the ids of related objects and do an
operation on all of them. Throughout this thread I have been talking
A variable sized pool could work. Because of the nature of the way our
memory cache (Hazelcast) distributes map data and the essential need to run
the operations local to that data, its essential we route the message to an
actor on the node co-resident with the data, hence the router. Im not
Ah... there it is - I missed that little Await there...
Sorry :-)
Anyway, I'd rewrite it differently.
In my eyes you have a few options.
If in order to fulfill a request, you don't need to maintain any state (in
your program, not in a DB, or something like Hazelcast), and the request is
local,
Hmm I don't know why you would think there is a race condition. The code
calls an Await() on all the futures from the ASK to Order. Furthermore, the
method NEEDS the result to the call to Order to finish the JSON map. How
would you do this without a list of futures? Remember all of the data
I am using play framework with a mix of scala and java. I can return a
promise to the play framework and that promise can call the actor to get
the information in a future. No Problem there. The problem is when an actor
(A) needs something from another actor (B) and B needs something from A. A
Compiler or not, the code above has a race condition and I'd bet that it
would return an empty map in most cases. The actor is sending the reply
without waiting fir the future to end. (It should not deadlock BTW). If
anything, I'd pipe the result to the sender.
But a future is not needed at all
Have you looked at Future.sequence? It turns a List[Future[A]] into a
Future[List[A]].
Then you can pipe that result to the same actor or another, or add a
complete handler as you have done.
On Wed, Aug 26, 2015 at 11:17 AM, kraythe kray...@gmail.com wrote:
I am using play framework with a mix
Either way I have to return just the map to the sender that called with
OrderHistory. In fact the sender could be on another node in the cluster so
sending the futures is not a viable solution. This is a multiple node
environment where the actors MUST run local to where Hazelcast stores the
You could also look at Requester (I haven't)
https://github.com/jducoeur/Requester
On Wed, Aug 26, 2015 at 10:21 AM, Richard Rodseth rrods...@gmail.com
wrote:
Robert, in my case the REST endoint is using Spray. The per-request actor
has a reference to the RequestContext, and calls complete()
Im not attempting to rant, sorry. Im just frustrated at being told what I
percieve is, hey your entire software structure is wrong, rewrite it all.
But lets leave that as it is.
So you are saying if I invoke an ask() inside an actor which invokes an
ask() inside another actor that there is no
ask() returns a future. You can do things like use Future.sequence, or
for-comprehensions.
That said, in my project we worked pretty hard to avoid using the ask()
pattern.
http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/
On Wed, Aug 26, 2015 at 9:11 AM, kraythe
Robert, in my case the REST endoint is using Spray. The per-request actor
has a reference to the RequestContext, and calls complete() on it, before
stopping itself.
I don't have time to check, but it might be modelled on this Activator
Template (which I think is referenced in the net-a-porter
I still have no idea what you mean by wait here. Do you mean block?
Please either show some code to illustrate or be more specific, it's
impossible to answer otherwise and it just ends up being a lot of replying
for nothing. :(
--
Cheers,
√
On 26 Aug 2015 08:28, kraythe kray...@gmail.com wrote:
Perhaps I am being abnormally stupid but how can you avoid an ask pattern
or some other kind of future completion when a user hits a REST endpoint
and expects data back in the response?
-- Robert
On Wednesday, August 26, 2015 at 11:21:49 AM UTC-5, Adam wrote:
What kind of web container (if
What kind of web container (if any are you using)?
I'd say using ask and blocking on it is still an improvement with pre 3.0
servlets.
With asynchronous servlets you can push the AsyncContext down in a message or
use as in the ask future's onComplete callback.
With other frameworks (Netty,
Interesting ideas. Actor per request is something i didn't know about. I
will research that. That would of course prevent a deadlock because the
pool of actors would not be fixed. The question then becomes, in the domain
management model I have (basically the actors are managing and extracting
In our case, we're indeed using work pulling, but each worker encapsulates
a single per request chain.
But we do this because of our specific requirements of prioritization,
back-pressure and gradual service degradation when overloaded.
With simpler requirements I'd likely prefer to use a router
The normal way to implement this would not use the ask pattern: if A wants to
know something and sends GetSomething to B, but B does not have it and needs to
defer to C, then in the Actor world it is possible and completely idiomatic to
have C send the result back to A directly. This is the big
I'm not quite sure but it sounds like work pulling pattern + cluster
sharding is what you're looking for.
On Wednesday, August 26, 2015 at 2:22:32 PM UTC-6, kraythe wrote:
Interesting ideas. Actor per request is something i didn't know about. I
will research that. That would of course
If you need the results of the generated futures then it waits for them all
to be completed. Process A needs the results of Process B in order to
complete. This is a pretty common paradigm in our software.
-- Robert
On Tuesday, August 25, 2015 at 9:43:11 PM UTC-5, √ wrote:
how does that
However, this has to be combined with some synchronous calls. Many parts of
the system are Asynch but not all. We have users hitting web pages
expecting to get certain data. We cant say thanks for your submission and
we will mail you your account information. We need to go fetch that
how does that wait?
--
Cheers,
√
On 25 Aug 2015 18:17, kraythe kray...@gmail.com wrote:
Call another actor using an ask pattern.
On Tuesday, August 25, 2015 at 7:22:00 PM UTC-5, √ wrote:
define wait for the responses to send back to the caller
On Tue, Aug 25, 2015 at 12:04 PM, kraythe
Lets say that we create a pool of 5 actors using round robin logic and then
we send 5 messages at the same time and those messages in the course of
being processed send another 5 messages each to the actor and wait for the
responses to send back to the caller. If this was a java executor it
define wait for the responses to send back to the caller
On Tue, Aug 25, 2015 at 12:04 PM, kraythe kray...@gmail.com wrote:
Lets say that we create a pool of 5 actors using round robin logic and
then we send 5 messages at the same time and those messages in the course
of being processed send
Call another actor using an ask pattern.
On Tuesday, August 25, 2015 at 7:22:00 PM UTC-5, √ wrote:
define wait for the responses to send back to the caller
On Tue, Aug 25, 2015 at 12:04 PM, kraythe kra...@gmail.com javascript:
wrote:
Lets say that we create a pool of 5 actors using round
27 matches
Mail list logo
