[Lift] Re: jetty/actors performance question tangentially related to lift

2009-11-12 Thread Lincoln
Hi, thank you very much for your help so far I really appreciate it.
 Apologies in advance if this thread has become inappropriate since it's not
directly related to Lift.  Just let me know if that's the case and I will
attempt to solve this problem another way.  But, I'm hoping you can help me
some more...

Warning: Long email ahead...

Here's the summary of my load testing results:

Each request in my load test consists of a single save() to mongodb,
followed by a findOne() for the record just written and then an arbitrary
find() for 1000 docs.

I've been experimenting with 3 scenarios:

   1. A single actor processing all requests (this effectively makes things
   single-threaded)
   2. A pool of 50 actors handling requests that are dispatched to via a
   round robin scheduler
   3. Create a new actor on demand for every request.

The load I've been using for all tests is 2000 requests at a concurrency
level of 75.  All the results I'm reporting are averages over 3 executions.

As a benchmark, I ran all these scenarios with the worker stubbed out to
simply sleep for 100ms and then return.  Here are the results when I ran the
benchmark:

   - Single shared worker: 7534.439 ms
   - Shared Pool of 50 workers: 156.190 ms
   - On-demand actor for each request: 127.066 ms

These results are about what I expected.  In the single worker case the
queue quickly backed up and stayed at 74 requests, thus the results were
about the concurrency level (75) multiplied by the work length (100 ms).
 The shared pool was obviously a huge improvement, but the actor on demand
was even better because the concurrency level (75) was greater than the
number of actors in the shared pool (50) and thus there was still some
queueing in that case.

I expected when I ran the tests with the mongodb work plugged in that I
would see results that were roughly proportional to the benchmark.  However,
here's what I got:

   - Single shared worker: 1968.113 ms
   - Shared Pool of 50 workers: 1955.218 ms
   - On-demand actor for each request: 1951.352 ms

For the vast majority of these requests, most of the time for the request is
spent waiting for the actor to receive the work job.  This is the case
regardless of whether I'm using a single actor, a pool, or creating actors
on demand.  In most cases, the mongo work takes 0 - 100 ms but with a
meaningful minority in the 100 - 300ms range.  I think this means the JVM
must be busy with something else while that waiting is happening.

I guess it makes sense that the single-threaded case goes faster since most
of the time the mongodb operations take far less than 100 ms.  However, I
don't understand why I'm not seeing proportional improvement in the pooled
and on-demand scenarios.

Here is the method I'm using to create my actors, whether it be 1, the pool
of 50, or a new one on demand every time:

def worker(n: Int) = actor {
loop {
 react {
case msg @ LoadReq(timer, stats, cont) =
timer.split(react)
 stats(mailboxSize) = mailboxSize.toLong
 val coll = staticColl
 val dbo = (
_msg - blah blah blah 
_event - blah blah blah 
 _user - blah blah blah 
_name - Lincoln
)
 coll.save(dbo)
timer.split(save)
 coll.findOne(_name - Lincoln)
 timer.split(findOne)
 val res = coll.find().limit(1000).toArray
 timer.split(findAll)

// timer.split(sleep)
cont.setAttribute(Base.CONTINUATION_RESP, LoadResp(timer, stats))
 cont.resume
 case other = trace(worker discarded: +other)
 }
}
}

I took a kill -3 while my load test was running and I saw a lot of these:

qtp1491907201-104 prio=5 tid=0x000102278800 nid=0x153199000 runnable
[0x000153198000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
 - parking to wait for  0x000108bca370 (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
 at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1963)
at
org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:319)
 at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:450)
at java.lang.Thread.run(Thread.java:637)

I also used jstat throughout:

Timestamp S0 S1 E  O  P YGC YGCTFGC
 FGCT GCT
  161.8 100.00   0.00   0.00  68.15  60.181029.215 2
 0.0229.237
  166.8 100.00   0.00  10.04  28.97  60.32134   12.083 4
 0.049   12.132
  171.8 100.00   0.00  60.79  68.23  60.06172   14.904 4
 0.049   14.952
  176.8   0.00 100.00 100.00   4.04  59.87191   17.437 7
 1.362   18.799
  181.8 100.00   0.00   2.12   4.56  59.88196   18.363 8
 1.712   20.075
  186.8 100.00   0.00   4.62   4.56  59.88196   18.363 8
 1.712   20.075
  191.8 100.00   0.00   4.65   4.56  59.88196   18.363 8
 1.712   20.075

Am I reading this correctly that it's

[Lift] Re: jetty/actors performance question tangentially related to lift

2009-11-12 Thread Lincoln

Thanks David, I will give Lift Actors a try.  Mongodb is supposedly
using a connection pool behind the scenes so it isn't supposed to
matter whether I create 1 or many connection objects, but I will check
the source as I'm not 100% sure.

Thanks,
Lincoln

On Thu, Nov 12, 2009 at 8:05 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
 This is getting off-topic but...

 I think the issue is that there's a single connection or a single thread
 accessing MongoDB.  I'd suggest trying a connection pool to MongoDB or to
 otherwise see why the MongoDB stuff is not getting parallelized.

 Also, Scala Actors do a lot of fancy stuff in terms of scheduling... you
 might want to try the same benchmarks with Lift Actors and see if there's a
 difference.

 On Thu, Nov 12, 2009 at 4:48 PM, Lincoln linxbet...@gmail.com wrote:

 Hi, thank you very much for your help so far I really appreciate it.
  Apologies in advance if this thread has become inappropriate since it's not
 directly related to Lift.  Just let me know if that's the case and I will
 attempt to solve this problem another way.  But, I'm hoping you can help me
 some more...
 Warning: Long email ahead...
 Here's the summary of my load testing results:
 Each request in my load test consists of a single save() to mongodb,
 followed by a findOne() for the record just written and then an arbitrary
 find() for 1000 docs.

 I've been experimenting with 3 scenarios:

 A single actor processing all requests (this effectively makes things
 single-threaded)
 A pool of 50 actors handling requests that are dispatched to via a round
 robin scheduler
 Create a new actor on demand for every request.

 The load I've been using for all tests is 2000 requests at a concurrency
 level of 75.  All the results I'm reporting are averages over 3 executions.
 As a benchmark, I ran all these scenarios with the worker stubbed out to
 simply sleep for 100ms and then return.  Here are the results when I ran the
 benchmark:

 Single shared worker: 7534.439 ms
 Shared Pool of 50 workers: 156.190 ms
 On-demand actor for each request: 127.066 ms

 These results are about what I expected.  In the single worker case the
 queue quickly backed up and stayed at 74 requests, thus the results were
 about the concurrency level (75) multiplied by the work length (100 ms).
  The shared pool was obviously a huge improvement, but the actor on demand
 was even better because the concurrency level (75) was greater than the
 number of actors in the shared pool (50) and thus there was still some
 queueing in that case.
 I expected when I ran the tests with the mongodb work plugged in that I
 would see results that were roughly proportional to the benchmark.  However,
 here's what I got:

 Single shared worker: 1968.113 ms
 Shared Pool of 50 workers: 1955.218 ms
 On-demand actor for each request: 1951.352 ms

 For the vast majority of these requests, most of the time for the request
 is spent waiting for the actor to receive the work job.  This is the case
 regardless of whether I'm using a single actor, a pool, or creating actors
 on demand.  In most cases, the mongo work takes 0 - 100 ms but with a
 meaningful minority in the 100 - 300ms range.  I think this means the JVM
 must be busy with something else while that waiting is happening.
 I guess it makes sense that the single-threaded case goes faster since
 most of the time the mongodb operations take far less than 100 ms.  However,
 I don't understand why I'm not seeing proportional improvement in the pooled
 and on-demand scenarios.
 Here is the method I'm using to create my actors, whether it be 1, the
 pool of 50, or a new one on demand every time:
 def worker(n: Int) = actor {
 loop {
 react {
 case msg @ LoadReq(timer, stats, cont) =
 timer.split(react)
 stats(mailboxSize) = mailboxSize.toLong
 val coll = staticColl
 val dbo = (
 _msg - blah blah blah 
 _event - blah blah blah 
 _user - blah blah blah 
 _name - Lincoln
 )
 coll.save(dbo)
 timer.split(save)
 coll.findOne(_name - Lincoln)
 timer.split(findOne)
 val res = coll.find().limit(1000).toArray
 timer.split(findAll)
 // timer.split(sleep)
 cont.setAttribute(Base.CONTINUATION_RESP, LoadResp(timer, stats))
 cont.resume
 case other = trace(worker discarded: +other)
 }
 }
 }
 I took a kill -3 while my load test was running and I saw a lot of these:
 qtp1491907201-104 prio=5 tid=0x000102278800 nid=0x153199000 runnable
 [0x000153198000]
    java.lang.Thread.State: TIMED_WAITING (parking)
 at sun.misc.Unsafe.park(Native Method)
 - parking to wait for  0x000108bca370 (a
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
 at
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1963)
 at
 org.eclipse.jetty.util.BlockingArrayQueue.poll(BlockingArrayQueue.java:319)
 at
 org.eclipse.jetty.util.thread.QueuedThreadPool$2.run

[Lift] jetty/actors performance question tangentially related to lift

2009-11-08 Thread Lincoln

Hi,

Currently I have a jetty webapp that uses continuations and actors to
scale to many connections. While this isn't a lift question per se I
was hoping the folks on this list could help since it's my
understanding that Lift does similar stuff under certain setups.

Basically, the functionality that I'm testing receives a request,
suspends it via jetty continuations, and fires it off to an actor for
processing.  Once the work is done (some benchmark database requests,
usually on the order of 10 to 100ms) the continuation is resumed and
results are returned.

As I scale up to 1000+ concurrents in apache benchmark, I notice that
the vast majority of time from receipt of the request to response, is
between when the continuation is suspended and when my actor receives
the message.  This strikes me as bizarre since I'm monitoring the
mailbox and it never grows to a size larger than 1 or 2.  It gets to
the point where requests are taking 10 seconds to come back and 9.5 of
those seconds are my actor waiting to receive the work request.

Throughout the load test the database does not become stressed.

Any thoughts on this?  I guess I'm hoping there is something basic
that I'm doing wrong.  Just in case, I've tried creating an actor pool
to receive the work requests but that apparently has no effect on the
results.

My only speculation at this point is that perhaps the reason messages
are taking so long to get to my actor is because jetty itself is
overloaded trying to queue requests but that is just a guess.

Thanks,
Lincoln

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



[Lift] Re: jetty/actors performance question tangentially related to lift

2009-11-08 Thread Lincoln

Thanks for the feedback David... I have also created a pool of actors
and dispatch requests round-robin style to it.  Oddly enough, I see
absolutely no difference in the performance characteristics - in both
cases 95% of the time is spent between the suspend and the actor
receiving the request, but the mailbox never grows past a size of 1 or
2.  I will try and send along a simplified version of my code to
illustrate what I'm doing.

Thanks,
Lincoln

On Sun, Nov 8, 2009 at 11:02 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
 If you have all your requests going to 1 actor, then you've reduced your
 application to a single threaded app.

 If you're using Scala Actors, there are all kinds of wacky things that
 happen with the Fork-Join library that the Actors use for scheduling and a
 whole lot of knobs to turn to get the scheduling right depending on your
 number of CPUs, etc.

 But, at the end of the day, if you're just pushing work from one thread (the
 thread that the HTTP request comes in on) to another thread (the thread
 that's waiting for the RDBMS request), you're not saving any time or
 threads, in fact you're only increasing the amount of thrash between
 scheduling the Actor, suspending the HTTP request thread, etc.

 But, without seeing your code, it's hard to give you a better analysis.

 On Sun, Nov 8, 2009 at 7:08 PM, Lincoln linxbet...@gmail.com wrote:

 Hi,

 Currently I have a jetty webapp that uses continuations and actors to
 scale to many connections. While this isn't a lift question per se I
 was hoping the folks on this list could help since it's my
 understanding that Lift does similar stuff under certain setups.

 Basically, the functionality that I'm testing receives a request,
 suspends it via jetty continuations, and fires it off to an actor for
 processing.  Once the work is done (some benchmark database requests,
 usually on the order of 10 to 100ms) the continuation is resumed and
 results are returned.

 As I scale up to 1000+ concurrents in apache benchmark, I notice that
 the vast majority of time from receipt of the request to response, is
 between when the continuation is suspended and when my actor receives
 the message.  This strikes me as bizarre since I'm monitoring the
 mailbox and it never grows to a size larger than 1 or 2.  It gets to
 the point where requests are taking 10 seconds to come back and 9.5 of
 those seconds are my actor waiting to receive the work request.

 Throughout the load test the database does not become stressed.

 Any thoughts on this?  I guess I'm hoping there is something basic
 that I'm doing wrong.  Just in case, I've tried creating an actor pool
 to receive the work requests but that apparently has no effect on the
 results.

 My only speculation at this point is that perhaps the reason messages
 are taking so long to get to my actor is because jetty itself is
 overloaded trying to queue requests but that is just a guess.

 Thanks,
 Lincoln





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



[Lift] Re: json extraction problem

2009-10-01 Thread Lincoln
Cool, thanks Joni.  I'll give it a try.

On Thu, Oct 1, 2009 at 2:36 AM, Joni Freeman freeman.j...@gmail.com wrote:


 Hi,

 I pasted this to scala console and it worked. I am pretty sure that
 the problem is that your case classes are inner classes. Inner classes
 get one extra implicit constructor parameter, a reference to the outer
 class (same way as in Java). You need to move those case classes away
 from enclosing class (to an object or package etc.).

 The error message is very bad in this case. I will fix it.

 Cheers Joni

 On Oct 1, 7:49 am, Lincoln linxbet...@gmail.com wrote:
  Hi, I've been playing around with lift-json and I keep running into basic
  problems.  I'm hoping someone can point out my mistake.
  I'm using net.liftweb % lift-json % 1.1-M5
 
  Here's the code I'm trying to run:
 
  implicit val formats = net.liftweb.json.DefaultFormats
  case class Name(first: String, last: String)
  case class User(name: Name, email: String)
  import net.liftweb.json.JsonParser._
  val u = {
  import JsonDSL._
  (name -
  (first - Lincoln) ~
  (last - Hochberg)
  ) ~
  (email - linxbet...@gmail.com)}
 
  val json = JsonDSL.pretty(JsonAST.render(u))
  val jsonAST = JsonParser.parse(json)
  val user = jsonAST.extract[User]
 
  This blows up with the following exception:
 
  net.liftweb.json.MappingException: Parsed JSON values do not match with
  class constructor
  args=
  arg types=
  constructor=public
  pkg.TestSpec$$anonfun$1$$anonfun$apply$1(pkg.TestSpec$$anonfun$1)
  at
 
 net.liftweb.json.Extraction$.net$liftweb$json$Extraction$$fail(Extraction.scala:151)
  at net.liftweb.json.Extraction$.newInstance$1(Extraction.scala:72)
  at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
  at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
  at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
  at scala.List.flatMap(List.scala:1132)
  at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
  at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
  at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
  at scala.List.flatMap(List.scala:1132)
  at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
  at net.liftweb.json.Extraction$.extract0(Extraction.scala:109)
  at net.liftweb.json.Extraction$.extract(Extraction.scala:60)
  at net.liftweb.json.JsonAST$JValue.extract(Json.scala:109)
  at
 
 com.hotpotato.core.ops.TestSpec$$anonfun$1$$anonfun$apply$1.apply(TestSpec.scala:48)
  at
 
 com.hotpotato.core.ops.TestSpec$$anonfun$1$$anonfun$apply$1.apply(TestSpec.scala:14)
  at
 
 org.specs.specification.ExampleExecution$$anonfun$3$$anonfun$apply$1.apply(Example.scala:207)
  at org.specs.specification.Example.execute(Example.scala:121)
  at
 
 org.specs.specification.ExampleLifeCycle$class.executeTest(ExampleLifeCycle.scala:20)
  at org.specs.Specification.executeTest(Specification.scala:28)
  at org.specs.specification.Sus.executeTest(Sus.scala:147)
  at
 
 org.specs.specification.ExampleExecution$$anonfun$3.apply(Example.scala:207)
  at
 
 org.specs.specification.ExampleExecution$$anonfun$3.apply(Example.scala:194)
  at
 
 org.specs.specification.ExampleExecution$$anonfun$2.apply(Example.scala:185)
  at org.specs.specification.ExampleExecution.execute(Example.scala:227)
  at org.specs.specification.Example.execute(Example.scala:117)
  at org.specs.specification.Example.errors(Example.scala:143)
  at org.specs.specification.Sus$$anonfun$successes$1.apply(Sus.scala:122)
  at org.specs.specification.Sus$$anonfun$successes$1.apply(Sus.scala:122)
  at scala.List.filter(List.scala:859)
  at org.specs.specification.Sus.successes(Sus.scala:122)
  at
 
 org.specs.Specification$$anonfun$successes$1.apply(Specification.scala:84)
  at
 
 org.specs.Specification$$anonfun$successes$1.apply(Specification.scala:84)
  at scala.List.flatMap(List.scala:1132)
  at org.specs.Specification.successes(Specification.scala:84)
  at
 
 sbt.impl.SpecsRunner.sbt$impl$SpecsRunner$$reportSpecification(TestFrameworkImpl.scala:140)
  at sbt.impl.SpecsRunner.runTest(TestFrameworkImpl.scala:123)
  at sbt.BasicTestRunner.run(TestFramework.scala:38)
  at
 
 sbt.TestFramework$$anonfun$7$$anonfun$apply$8.runTest$1(TestFramework.scala:136)
  at
 
 sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply$9.apply(TestFramework.scala:147)
  at
 
 sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply$9.apply(TestFramework.scala:147)
  at sbt.NamedTestTask.run(TestFramework.scala:57)
  at
 
 sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:167)
  at
 
 sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:167)
  at sbt.TaskManager$Task.invoke(TaskManager.scala:62)
  at sbt.impl.RunTask.runTask(RunTask.scala:78)
  at sbt.impl.RunTask.sbt$impl$RunTask$$runIfNotRoot(RunTask.scala:63)
  at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$3.apply(RunTask.scala:49)
  at sbt.impl.RunTask$$anonfun

[Lift] json extraction problem

2009-09-30 Thread Lincoln
Hi, I've been playing around with lift-json and I keep running into basic
problems.  I'm hoping someone can point out my mistake.
I'm using net.liftweb % lift-json % 1.1-M5

Here's the code I'm trying to run:

implicit val formats = net.liftweb.json.DefaultFormats
case class Name(first: String, last: String)
case class User(name: Name, email: String)
import net.liftweb.json.JsonParser._
val u = {
import JsonDSL._
(name -
(first - Lincoln) ~
(last - Hochberg)
) ~
(email - linxbet...@gmail.com)
}
val json = JsonDSL.pretty(JsonAST.render(u))
val jsonAST = JsonParser.parse(json)
val user = jsonAST.extract[User]

This blows up with the following exception:

net.liftweb.json.MappingException: Parsed JSON values do not match with
class constructor
args=
arg types=
constructor=public
pkg.TestSpec$$anonfun$1$$anonfun$apply$1(pkg.TestSpec$$anonfun$1)
at
net.liftweb.json.Extraction$.net$liftweb$json$Extraction$$fail(Extraction.scala:151)
at net.liftweb.json.Extraction$.newInstance$1(Extraction.scala:72)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply(Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$.extract0(Extraction.scala:109)
at net.liftweb.json.Extraction$.extract(Extraction.scala:60)
at net.liftweb.json.JsonAST$JValue.extract(Json.scala:109)
at
com.hotpotato.core.ops.TestSpec$$anonfun$1$$anonfun$apply$1.apply(TestSpec.scala:48)
at
com.hotpotato.core.ops.TestSpec$$anonfun$1$$anonfun$apply$1.apply(TestSpec.scala:14)
at
org.specs.specification.ExampleExecution$$anonfun$3$$anonfun$apply$1.apply(Example.scala:207)
at org.specs.specification.Example.execute(Example.scala:121)
at
org.specs.specification.ExampleLifeCycle$class.executeTest(ExampleLifeCycle.scala:20)
at org.specs.Specification.executeTest(Specification.scala:28)
at org.specs.specification.Sus.executeTest(Sus.scala:147)
at
org.specs.specification.ExampleExecution$$anonfun$3.apply(Example.scala:207)
at
org.specs.specification.ExampleExecution$$anonfun$3.apply(Example.scala:194)
at
org.specs.specification.ExampleExecution$$anonfun$2.apply(Example.scala:185)
at org.specs.specification.ExampleExecution.execute(Example.scala:227)
at org.specs.specification.Example.execute(Example.scala:117)
at org.specs.specification.Example.errors(Example.scala:143)
at org.specs.specification.Sus$$anonfun$successes$1.apply(Sus.scala:122)
at org.specs.specification.Sus$$anonfun$successes$1.apply(Sus.scala:122)
at scala.List.filter(List.scala:859)
at org.specs.specification.Sus.successes(Sus.scala:122)
at
org.specs.Specification$$anonfun$successes$1.apply(Specification.scala:84)
at
org.specs.Specification$$anonfun$successes$1.apply(Specification.scala:84)
at scala.List.flatMap(List.scala:1132)
at org.specs.Specification.successes(Specification.scala:84)
at
sbt.impl.SpecsRunner.sbt$impl$SpecsRunner$$reportSpecification(TestFrameworkImpl.scala:140)
at sbt.impl.SpecsRunner.runTest(TestFrameworkImpl.scala:123)
at sbt.BasicTestRunner.run(TestFramework.scala:38)
at
sbt.TestFramework$$anonfun$7$$anonfun$apply$8.runTest$1(TestFramework.scala:136)
at
sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply$9.apply(TestFramework.scala:147)
at
sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply$9.apply(TestFramework.scala:147)
at sbt.NamedTestTask.run(TestFramework.scala:57)
at
sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:167)
at
sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply(ScalaProject.scala:167)
at sbt.TaskManager$Task.invoke(TaskManager.scala:62)
at sbt.impl.RunTask.runTask(RunTask.scala:78)
at sbt.impl.RunTask.sbt$impl$RunTask$$runIfNotRoot(RunTask.scala:63)
at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$3.apply(RunTask.scala:49)
at sbt.impl.RunTask$$anonfun$runTasksExceptRoot$3.apply(RunTask.scala:49)
at sbt.Distributor$Run$Worker$$anonfun$2.apply(ParallelRunner.scala:130)
at sbt.Distributor$Run$Worker$$anonfun$2.apply(ParallelRunner.scala:130)
at sbt.Control$.trapUnit(Control.scala:19)
at sbt.Distributor$Run$Worker.run(ParallelRunner.scala:130)

Any ideas?

Thanks,
Lincoln

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



[Lift] Re: lift-json

2009-09-13 Thread Lincoln
Sorry, here's the full code I'm using:

case class MyName(first:String, last:String)
case class MyUser(id:String, name:MyName, url:String) {
  val wtf = wtf
}

implicit val formats = net.liftweb.json.DefaultFormats
val json =
(id - me.id) ~
(name -
(first - me.name.first) ~
(last - me.name.last)
) ~
(url - me.url)
val output = JsonDSL.pretty(render(json))
val jsonCopy = parse(output)
val user = jsonCopy.extract[MyUser]
println(user = +user)




On Sun, Sep 13, 2009 at 12:07 AM, linxbetter linxbet...@gmail.com wrote:

 Hello, I saw a post about lift-json on the scala-user list so I
 decided to check it out.  I was particularly interested in the ability
 to call something along the lines of json.extract[MyClass].  I set up
 a little test case for this though, and apparently having a val of any
 sort in my case class causes the below exception.  Any thoughts?

 My classes looked like this:
 case class MyName(first:String, last:String)
 case class MyUser(id:String, name:MyName, url:String) {
  val wtf = wtf
 }

 And the output of my test

 [info]   lift-json should
 [info]   x do pain-free json conversion on nested objects
 net.liftweb.json.MappingException: Expected JField but got JNothing,
 json='JField(name,JObject(List(JField(first,JString(Lincoln)), JField
 (last,JString(Hochberg)', path='wtf'
at net.liftweb.json.Extraction$.net$liftweb$json$Extraction$
 $fail(Extraction.scala:151)
at net.liftweb.json.Extraction$.fieldValue$1(Extraction.scala:
 106)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:78)
at net.liftweb.json.Extraction$$anonfun$1.apply
 (Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
 (Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
 (Extraction.scala:84)
at net.liftweb.json.Extraction$$anonfun$1.apply
 (Extraction.scala:84)
at scala.List.flatMap(List.scala:1132)
at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
at net.liftweb.json.Extraction$.extract0(Extraction.scala:109)
at net.liftweb.json.Extraction$.extract(Extraction.scala:60)
at net.liftweb.json.JsonAST$JValue.extract(Json.scala:109)
at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
 $apply$1.apply(SerializationSpec.scala:87)
at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
 $apply$1.apply(SerializationSpec.scala:69)
at org.specs.specification.ExampleExecution$$anonfun$3$$anonfun
 $apply$1.apply(Example.scala:207)
at org.specs.specification.Example.execute(Example.scala:121)
at org.specs.specification.ExampleLifeCycle$class.executeTest
 (ExampleLifeCycle.scala:20)
at org.specs.Specification.executeTest(Specification.scala:28)
at org.specs.specification.Sus.executeTest(Sus.scala:147)
at org.specs.specification.ExampleExecution$$anonfun$3.apply
 (Example.scala:207)
at org.specs.specification.ExampleExecution$$anonfun$3.apply
 (Example.scala:194)
at org.specs.specification.ExampleExecution$$anonfun$2.apply
 (Example.scala:185)
at org.specs.specification.ExampleExecution.execute
 (Example.scala:227)
at org.specs.specification.Example.execute(Example.scala:117)
at org.specs.specification.Example.errors(Example.scala:143)
at org.specs.specification.Sus$$anonfun$successes$1.apply
 (Sus.scala:122)
at org.specs.specification.Sus$$anonfun$successes$1.apply
 (Sus.scala:122)
at scala.List.filter(List.scala:859)
at org.specs.specification.Sus.successes(Sus.scala:122)
at org.specs.Specification$$anonfun$successes$1.apply
 (Specification.scala:84)
at org.specs.Specification$$anonfun$successes$1.apply
 (Specification.scala:84)
at scala.List.flatMap(List.scala:1132)
at org.specs.Specification.successes(Specification.scala:84)
at sbt.impl.SpecsRunner.sbt$impl$SpecsRunner$
 $reportSpecification(TestFrameworkImpl.scala:140)
at sbt.impl.SpecsRunner.runTest(TestFrameworkImpl.scala:123)
at sbt.BasicTestRunner.run(TestFramework.scala:38)
at sbt.TestFramework$$anonfun$7$$anonfun$apply$8.runTest$1
 (TestFramework.scala:136)
at sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply
 $9.apply(TestFramework.scala:147)
at sbt.TestFramework$$anonfun$7$$anonfun$apply$8$$anonfun$apply
 $9.apply(TestFramework.scala:147)
at sbt.NamedTestTask.run(TestFramework.scala:57)
at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply
 (ScalaProject.scala:167)
at sbt.ScalaProject$$anonfun$sbt$ScalaProject$$toTask$1.apply
 (ScalaProject.scala:167)
at sbt.TaskManager$Task.invoke(TaskManager.scala:62)
at sbt.impl.RunTask.runTask(RunTask.scala:78)
at sbt.impl.RunTask.sbt$impl$RunTask$$runIfNotRoot
 (RunTask.scala:63

[Lift] Re: lift-json

2009-09-13 Thread Lincoln
Got it.  Thanks for the info.  I was afraid I was doing something wrong.
Thanks,
Lincoln

On Sun, Sep 13, 2009 at 9:48 AM, Joni Freeman freeman.j...@gmail.comwrote:


 Hi,

 Your example should work if you take the val away from your case
 class:

 case class MyName(first:String, last:String)
 case class MyUser(id:String, name:MyName, url:String)

 The reflection code currently fails to find the primary constructor of
 case class if there's extra fields. This will hopefully be fixed some
 day when the reflection story of Scala gets better (using Java
 reflection is very awkward).

 Cheers Joni

 On Sep 13, 7:55 am, Lincoln linxbet...@gmail.com wrote:
  Sorry, here's the full code I'm using:
 
  case class MyName(first:String, last:String)
  case class MyUser(id:String, name:MyName, url:String) {
val wtf = wtf
 
  }
 
  implicit val formats = net.liftweb.json.DefaultFormats
  val json =
  (id - me.id) ~
  (name -
  (first - me.name.first) ~
  (last - me.name.last)
  ) ~
  (url - me.url)
  val output = JsonDSL.pretty(render(json))
  val jsonCopy = parse(output)
  val user = jsonCopy.extract[MyUser]
  println(user = +user)
 
  On Sun, Sep 13, 2009 at 12:07 AM, linxbetter linxbet...@gmail.com
 wrote:
   Hello, I saw a post about lift-json on the scala-user list so I
   decided to check it out.  I was particularly interested in the ability
   to call something along the lines of json.extract[MyClass].  I set up
   a little test case for this though, and apparently having a val of any
   sort in my case class causes the below exception.  Any thoughts?
 
   My classes looked like this:
   case class MyName(first:String, last:String)
   case class MyUser(id:String, name:MyName, url:String) {
val wtf = wtf
   }
 
   And the output of my test
 
   [info]   lift-json should
   [info]   x do pain-free json conversion on nested objects
   net.liftweb.json.MappingException: Expected JField but got JNothing,
   json='JField(name,JObject(List(JField(first,JString(Lincoln)), JField
   (last,JString(Hochberg)', path='wtf'
  at net.liftweb.json.Extraction$.net$liftweb$json$Extraction$
   $fail(Extraction.scala:151)
  at net.liftweb.json.Extraction$.fieldValue$1(Extraction.scala:
   106)
  at net.liftweb.json.Extraction$.build$1(Extraction.scala:78)
  at net.liftweb.json.Extraction$$anonfun$1.apply
   (Extraction.scala:84)
  at net.liftweb.json.Extraction$$anonfun$1.apply
   (Extraction.scala:84)
  at scala.List.flatMap(List.scala:1132)
  at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
  at net.liftweb.json.Extraction$$anonfun$1.apply
   (Extraction.scala:84)
  at net.liftweb.json.Extraction$$anonfun$1.apply
   (Extraction.scala:84)
  at scala.List.flatMap(List.scala:1132)
  at net.liftweb.json.Extraction$.build$1(Extraction.scala:84)
  at net.liftweb.json.Extraction$.extract0(Extraction.scala:109)
  at net.liftweb.json.Extraction$.extract(Extraction.scala:60)
  at net.liftweb.json.JsonAST$JValue.extract(Json.scala:109)
  at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
   $apply$1.apply(SerializationSpec.scala:87)
  at com.hotpotato.core.SerializationSpec$$anonfun$1$$anonfun
   $apply$1.apply(SerializationSpec.scala:69)
  at org.specs.specification.ExampleExecution$$anonfun$3$$anonfun
   $apply$1.apply(Example.scala:207)
  at org.specs.specification.Example.execute(Example.scala:121)
  at org.specs.specification.ExampleLifeCycle$class.executeTest
   (ExampleLifeCycle.scala:20)
  at org.specs.Specification.executeTest(Specification.scala:28)
  at org.specs.specification.Sus.executeTest(Sus.scala:147)
  at org.specs.specification.ExampleExecution$$anonfun$3.apply
   (Example.scala:207)
  at org.specs.specification.ExampleExecution$$anonfun$3.apply
   (Example.scala:194)
  at org.specs.specification.ExampleExecution$$anonfun$2.apply
   (Example.scala:185)
  at org.specs.specification.ExampleExecution.execute
   (Example.scala:227)
  at org.specs.specification.Example.execute(Example.scala:117)
  at org.specs.specification.Example.errors(Example.scala:143)
  at org.specs.specification.Sus$$anonfun$successes$1.apply
   (Sus.scala:122)
  at org.specs.specification.Sus$$anonfun$successes$1.apply
   (Sus.scala:122)
  at scala.List.filter(List.scala:859)
  at org.specs.specification.Sus.successes(Sus.scala:122)
  at org.specs.Specification$$anonfun$successes$1.apply
   (Specification.scala:84)
  at org.specs.Specification$$anonfun$successes$1.apply
   (Specification.scala:84)
  at scala.List.flatMap(List.scala:1132)
  at org.specs.Specification.successes(Specification.scala:84)
  at sbt.impl.SpecsRunner.sbt$impl$SpecsRunner$
   $reportSpecification(TestFrameworkImpl.scala:140

[Lift] Re: Google App Engine

2009-04-08 Thread Lincoln Stoll

This looks like the thread: 
http://www.nabble.com/-scala--Google-App-Engine-for-Scala%21-td22944265.html

Linc.

On 08/04/2009, at 4:53 PM, Timothy Perrett wrote:


 Can you fwd to the lift list for those of us not on the main scala
 mailing lists?

 Thanks, Tim

 On Apr 8, 3:14 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
 See my response on the scala list

 


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