Let it crash

Dear hAkkers,

We—the Akka committers—are pleased to be able to announce the availability of Akka 2.1.4. This is the fourth maintenance release of the 2.1 branch, containing documentation improvements and fixing several issues including:

• CallingThreadDispatcher deadlock problems
• Stack overflow while loading messages from persistent mailbox
• More robust recovery in remoting in case of malformed messages
• Proper deployment of typed actors

 … and several smaller fixes

IMPORTANT NOTE:

Release 2.1.3 was broken due to a bug in the release scripts and build process, please use this release instead. There were no code changes between 2.1.3 and 2.1.4.
 
This release is backwards binary compatible with version 2.1.0, 2.1.1, and 2.1.2, which means that the new JARs are a drop-in replacement for the old ones (but not the other way around). Always make sure to use at least the latest version required by any of your project’s dependencies.

Known Issues

Due to the restriction imposed by binary compatibility—which is kept for the patch releases within a minor release such as 2.1.x—not all known issues can be fixed. The currently known issues in the 2.1.x series are:

• ActorSystem.shutdown() does not terminate all threads if akka.remote.netty.use-dispatcher-for-io is set to true

Migrating from Older Releases

When migrating an existing project from Akka 2.0.x please have a look at our migration guide:
http://doc.akka.io/docs/akka/2.1.4/project/migration-guide-2.0.x-2.1.x.html

When migrating from the Akka 1.3.x series please follow first the migration guide towards version 2.0.5:
http://doc.akka.io/docs/akka/2.0.5/project/migration-guide-1.3.x-2.0.x.html

About the Cluster Support

The “akka-cluster” module is published under the name “akka-cluster-experimental” to emphasize that its status is not yet final. This denomination is not due to sub-par standard of the module; the cluster support has been tested thoroughly and it works as documented. The reason for the “experimental” tag is that this rather important module is now presented to the general public for the first time, and although we have received valuable feedback from early adopters we anticipate possible API changes in order to meet all of your requirements. Work is continuing on Akka’s cluster support, and we will formally declare it officially supported and stable with the next major release—Akka 2.2 ‘Coltrane’. Please help us make it the best possible solution by continuing to give feedback on the mailing list and telling us what can be improved.

IMPORTANT NOTICE

The artifacts comprising this release have been published to https://oss.sonatype.org/content/repositories/releases/ and also to Maven Central. In addition, we adopted the SBT standard of encoding the Scala binary version in the artifact name, i.e. the core actor package’s artifactId is “akka-actor_2.10”.

2.1.4 compared to 2.1.2:

•  12 tickets closed
•  40 files changed, 437 insertions(+), 222 deletions(-)
•  … and a total of 5 committers!

Fixed Tickets:

• 2911  DOC: IOManager error handling
• 3163  DOC: Misplaced headings in cluster docs
• 3180  Backport CallingThreadDispatcher fixes
• 3182  Stack overflow when loading messages using persistent mailbox
• 3220  backport fix for ActWithStash vs. lifecycle hooks
• 3241  remoting breaks down with protobuf errors (truncated messages)
• 3250  Backport: 3182 - Stack overflow when loading messages using persistent mailbox
• 3276  actorSelection(/…) should start matching at rootGuardian
• 3282  publish EPUB docs for 2.1.x
• 3328  backport FSM.nextState memory retention fix
• 3336  TypedProps ignores deployment options
• 3338  2.1: update to genjavadoc 0.5

Credits:

commits added removed
      7   131      49 Endre Sándor Varga
      7   110      14 Roland
      2    96      88 Björn Antonsson
      2    30       8 Viktor Klang
      1    15      14 Patrik Nordwall

Website:

http://akka.io

Binary distribution:

http://download.akka.io/downloads/akka-2.1.4.tgz
http://download.akka.io/downloads/akka-2.1.4.zip

Documentation:

http://doc.akka.io/docs/akka/2.1.4/
http://doc.akka.io/japi/akka/2.1.4/
http://doc.akka.io/api/akka/2.1.4

Issue tracker:

http://www.assembla.com/spaces/akka/

Mailing list:

https://groups.google.com/group/akka-user

Akka is released under the Apache V2 license.

IMPORTANT NOTICE

Release 2.1.3 is broken due to a bug in the release script. Please use 2.1.4 instead.

The original announcement for 2.1.3 is available below

Read More

From 2.2-M3 onwards you will probably notice several new deprecation warnings when trying out the Akka update on an existing project since all factories taking UntypedActorFactory, Creator<Actor> or Scala by-name arguments will produce warnings. We know that some of you will—at first sight—not like this, but please bear with us because we do this for a very good reason: we want to make your code safer!

The background for this change is that we have seen on many occasions code like the following:

… or in Scala:

It is an easy mistake to make and sometimes harmless, until you happen to call a method which is not thread-safe (as shown above) or you want to make this a remote deployment. In the first case you break actor encapsulating by implicitly passing “this” into the closure—deviously hidden by closure syntax—introducing race conditions and releasing the whole host of concurrency demons. In the second case the deployment will fail mysteriously because the enclosing class—often an Actor—is not serializable.

Akka’s mission is to make your life less frustrating, so we chose to replace those hidden failures which are hard to debug by early warnings from your dearest friend, the compiler.

So What Shall I Do?

The foremost use of the deprecated methods was to construct actors which take arguments. We have made this even simpler than before:

This syntax actually improves the LoC balance in the Java case considerably. For Scala it looks like this:

And What About Dependency Injection?

Another use-case for UntypedActorFactory was to let another framework perform the actual actor creation, e.g. OSGi/CDI/Spring/you-name-it. For those cases allow me to refer to our documentation for Java and Scala.

What the Future May Bring

For Scala there are two more use cases to consider: the inline construction of ad-hoc actors and the cake pattern—its close relative. The former is dangerous when performed inside another actor for the reasons outlined above, while the latter is usually safe. Therefore we plan on introducing macro-based alternatives which allow your favorite syntax to be used while not suffering from the pitfalls; stay tuned but please do not literally hold your breath, it may take several weeks until more pressing matters are resolved. Until then we are truly sorry for littering your builds with some false warnings.

Dear hAkkers,

we—the Akka committers—are pleased to announce the THIRD PRE-RELEASE MILESTONE of Akka 2.2 “Coltrane”. As discussed earlier this is to be the final and feature-complete milestone, so please take a good look and give feedback. We will gladly fix all rough edges you report while we will thoroughly test and benchmark and if necessary improve the current state of the toolkit. We do this so that we can then confidently proclaim the first release candidate in a few weeks.

What’s New?

• Reliable delivery of system messages, meaning that remote DeathWatch and remote deployment now work properly even if the network fails (DeathWatch worked already for the cluster case)

• Failure and DeathWatch communication is reliable (technically the corresponding messages became a system messages to profit from reliable delivery); failure signaling semantics changed such that the supervisor strategy may be invoked earlier than in previous versions (the Failed message “jumps the queue”)

• The generation of the Terminated message has been made more intuitive: you will no longer receive it after having unwatched the actor in question; also DeathPactException now leads to Stop instead of Restart in the defaultStrategy

• Mailboxes can now be configured separately from dispatchers, either from Props or from deployment configuration section, for example this means that it is easier to use the stashing mailbox

• Cluster nodes cannot rejoin a cluster, UIDs have been introduced to prevent communication with systems which were removed from the cluster

• ActorRefs now refer to a specific actor incarnation at a path; if you create a new actor at the same path then old ActorRefs will not send to it (this used to be the case only locally, hence we removed the difference in semantics observed with remoting); this change means that actorFor() needed to be deprecated in favor of actorSelection() which has been brought up to speed wrt. remote look-ups

• The IO layer learned SSL and WriteFile for TCP, names have been cleaned up for UDP, spray-io’s pipelines have been incorporated, complete samples including ACK- and NACK-based back-pressure have been added and more documentation updates will be coming

• Props have been restructured to not rely on closures internally but only on Class[_] and arrays of (serializable) arguments; this has been done to avoid closing over actor internal state or other non-serializable data; consequently the closure-taking Props(new Actor …) and the UntypedActorFactory have been deprecated (in the Java case this usually even saves a few lines of code on your end); there will be a more detailed blog post on this soon

• Lots of little fixes and hardening, especially of the cluster code

• Cluster-aware distributed Pub-Sub module and external cluster client

This is a lot and should probably justify the time it took since the last milestone which was released exactly one month ago.

What’s in the Pipeline?

Besides testing and benchmarking there are some things we need to clean up internally before calling it a final, and we also want to comb through especially the JavaDoc since that is just a machine translation of the ScalaDoc and does not everywhere look as complete as it could.

Release Details

When migrating an existing project from Akka 2.1.2 please have a look at our migration guide: http://doc.akka.io/docs/akka/2.2-M3/project/migration-guide-2.1.x-2.2.x.html

v2.2-M2 compared to Akka v2.2-M3:

* 84 tickets closed, see the assembla milesone

* 553 files changed, 32738 insertions(+), 15684 deletions(-)

* 637 pages of docs vs 489 in v2.2-M2

* … and a total of 10 committers!

Special thanks go to Christophe and Raman for their contribution of an OSGi sample application, and to Mathias and Johannes of spray.io for their continued work on the IO layer.

Akka is released under the Apache V2 license.

Credits:

commits added removed
   20    6439    2396 Patrik Nordwall
   13    4035    2077 Viktor Klang
   10    7806    2061 Roland
    8    1781     341 Björn Antonsson
    8    5586    3101 Endre Sándor Varga
    8     265      93 Johannes Rudolph
    4      40      22 Mathias
    3    1212     490 Raman Gupta
    3    1336     240 Christophe Pache
    1     129      23 Rich Dougherty

Take it for a spin! Happy hAkking!

commits added removed
   19    2119    1348 Patrik Nordwall
   10     528     371 Björn Antonsson
    6      67      41 Viktor Klang
    5     289     296 Roland
    4     106      81 Endre Sándor Varga
    2     527     128 Rich Dougherty
    2      95      53 Kevin Wright
    1      21       7 Johannes Rudolph
    1      31      19 Mathias

Take it for a spin! Happy hAkking!

Dear hAkkers,

We—the Akka committers—are pleased to be able to announce the availability of Akka 2.1.2. This is the second maintenance release of the 2.1 branch, where the main changes are that it was built and tested against Scala 2.10.1 and that it comes with true Javadoc generated by the GenJavaDoc plugin.

This release is backwards binary compatible with version 2.1.0, and 2.1.1, which means that the new JARs are a drop-in replacement for the old ones (but not the other way around). Always make sure to use at least the latest version required by any of your project’s dependencies.

Known Issues

Due to the restriction imposed by binary compatibility—which is kept for the patch releases within a minor release such as 2.1.x—not all known issues can be fixed. The currently known issues in the 2.1.x series are:

• ActorSystem.shutdown() does not terminate all threads if akka.remote.netty.use-dispatcher-for-io is set to true

Migrating from Older Releases

When migrating an existing project from Akka 2.0.x please have a look at our migration guide

When migrating from the Akka 1.3.x series please follow first the migration guide towards version 2.0.5


About the Cluster Support

The “akka-cluster” module is published under the name “akka-cluster-experimental” to emphasize that its status is not yet final. This denomination is not due to sub-par standard of the module; the cluster support has been tested thoroughly and it works as documented. The reason for the “experimental” tag is that this rather important module is now presented to the general public for the first time, and although we have received valuable feedback from early adopters we anticipate possible API changes in order to meet all of your requirements. Work is continuing on Akka’s cluster support, and we will formally declare it officially supported and stable with the next major release—Akka 2.2 ‘Coltrane’. Please help us make it the best possible solution by continuing to give feedback on the mailing list and telling us what can be improved.

IMPORTANT NOTICE

The artifacts comprising this release candidate have been published to https://oss.sonatype.org/content/repositories/releases/ and also to Maven Central. In addition, we adopted the SBT standard of encoding the Scala binary version in the artifact name, i.e. the core actor package’s artifactId is “akka-actor_2.10”.


2.1.2 compared to 2.1.1:

* 5 tickets closed
* 49 files changed, 361 insertions(+), 287 deletions(-)
* … and a total of 3 committers!

Fixed Tickets: see the assembla milestone

Happy hAkking!

Dear hAkkers,

the end of the first quarter of 2013 is drawing close and many of you are looking forward to the release of “Coltrane” a.k.a. Akka 2.2. The main new feature in this release will be cluster support without the“experimental” tag. We have received some encouraging feedback for the cluster preview shipped withAkka 2.1 and have been developing a few things on top of it ourselves, which has led us to replace and/or polish some parts (the new actor-based remoting comes to mind as well as improving the formulation of the core ActorCell to keep it well-oiled and maintainable) and has also highlighted a few warts which need to be removed. The latter include making the internal parent–child communication reliable in all cases—which means for example changing the way how failure is signaled to the parent—and it also means bringing the life-cycle semantics of local and remote ActorRefs in sync (up to 2.1 a remote ActorRef would look up the current inhabitant of a name on the remote host for each message send, even if that actor terminated int he meantime and a new one was created with the same name).

We also discovered some missing features which would make a lot of sense on the Coltrane milestone, for example the ability to slice a cluster into multiple pieces with different roles, or fixing the message serialization protocol to support interoperability between different versions of Akka in the future. The precise details of how far the latter reaches remain to be determined. We could have placed these features on the next milestone—Rollins—but we felt that they are more urgently needed than the cluster name service.

All in all we have expanded the scope of Coltrane and also spent energy on removing technical debt before it accumulates, which leads to a delay in getting the release out. We will cut a new milestone next Monday which contains some of the aforementioned work, but it will take approximately until the first week of April until we can call Coltrane feature complete. At that point we will release another milestone so all the curious and adventurous among you can try it out in anger, which is also what we will then be doing: in order to deliver the best possible Coltrane release we will concentrate for a few weeks on giving it a thorough beating, writing more tests, running benchmark applications and so on. This will flush out bugs and help us identify and fix remaining usability issues, and we hope that you—our dear and helpful community—will lend a hand with this.

The previous post described the ground work, getting geared up to employ the power of macros within Akka and doing type calculations. This post focuses on the user-visible features which are enabled by the macro machinery, presenting a new face for actor communication. The untyped “receive” method is replaced by declaration of any number of different input channels (though the single-mailbox principle is kept); the untyped “!” operator is replaced by different ones to avoid confusion.

Read More

Dear hAkkers,

We—the Akka committers—are pleased to be able to announce the availability of Akka 2.1.1. This is the first maintenance release of the 2.1 branch, which besides documentation updates and the fixes mentioned below also contains a back-port of most of the cluster-related changes in the recently released 2.2-M1.

The issues fixed are:

• release thread pool used by Netty’s ExecutionHandler more timely
• passive remote connections now work when using secure cookies
• do not silently swallow exceptions in ForkJoinPool executor anymore
• fix a bug in HashedWheelTimer which would schedule events incorrectly if delay is multiple of one wheel rotation (thanks Matthew Neeley)
• fix reporting of error condition when IOManager binds to a port
• make sure to set Thread.interrupt() flag when catching InterruptedException during tell()
• Netty does not close the connection anymore upon encountering a non-serializable or too large message
• PinnedDispatcher does not allow its thread to time out anymore, keeping the actor on the same thread (as opposed to only on its own thread)
• actually disallow sending `null` messages (was always forbidden by documentation and only worked on some special ActorRefs)
• StdoutLogger restores stdout-loglevel during system shutdown
• do not leak the default dispatcher anymore
• do not set SO_REUSEADDR for remoting on Windows (which implements this in a buggy way)
• properly log exceptions without a message in JulEventLogger (thanks Sam Halliday)

The changes in the cluster module are:

• cluster metric-aware adaptive load balancing routers
• automatically load cluster extension when used, no need to declare in `akka.extensions` anymore
• fire DeathWatch only upon member DOWN, not already at UNREACHABLE
• allow configuration of minimum number of members before starting the cluster
• cluster singleton pattern
• detect failure even when no heartbeat was ever sent

In addition there have been a great number of documentation updates including a whole new section on terminology.

This release is backwards binary compatible with version 2.1.0, which means that the new JARs are a drop-in replacement for the old ones (but not the other way around). Always make sure to use at least the latest version required by any of your project’s dependencies.

Known Issues

Due to the restriction imposed by binary compatibility—which is kept for the patch releases within a minor release such as 2.1.x—not all known issues can be fixed. The currently known issues in the 2.1.x series are:

• ActorSystem.shutdown() does not terminate all threads if akka.remote.netty.use-dispatcher-for-io is set to true

Migrating from Older Releases

When migrating an existing project from Akka 2.0.x please have a look at our migration guide.

When migrating from the Akka 1.3.x series please follow first the migration guide towards version 2.0.5.

About the Cluster Support

The “akka-cluster” module is published under the name “akka-cluster-experimental” to emphasize that its status is not yet final. This denomination is not due to sub-par standard of the module; the cluster support has been tested thoroughly and it works as documented. The reason for the “experimental” tag is that this rather important module is now presented to the general public for the first time, and although we have received valuable feedback from early adopters we anticipate possible API changes in order to meet all of your requirements. Work is continuing on Akka’s cluster support, and we will formally declare it officially supported and stable with the next major release—Akka 2.2 ‘Coltrane’. Please help us make it the best possible solution by continuing to give feedback on the mailing list and telling us what can be improved.

IMPORTANT NOTICE

The artifacts comprising this release candidate have been published to https://oss.sonatype.org/content/repositories/releases/ and also to Maven Central. In addition, we adopted the SBT standard of encoding the Scala binary version in the artifact name, i.e. the core actor package’s artifactId is “akka-actor_2.10”.

2.1.1compared to 2.1.0:

• 55 tickets closed
• 604 files changed, 8100 insertions(+), 2626 deletions(–)
• … and a total of 8 committers!

Fixed Tickets: see the assembla milestone

Happy hAkking!

Using a singleton should not be the first design choice, but for some use cases it is convenient and sometimes also mandatory to ensure that you have exactly one actor of a certain type running somewhere in the cluster.

This can be implemented by subscribing to LeaderChanged events, but there are several corner cases to consider. Therefore, this specific use case is made easily accessible by the Cluster Singleton Pattern in the contrib module.

The singleton actor is always running on the leader member, which is nothing more than the address currently sorted first in the member ring. This can change when adding or removing members. With the names given above the path of singleton actor can be constructed by subscribing to LeaderChanged cluster event and the actor reference is then looked up using actorFor:

Read more in the documentation.