Intercept messages sent to actor

[Joeri De Koster]

I would like to define a new actor trait that allows me to intercept messages sent to actors before forwarding them. Unfortunately I am not able to override the aroundReceive method defined in akka.actor.Actor as it is protected.

Is there any other way for me to do this?

trait LoggingActor extends Actor {

override def aroundReceive(receive: Receive, msg: Any): Unit = {

myLog(msg)

super.aroundReceive(receive, msg)

}

}

Regards,

Joeri

[√iktor Ҡlang]

Hi Joeri,

Does this solve your actual problem?

1.  
2. debug {
3. # enable function of Actor.loggable(), which is to log any received message
4. # at DEBUG level, see the “Testing Actor Systems” section of the Akka
5. # Documentation at http://akka.io/docs
6. receive = off

http://doc.akka.io/docs/akka/2.2.3/general/configuration.html

Cheers,

√

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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+...@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/groups/opt_out.

--

Cheers,

√

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang

[Joeri De Koster]

Not really.

The logging was just an example.

I wanted to use this technique to handle special types of messages in some custom way, not only for logging.

In Scala I have the following implementation:

trait NotificationActor extends Actor {

override def receive[R](body: PartialFunction[Any, R]): R = {

   val wrapper: PartialFunction[Any, R] = {

     case Notification(value) =>

       report(value)

        receive(body)

     case any =>

body(any)

   }

   return super.receive(wrapper)

 }

}

And now I want to port this implementation to akka.

Thank you for your help,

Joeri

[Eric Pederson]

This might help:

http://stackoverflow.com/questions/19827027/how-to-add-logging-function-in-sending-and-receiving-action-in-akka/19838821

[Andrew Easter]

This subject came up in another thread during discussions about akka-persistence. Martin Krasser suggested implementing a hook that can optionally be implemented should you wish to do some custom message handling prior to the main receive message loop. One useful benefit is the ability to use become/unbecome whilst still handling certain messages regardless of the behaviour of the receive message loop.

It was agreed that making Actor.aroundReceive public would be a bad idea - as Martin said, it would be open to abuse.

[Joeri De Koster]

Do you have a link to this discussion?

I can see why you would want to keep Actor.aroundReceive protected for application developers but it does limit what is possible to do from a library implementation.

Here is my current workaround:

// Library Code

case class Notification(val value: Any) {}

trait NotificationActor extends Actor {

def notifiable(receive: Receive): Receive = {

case Notification(value) =>

report(value)

case msg =>

receive(msg)

}

}

// Application code

class TestActor extends NotificationActor {

def receive = notifiable {

case any => {

println("Hello World!")

}

}

[Andrew Easter]

On Wednesday, 13 November 2013 04:40:36 UTC-8, Joeri De Koster wrote:

Do you have a link to this discussion?

Was actually on Akka Developer List as it turns out:

https://groups.google.com/d/msg/akka-dev/UCvGJ3p5-o8/ZJV8TY0QnOYJ

Andrew 

[Roland Kuhn]

While we should probably be careful and not make it available in 2.3 (to see how it works out), I wouldn’t say that we won’t open it up later. Meanwhile library writers can put their actor-transforming support traits into the akka package.

Regards,

Roland

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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+...@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/groups/opt_out.

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn

[Andrew Easter]

Roland,

Do you think there's scope, though, for adding Martin's suggestion of a public Processor-specific interceptor hook?

Regards,

Andrew

[Akka Team]

Hi Andrew,

what precisely do you have in mind? (exact method signature, semantics and purpose)

What I can see in the thread you linked to is not really specific to Processor in the sense that my proposal of a support trait situated in the akka package would not give you all you need. The other question is whether it makes sense to be able to control the snapshot policy from the outside (i.e. whether the actor might in general be in states which lend themselves better or worse for taking a snapshot).

Regards,

Roland

--

>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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+...@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/groups/opt_out.

--

Akka Team

Typesafe - The software stack for applications that scale

Blog: letitcrash.com
Twitter: @akkateam

[Andrew Easter]

On Wednesday, 13 November 2013 12:44:17 UTC-8, Akka Team wrote:

what precisely do you have in mind? (exact method signature, semantics and purpose)

The purpose is to allow a general way to perform some message handling regardless of the receive message loop implemented in the actor - the point being that you might wish for some messages (SaveSnapshot in the example) to be handled regardless of the receive state the actor has been placed in (i.e. actor might be using become/unbecome).

What I had in mind would be some kind of preReceive method that either chooses to handle a message or allows execution to fall through to the main receive message loop. So, it would look very much like a normal receive except you'd know it will always be invoked regardless of the main receive message loop. 

Does that make sense?

Andrew

[Martin Krasser]

The main reason why I discouraged overriding aroundReceive is that it implements a journaling/snapshot protocol in Processor and EventsourcedProcessor. Any processor overriding/extending these implementations would make itself dependent on this internal protocol which may change any time (e.g. for optimization purposes).

A processor-specific pre/post (or even around-) receive hook could avoid that but I'm still not sure if its a good idea to add further hooks just to be able to continue using context.become() (instead of a custom "switchTo" as proposed in this post). Another advantage of the "switchTo" example is that it adds common behavior by partial function composition instead of subclassing.

Andrew

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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+...@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/groups/opt_out.

-- 
Martin Krasser

blog:    http://krasserm.blogspot.com
code:    http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

[Andrew Easter]

On Wednesday, 13 November 2013 22:13:08 UTC-8, Martin Krasser wrote:

A processor-specific pre/post (or even around-) receive hook could avoid that but I'm still not sure if its a good idea to add further hooks just to be able to continue using context.become() (instead of a custom "switchTo" as proposed in this post). Another advantage of the "switchTo" example is that it adds common behavior by partial function composition instead of subclassing.

I think I'll stick with the switchTo approach - it definitely addresses the problem at hand. I guess my only issue with this would be that it doesn't actually stop someone deciding to circumvent it and use context.become directly. I suppose, though, you could use that argument in most situations - just because you can do something, doesn't mean you should. 

Andrew