Hi Josh,

I don't think it is such a bad sign that multiple actor libraries are
popping up. There isn't one way to write actors. There are many. List
seems to create lots of very short-lived actors if I have understood
that correctly. Nothing wrong with that, but it doesn't mean that all
implementations of the actor concept must absolutely support that use
case. Some actors can be tuned to be short lived creatures, others
designed for more stable, longer lives. Some actors can be designed
primarily for being in one VM, others for existing in distributed
systems, etc. Scala's focus on letting people design things in
libraries is exactly why it is possible to do multiple actor designs.
In Erlang it might not be as easy.

That said, it would be nice to get the memory leak problem solved in
Scala actors, and I'm confident that will happen eventually. But I use
one simple Scala actor in ScalaTest and it works just fine for my use
case, which is to collect events fired during parallel runs, serialize
them, and report them in various ways. There's just one actor for each
ScalaTest run, so I have no memory leak problem. I probably will
remove that actor eventually though, not because of any problems with
the implementation but just because I suspect it isn't the best fit

On Tue, Sep 29, 2009 at 7:37 PM, Josh Suereth <joshua.suer...@gmail.com> wrote:
> 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?
> - 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
> >

Bill Venners
Artima, Inc.

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 
For more options, visit this group at 

Reply via email to