unsubscribe On Wed, Apr 16, 2014 at 10:28 AM, <[email protected]> wrote:
> Today's topic summary > > Group: http://groups.google.com/group/akka-user/topics > > - Patterns.gracefulStop - This doesn't seem to work > <#m_602575461944839151_group_thread_0> [5 Updates] > - Is there a standard term for "a bunch of closely related Actors"? > <#m_602575461944839151_group_thread_1> [6 Updates] > - Is there some way to save sender reference in a list when use remote > akka? <#m_602575461944839151_group_thread_2> [1 Update] > - What is the best way to integrate kafka and akka > <#m_602575461944839151_group_thread_3> [3 Updates] > - Akka Persistence - Views with multiple processors > <#m_602575461944839151_group_thread_4> [1 Update] > - DDD/Eventsourcing with Akka Persistence > <#m_602575461944839151_group_thread_5> [1 Update] > > Patterns.gracefulStop - This doesn't seem to work > <http://groups.google.com/group/akka-user/t/29b02007604c4c00> > > Boney Sekh <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> Apr 16 04:03PM +0200 > > You're most welcome. > > Happy hAkking! > > > > -- > Cheers, > √ > > > > Is there a standard term for "a bunch of closely related Actors"? > <http://groups.google.com/group/akka-user/t/a130b09f52aa3b7c> > > Justin du coeur <[email protected]> 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" <[email protected]> Apr 15 10:16PM +0200 > > "A cast of actors"? > > > > -- > Cheers, > √ > > > > > Justin du coeur <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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? <http://groups.google.com/group/akka-user/t/8ddf82db438e28c4> > > Liang Tang <[email protected]> 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 > <http://groups.google.com/group/akka-user/t/a61060b24c9f4237> > > Filippo De Luca <[email protected]> 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: [email protected] > > > > > Scott Clasen <[email protected]> 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 <[email protected]> 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: [email protected] > > > > Akka Persistence - Views with multiple processors > <http://groups.google.com/group/akka-user/t/761c99f96a703f3e> > > delasoul <[email protected]> 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 > <http://groups.google.com/group/akka-user/t/27b074ff90eebe96> > > Jakub Czuchnowski <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
