Re: [akka-user] Digest for akka-user@googlegroups.com - 17 updates in 6 topics

[Jason Mason]

unsubscribe

On Wed, Apr 16, 2014 at 10:28 AM, <akka...@googlegroups.com> wrote:

  Today's topic summary

Group: http://groups.google.com/group/akka-user/topics

• Patterns.gracefulStop - This doesn't seem to work [5 Updates]
• Is there a standard term for "a bunch of closely related Actors"? [6 Updates]
• Is there some way to save sender reference in a list when use remote akka? [1 Update]
• What is the best way to integrate kafka and akka [3 Updates]
• Akka Persistence - Views with multiple processors [1 Update]
• DDD/Eventsourcing with Akka Persistence [1 Update]

 Patterns.gracefulStop - This doesn't seem to work

Boney Sekh <bone...@gmail.com> Apr 15 10:55PM -0700  

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 extends UntypedActor {
 
private final Logger log = LoggerFactory.getLogger(TestActor.class);
 
final ActorRef target;
 
public TestActor( ActorRef target ) {
this.target = target;
}
 
@Override
public void postStop() throws Exception {
super.postStop();
log.info("Actor stopped...");
}
 
@Override
public void onReceive( Object msg ) {
if ( msg == Command.STOP_PROCESSING ) {
log.info("Stopping actor...");
getContext().stop( getSelf() );
} else {
unhandled(msg);
}
}
 
}
 
Code to stop:
 
Future< Boolean > stopped = Patterns.gracefulStop( actorRef,
Duration.create( 5, TimeUnit.SECONDS ), Command.STOP_PROCESSING );
Await.result( stopped, Duration.Inf() );


 

Boney Sekh <bone...@gmail.com> Apr 16 01:59AM -0700  

Hi,
 
I thought I should add this. Basically this works when my TestActor is at
the system level, i.e. system.actorOf. However what I am trying to do is to
stop an actor *which is a child of another*.
 
Thanks,
B
 
On Wednesday, April 16, 2014 1:55:59 PM UTC+8, Boney Sekh wrote:


 

"√iktor Ҡlang" <viktor...@gmail.com> Apr 16 11:24AM +0200  

Hi Boney,
 
can you create a _minimized_ code sample that is self contained and shows
the perceived bug?
 
 
 
--
Cheers,
√


 

Boney Sekh <bone...@gmail.com> Apr 16 06:54AM -0700  

Hi Victor,
 
Thanks for your reply. While I was trying to create the sample, I realized
the problem was that I was using TestActorRef and that was probably the
reason. When I moved my test to using JavaTestKit, it worked fine. Your
reply helped me to get to the problem and thanks for that.
 
Regards,
Boney
 
On Wednesday, April 16, 2014 5:24:52 PM UTC+8, √ wrote:


 

"√iktor Ҡlang" <viktor...@gmail.com> Apr 16 04:03PM +0200  

You're most welcome.
 
Happy hAkking!
 
 
 
--
Cheers,
√


 

 Is there a standard term for "a bunch of closely related Actors"?

Justin du coeur <jduc...@gmail.com> Apr 15 03:07PM -0400  

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 UserSessionManager, and a router/root dealing with messaging
through this whole shebang. They're very deeply inter-related to each
other, and I find myself needing to refer to the collection in the
comments/docs.
 
I've found myself calling this a "hive", for no particular reason except
that it's the term that seems most intuitive to me, but I was wondering if
there is any consensus terminology here.
 
The closest I can think of from what I've seen is "aggregate", but that's
fairly recent since DDD became a hot topic around here, and it feels like
slightly the wrong semantic level: "aggregate" is really about the data,
and I'm thinking about the Actors themselves. (That said, folks do seem to
be calling the idea of that router the "aggregate root", so it is possible
that DDD terminology is taking over.)
 
What have y'all been calling this concept, if anything?


 

"√iktor Ҡlang" <viktor...@gmail.com> Apr 15 10:16PM +0200  

"A cast of actors"?
 
 
 
--
Cheers,
√


 

Justin du coeur <jduc...@gmail.com> Apr 15 04:43PM -0400  


> "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...


 

Daniel Armak <dana...@gmail.com> Apr 15 11:52PM +0300  

"Cast" does seem to have the potential for confusion. How about "a company
of actors", or maybe "troupe"?
 


 

Justin du coeur <jduc...@gmail.com> Apr 15 05:21PM -0400  


> "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. Thanks! (And thanks
to Viktor for starting this line of thinking...)


 

"√iktor Ҡlang" <viktor...@gmail.com> Apr 15 11:25PM +0200  

you're most welcome
 
happy hakking!
 
 
 
--
Cheers,
√


 

 Is there some way to save sender reference in a list when use remote akka?

Liang Tang <liang...@gmail.com> Apr 15 09:19AM -0700  

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:


 

 What is the best way to integrate kafka and akka

Filippo De Luca <m...@filippodeluca.com> Apr 15 07:37PM +0100  

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.
 
 
 
--
*Filippo De Luca*
---------------------
WWW: http://filippodeluca.com
IM: filosg...@gmail.com


 

Scott Clasen <scott....@gmail.com> Apr 15 11:59AM -0700  

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 stream and do something if there is a result,
for instance. Once you receive a message, do something with it, then send
 
self ! Receive
 
to continue processing the stream.
 
in the mean time between processing the received message and the `self !
Receive`, the actor could have received other messages which it will
process before processing the next Receive message.
 
 
 
On Tuesday, April 15, 2014 11:37:54 AM UTC-7, Filippo De Luca wrote:


 

Filippo De Luca <m...@filippodeluca.com> Apr 15 09:08PM +0100  

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
 
 
 
--
*Filippo De Luca*
---------------------
WWW: http://filippodeluca.com
IM: filosg...@gmail.com


 

 Akka Persistence - Views with multiple processors

delasoul <michael...@gmx.at> Apr 15 12:44PM -0700  

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 events from views to an aggregator still leaves me
with the question why then use a view at all and not just send the events
from
the processor to the aggregator directly? When using a view in the "middle"
one has to deal again with not sending duplicate messages to the aggregator
when views
replay, persistence(if needed) of the aggregator, losing messages etc. or
am I missing smthg?
 
michael
 
 
 
 
 
 
 
On Monday, 14 April 2014 16:42:08 UTC+2, Chanan Braunstein wrote:


 

 DDD/Eventsourcing with Akka Persistence

Jakub Czuchnowski <jakub.cz...@gmail.com> Apr 15 10:41AM -0700  

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:


 

--
>>>>>>>>>> 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/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscribe@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.