tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <>
Subject Re: Help in diagnosing server unresponsiveness
Date Wed, 06 Feb 2013 21:09:54 GMT

On Wed, Feb 6, 2013 at 12:11 PM, Christopher Schultz
<> wrote:
> 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 certain employees can view 'the schedule' on their
mobile phones and tablets.

> - -chris
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools -
> Comment: Using GnuPG with Thunderbird -
> +UoAnRph0Qh6c8D5f9Mk0vHis3E1iMSy
> =GDk7
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message