Also, its pretty well documented. Read more here: http://akkasource.org/ We need feedback so please let me know what you think.
2009/9/30 Jonas Bonér <[email protected]>: > 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 <[email protected]>: >> >> 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 <[email protected]> wrote: >>> >>> 2009/9/30 Josh Suereth <[email protected]>: >>>> 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 >>>> <[email protected]> wrote: >>>>> >>>>> >>>>> On Tue, Sep 29, 2009 at 2:35 AM, Stuart Roebuck <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 > -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
