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 On Feb 24, 2009, at 5:43 AM PST, David Pollak wrote: > > > On Mon, Feb 23, 2009 at 6:33 PM, Paul O'Rorke <[email protected]> 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. > > > ---Paul O > > On Feb 23, 4:06 pm, David Pollak <[email protected]> > wrote: > > On Mon, Feb 23, 2009 at 3:55 PM, Paul O'Rorke <[email protected]> > 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. > > > > > > > > > > > > > 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 <[email protected]> > > > 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.netallthe > 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 > <[email protected]> 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 > > > > Follow me:http://twitter.com/dpp > > > > Git some:http://github.com/dpp > > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > Follow me:http://twitter.com/dpp > > Git some:http://github.com/dpp > > > > > -- > 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 > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
