It's funny just now I have met the same situation! :)
More strictly, my case is even simpler as far as an actor hasn't got state.
I also use RoundRobinPool(1) to force serialization. I have tried just to
use Await.result(), and it seems to work . To call function returning Future
I use contex
Дмитрий,
In this topic
https://groups.google.com/forum/#!folder/current/akka-user/R1ZxPKlp1fI
*Michael Frank* has suggested an idea, I have implemented it, and it does
work at my use case as expected. Probably, you will get something useful
there also :)
--
>> Read the docs: htt
I feel like it's a more general problem:
Actors are imperative. So all these simple patterns are not composable.
When you perform something like "I need to do smth with future and then
change state of actor", you have a plenty of solutions. Piping, actors per
requests, request ids, etc.
But wh
Have you looked at the pipeTo pattern and the Stash trait? I'm not sure why
a combination of pipeTo and become() with Stash wouldn't work.
On Thu, May 14, 2015 at 4:33 AM, Andrew Gaydenko
wrote:
> It's funny just now I have met the same situation! :)
>
> More strictly, my case is even simpler as
On Thursday, May 14, 2015 at 1:41:30 PM UTC+3, rrodseth wrote:
>
> Have you looked at the pipeTo pattern and the Stash trait? I'm not sure
> why a combination of pipeTo and become() with Stash wouldn't work.
>
What is that relation between stashing and piping with resolving a future?
Can you, pl
Piping does not guarantee that order will be preserved.
There are several ways to do this without waiting.
For example, you can maintain a sequence number and send current sequence
number to your long-running service to be returned when job completes.
Then you can have logic to assure that, when
Sequence order isn't a problem. RondRobinPool(1) here isn't more rather
just a limiting CPU consumption to a single core. As at the first message
in the topic, the problem is to gracefully call function returning Future
inside a message handler. We don't want answering to sender, don't want to
What if it never completes?
On Thu, May 14, 2015 at 7:03 PM, Andrew Gaydenko
wrote:
> Sequence order isn't a problem. RondRobinPool(1) here isn't more rather
> just a limiting CPU consumption to a single core. As at the first message
> in the topic, the problem is to gracefully call function ret
On Thursday, May 14, 2015 at 8:04:50 PM UTC+3, √ wrote:
>
> What if it never completes?
>
Timeout is acceptable.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the a
Stash and pipeTo is probably the best you can do today.
The reason for things to be as they are is because it amounts to what's
called a "selective receive" and it is typically a cause of poor
performance during runtime (since it stalls the actor).
If you have a more typical "pipeline processing"
If there are no relationship (no ordering) between the future result and other
incoming messages you can just use pipe, without stash.
/Patrik
> 14 maj 2015 kl. 19:24 skrev Viktor Klang :
>
> Stash and pipeTo is probably the best you can do today.
> The reason for things to be as they are is be
On Thursday, May 14, 2015 at 8:46:27 PM UTC+3, Patrik Nordwall wrote:
>
> If there are no relationship (no ordering) between the future result and
> other incoming messages you can just use pipe, without stash.
>
Let's assume at the moment we have:
def receive = {
case Msg(data) =>
def job
The common way for pipes:
def receive = {
case m =>
val s = sender()
f(m) pipeTo self
context.become({
case e:Status.Failure =>
s ! e
context.unbecome()
unstashAll()
case ok:OkType =>
s ! ok
Дмитрий.
Will it look simpler would we add dedicated actor to pipe to? I have tried
this way. The problem at my case is a function returns Future limited with
timeout, and time starts to tick too early resulting in multiple timeouts
(while the dumb way with awaiting doesn't result in any errors
I've just implemented something similar to allow Aggregate Roots
collaborate with other Domain Service
actors:
https://github.com/pawelkaczor/akka-ddd/commit/4bb69eacb1cfe2ec108fbc2980e58e1da9a85bd0
I'm using tell (+ scheduled timeout) instead of ask.
--
>> Read the docs: http://
Having a Await.result (blocking) inside your receive method will kill your
performance.
On Thursday, May 14, 2015 at 2:19:30 PM UTC-4, Andrew Gaydenko wrote:
>
> On Thursday, May 14, 2015 at 8:46:27 PM UTC+3, Patrik Nordwall wrote:
>>
>> If there are no relationship (no ordering) between the fut
OK, let's take a suggestion and use piping. So, say, we have actor1 (for
example, with RoundRobin(1)). calling a function on received message
returning Future, and this actor1 pipes the future to actor2 (for example,
with RoundRobin(5)). And the last one does some final work. I have not
found a
17 matches
Mail list logo
