Re: [Lift] Re: Actor.timer daemon thread terminates after first request?
On Tue, Jan 19, 2010 at 11:58 PM, Yu-Shan Fung wrote:
> Thanks for the reply, David!
>
> I finally realized my problem is that I was compiling against the scala
> 2.7.3 library instead of 2.7.7 as I thought. When I use the newer lib, the
> exception apparently goes away.
>
Scala is very version sensitive. If you're using Lift 1.1-M5+, you must use
Scala 2.7.7. If you're using Lift 1.0.2, I think the correct version is
2.7.5.
>
> Regardless, what would be a good replacement for the scala actors library?
>
Akka: akkasource.org
>
> Thanks,
> Yu-Shan
>
>
> On Tue, Jan 19, 2010 at 8:44 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Howdy,
>>
>> The short (and not politically popular) answer is that Scala's Actor
>> implementation is generally fragile and often broken. Lift made the painful
>> switch away from Scala Actors 4 or so months ago for this reason.
>>
>> If you can put together a simple example of the failure (basically
>> something that we can run with mvn jetty:run) and make it available on
>> GitHub, we can take a look at it.
>>
>> Thanks,
>>
>> David
>>
>> On Tue, Jan 19, 2010 at 5:02 PM, Yu-Shan Fung wrote:
>>
>>> Thanks for the reply, Marius. Where can I get the 1.1 or 2.0 snapshot?
>>>
>>> I'm not doing any scheduling myself. I just created a bunch of Future's,
>>> and then call Futures.awaitAll. But my understanding is that Future is
>>> implemented with Actor's.
>>>
>>> val fResults = ids.map { id => future(computeStuff(id)) }
>>> val fList = fResults.toList // forces creation of the future
>>> variables. otherwise they are created lazily, defeating parallelism
>>> val finalResults = Futures.awaitAll(5000, fList: _*)
>>>
>>> This works the first time (and sometimes for a few times). But pretty
>>> soon, the call to awaitAll would fail with the aforementioned exception.
>>>
>>> I dug a bit into the scala code, and the code that fails within
>>> Futures.awaitAll is this:
>>>
>>>Actor.timer.schedule(new java.util.TimerTask {
>>> def run() { thisActor ! TIMEOUT }
>>>}, timeout)
>>>
>>> And Actor.timer is defined as such:
>>>
>>> object Actor {
>>> ...
>>> private[actors] val timer = new Timer(true)
>>> ...
>>> }
>>>
>>>
>>> I'm pretty new to both scala and lift, but it looks like the Actor.timer
>>> is initialized once (created as a daemon), and expected to always be
>>> available. But I don't fully understand what aspects of the lift environment
>>> persists across requests, and how, if at all, would Actor.timer end up in a
>>> cancelled/terminated state.
>>>
>>> Any idea? Thanks in advance!
>>>
>>>
>>>
>>>
>>> On Tue, Jan 19, 2010 at 6:40 AM, Marius wrote:
>>>
I'd recommend using Lisft 1.1-SNAPSHOT or 2.0-SNAPSHOT
You stacktrace doesn't indicate anything related with Lift, so are you
using Java's scheduler, or are you using actors? Lift's ActorPing and
actors is a good way of doing scheduling. So can you elaborate on how
are you doing the scheduling?
Br's,
Marius
On Jan 19, 8:04 am, Yu-Shan Fung wrote:
> Hi All,
>
> I have a lift app, where one of the functions performs
sub-computations
> (including network operations) in parallel via future(s) &
Futures.awaitAll.
> It runs fine on the first request, but subsequent requests throws a
> IllegalStateException:
>
> Exception in thread "Thread-30" java.lang.IllegalStateException: Timer
> already cancelled.
> at java.util.Timer.sched(Timer.java:376)
> at java.util.Timer.schedule(Timer.java:192)
> at scala.actors.Futures$.awaitAll(Future.scala:76)
> at MyWorker.run(MyWorker.scala:20)
> at java.lang.Thread.run(Thread.java:636)
>
> I dug up more documentation and it looks like this exception indicates
an
> attempt to schedule a task on a timer that has already been cancelled
> (associated daemon thread terminated?). Any idea why, or if I'm doing
> something wrong?
>
> In case it matters, I'm running Scala code runner version 2.7.7.final,
> Liftweb 1.0, Jetty 6.1.22.
>
> Any tips/pointers would be appreciated. Thanks!
> Yu-Shan
>
> --
> “When nothing seems to help, I go look at a stonecutter hammering away
at
> his rock perhaps a hundred times without as much as a crack showing in
it.
> Yet at the hundred and first blow it will split in two, and I know it
was
> not that blow that did it, but all that had gone before.” — Jacob Riis
--
You received this message because you are subscribed to the Google
Groups "Lift" group.
To post to this group, send email to lift...@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.
>
Re: [Lift] Re: Actor.timer daemon thread terminates after first request?
Thanks for the reply, David!
I finally realized my problem is that I was compiling against the scala
2.7.3 library instead of 2.7.7 as I thought. When I use the newer lib, the
exception apparently goes away.
Regardless, what would be a good replacement for the scala actors library?
Thanks,
Yu-Shan
On Tue, Jan 19, 2010 at 8:44 PM, David Pollak wrote:
> Howdy,
>
> The short (and not politically popular) answer is that Scala's Actor
> implementation is generally fragile and often broken. Lift made the painful
> switch away from Scala Actors 4 or so months ago for this reason.
>
> If you can put together a simple example of the failure (basically
> something that we can run with mvn jetty:run) and make it available on
> GitHub, we can take a look at it.
>
> Thanks,
>
> David
>
> On Tue, Jan 19, 2010 at 5:02 PM, Yu-Shan Fung wrote:
>
>> Thanks for the reply, Marius. Where can I get the 1.1 or 2.0 snapshot?
>>
>> I'm not doing any scheduling myself. I just created a bunch of Future's,
>> and then call Futures.awaitAll. But my understanding is that Future is
>> implemented with Actor's.
>>
>> val fResults = ids.map { id => future(computeStuff(id)) }
>> val fList = fResults.toList // forces creation of the future
>> variables. otherwise they are created lazily, defeating parallelism
>> val finalResults = Futures.awaitAll(5000, fList: _*)
>>
>> This works the first time (and sometimes for a few times). But pretty
>> soon, the call to awaitAll would fail with the aforementioned exception.
>>
>> I dug a bit into the scala code, and the code that fails within
>> Futures.awaitAll is this:
>>
>>Actor.timer.schedule(new java.util.TimerTask {
>> def run() { thisActor ! TIMEOUT }
>>}, timeout)
>>
>> And Actor.timer is defined as such:
>>
>> object Actor {
>> ...
>> private[actors] val timer = new Timer(true)
>> ...
>> }
>>
>>
>> I'm pretty new to both scala and lift, but it looks like the Actor.timer
>> is initialized once (created as a daemon), and expected to always be
>> available. But I don't fully understand what aspects of the lift environment
>> persists across requests, and how, if at all, would Actor.timer end up in a
>> cancelled/terminated state.
>>
>> Any idea? Thanks in advance!
>>
>>
>>
>>
>> On Tue, Jan 19, 2010 at 6:40 AM, Marius wrote:
>>
>>> I'd recommend using Lisft 1.1-SNAPSHOT or 2.0-SNAPSHOT
>>>
>>> You stacktrace doesn't indicate anything related with Lift, so are you
>>> using Java's scheduler, or are you using actors? Lift's ActorPing and
>>> actors is a good way of doing scheduling. So can you elaborate on how
>>> are you doing the scheduling?
>>>
>>> Br's,
>>> Marius
>>>
>>> On Jan 19, 8:04 am, Yu-Shan Fung wrote:
>>> > Hi All,
>>> >
>>> > I have a lift app, where one of the functions performs sub-computations
>>> > (including network operations) in parallel via future(s) &
>>> Futures.awaitAll.
>>> > It runs fine on the first request, but subsequent requests throws a
>>> > IllegalStateException:
>>> >
>>> > Exception in thread "Thread-30" java.lang.IllegalStateException: Timer
>>> > already cancelled.
>>> > at java.util.Timer.sched(Timer.java:376)
>>> > at java.util.Timer.schedule(Timer.java:192)
>>> > at scala.actors.Futures$.awaitAll(Future.scala:76)
>>> > at MyWorker.run(MyWorker.scala:20)
>>> > at java.lang.Thread.run(Thread.java:636)
>>> >
>>> > I dug up more documentation and it looks like this exception indicates
>>> an
>>> > attempt to schedule a task on a timer that has already been cancelled
>>> > (associated daemon thread terminated?). Any idea why, or if I'm doing
>>> > something wrong?
>>> >
>>> > In case it matters, I'm running Scala code runner version 2.7.7.final,
>>> > Liftweb 1.0, Jetty 6.1.22.
>>> >
>>> > Any tips/pointers would be appreciated. Thanks!
>>> > Yu-Shan
>>> >
>>> > --
>>> > “When nothing seems to help, I go look at a stonecutter hammering away
>>> at
>>> > his rock perhaps a hundred times without as much as a crack showing in
>>> it.
>>> > Yet at the hundred and first blow it will split in two, and I know it
>>> was
>>> > not that blow that did it, but all that had gone before.” — Jacob Riis
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@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.
>>>
>>>
>>>
>>>
>>
>>
>> --
>> “When nothing seems to help, I go look at a stonecutter hammering away at
>> his rock perhaps a hundred times without as much as a crack showing in it.
>> Yet at the hundred and first blow it will split in two, and I know it was
>> not that blow that did it, but all that had gone before.” — Jacob Riis
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>>
Re: [Lift] Re: Actor.timer daemon thread terminates after first request?
Howdy,
The short (and not politically popular) answer is that Scala's Actor
implementation is generally fragile and often broken. Lift made the painful
switch away from Scala Actors 4 or so months ago for this reason.
If you can put together a simple example of the failure (basically something
that we can run with mvn jetty:run) and make it available on GitHub, we can
take a look at it.
Thanks,
David
On Tue, Jan 19, 2010 at 5:02 PM, Yu-Shan Fung wrote:
> Thanks for the reply, Marius. Where can I get the 1.1 or 2.0 snapshot?
>
> I'm not doing any scheduling myself. I just created a bunch of Future's,
> and then call Futures.awaitAll. But my understanding is that Future is
> implemented with Actor's.
>
> val fResults = ids.map { id => future(computeStuff(id)) }
> val fList = fResults.toList // forces creation of the future
> variables. otherwise they are created lazily, defeating parallelism
> val finalResults = Futures.awaitAll(5000, fList: _*)
>
> This works the first time (and sometimes for a few times). But pretty soon,
> the call to awaitAll would fail with the aforementioned exception.
>
> I dug a bit into the scala code, and the code that fails within
> Futures.awaitAll is this:
>
>Actor.timer.schedule(new java.util.TimerTask {
> def run() { thisActor ! TIMEOUT }
>}, timeout)
>
> And Actor.timer is defined as such:
>
> object Actor {
> ...
> private[actors] val timer = new Timer(true)
> ...
> }
>
>
> I'm pretty new to both scala and lift, but it looks like the Actor.timer is
> initialized once (created as a daemon), and expected to always be available.
> But I don't fully understand what aspects of the lift environment persists
> across requests, and how, if at all, would Actor.timer end up in a
> cancelled/terminated state.
>
> Any idea? Thanks in advance!
>
>
>
>
> On Tue, Jan 19, 2010 at 6:40 AM, Marius wrote:
>
>> I'd recommend using Lisft 1.1-SNAPSHOT or 2.0-SNAPSHOT
>>
>> You stacktrace doesn't indicate anything related with Lift, so are you
>> using Java's scheduler, or are you using actors? Lift's ActorPing and
>> actors is a good way of doing scheduling. So can you elaborate on how
>> are you doing the scheduling?
>>
>> Br's,
>> Marius
>>
>> On Jan 19, 8:04 am, Yu-Shan Fung wrote:
>> > Hi All,
>> >
>> > I have a lift app, where one of the functions performs sub-computations
>> > (including network operations) in parallel via future(s) &
>> Futures.awaitAll.
>> > It runs fine on the first request, but subsequent requests throws a
>> > IllegalStateException:
>> >
>> > Exception in thread "Thread-30" java.lang.IllegalStateException: Timer
>> > already cancelled.
>> > at java.util.Timer.sched(Timer.java:376)
>> > at java.util.Timer.schedule(Timer.java:192)
>> > at scala.actors.Futures$.awaitAll(Future.scala:76)
>> > at MyWorker.run(MyWorker.scala:20)
>> > at java.lang.Thread.run(Thread.java:636)
>> >
>> > I dug up more documentation and it looks like this exception indicates
>> an
>> > attempt to schedule a task on a timer that has already been cancelled
>> > (associated daemon thread terminated?). Any idea why, or if I'm doing
>> > something wrong?
>> >
>> > In case it matters, I'm running Scala code runner version 2.7.7.final,
>> > Liftweb 1.0, Jetty 6.1.22.
>> >
>> > Any tips/pointers would be appreciated. Thanks!
>> > Yu-Shan
>> >
>> > --
>> > “When nothing seems to help, I go look at a stonecutter hammering away
>> at
>> > his rock perhaps a hundred times without as much as a crack showing in
>> it.
>> > Yet at the hundred and first blow it will split in two, and I know it
>> was
>> > not that blow that did it, but all that had gone before.” — Jacob Riis
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@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.
>>
>>
>>
>>
>
>
> --
> “When nothing seems to help, I go look at a stonecutter hammering away at
> his rock perhaps a hundred times without as much as a crack showing in it.
> Yet at the hundred and first blow it will split in two, and I know it was
> not that blow that did it, but all that had gone before.” — Jacob Riis
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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.
>
--
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
--
You received this message because you are subscribed to the Google Groups
Re: [Lift] Re: Actor.timer daemon thread terminates after first request?
Thanks for the reply, Marius. Where can I get the 1.1 or 2.0 snapshot?
I'm not doing any scheduling myself. I just created a bunch of Future's, and
then call Futures.awaitAll. But my understanding is that Future is
implemented with Actor's.
val fResults = ids.map { id => future(computeStuff(id)) }
val fList = fResults.toList // forces creation of the future
variables. otherwise they are created lazily, defeating parallelism
val finalResults = Futures.awaitAll(5000, fList: _*)
This works the first time (and sometimes for a few times). But pretty soon,
the call to awaitAll would fail with the aforementioned exception.
I dug a bit into the scala code, and the code that fails within
Futures.awaitAll is this:
Actor.timer.schedule(new java.util.TimerTask {
def run() { thisActor ! TIMEOUT }
}, timeout)
And Actor.timer is defined as such:
object Actor {
...
private[actors] val timer = new Timer(true)
...
}
I'm pretty new to both scala and lift, but it looks like the Actor.timer is
initialized once (created as a daemon), and expected to always be available.
But I don't fully understand what aspects of the lift environment persists
across requests, and how, if at all, would Actor.timer end up in a
cancelled/terminated state.
Any idea? Thanks in advance!
On Tue, Jan 19, 2010 at 6:40 AM, Marius wrote:
> I'd recommend using Lisft 1.1-SNAPSHOT or 2.0-SNAPSHOT
>
> You stacktrace doesn't indicate anything related with Lift, so are you
> using Java's scheduler, or are you using actors? Lift's ActorPing and
> actors is a good way of doing scheduling. So can you elaborate on how
> are you doing the scheduling?
>
> Br's,
> Marius
>
> On Jan 19, 8:04 am, Yu-Shan Fung wrote:
> > Hi All,
> >
> > I have a lift app, where one of the functions performs sub-computations
> > (including network operations) in parallel via future(s) &
> Futures.awaitAll.
> > It runs fine on the first request, but subsequent requests throws a
> > IllegalStateException:
> >
> > Exception in thread "Thread-30" java.lang.IllegalStateException: Timer
> > already cancelled.
> > at java.util.Timer.sched(Timer.java:376)
> > at java.util.Timer.schedule(Timer.java:192)
> > at scala.actors.Futures$.awaitAll(Future.scala:76)
> > at MyWorker.run(MyWorker.scala:20)
> > at java.lang.Thread.run(Thread.java:636)
> >
> > I dug up more documentation and it looks like this exception indicates an
> > attempt to schedule a task on a timer that has already been cancelled
> > (associated daemon thread terminated?). Any idea why, or if I'm doing
> > something wrong?
> >
> > In case it matters, I'm running Scala code runner version 2.7.7.final,
> > Liftweb 1.0, Jetty 6.1.22.
> >
> > Any tips/pointers would be appreciated. Thanks!
> > Yu-Shan
> >
> > --
> > “When nothing seems to help, I go look at a stonecutter hammering away at
> > his rock perhaps a hundred times without as much as a crack showing in
> it.
> > Yet at the hundred and first blow it will split in two, and I know it was
> > not that blow that did it, but all that had gone before.” — Jacob Riis
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@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.
>
>
>
>
--
“When nothing seems to help, I go look at a stonecutter hammering away at
his rock perhaps a hundred times without as much as a crack showing in it.
Yet at the hundred and first blow it will split in two, and I know it was
not that blow that did it, but all that had gone before.” — Jacob Riis
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@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.
[Lift] Re: Actor.timer daemon thread terminates after first request?
I'd recommend using Lisft 1.1-SNAPSHOT or 2.0-SNAPSHOT You stacktrace doesn't indicate anything related with Lift, so are you using Java's scheduler, or are you using actors? Lift's ActorPing and actors is a good way of doing scheduling. So can you elaborate on how are you doing the scheduling? Br's, Marius On Jan 19, 8:04 am, Yu-Shan Fung wrote: > Hi All, > > I have a lift app, where one of the functions performs sub-computations > (including network operations) in parallel via future(s) & Futures.awaitAll. > It runs fine on the first request, but subsequent requests throws a > IllegalStateException: > > Exception in thread "Thread-30" java.lang.IllegalStateException: Timer > already cancelled. > at java.util.Timer.sched(Timer.java:376) > at java.util.Timer.schedule(Timer.java:192) > at scala.actors.Futures$.awaitAll(Future.scala:76) > at MyWorker.run(MyWorker.scala:20) > at java.lang.Thread.run(Thread.java:636) > > I dug up more documentation and it looks like this exception indicates an > attempt to schedule a task on a timer that has already been cancelled > (associated daemon thread terminated?). Any idea why, or if I'm doing > something wrong? > > In case it matters, I'm running Scala code runner version 2.7.7.final, > Liftweb 1.0, Jetty 6.1.22. > > Any tips/pointers would be appreciated. Thanks! > Yu-Shan > > -- > “When nothing seems to help, I go look at a stonecutter hammering away at > his rock perhaps a hundred times without as much as a crack showing in it. > Yet at the hundred and first blow it will split in two, and I know it was > not that blow that did it, but all that had gone before.” — Jacob Riis -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@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.
