Glad I could help a bit. Whether it's the source of your problem is difficult to say, since I don't know the environment your app is running in, but it's such a nasty bug it's probably just good to know that it exists and to watch out for it (especially because it depends on a couple of factors coming together: IE6, HTTPS, AJAX, and hard shutdowns of connections which are still in the connection pool in IE). If you watch IE6 in TDIMon (or similar tool that shows events from the Windows Transport Driver Interface (TDI)), you can actually see that the use of connections is completely messed up: you see the closing event received from the LB (or whoever resets the connection) and after you use AJAX again, you see the same connection identifier reused without re-initiating the SSL handshake and establishing the connection. As for the keepalives, you set them in your HTTP server (either in Apache, if you have one in front of your container, or directly in the container). Also check the resolution in the article I linked above. I personally think, his solution is probably solving the problem in a 'cleaner' way, since he didn't increase general resource consumption on the server and also just changed the behavior for the affected clients (for the lazy: he sets [2] in the ssl conf of apache, but read more at [1]). But it's also a bit more involved (I personally wouldn't know how to affect the different containers to behave in such a way, but if someone knows, please post here/put it on the wiki ;) ) And also make sure to verify that the keepalives get interpreted correctly and really fix the problem. We only got everything right after a couple of attempts (unfortunately communicated as fixes to the client), and the client will fail to see why it should be so difficult to fix a simple bug in your application. The client cannot really appreciate the nature and difficulty of the problem (there's something wrong with your application, it's really annoying, please fix it ASAP), and he will fail to see that it's not really the problem of your application, but rather the combination of client and server side software that trigger a bug in his browser (what was that about lazy sysadmins?).
Oh, and by the way, thanks for Lift. Always Lifts my mood when working with it ;) [1] http://extjs.com/forum/showthread.php?t=45673 [2] SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 On Mar 26, 3:50 am, "Charles F. Munat" <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
