Hi,
I have been trying to use the Patterns.gracefulStop to stop an actor
gracefully. I know my internal actor is stopped by verifying the postStop
method is invoked.
However, the future is not returning true and is held until timeout.
Is there a bug?
Here is my code:
public class TestActor ex
you're most welcome
happy hakking!
On Tue, Apr 15, 2014 at 11:21 PM, Justin du coeur wrote:
> On Tue, Apr 15, 2014 at 4:52 PM, Daniel Armak wrote:
>
>> "Cast" does seem to have the potential for confusion. How about "a
>> company of actors", or maybe "troupe"?
>>
>
> Oooh -- a word that isn't
On Tue, Apr 15, 2014 at 4:52 PM, Daniel Armak wrote:
> "Cast" does seem to have the potential for confusion. How about "a company
> of actors", or maybe "troupe"?
>
Oooh -- a word that isn't being used for anything else yet! Beautifully
evocative, too. I think I'll use "troupe" for now. Thank
"Cast" does seem to have the potential for confusion. How about "a company
of actors", or maybe "troupe"?
On Tue, Apr 15, 2014 at 11:43 PM, Justin du coeur wrote:
> On Tue, Apr 15, 2014 at 4:16 PM, √iktor Ҡlang wrote:
>
>> "A cast of actors"?
>>
>
> Heh. Aside from the word "cast" invoking a bit
I discovered the bug finally: the name in system.actorOf is wrongly
defined. That Caused this bug.
On Monday, April 14, 2014 9:56:21 AM UTC-5, Martynas Mickevičius wrote:
>
> Hi Liang,
>
> this is too little information for a definite answer. If you could package
> a small program which is able
On Tue, Apr 15, 2014 at 4:16 PM, √iktor Ҡlang wrote:
> "A cast of actors"?
>
Heh. Aside from the word "cast" invoking a bit of lingering PTSD from my
C-programming days, I rather like it...
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http:/
"A cast of actors"?
On Tue, Apr 15, 2014 at 9:07 PM, Justin du coeur wrote:
> Fairly idle question, but I'm curious whether the team has an opinion.
>
> In my development, I'm getting to the point where each Space has a
> good-sized collection of Actors involved with it: a state manager, a
> co
Oh I see,
Of course between one receive and another one, the mailbox could receive
other messages. And it will be process one for each Receive.
Got it, It is cool. Thanks
On 15 April 2014 19:59, Scott Clasen wrote:
> Not necesarily true depending how you model it. Im not suggesting sending
>
Hello,
problems using a view for multiple processors have been discussed before,
e.g.:
https://groups.google.com/d/msg/akka-user/Tb1Qqh4ZMmo/ssqiBEQ_Eb0J
It would still be a great feature to have though(when you need an
aggregated view on events of multiple processors).
The solution to send the
Fairly idle question, but I'm curious whether the team has an opinion.
In my development, I'm getting to the point where each Space has a
good-sized collection of Actors involved with it: a state manager, a
conversations manager, a couple of persistence workers, n UserSession
Actors with a UserSes
Not necesarily true depending how you model it. Im not suggesting sending
all messages received from the stream to the actor, but to send control
messages to the actor to tell it what to do with the stream.
For instance, model such that...
streamActor ! Receive
will make the actor poll the
The thing is, under the load, the actor will have always messages so it
will never process other messages. That may fit the user case anyway, but
may also not.
Btw it was one of my initial idea.
On 14 April 2014 22:59, Scott Clasen wrote:
> Hey man!
>
> So far so good, under load you dont have
Thank you guys for the information. I'm going to write some code now and
get back with more questions :)
Jakub
On Monday, April 14, 2014 10:34:59 PM UTC+2, rrodseth wrote:
>
> Here's a pertinent reply from Patrik to me:
>
> On Mon, Mar 3, 2014 at 4:07 PM, Richard Rodseth
>
> > wrote:
>
>> I ha
Hi Benard,
one detail that caught my eye is a configuration setting for receptionist
name in your name method. It should start with *akka*.
Documentation on this setting here:
http://doc.akka.io/docs/akka/snapshot/contrib/cluster-client.html#ClusterReceptionistExtension
If that is not the source
Yes, the cluster startup issue has been fixed. :)
Thanks!
Tommaso.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akk
Hi Mike,
ClusterSingletonManager has parameters that can be reduced when testing,
maxHandOverRetries, maxTakeOverRetries, retryInterval.
Cluster config settings that you can try to reduce:
akka.cluster {
jmx.enabled = off
gossip-interval = 200 ms
leader-actions-interval = 200 ms
unreachab
On Tue, Apr 15, 2014 at 12:53 AM, Chris Toomey wrote:
> Thanks. It'd be helpful to include this information about persistent
> channels being resettable via the Reset message and via a restart in the
> documentation on persistent channels (both the overall persistence doc. and
> the PersistentCh
17 matches
Mail list logo
