Hi Bill. Here is a list of the things that Akka currently does (and that are not in Scala Actors) and what I see needed in a production actor based system (not all in all projects though).
Transactors: Marriage of Actors and STM. Allows, ACI (Atomic, Consistent & Isolated) compositional message flows. IMO the best of both worlds, since just actors is not sufficient in many scenarios. STM is based on persistent datastructures and managed references. Supervisor hierarchies: Declarative and programatic API with same API and semantics as in Erlang. This is IMO the most interesting part of Actors and is fantastic to build fault-tolerant systems. This was the goal of Scala OTP, but I have rewritten it and is much better now. Pluggable message dispatchers: Thread-based, event-based, single-thread-event-based. With DSL for building and configuring up thread-pools etc. Even concurrent mode which abandons the Actor model contract for best performance (if needed). This exists to some extent in Scala Actors, but not as open as easily configured. Pluggable messagequeue implementation: Choose between LinkedBlockingQueue, SynchronousQueue, ArrayBlockingQueue. Bounded or unbounded, with different back-off strategies and more. NIO-based remote actors: High-performance nio impl based on Netty and Protobuf. Actor supervision (linking) for fault-tolerance works across remote machines as expected. Java API: Through Active Objects. Use plain POJOs which are turned into asynchronous non-blocking “actors” using bytecode munging. RESTful Actors: Expose Actors as restful services through JAX-RS. Persistent Actors: Pluggable persistence. Currently supporting Cassandra and MongoDB. More to come. Works with the STM to create ACI *D* e.g. durable, persistent actors. Persistent messagequeue is on its way. Monitoring and mangament: Through JMX and REST. Allows you to monitor and manage all moving parts including internals such as messagequeues, dispatchers etc. Can be used as a standalone kernel or as a library in webapps etc. That pretty much sums it up. /Jonas 2009/9/30 Bill Venners <b...@artima.com>: > > Hi Jonas, > > Can you list what the "things Akka implements now" are that Scala > actors don't have? > > Thanks. > > Bill > > On Wed, Sep 30, 2009 at 4:34 AM, Jonas Bonér <jbo...@gmail.com> wrote: >> >> 2009/9/30 Josh Suereth <joshua.suer...@gmail.com>: >>> As much as I agree with your decision, it just makes me sad. I know lots >>> of people that learned scala for "actors are the way of the future".... I >>> think we need to push harder. Hopefully all major projects migrating off >>> actors will give EPFL a wake up call? >> >> This is the reason I created Akka, to have a standard platform for >> Actors with all the things one need to write production applications. >> Akka already have 4 committers and honestly, looking at the pace EPFL >> has had with bugfixing, features etc I think they will have a very >> hard time keep up with what the market needs. I have unfortunately >> given up up the Scala Actors library. I need the things Akka >> implements now and don't have time to wait indefinitely. >> >>> >>> - Josh >>> >>> On Tue, Sep 29, 2009 at 1:41 PM, David Pollak >>> <feeder.of.the.be...@gmail.com> wrote: >>>> >>>> >>>> On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck <stuart.roeb...@gmail.com> >>>> wrote: >>>>> >>>>> Apologies if I've missed something obvious but my web search hasn't >>>>> turned anything up... >>>>> >>>>> What are the Scala Actors instability issues? I'm in the process of >>>>> doing some major Scala development work and this comment raises >>>>> concerns that I'd like to understand. >>>> >>>> The issues (with the Scala Actors in general and Lift's use of them) are: >>>> >>>> Scala Actors use a custom version of Doug Leah's Fork/Join library. This >>>> was necessary for JDK 1.4 support. With JDK 1.5, the java.util.concurrent >>>> stuff should have been used. I was led to understand that this change was >>>> made in Scala 2.7.5, but it was not and even the Scala 2.8 stuff still >>>> contains fork-join. The FJ library has a memory retention issue where it >>>> trades memory for non-locking performance and, with many threads in a >>>> thread-pool, this leads to out of memory issues. >>>> The Scala Actor code is very brittle. >>>> See http://erikengbrecht.blogspot.com/2009/01/refactoring-scala-actors.html >>>> The code has not been materially refactored, which means that even in 2.8, >>>> there will be significant potential problems with the Actors. Those >>>> potential problems have manifest themselves as real problems in 2.7.x. I >>>> have spent in aggregate nearly 3 weeks of my time since November 2008 >>>> working around the defects in the Actor library. It's easier to have our >>>> own Actors (the current Actor library is about 2 days of work on my part >>>> and >>>> the refactoring of Lift to work with the existing Actor library is another >>>> 2 >>>> days of work.) >>>> EPFL has been generally slow to respond to bug reports. I am very >>>> frustrated and quite frankly tired of having to cajole EPFL into responding >>>> to defects in one of the premier Scala libraries. >>>> >>>> I would strongly suggest that you look at Akka. It's got a better view >>>> and implementation of Actors than does the standard Scala distribution. >>>> Akka >>>> includes support for distributed actors, etc. >>>> Hope this helps. >>>> >>>>> >>>>> Best, >>>>> >>>>> Stuart >>>>> >>>>> On Sep 29, 3:30 am, David Pollak <feeder.of.the.be...@gmail.com> >>>>> wrote: >>>>> > Folks, >>>>> > >>>>> > Given the continued instability of Scala Actors, I've decided to remove >>>>> > them >>>>> > from Lift. >>>>> > >>>>> > Specifically, I'm migrating CometActors to sit on top of Lift's Actors. >>>>> > But, you'll also be able to use Akka Actors to power Lift's >>>>> > CometActors. >>>>> > Specifically, I'm working with Jonas to make sure that we share a >>>>> > common >>>>> > interface to Actors. >>>>> > >>>>> > I've gotten Lift nearly completely migrated over to Lift's Actors on >>>>> > the >>>>> > dpp_wip_actorize branch. >>>>> > Seehttp://github.com/dpp/liftweb/tree/dpp_wip_actorize >>>>> > >>>>> > There will be some breaking changes to your applications. >>>>> > Specifically: >>>>> > >>>>> > - Box will be moved to a new package, net.liftweb.base (this is >>>>> > where the >>>>> > interface for Actors will live as well) >>>>> > - If you make any assumptions about your CometActors being Scala >>>>> > Actors >>>>> > (e.g., using linking), you will have to rewrite this code >>>>> > - Some methods in Lift that currently take Scala Actors as >>>>> > parameters >>>>> > will take Lift Actors (e.g., ActorPing) >>>>> > >>>>> > There will be a parallel Maven repository with the new Lift Actor stuff >>>>> > in >>>>> > it so you will be able to build you apps against the new code before >>>>> > the >>>>> > official switch-over. >>>>> > >>>>> > Milestone 6 (which should be out next week) will be based on the >>>>> > existing >>>>> > Actor model. After we get feedback from the community about the new >>>>> > Actor >>>>> > stuff, we will switch -SNAPSHOT over to the new Actor stuff. >>>>> > >>>>> > Questions, thoughts, or comments? >>>>> > >>>>> > Thanks, >>>>> > >>>>> > David >>>>> > >>>>> > -- >>>>> > Lift, the simply functional web frameworkhttp://liftweb.net >>>>> > Beginning Scalahttp://www.apress.com/book/view/1430219890 >>>>> > Follow me:http://twitter.com/dpp >>>>> > Surf the harmonics >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Lift, the simply functional web framework http://liftweb.net >>>> Beginning Scala http://www.apress.com/book/view/1430219890 >>>> Follow me: http://twitter.com/dpp >>>> Surf the harmonics >>>> >>>> >>> >>> >>> > >>> >> >> >> >> -- >> Jonas Bonér >> >> twitter: @jboner >> blog: http://jonasboner.com >> work: http://crisp.se >> work: http://scalablesolutions.se >> code: http://github.com/jboner >> code: http://akkasource.org >> >> > >> > > > > -- > Bill Venners > Artima, Inc. > http://www.artima.com > > > > -- Jonas Bonér twitter: @jboner blog: http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner code: http://akkasource.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
