Chris, On Wed, Feb 6, 2013 at 12:11 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Howard, > > > It depends on how you configure things. It's usually the lb that makes > that decision, so you configure it there. I would imagine that a good > lb would be able to do things like "guess" the health of the > backend-server and take it out of rotation if it's not healthy. mod_jk > has a variety of health-checks that you can perform to decide when a > Tomcat needs to be abandoned (perhaps temporarily).
good to know, thanks. > > Your app fails-over to a 404? Something must be misconfigured. Or were > you saying that your webapp returns a 404 if a query runs too long or > something... that doesn't sound optimal. > Misconfigured? Maybe not configured quite yet as I only have 2 months experience with Tomcat/TomEE. I think the 404 is caused by a query (or update logic) that runs too long, and agreed, I'm sure some optimizing is in order, but the endusers don't report this to me at all, as they are a bit new to using a web application (as they have been using an MS-DOS dBase IV app ever since 1994/1995; that app just recently got migrated to a JSF web application, they have been using it since July 2012, and they are quite pleased with the web app), and I do my best to monitor the logs for exceptions that need to be fixed, and poll the users about their experience with the app. I may be the only one that experience the 404 at times. In reading some of today's responses, I am in full agreement that some queries/logic may need to be reworked, and definitely endusers will probably never view/read 35,000 objects on a single http request. As the developer of the web app, I am probably the only person selecting-and-viewing 35,000 objects in a single http request. The data is primarily filtered and/or selected by date, and most-case scenario, they are selecting data for one date in time, but sometimes, they may select data via a small range of dates. I think the user-requested database updates may be the cause, as google calendar API is used to strategically synchronize certain/selected data in the database with the organization's google calendar...so certain employees can view 'the schedule' on their mobile phones and tablets. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEAREIAAYFAlESjtAACgkQ9CaO5/Lv0PAQtwCgvzniTJG11eoJeOJcV3Gpnz6Y > +UoAnRph0Qh6c8D5f9Mk0vHis3E1iMSy > =GDk7 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
