ANNOUNCE: Akka 2.3-M1 (PRE-RELEASE MILESTONE)

[Patrik Nordwall]

Dear hakkers,

We—the Akka committers—are pleased to be able to announce the availability of Akka 2.3-M1 (PRE-RELEASE MILESTONE ONE). It is a preview on what is going to become Akka 2.3, so please give us feedback!

The most exciting new feature is Akka Persistence, developed by Martin Krasser in collaboration with the Akka team. It allows stateful actors to persist their internal state so that it can be recovered when an actor is started, restarted by a supervisor or migrated in a cluster. It also allows stateful actors to recover from JVM crashes, for example. The key concept behind Akka Persistence is that instead of storing an actor’s state you persist the changes that are applied to it. These changes are immutable facts that are appended to a journal, which allows for very high transaction rates and efficient replication. Stateful actors are recovered by replaying stored changes, rebuilding the actors’ internal state.

Akka Persistence features in 2.3-M1 include:

• event sourcing and command sourcing
• automated and explicit recovery
• state snapshots to reduce recovery times
• journal and snapshot store plugin APIs
• channels as gateways to other services
• persistent FSMs

Current focus is on API and functionality, to get early user feedback. Performance optimizations will be done in later milestones.

Other notable features in this release are:

• Detection of when cluster nodes become reachable again after having been unreachable, allowing the cluster to heal again. This makes the cluster more resilient to transient network failures and long garbage collection pauses.

• Automatic removal of cluster nodes after a configured time period of unreachability (replaces the previously immediate “auto-down” feature to allow some time for nodes to come back).

• Routers have been cleaned up and enhanced. The routing logic has been extracted to be usable within normal actors as well. Some usability problems have been solved, such as properly rejecting invalid configuration combinations. Routees can be dynamically added and removed by sending special management messages to the router.

• Cluster routers with multiple routee paths per node.

• Aggregator pattern, contributed by Akara Sucharitakul.

• Several scalability improvements of clustering and remoting.
  

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

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”.

Take it for a spin!

Website:

http://akka.io

Maven repository:

http://repo.akka.io/releases

Binary distribution:

http://akka.io/downloads/

Documentation:

http://doc.akka.io/docs/akka/2.3-M1/

http://doc.akka.io/api/akka/2.3-M1/

http://doc.akka.io/japi/akka/2.3-M1/

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.

v2.2.1 compared to Akka v2.3-M1:

• 51 tickets closed, see 2.3-M1 milestone in Assembla 
• 344 files changed, 50208 insertions(+), 12098 deletions(-)
• … and a total of 24 committers!

Credits:

commits added removed

  60   12357    7901 Patrik Nordwall

  23    1642     311 Endre Sándor Varga

  15   25194    2817 Björn Antonsson

   8      49      30 Roland Kuhn

   7   11027    1563 Martin Krasser

   5     199     177 Viktor Klang

   3      67      12 Johannes Rudolph

   3     302     119 Mathias

   1       1       1 Luc Perkins

   1      49      21 Josh Suereth

   1       6       0 Mark "Justin" Waks

   1       1       1 Joa Ebert

   1      16      11 Taylor Leese

   1       1       1 oakwhiz

   1       0       5 Nilanjan Raychaudhuri

   1       1       1 Francois Armand

   1       2       1 Andrey Stepachev

   1       1       1 Levi Notik

   1      13       0 Michael Pollmeier

   1      39      42 Gustav Åkesson

   1     114       6 Ian Wormsbecker

   1     691       0 Akara Sucharitakul

   1       1       1 Jonas Bonér

   1       2       2 dave

Happy hakking!

--

Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

[Ryan Tanner]

I'm excited about the aggregator pattern.  Our early attempts to solve that problem revolved around a massive for-comprehension of ask()s to child actor.  We managed to avoid mutating internal state but we ran into all sorts of other problems (including one we like to term "rogue concurrency") and eventually replaced it with an FSM.  We're happy with our current solution but there's definitely some unnecessary repetition I'd like to remove.

[√iktor Ҡlang]

Woot!

So much niceties in the upcoming 2.3!

Cheers,

√

--
You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Cheers,

√

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang

[Andrew Easter]

Really excited about the event sourcing support enabled by akka-persistence. I think it's a real game changer - CQRS and event sourcing together provide a really compelling alternative to the typical "defacto" CRUD based approaches, and combining the power of the Actor model with these patterns gives a really accessible way for people to start exploring new ways of building their application domain layer.

Awesome work, team.

[Roland Kuhn]

18 okt 2013 kl. 17:52 skrev Andrew Easter:

Really excited about the event sourcing support enabled by akka-persistence. I think it's a real game changer - CQRS and event sourcing together provide a really compelling alternative to the typical "defacto" CRUD based approaches, and combining the power of the Actor model with these patterns gives a really accessible way for people to start exploring new ways of building their application domain layer.

Yes, this is definitely the part to be most excited about. We want this to be simply awesome (a.k.a. game changer), so please try it out and give feedback while the API is still being formed and hardened.

Awesome work, team.

Indeed! (says the one who is currently more observing than in the thick of it)

It is great to have such a community as well :-)

Regards,

Roland

--
You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.
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

[Martin Krasser]

Hi,

I'd like to add some comments regarding akka-persistence performance and limitations of the current EventsourcedProcessor implementation. The following numbers were obtained running simple performance tests on a 2013 MBP with a LevelDB Java port as journal, using default JVM settings.

Command sourcing (i.e. sending Persistent messages to a Processor directly):

- throughput is 30-50k persistent messages per second
- a Processor actor can already be used under high load

Event sourcing (i.e. sending non-persistent commands to an EventsourcedProcessor, which internally persists events):

- an EventsourcedProcessor currently cannot be used under high load (throughput decreases)
- throughput currently very limited (< 4k persistent events per second).

I started to work on an optimization of EventsourcedProcessor where initial results show a throughput of approx. 15k commands per second (without decreasing under high load). This is approx. 1/3 of command sourcing (the test generated 1 persistent event per command). The optimization replaces the current stash-based approach with an internal command buffer actor that is communicated with using an ack protocol. This optimization will be available with the next (milestone) release and I'll see if I can push throughput further.

Except for the described event sourcing performance optimizations, no further optimization work has been done yet on akka-persistence. In this context, the performance numbers, especially for command sourcing, are a good starting point IMO. There's lot of room for further optimizations on which we'll work for upcoming releases.

Cheers,
Martin

[Carsten Saathoff]

Hi,

very nice, looking forward to playing around with this milestone.

But one question:

Am Samstag, 19. Oktober 2013 08:24:54 UTC+2 schrieb Martin Krasser:

Command sourcing (i.e. sending Persistent messages to a Processor directly):

- throughput is 30-50k persistent messages per second
- a Processor actor can already be used under high load

Is that throughput per Processor or per system? I assume it's primarily limited by the writing speed of the log, right?

best

Carsten

[Martin Krasser]

Hi Carsten,

Your assumption is right, it is per system.
 

best

Carsten

[Roland Kuhn]

Hi Martin,

In case of event sourcing the trouble is the round-trip during which the actor is idle, right? Which means that multiple event processors would aggregate up to the same rate as you measured for command sourcing.

Regards,

Roland

 

best

Carsten

--
>>>>>>>>>> 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]

Hi Roland,

no, the problem are the stash/unstash operations while persisting events: For example, when sending 5 commands (cmd-${i}) to an eventsourced

- cmd-1 is processed, cmd-2 - cmd-5 get stashed, and then unstashed when the events (created by cmd-1) are persisted. Then,
- cmd-2 is processed, cmd-3 - cmd-5 get stashed, and so on ...

i.e. in the worst case you have n * (n-1) stash operations and re-receives of commands by the eventsourced processor. I'm currently fixing this by replacing stash/unstash with a command buffer actor that is asked to deliver the next command when an event has been persisted. This is comparable to a peek mailbox.

With the new solution, the throughput of multiple event sourced processors should aggregate up to that of command sourcing, but I didn't measure that yet.

You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.

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