occasional unresponsiveness after a long period of inactivity

[Paul O'Rorke]

Several times now when I've left a page with Ajax checkboxes and
textboxes sitting for a while, and then when I've gone to check a box
or type in a textbox, there is no response from the server. In the
console window, I see nothing unusual.

Sometimes I used to get "could not reach server" messages in this sort
of situation but I don't seem to be getting those anymore or else I'm
just not waiting long enough for them.

This is in a web app that I want to be able to treat like a desktop
app. It has a very long session timeout but I have not changed any
other timeouts like the ajax timeout. (Perhaps I should?)

A workaround is just to reload the page. (I think that tends to
happen anyway sort of automatically on my iPhone but not on my
desktop.)

[David Pollak]

Paul,

This can result from a number of things:

• The process that's running your web app gets swapped out on the server.  If you're running on Linux, this is less likely to happen if you have enough RAM.  I've seen Windows swamp processes out so it can run the screen saver.
• Your browser does not do well with long running JavaScript.  Firefox, in my experience, is particularly bad about this.  I have to restart Firefox almost daily.  On the other hand, Google Chrome seems to be the best browser in terms of hanging out on the same page for days, weeks, at a time.

I have a browser window open to http://demo.liftweb.net all the time.  Other than the above-mentioned need to periodically restart Firefox, the page is always responsive.

If you can put together a reproducable case of this problem, I'll look into it.

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Paul O'Rorke]

David: I think you are probably right that it is something external
to lift or scala as it seems to be intermittent, happening sometimes
but not others under what seem to be the same circumstances.

The server process is on a mac book pro laptop for now and it may well
be getting swapped out although not for a screen saver as I am usually
keeping the machine busy working on other things. But wouldn't a
request to the server cause it to be swapped back in again?

I'm using Safari almost all the time. Thanks for suggesting Chrome as
a good alternative for this application.

It gives a bit of a feel of flakyness if you go to do something simple
and it doesn't work as intended so I thought it worth noting and will
keep a lookout to see if it happens often enough and regularly enough
that I can replicate it simply somehow.
---Paul O

On Feb 23, 2:40 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Paul,
>
> This can result from a number of things:
>

>    - The process that's running your web app gets swapped out on the

>    server.  If you're running on Linux, this is less likely to happen if you
>    have enough RAM.  I've seen Windows swamp processes out so it can run the
>    screen saver.

>    - Your browser does not do well with long running JavaScript.  Firefox,

>    in my experience, is particularly bad about this.  I have to restart Firefox
>    almost daily.  On the other hand, Google Chrome seems to be the best browser
>    in terms of hanging out on the same page for days, weeks, at a time.
>

> I have a browser window open tohttp://demo.liftweb.netall the time.  Other

> than the above-mentioned need to periodically restart Firefox, the page is
> always responsive.
>
> If you can put together a reproducable case of this problem, I'll look into
> it.
>
> Thanks,
>
> David
>
>
>
> On Mon, Feb 23, 2009 at 2:34 PM, Paul O'Rorke <p...@ororke.com> wrote:
>
> > Several times now when I've left a page with Ajax checkboxes and
> > textboxes sitting for a while, and then when I've gone to check a box
> > or type in a textbox, there is no response from the server.  In the
> > console window, I see nothing unusual.
>
> > Sometimes I used to get "could not reach server" messages in this sort
> > of situation but I don't seem to be getting those anymore or else I'm
> > just not waiting long enough for them.
>
> > This is in a web app that I want to be able to treat like a desktop
> > app.  It has a very long session timeout but I have not changed any
> > other timeouts like the ajax timeout.  (Perhaps I should?)
>
> > A workaround is just to reload the page.  (I think that tends to
> > happen anyway sort of automatically on my iPhone but not on my
> > desktop.)
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[David Pollak]

On Mon, Feb 23, 2009 at 3:55 PM, Paul O'Rorke <pa...@ororke.com> wrote:

David:  I think you are probably right that it is something external
to lift or scala as it seems to be intermittent, happening sometimes
but not others under what seem to be the same circumstances.

The server process is on a mac book pro laptop for now and it may well
be getting swapped out although not for a screen saver as I am usually
keeping the machine busy working on other things.  But wouldn't a
request to the server cause it to be swapped back in again?

Yes.  This is how virtual memory works.

How much RAM is in your machine?

Perhaps some Mac-head on the list can tell us how to determine how much of a process is actually swapped to disk.

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[Paul O'Rorke]

Yes, even tho I wasn't living in Silicon Valley at the time, I did
learn about virtual memory as a kid and then again in operating
systems courses well before I got my Ph.D. in C.S. ;).

I just did a little experiment where I waited patiently this time
after not getting an immediate response and I did get another "server
did not respond" type message.
After getting this mesage, I tried clicking again on an Ajax checkbox
a couple of times and it worked fine without my having to reload the
page.

So your theory, I take it, is that virtual memory is so slow swapping
the server process back in that the client gives up and thinks it is
never going to respond? Is there some timeout in lift and/or in the
Ajax Javascript code that can be tweaked to let it wait a little
longer for a response before giving up?
---Paul O

On Feb 23, 4:06 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> > > I have a browser window open tohttp://demo.liftweb.netallthe time.

[David Pollak]

On Mon, Feb 23, 2009 at 6:33 PM, Paul O'Rorke <pa...@ororke.com> wrote:

Yes, even tho I wasn't living in Silicon Valley at the time, I did
learn about virtual memory as a kid and then again in operating
systems courses well before I got my Ph.D. in C.S. ;).

I just did a little experiment where I waited patiently this time
after not getting an immediate response and I did get another "server
did not respond" type message.
After getting this mesage, I tried clicking again on an Ajax checkbox
a couple of times and it worked fine without my having to reload the
page.

So your theory, I take it, is that virtual memory is so slow swapping
the server process back in that the client gives up and thinks it is
never going to respond?  Is there some timeout in lift and/or in the
Ajax Javascript code that can be tweaked to let it wait a little
longer for a response before giving up?

The Ajax stuff retries the server based on the LiftRules.ajaxRetryCount setting (by default 3).  It backs off by doubling the wait time between tries, so adding LiftRules.ajaxRetryCount = Full(5) to Boot.scala should address the issue.

On a broader note, running any JVM code on a machine that is using significant amount of swap space is less than optimal.  The JVM's garbage collector touches every page in a process at least onces, so in order to do a full GC, the whole process gets swapped in.

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[O'Rorke Paul]

David thanks for the suggestion.  I tried it this morning but it didn't seem to help.

One thing that's rather odd is that I see messages like the following in my terminal window periodically with a fairly short period:

INFO - Service request (POST) /ajax_request/F112231369327YH0/ took 2 Milliseconds

INFO - Service request (POST) /ajax_request/F112231369327YH0/ took 2 Milliseconds

INFO - Service request (POST) /ajax_request/F112231369327YH0/ took 2 Milliseconds

I assume these have to do with the lift GC stuff that you guys are doing and/or the client is polling the server?

These messages happen all the time but interestingly they happen while I'm waiting for a response after I click on an ajax checkbox or whatever.

So I think the server is doing stuff, it just doesn't seem to reply to the client.

On the other hand, when I click on an ajax checkbox in my browser, I can see the server getting that POST ajax_request.

But other things that should happen in the browser, like a redisplay where the checked item disappears, do not happen.

I guess this is still consistent with a virtual memory explanation, if the server can't get itself together enough to reply in a reasonable time.

But here are some other little details in case they might help:

When I click multiple times on the checkbox, I thought previously that it was actually doing the right thing when the box was rechecked but this time I didn't see that.

Clicking on a checkbox causes it to appear to be checked and I seem to see a corresponding ajax_request in the server terminal window but...

When I reload the page, I can see that, although the checkbox was checked, this didn't really register on the server, as the item is unchecked again in the newly fetched browser page.

Once the page is reloaded, everything works fine and pretty quickly.

I am seeing some ajax_request times on the order of tens of seconds around the times when I have the inactivity/unresponsiveness issue.

I'm sure I'll have to start doing some performance work pretty soon but I'm reporting all this in the hope that it might help identify issues that others may encounter.

---Paul O

[David Pollak]

On Tue, Feb 24, 2009 at 2:04 PM, O'Rorke Paul <pa...@ororke.com> wrote:

David thanks for the suggestion.  I tried it this morning but it didn't seem to help.

One thing that's rather odd is that I see messages like the following in my terminal window periodically with a fairly short period:

INFO - Service request (POST) /ajax_request/F112231369327YH0/ took 2 Milliseconds

INFO - Service request (POST) /ajax_request/F112231369327YH0/ took 2 Milliseconds

INFO - Service request (POST) /ajax_request/F112231369327YH0/ took 2 Milliseconds

I assume these have to do with the lift GC stuff that you guys are doing and/or the client is polling the server?

These are likely part of the GC stuff.

 

These messages happen all the time but interestingly they happen while I'm waiting for a response after I click on an ajax checkbox or whatever.

So I think the server is doing stuff, it just doesn't seem to reply to the client.

I doubt that.  There is no code path that I can find in which the server receives an AJAX request but does not respond to the browser.

 

On the other hand, when I click on an ajax checkbox in my browser, I can see the server getting that POST ajax_request.

Please use Firefox and Firebug to see what the client is sending to the server and what the server is sending back to the client.

 

But other things that should happen in the browser, like a redisplay where the checked item disappears, do not happen.

I guess this is still consistent with a virtual memory explanation, if the server can't get itself together enough to reply in a reasonable time.

But here are some other little details in case they might help:

When I click multiple times on the checkbox, I thought previously that it was actually doing the right thing when the box was rechecked but this time I didn't see that.

Clicking on a checkbox causes it to appear to be checked and I seem to see a corresponding ajax_request in the server terminal window but...

When I reload the page, I can see that, although the checkbox was checked, this didn't really register on the server, as the item is unchecked again in the newly fetched browser page.

Once the page is reloaded, everything works fine and pretty quickly.

I am seeing some ajax_request times on the order of tens of seconds around the times when I have the inactivity/unresponsiveness issue.

If you can send a reproduceable case, I'll look into it. 

I'm sure I'll have to start doing some performance work pretty soon but I'm reporting all this in the hope that it might help identify issues that others may encounter.

There are a bunch of Lift-powered apps that I have in production.  Many of them are similar to your application in that they stay on the same page for a long time.  I have not seen any of the issues that you're describing.  If you can post a reproduceable case, I'll be glad to look into it, but without data beyond "stuff taking a long time on my machine," I can't really offer you much more help.

Thanks,

David

[O'Rorke Paul]

David:  I will switch to running under firefox with firebug on next.

But I tried running with more ajax retries (7 rather than 5) and got some new messages on the console including the following...

INFO - Service request (POST) /ajax_request/F1020691445309YRN/ took 210519 Milliseconds

WARN - Request for /ajax_request/F1020691445309YRN/ failed At least one parameter to the current statement is uninitialized.

ERROR 07000: At least one parameter to the current statement is uninitialized.

at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)

at org.apache.derby.impl.sql.execute.BaseActivation.throwIfMissingParms(Unknown Source)

at org.apache.derby.exe.ac601a400fx011fxac49xb432x00000e427b504.execute(Unknown Source)

at org.apache.derby.impl.sql.GenericActivationHolder.execute(Unknown Source)

at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)

at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)

at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)

at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)

at net.liftweb.mapper.MetaMapper$$anonfun$12$$anonfun$13.apply(MetaMapper.scala:601)

at net.liftweb.mapper.MetaMapper$$anonfun$12$$anonfun$13.apply(MetaMapper.scala:584)

at net.liftweb.mapper.DB$$anonfun$prepareStatement$1.apply(DB.scala:281)

at net.liftweb.mapper.DB$$anonfun$prepareStatement$1.apply(DB.scala:277)

at net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241)

at net.liftweb.util.Helpers$.calcTime(Helpers.scala:29)

at net.liftweb.mapper.DB$.prepareStatement(DB.scala:277)

at net.liftweb.mapper.MetaMapper$$anonfun$12.apply(MetaMapper.scala:583)

at net.liftweb.mapper.MetaMapper$$anonfun$12.apply(MetaMapper.scala:578)

at net.liftweb.mapper.DB$.use(DB.scala:305)

at net.liftweb.mapper.MetaMapper$class.save(MetaMapper.scala:577)

at com.liftworkshop.model.ToDo$.save(ToDo.scala:242)

at net.liftweb.mapper.Mapper$$anonfun$save$1.apply(Mapper.scala:84)

at net.liftweb.mapper.Mapper$$anonfun$save$1.apply(Mapper.scala:84)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.mapper.Safe$.runSafe(Safe.scala:44)

at net.liftweb.mapper.Mapper$class.runSafe(Mapper.scala:50)

at com.liftworkshop.model.ToDo.runSafe(ToDo.scala:37)

at net.liftweb.mapper.Mapper$class.save(Mapper.scala:83)

at com.liftworkshop.model.ToDo.save(ToDo.scala:37)

at com.liftworkshop.snippet.TD$$anonfun$com$liftworkshop$snippet$TD$$doList$1$$anonfun$apply$10.apply(TD.scala:220)

at com.liftworkshop.snippet.TD$$anonfun$com$liftworkshop$snippet$TD$$doList$1$$anonfun$apply$10.apply(TD.scala:220)

at net.liftweb.http.SHtml$$anonfun$ajaxCheckbox$1.apply(SHtml.scala:169)

at net.liftweb.http.SHtml$$anonfun$ajaxCheckbox$1.apply(SHtml.scala:169)

at net.liftweb.http.S$LFuncHolder.apply(S.scala:926)

at net.liftweb.http.LiftSession$$anonfun$buildFunc$1$2.apply(LiftSession.scala:307)

at net.liftweb.http.LiftSession$$anonfun$5$$anonfun$apply$19.apply(LiftSession.scala:322)

at net.liftweb.http.LiftSession$$anonfun$5$$anonfun$apply$19.apply(LiftSession.scala:322)

at scala.List.map(List.scala:805)

at net.liftweb.http.LiftSession$$anonfun$5.apply(LiftSession.scala:322)

at net.liftweb.http.LiftSession$$anonfun$5.apply(LiftSession.scala:311)

at scala.List.flatMap(List.scala:1125)

at net.liftweb.http.LiftSession.runParams(LiftSession.scala:311)

at net.liftweb.http.LiftServlet.handleAjax(LiftServlet.scala:276)

at net.liftweb.http.LiftServlet.net$liftweb$http$LiftServlet$$dispatchStatefulRequest(LiftServlet.scala:243)

at net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala:176)

at net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala:176)

at net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:398)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit$1$$anonfun$apply$16.apply(S.scala:453)

at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:372)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$doAround$1.apply(S.scala:373)

at net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$$doWith(DB.scala:117)

at net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$$doWith$1.apply(DB.scala:118)

at net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$$doWith$1.apply(DB.scala:118)

at net.liftweb.mapper.DB$.use(DB.scala:305)

at net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$$doWith(DB.scala:118)

at net.liftweb.mapper.DB$$anon$1.apply(DB.scala:124)

at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:373)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit$1.apply(S.scala:451)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit(S.scala:450)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun$apply$19$$anonfun$apply$20$$anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply$24.apply(S.scala:471)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun$apply$19$$anonfun$apply$20$$anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23.apply(S.scala:470)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun$apply$19$$anonfun$apply$20$$anonfun$apply$21$$anonfun$apply$22.apply(S.scala:469)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun$apply$19$$anonfun$apply$20$$anonfun$apply$21.apply(S.scala:468)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun$apply$19$$anonfun$apply$20.apply(S.scala:467)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$$anonfun$apply$19.apply(S.scala:466)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1.apply(S.scala:465)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$.net$liftweb$http$S$$_innerInit(S.scala:464)

at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$27$$anonfun$apply$28$$anonfun$apply$29$$anonfun$apply$30.apply(S.scala:495)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$27$$anonfun$apply$28$$anonfun$apply$29.apply(S.scala:494)

at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:191)

at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$27$$anonfun$apply$28.apply(S.scala:493)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$27.apply(S.scala:492)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$$anonfun$_init$1.apply(S.scala:491)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.S$._init(S.scala:490)

at net.liftweb.http.S$.init(S.scala:334)

at net.liftweb.http.LiftServlet.doService(LiftServlet.scala:175)

at net.liftweb.http.LiftServlet$$anonfun$doIt$1$1.apply(LiftServlet.scala:104)

at net.liftweb.http.LiftServlet$$anonfun$doIt$1$1.apply(LiftServlet.scala:104)

at net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241)

at net.liftweb.util.Helpers$.calcTime(Helpers.scala:29)

at net.liftweb.util.TimeHelpers$class.logTime(TimeHelpers.scala:250)

at net.liftweb.util.Helpers$.logTime(Helpers.scala:29)

at net.liftweb.http.LiftServlet.doIt$1(LiftServlet.scala:103)

at net.liftweb.http.LiftServlet.service(LiftServlet.scala:112)

at net.liftweb.http.LiftFilterTrait$$anonfun$doFilter$1$$anonfun$apply$22.apply(LiftServlet.scala:525)

at net.liftweb.http.LiftFilterTrait$$anonfun$doFilter$1$$anonfun$apply$22.apply(LiftServlet.scala:525)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.URLRewriter$.doWith(Req.scala:390)

at net.liftweb.http.LiftFilterTrait$$anonfun$doFilter$1.apply(LiftServlet.scala:524)

at net.liftweb.http.LiftFilterTrait$$anonfun$doFilter$1.apply(LiftServlet.scala:518)

at net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply$4$$anonfun$apply$5$$anonfun$apply$6.apply(Vars.scala:197)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply$4$$anonfun$apply$5.apply(Vars.scala:196)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun$apply$4.apply(Vars.scala:195)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.RequestVarHandler$$anonfun$apply$3.apply(Vars.scala:194)

at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)

at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:193)

at net.liftweb.http.LiftFilterTrait$class.doFilter(LiftServlet.scala:517)

at net.liftweb.http.LiftFilter.doFilter(LiftServlet.scala:536)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1139)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:378)

at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)

at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)

at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)

at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)

at org.mortbay.jetty.Server.handle(Server.java:324)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535)

at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:880)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)

at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)

at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)

Dunno if getting these messages is due in part to more retries over a longer time or if this is a result of my becoming impatient and clicking on a checkbox again one or more times.

However, I did discover that retrying manually in the browser does work sometimes (although not always).  In other words it does respond correctly after unchecking, then rechecking a box

(sometimes it takes multiple times).

---Paul O

[David Pollak]

Paul,

I'll be happy to help you debug the application if you can send me code that reproduces the problem.  Sometimes stack traces and behavior reports are helpful, but I am not able to diagnose what's going on in your app without being able to make the problems happen on my machine.

Looking at the stack trace, it's looking to me a whole lot like it's a Derby problem.  The exception is happening in Derby.  The exception is due to a problem with a prepared statement.  If Lift were building prepared statements incorrectly, the problem would be constant rather than transient.  My guess is that there's some threading problems or timeout problems or something like that in Derby and Derby is failing.

But without being able to reproduce the problems on my machine, I'm just shooting in the dark.

Thanks,

David

[Derek Chen-Becker]

Specifically, this appears to be the last line in the stack trace before we hit Mapper internals:

at com.liftworkshop.model.ToDo$.save(ToDo.scala:242)

Any way to see what exactly is happening in ToDo.save?

Derek

[O'Rorke Paul]

Derek:  it's the save from CRUDify.

David:  this is the same app that caused the GC parse issue that you nailed earlier;  essentially a souped up version of the todo tutorial app.

The issue could be virtual memory paging related and does seem timeout related and is also possibly as much an issue of too many todos (data not just code).  It just plops them all on one page.  I should move to paging thru them.

Also plan to move off Derby (sooner rather than later if it may or if it turns out that it does contribute to the problem somehow).

I'll try to catch this with Firebug to see if there's anything more there.

---Paul O