tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From VenkateswaraRao Eswar <>
Subject Re: WARNING: Error registering request
Date Tue, 17 Aug 2010 05:41:22 GMT
Could you please respond to this mail ASAP?

--- On Tue, 10/8/10, VenkateswaraRao Eswar <> wrote:

From: VenkateswaraRao Eswar <>
Subject: Re: WARNING: Error registering request
To: "Tomcat Users List" <>
Date: Tuesday, 10 August, 2010, 9:21 PM

Thanks for your suggestions. Upgrading to newer versions is defenetely a good solution. But
unfortunately, we are not looking to upgrade our production environment at this point of
Any alternate solution to this issue with the current jdk/tomcat/Apache proxy versions instead
of upgrading to newer versions?

--- On Fri, 6/8/10, Christopher Schultz <> wrote:

From: Christopher Schultz <>
Subject: Re: WARNING: Error registering request
To: "Tomcat Users List" <>
Date: Friday, 6 August, 2010, 10:59 AM

Hash: SHA1

On 8/6/2010 5:20 AM, VenkateswaraRao Eswar wrote:
> With our production application, I am getting
> "" error messeges
> repeatedly before resulting in "OutOfMemoryError".

While I appreciate and agree with Mark's sentiments, it's always nice to
have a production system that is working.

How long has your application been in production?

How long has this InstanceAlreadyExistsException - > OutOfMemoryError
condition been happening.

Did anything change in your production configuration around the time
that these errors started occurring?

Generally speaking, these kinds of things don't just magically start to
happen in a production system. Usually, one of the following things has

1. Someone tweaked some configuration and didn't properly test the effects

2. You released a new version of your web application and didn't
properly test it

The solution to the first problem is, of course, to reverse the
configuration change and resume normal operations.

The solution to the second problem is probably to downgrade your wep
application, and re-think your next steps.

Once you get your production system back up and running, you can
concentrate on Mark's suggestions, which are, specifically:

1. Upgrade to a supported version of Java (which would be 1.6.x). This
is perhaps the easiest thing you can possibly do, since the APIs are (in
theory, anyway) backward compatible. The most noticeable thing about the
upgrade will be better performance all around.

2. Upgrade mod_jk2 to mod_jk (yes, it sounds like a downgrade but jk2
was abandoned because jk basically back-ported all the features of jk2).
The current version is 1.2.30. You didn't say what type of OS you were
on. If you're on *NIX, compile it yourself. If you're on Windows,
download the binary from the Tomcat website. Configuration is not too
bad, and we can help with that when you're ready to transition, if the
documentation isn't clear. Reading the sample mod_jk.conf file that
ships with mod_jk is very instructive, so do that before you come crying
to us.

3. Upgrade Tomcat to a supported version. 6.0.29 would be best, though
sometimes it's prudent to stay a few point-releases behind the latest,
just in case some weird bug appears that affects you. Upgrading from 5.0
to 6.0 shouldn't be too painful: just remember that you shouldn't try to
use your server.xml from your 5.0 install to go to 6.0. Instead, use the
stock 6.0 server.xml as a basis, and see what changes you'll need to
make. Again, this shouldn't be tough to do since Tomcat should be
backward-compatible as long as you stick to the servlet specification's
rules. Just remember that as Tomcat matures, it gets more strict about
the servlet spec rules, so you might notice things that no longer work
because you were relying on out-of-spec behavior.

(I thought there was an "upgrade" or "migration" page on the Wiki, but
it appears there is none... perhaps I should write one).

Hope that helps,
- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message