On Tue, Feb 24, 2009 at 2:04 PM, O'Rorke Paul <[email protected]> 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 <[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
>
>
>
>
>
> >
>


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

Reply via email to