Irmo Manie
UPD
#278 RabbitMQ 1.8.01.8.1
Irmo Manie
UPD

#317 Change documentation for Actor Serialization
Debasish Ghosh
ADD
#292 Add scheduleOnce to Scheduler
Irmo Manie
ADD
#308 Initial receive timeout on actor
Irmo Manie
ADD
Redesign of AMQP module (more ...)
Irmo Manie
UPD
#278 RabbitMQ 1.8.0
Irmo Manie
UPD
Netty to 3.2.1.Final
#301 DI does not work in akka-spring when specifying an interface
Johan Rask
FIX
#328 trapExit should pass through self with Exit to supervisor
Irmo Manie
Release 0.9 - June 2th 2010
Type

val supervisor = actorOf(new Actor{
self.trapExit = List(classOf[Throwable])
self.faultHandler = Some(OneForOneStrategy(1,Some(OneForOneStrategy(5, 5000))
protected def receive = {
case MaximumNumberOfRestartsWithinTimeRangeReached(
}).start
You will also get this log warning similar to this:
of restarts [1][5] within time
WAR [20100715-14:05:25.821] actor: Will *not* restart actor [Actor[se.scalablesolutions.akka.actor.SupervisorHierarchySpec$CountDownActor:1279195525812]] anymore.
WAR [20100715-14:05:25.821] actor: Last exception causing restart was [se.scalablesolutions.akka.actor.SupervisorHierarchySpec$FireWorkerException: Fire the worker!].

}
}
===Handling Handling too many actor restarts within a specific time limit
If you remember, when you define the 'RestartStrategy' you also defined maximum number of restart retries within time in millis.
RestartStrategy(

}
}
===Handling
If you remember, when you define the 'RestartStrategy' you also defined maximum number of restart retries within time in millis.
RestartStrategy(
AllForOne(), // restart policy (AllForOne or OneForOne)
3, // maximum number of restart retries
5000 // within time in millis
)
Now, what happens if this limit is reached?
What will happen is that the failing actor will send a system message to its supervisor called 'MaximumNumberOfRestartsWithinTimeRangeReached' with the following signature:
case class MaximumNumberOfRestartsWithinTimeRangeReached(
victim: ActorRef, maxNrOfRetries: Int, withinTimeRange: Int, lastExceptionCausingRestart: Throwable)
If you want to be able to take action upon this event (highly recommended) then you have to create a message handle for it in the supervisor.
Here is an example:
val supervisor = actorOf(new Actor{
self.trapExit = List(classOf[Throwable])
self.faultHandler = Some(OneForOneStrategy(1, 5000))
protected def receive = {
case MaximumNumberOfRestartsWithinTimeRangeReached(
victimActorRef, maxNrOfRetries, withinTimeRange, lastExceptionCausingRestart) =>
... // handle the error situation
}
}).start
You will also get this log warning similar to this:
WAR [20100715-14:05:25.821] actor: Maximum number of restarts [1] within time range [5000] reached.
WAR [20100715-14:05:25.821] actor: Will *not* restart actor [Actor[se.scalablesolutions.akka.actor.SupervisorHierarchySpec$CountDownActor:1279195525812]] anymore.
WAR [20100715-14:05:25.821] actor: Last exception causing restart was [se.scalablesolutions.akka.actor.SupervisorHierarchySpec$FireWorkerException: Fire the worker!].
If you don't define a message handler for this message then you don't get an error but the message is simply not sent to the supervisor. Instead you will get a log warning.
supervise-active-object
Supervising Active Objects (Java API)

Producer (...)
Sync (...)
@consume annotation can not placed any longer on actors (i.e. on type-level), only on active object methods. Consumer actors must mixin the Consumer trait.
consumeConsume messages
Both actors and active objects can receive (consume) messages from Camel endpoints. For actors to receive messages, they must be either annotated with @consume or mixin the Consumer trait. For example, the following actor class (Consumer1) implements the endpointUri method, which is declared in the Consumer trait, in order to receive messages from the file:data/input/actor Camel endpoint.

ADD
Rewritten network protocol. More efficient and cleaner.
Jonas Bonér
ADD
Rewritten Java Active Object tests into Scala to be able to run the in SBT.
Jonas Bonér
ADD

# This file has all the default settings, so all these could be removed with no visible effect.
# Modify as needed.
<log>log {
filename = "./logs/akka.log"
roll = "daily" # Options: never, hourly, daily, sunday/monday/...
# syslog_host = ""
# syslog_server_name = ""
</log>
<akka>akka {
node = "se.scalablesolutions.akka"
level = "info"
}
}
akka {
version = "0.9""0.10"
# FQN (Fully Qualified Name) to the class doing initial active object/actor
# supervisor bootstrap, should be defined in default constructor
boot = ["sample.camel.Boot",
"sample.rest.java.Boot",
"sample.rest.scala.Boot",
"sample.security.Boot"]
<actor>actor {
timeout = 5000 ## default timeout = off ## does a ensure immutability
</actor>
<dispatcher>
throughput = 5 # default throughput for ExecutorBasedEventDrivenDispatcher
</dispatcher>
<stm>
service = on}
stm {
fair = # should global transactions be better performance)
max-nr-of-retries = 1000 # max nr of retries of a failing transaction before giving up
timeout = 10000 # transaction timeout; if transaction has not committed within the timeout then it is aborted
jta-aware = off # 'on' means that if there JTA Transaction Manager available then the STM will
# begin (or join), commit or rollback the JTA transaction. Default is 'off'.
</stm>
<jta>}
jta {
provider = the JNDI)
#
# "atomikos" (means in 'akka-jta',
# e.g. you need the akka-jta JARs on classpath).
timeout = 60000
</jta>
<rest>}
rest {
service = on
hostname = "localhost"
authenticator = "sample.security.BasicAuthenticationService" # The authentication service to use. Need to be overridden (uses sample now)
#IF you are using a KerberosAuthenticationActor
# <kerberos>kerberos {
# servicePrincipal = "HTTP/[email protected]"
# keyTabLocation = "URL to keytab"
# kerberosDebug = "true"
# realm = "EXAMPLE.COM"
# </kerberos>
</rest>
<remote>}
}
remote {
compression-scheme = "zlib" # Options: "zlib" (lzf to come), leave out for no compression
zlib-compression-level = 6 # Options: 0-9 (1 being fastest and 9 being the most compressed), default is 6
<cluster>cluster {
service = on
name = "default" # The name of the cluster
actor = "se.scalablesolutions.akka.remote.JGroupsClusterActor" # FQN of an implementation of ClusterActor
serializer = "se.scalablesolutions.akka.serialization.Serializer$Java$" # FQN of the serializer class
</cluster>
<server> }
server {
service = on
hostname = "localhost"
port = 9999
connection-timeout = 1000 # in millis (1 sec default)
</server>
<client>}
client {
reconnect-delay = 5000 # in millis (5 sec default)
read-timeout = 10000 # in millis (10 sec default)
</client>
</remote>
<storage>
<cassandra>}
}
storage {
cassandra {
hostname = "127.0.0.1" # IP address or hostname of one of the Cassandra cluster's seeds
port = 9160
consistency-level = "QUORUM" # Options: ZERO, ONE, QUORUM, DCQUORUM, DCQUORUMSYNC, ALL, ANY
</cassandra>
<mongodb>}
mongodb {
hostname = "127.0.0.1" # IP address or hostname of the MongoDB DB instance
port = 27017
dbname = "mydb"
</mongodb>
<redis>}
redis {
hostname = "127.0.0.1" # IP address or hostname of the Redis instance
port = 6379
</redis>
</storage>
</akka>}
}
}

ADD
Added ActiveObjectContext with sender reference etc
Jonas Bonér
ADD
#293 Changed config format to JSON-style
Jonas Bonér
ADD
#302: Incorporate new ReceiveTimeout in Actor serialization
Jonas Bonér
ADD
FIX
Fixed memory leak in Active Objects
Jonas Bonér
FIX
Fixed indeterministic deadlock in Transactor restart
Jonas Bonér
FIX
#325 Fixed bug in STM with dead hanging CountDownCommitBarrier
Jonas Bonér
FIX
#316: NoSuchElementException during ActiveObject restart
Jonas Bonér
FIX
#256: Tests for ActiveObjectContext
Jonas Bonér
FIX

Samples of various Akka features (in Scala)
http://github.com/efleming969/akka-samples
Fork at http://github.com/flintobrien/akka-samples
A sample sbt setup for running the akka-sample-chat
http://github.com/dwhitney/sbt-akka-sample-chat

http://akkasource.org/schema/akka
http://scalablesolutions.se/akka/akka-0.10.xsd">
Active object lifecycle
Since akka manages the lifecycle of an active object the spring configuration mainly try to support in the creation of instances and currently support the following.
Scopes
An active object can be either prototype or singleton.
Post construction callback
You can annotate a method with [email protected] if you need a method to be called directly after construction. If you specify an interface and annotate the interface, the method will be called on the active object (async) and if you annotate the implementation the invocation will be called on the target instance (not async). If you do not specify an interface the invocation is always done on the active object (async). I.e, if you need the invocation to be part of a transaction, the invocation must be on the active object.
Pre destruction callback
This is supported in akka core, but it is important to understand the difference between prototypes and singleton. Read more below.
Creating Active Objects
Here are some examples how to create Active Objects with the Spring framework:

belowSpringbelowbelowSpring Integration
Module stability: IN PROGRESS
Akkas integration with the Spring Framework supplies the Spring way of using the Active Object Java API and for configuring CamelService instances. It uses Spring's custom namespaces to create Active Objects, supervisor hierarchies and a CamelService in a Spring environment.
available at http://scalablesolutions.se/akka/akka.xsd (TODO: needs to be updated).http://scalablesolutions.se/akka/akka-0.10.xsd (previous was http://scalablesolutions.se/akka/akka-0.10.xsd ). The namespace
xmlns:akka="http://akkasource.org/schema/akka"
Example header for Akka Spring configuration:

SpringbelowSpring Integration
Module stability: IN PROGRESS
Akkas integration with the Spring Framework supplies the Spring way of using the Active Object Java API and for configuring CamelService instances. It uses Spring's custom namespaces to create Active Objects, supervisor hierarchies and a CamelService in a Spring environment.
You can annotate a method with [email protected] if you need a method to be called directly after construction. If you specify an interface and annotate the interface, the method will be called on the active object (async) and if you annotate the implementation the invocation will be called on the target instance (not async). If you do not specify an interface the invocation is always done on the active object (async). I.e, if you need the invocation to be part of a transaction, the invocation must be on the active object.
Pre destruction callback
akka core, readbut it is important to understand the difference between prototypes and singleton. Read more here.below.
Creating Active Objects
Here are some examples how to create Active Objects with the Spring framework: