hooking into (re)actor lifecycle

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

hooking into (re)actor lifecycle

Bob Brown
More investigations...

I have

///
def sink =  Actors.actor {
  log "Sink: Starting..."
  loop {
    react { msg ->
      def seq = n(msg)
      def rep = "PONG.$seq"
      log true, "Sink;  received: '$msg', response: $rep"
      reply rep
    }
  }
}
///

I'd like to tidy this up.

I thought of using a reactor:

///
def sink =  Actors.reactor { msg ->
  def rep = "PONG.${seq(msg)}"
  log true, "Sink;  received: '$msg', response: $rep"
  rep
}
///

Much nicer...

BUT I can't work out how to tie into the lifecycle...I'd like to print
start/stop messages (at minimum).

I THOUGHT I could do something like (from " Creating an actor using a
factory method"):

///
def sink =  Actors.reactor { msg ->
  delegate.metaClass {
        afterStart = {-> log true, "Sink has started..." }
  }
  def rep = "PONG.${seq(msg)}"
  log true, "Sink;  received: '$msg', response: $rep"
  rep
}
///

(couldn't do it with a plain actor either...)

Suggestions gratefully accepted.

Cheers,

BOB


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: hooking into (re)actor lifecycle

Vaclav
Administrator
You're correct, you don't get a chance to modify the afterStart() life-cycle method before the actor actually starts, if using the "actor" or "reactor" factory methods, which start actors automatically.
As for actors, the solution is to make the "afterStart" code an initial part of the actor's body. As for reactors, unfortunately I don't have an answer for you. A JIRA ticker might be appropriate, I guess.

Vaclav


On Mon, Mar 1, 2010 at 8:48 AM, Bob Brown <[hidden email]> wrote:
More investigations...

I have

///
def sink =  Actors.actor {
 log "Sink: Starting..."
 loop {
   react { msg ->
     def seq = n(msg)
     def rep = "PONG.$seq"
     log true, "Sink;  received: '$msg', response: $rep"
     reply rep
   }
 }
}
///

I'd like to tidy this up.

I thought of using a reactor:

///
def sink =  Actors.reactor { msg ->
 def rep = "PONG.${seq(msg)}"
 log true, "Sink;  received: '$msg', response: $rep"
 rep
}
///

Much nicer...

BUT I can't work out how to tie into the lifecycle...I'd like to print
start/stop messages (at minimum).

I THOUGHT I could do something like (from " Creating an actor using a
factory method"):

///
def sink =  Actors.reactor { msg ->
 delegate.metaClass {
       afterStart = {-> log true, "Sink has started..." }
 }
 def rep = "PONG.${seq(msg)}"
 log true, "Sink;  received: '$msg', response: $rep"
 rep
}
///

(couldn't do it with a plain actor either...)

Suggestions gratefully accepted.

Cheers,

BOB


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: hooking into (re)actor lifecycle

Russel Winder-2
In reply to this post by Bob Brown
On Mon, 2010-03-01 at 17:48 +1000, Bob Brown wrote:

> More investigations...
>
> I have
>
> ///
> def sink =  Actors.actor {
>   log "Sink: Starting..."
>   loop {
>     react { msg ->
>       def seq = n(msg)
>       def rep = "PONG.$seq"
>       log true, "Sink;  received: '$msg', response: $rep"
>       reply rep
>     }
>   }
> }
> ///
>
> I'd like to tidy this up.
>
> I thought of using a reactor:
>
> ///
> def sink =  Actors.reactor { msg ->
>   def rep = "PONG.${seq(msg)}"
>   log true, "Sink;  received: '$msg', response: $rep"
>   rep
> }
> ///
>
> Much nicer...
That was the whole point :-)

> BUT I can't work out how to tie into the lifecycle...I'd like to print
> start/stop messages (at minimum).

A reactor is a stateless actor that just processes messages, anything
else requires something else.  For the above start/stop messages, you
have to explicitly have access to the run method so that almost
certainly means having an anonymous class.

> I THOUGHT I could do something like (from " Creating an actor using a
> factory method"):
>
> ///
> def sink =  Actors.reactor { msg ->
>   delegate.metaClass {
>         afterStart = {-> log true, "Sink has started..." }
>   }
>   def rep = "PONG.${seq(msg)}"
>   log true, "Sink;  received: '$msg', response: $rep"
>   rep
> }
> ///
>
> (couldn't do it with a plain actor either...)
>
> Suggestions gratefully accepted.
Why not just something along the lines of:

        #! /usr/bin/env groovy
       
        @Grab ( 'org.codehaus.gpars:gpars:0.10-beta-1-SNAPSHOT' )
       
        import groovyx.gpars.actor.impl.RunnableBackedPooledActor
       
        def sink = new RunnableBackedPooledActor ( ) {
          public void act ( ) {
            println ( 'Starting . . . ' )
            loop {
              react { msg ->
                def seq = n(msg)
                def rep = "PONG.$seq"
                log true, "Sink;  received: '$msg', response: $rep"
                reply rep
              }
            }
            //  The above is actually an infinite loop so we can't get here but . . .
            println ( 'Stopping.' )
          }
        }
       
        sink.start ( )
        sink.join ( )



--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: hooking into (re)actor lifecycle

Bob Brown
In reply to this post by Vaclav
> You're correct, you don't get a chance to modify the afterStart()
life-cycle
> method before the actor actually starts, if using the "actor" or "reactor"
> factory methods, which start actors automatically.
> As for actors, the solution is to make the "afterStart" code an initial
part of
> the actor's body. As for reactors, unfortunately I don't have an answer
for
> you. A JIRA ticker might be appropriate, I guess.

> I THOUGHT I could do something like (from " Creating an actor using
a
> factory method"):

So does that mean that the doco is no longer correct?

I looked at the section 'Creating an actor using a factory method'...

BOB


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: hooking into (re)actor lifecycle

Vaclav
Administrator
Hi Bob,

I guess you're referring to the section 5.3 Tips and Tricks. I'll fix the code, since the metaClass obviously needs to be modified through the delegate property from within the actor's body. Did you find any other suspicious code samples in the documentation?

Vaclav


On Mon, Mar 1, 2010 at 12:52 PM, Bob Brown <[hidden email]> wrote:
> You're correct, you don't get a chance to modify the afterStart()
life-cycle
> method before the actor actually starts, if using the "actor" or "reactor"
> factory methods, which start actors automatically.
> As for actors, the solution is to make the "afterStart" code an initial
part of
> the actor's body. As for reactors, unfortunately I don't have an answer
for
> you. A JIRA ticker might be appropriate, I guess.

>       I THOUGHT I could do something like (from " Creating an actor using
a
>       factory method"):

So does that mean that the doco is no longer correct?

I looked at the section 'Creating an actor using a factory method'...

BOB


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech