Daniel, Thanks so much! This is excellent. I don't know if it's the problem, but it won't hurt to reset the keepalives and find out. Now to figure out how to do that...
Chas. Daniel Mueller wrote: > I'm not sure that this is of any help or even applies to lift, but we > had once a very similar situation with a corporate application. > Difference was that the problem occurred when you were working slower. > Here's the description of the problem and what the reason was. When we > ran our application in on dev servers, everything was working fine, > never any problems, never the server unavailable message. Even on the > test servers for the client there was never any problem and everything > was working fine, even though this time the app was using HTTPS. When > we put the application into production (HTTPS as well), we received > complaints similar to yours. Ok, differences between dev/test and > prod? Almost none, server setup the same (tomcat/apache at the time), > same OS, same build. Differences were only in network routing and that > the production was using a loadbalancer. Now that load balancer was a > pretty expensive piece of hardware, we used sticky sessions and the > app was built that it should even be able to handle session failover > gracefully (only cashing stuff in the session). And strangely we still > couldn't reproduce the bug even though the allowed us to test in the > production environment... > Now the fun started. It took some time to actually reproduce the bug, > because it happened only if you waited long enough on a page that is > using AJAX. It took a couple of minutes of waiting (doing nothing that > triggers AJAX) on a page before you could get the server unavailable > message when starting to use AJAX again which had to timeout as well > first. The wait time is not completely unreasonable (if you got a > complex form to fill, that's a reasonable time, depending on how your > site is structured) and after that, the AJAX part of the page was dead > (only reload could get you going again). > After being able to reproduce the bug, we set to find the source of > the problem. It turned out that the following things happened: Apache > has a configured connection pool and a configured connection keepalive > (sent in HTTP response header). It doesn't honor the keepalive though, > as long as you have enough spare connections in the pool (it'll simply > keep the timed out connections active). The loadbalancer on the other > hand is not that friendly and shuts the connections down after the > configured keepalive times out. That's the reason why it never showed > in dev and test and only with the loadbalancer (which is advertised as > being transparent) in place. > Ok, interesting story so far, but why does IE6 barf on it, connection > closing shouldn't be the end of the world, it happens often enough. > The problem is that IE6 automatic removal of SSLd keepalive > connections is seriously broken. It actually tries to reuse timed out > connections from the internal connection pool (IIRC, also see [1], or > google), which will not get you anywhere on the server, because the > connection has been shut down. > Resolution for us was to set the keepalive to a high value (half an > hour or so, the default is 300/5 minutes). This was also partially > because we were not allowed to touch the configuration of the > loadbalancer. [1] describes a different solution. > To find the problem we used SysInternals TCPView (free) to find out > what the issue was on the network, but that got us only that far. The > missing piece was SysInternals TDIMon (free), that showed us IE6s > internal connection pool events. TDIMon seems to be discontinued (at > least I couldn't find it on the site), and I haven't had to use it in > a while, so I don't know which application is actually filling the gap > or whether you can download it somewhere else (I don't know if the old > version is Vista compatible but it worked fine on XP). > > Hope that helps and that you find a solution (that was one of the > harder bugs I ever had to track down, thus the extensive writeup). > > Cheers, > -D > > [1] http://extjs.com/forum/showthread.php?t=45673 > [2] http://technet.microsoft.com/en-us/sysinternals/default.aspx > > On Mar 25, 2:22 am, "Charles F. Munat" <[email protected]> wrote: >> I have a survey online that updates the server via AJAX when individual >> form fields are blurred. Works beautifully in Firefox, Opera, IE7, etc. >> >> But in IE6 there are some serious problems. Unfortunately, the users of >> this survey are corporate, and some of them are forced to use IE6 (DEATH >> to lazy sysadmins!). What happens is that the saves sometimes work, and >> other times do not. Occasionally, a "server unavailable message" pops >> up, and after that nothing seems to work. I have a couple of customers >> who are very seriously pissed off because they've had to re-enter data >> four and five times. >> >> I suspect that this has something to do with IE6 limitations wrt number >> of browser connections available to AJAX. If they slow down a little, >> the problem diminishes. >> >> Anyone ever try something like this before? Anyone have any suggestions? >> Why only IE6? Is there a workaround? (I can't afford to rebuild the >> whole thing for one or two people.) >> >> Thanks! >> >> Chas. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
