tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edson Richter <>
Subject Re: Help in diagnosing server unresponsiveness
Date Wed, 06 Feb 2013 23:37:01 GMT
Em 06/02/2013 19:09, Howard W. Smith, Jr. escreveu:
> Chris,
> 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.

404 is page not found.
If query runs too long, you will get timeout or Error 500.
Check your web app... the only scenario I can think on 404 due timeout 
is if your app is querying the name of the next page, and then get an 
error as response (instead of the name of the page).



> 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
>> -----END PGP SIGNATURE-----
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message