[Lift] Re: occasional unresponsiveness after a long period of inactivity
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 On Mon, Feb 23, 2009 at 2:34 PM, Paul O'Rorke 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 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 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: occasional unresponsiveness after a long period of inactivity
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 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 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 --~--~-~--~~~---~--~~ 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: occasional unresponsiveness after a long period of inactivity
On Mon, Feb 23, 2009 at 3:55 PM, Paul O'Rorke 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 > 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 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 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 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: occasional unresponsiveness after a long period of inactivity
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 wrote: > On Mon, Feb 23, 2009 at 3:55 PM, Paul O'Rorke 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 > > 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 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 --~--~-~--~~~---~--~~ 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: occasional unresponsiveness after a long period of inactivity
On Mon, Feb 23, 2009 at 6:33 PM, Paul O'Rorke 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 > wrote: > > On Mon, Feb 23, 2009 at 3:55 PM, Paul O'Rorke 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 > > > 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 > 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 > >
[Lift] Re: occasional unresponsiveness after a long period of inactivity
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 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 > wrote: > > On Mon, Feb 23, 2009 at 3:55 PM, Paul O'Rorke > 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 som
[Lift] Re: occasional unresponsiveness after a long period of inactivity
On Tue, Feb 24, 2009 at 2:04 PM, O'Rorke Paul 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 > ---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 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 >> wrote: >> > On Mon, Feb 23, 2009 at 3:55 PM, Paul O'Rorke 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 a
