You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by VenkateswaraRao Eswar <ve...@yahoo.com> on 2010/08/06 11:20:10 UTC

WARNING: Error registering request

Hi, 
   With our production application, I am getting "javax.management.InstanceAlreadyExistsException" error messeges repeatedly before resulting in "OutOfMemoryError".
 
SEVERE: Error registering Catalina:type=RequestProcessor,worker=jk-8009,name=JkRequest9845
javax.management.InstanceAlreadyExistsException: Catalina:type=RequestProcessor,worker=jk-8009,name=JkRequest9845
        at com.sun.jmx.mbeanserver.RepositorySupport.addMBean(Unknown Source)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(Unknown Source)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(Unknown Source)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(Unknown Source)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(Unknown Source)
        at org.apache.commons.modeler.Registry.registerComponent(Registry.java:871)
        at org.apache.jk.common.ChannelSocket.registerRequest(ChannelSocket.java:436)
        at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:443)
        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675)
        at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Unknown Source)
Jan 21, 2010 5:05:52 PM org.apache.jk.common.ChannelSocket registerRequest
WARNING: Error registering request
 
-------------------

SEVERE: Exception invoking periodic operation:
java.lang.OutOfMemoryError: Java heap space
        at org.apache.catalina.session.ManagerBase.findSessions(ManagerBase.java:752)
        at org.apache.catalina.session.StandardManager.processExpires(StandardManager.java:778)
        at org.apache.catalina.session.StandardManager.backgroundProcess(StandardManager.java:795)
        at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4662)
        at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1619)
        at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628)
        at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628)
        at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1608)
        at java.lang.Thread.run(Unknown Source)
 
-------------------------

The below are the env details of our production system:
Apache Proxy: 2.2.11
Apache Tomcat: 5.0.30
JDK: 1.5.0_15
 
With JDK 1.4.2_15 on development, I could resolve this by adding request.registerRequests="false" in $TOMCAT_HOME/conf/jk2.properties. When applied the same to JDK 1.5.0_15, I am getting the below errors repeatedly before resulting in "OutOfMemoryError". Since it is production issue, could you please provide a solution for JDK 1.5.0_15 ASAP? Let me know if you need any details.
 
SEVERE: Error unregistering mbean
javax.management.RuntimeOperationsException: Object name cannot be null
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.isRegistered(Unknown Source)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.isRegistered(Unknown Source)
        at org.apache.commons.modeler.Registry.unregisterComponent(Registry.java:642)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:706)
        at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
        at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.IllegalArgumentException: Object name cannot be null
        ... 7 more
 
Thanks,
Venkat Kudipudi


Re: WARNING: Error registering request

Posted by Mark Thomas <ma...@apache.org>.
On 06/08/2010 10:20, VenkateswaraRao Eswar wrote:
> Hi, 
>    With our production application, I am getting "javax.management.InstanceAlreadyExistsException" error messeges repeatedly before resulting in "OutOfMemoryError".
>  
> SEVERE: Error registering Catalina:type=RequestProcessor,worker=jk-8009,name=JkRequest9845
> javax.management.InstanceAlreadyExistsException: Catalina:type=RequestProcessor,worker=jk-8009,name=JkRequest9845
>         at com.sun.jmx.mbeanserver.RepositorySupport.addMBean(Unknown Source)
>         at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(Unknown Source)
>         at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(Unknown Source)
>         at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(Unknown Source)
>         at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(Unknown Source)
>         at org.apache.commons.modeler.Registry.registerComponent(Registry.java:871)
>         at org.apache.jk.common.ChannelSocket.registerRequest(ChannelSocket.java:436)
>         at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:443)
>         at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352)
>         at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743)
>         at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675)
>         at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>         at java.lang.Thread.run(Unknown Source)
> Jan 21, 2010 5:05:52 PM org.apache.jk.common.ChannelSocket registerRequest
> WARNING: Error registering request
>  
> -------------------
> 
> SEVERE: Exception invoking periodic operation:
> java.lang.OutOfMemoryError: Java heap space
>         at org.apache.catalina.session.ManagerBase.findSessions(ManagerBase.java:752)
>         at org.apache.catalina.session.StandardManager.processExpires(StandardManager.java:778)
>         at org.apache.catalina.session.StandardManager.backgroundProcess(StandardManager.java:795)
>         at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4662)
>         at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1619)
>         at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628)
>         at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628)
>         at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1608)
>         at java.lang.Thread.run(Unknown Source)
>  
> -------------------------
> 
> The below are the env details of our production system:
> Apache Proxy: 2.2.11
> Apache Tomcat: 5.0.30
> JDK: 1.5.0_15
>  
> With JDK 1.4.2_15 on development, I could resolve this by adding request.registerRequests="false" in $TOMCAT_HOME/conf/jk2.properties. When applied the same to JDK 1.5.0_15, I am getting the below errors repeatedly before resulting in "OutOfMemoryError". Since it is production issue, could you please provide a solution for JDK 1.5.0_15 ASAP? Let me know if you need any details.

You seem to be under the mis-apprehension that you can treat the users'
mailing list the same way you would treat an organisation that is
providing Tomcat support on a commercial basis. If you want that sort of
support you'll need to pay for it.

The users' mailing list is a community of Tomcat users that help each
other solve Tomcat related problems. Like most similar communities, the
more you put in, the more you'll get out. Making demands of the
community isn't going to get you very far.

With regard to the error you are seeing, work on Tomcat 5.0.x was
discontinued some years ago. Many bugs have been fixed in later versions
including a number of important security fixes.

You also appear to be using mod_jk2, another component that has been
discontinued. You should switch to mod_jk or possibly mod_proxy.

Hmm. I spot a theme. Sun stopped supporting the JVM version you are
using some time ago (although there were a good number of updates to
1.5.0_15 before they did).

Your httpd major version is at least current, although not up to date
with the latest release.

It looks like you need to update most of the components in your system
before folks here are likely to be able to help you. As a minimum you
need to be on Tomcat 5.5.x and mod_jk. You really should consider Tomcat
6.0.x, JDK 1.6 and the latest httpd.

Mark
>  
> SEVERE: Error unregistering mbean
> javax.management.RuntimeOperationsException: Object name cannot be null
>         at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.isRegistered(Unknown Source)
>         at com.sun.jmx.mbeanserver.JmxMBeanServer.isRegistered(Unknown Source)
>         at org.apache.commons.modeler.Registry.unregisterComponent(Registry.java:642)
>         at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:706)
>         at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>         at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalArgumentException: Object name cannot be null
>         ... 7 more
>  
> Thanks,
> Venkat Kudipudi
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: WARNING: Error registering request

Posted by Peter Crowther <pe...@melandra.com>.
On 17 August 2010 06:41, VenkateswaraRao Eswar <ve...@yahoo.com>wrote:

> Could you please respond to this mail ASAP?
>
> That's a very good way of making sure the volunteers on this list *never*
respond to your email.  You are not paying for this support.  There is no
service level agreement.  If you want support that responds in a fixed time
- or at all - then buy some.

- Peter

Re: WARNING: Error registering request

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pid,

On 8/17/2010 4:16 AM, Pid wrote:
> You didn't respond to any of Chris's other points

+1

;)

That's exactly what I didn't bother to respond: Venkat ignored the crux
of my post (which was, in fact, aimed at keeping him running in
production with his current software versions) and focused on not upgrading.

When I get what I need to help him (or her?), I'll be happy to help if I
can.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxqm70ACgkQ9CaO5/Lv0PBgbgCfZ2NRLR0NbBJeDG0iJpkhRzDt
0vsAn07vqJu1vfvR4TkAz0PetXmwi/Kz
=gF63
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: WARNING: Error registering request

Posted by Pid <pi...@pidster.com>.
On 17/08/2010 06:41, VenkateswaraRao Eswar wrote:
> Could you please respond to this mail ASAP?

This is a community driven list, the people who give their time are
volunteers.

You didn't respond to any of Chris's other points and you're insisting
on staying with a Tomcat version that isn't supported any more.  The
ball's in your court, I'd say.


p

> Thanks,
> Venkat
> 
> --- On Tue, 10/8/10, VenkateswaraRao Eswar <ve...@yahoo.com> wrote:
> 
> 
> From: VenkateswaraRao Eswar <ve...@yahoo.com>
> Subject: Re: WARNING: Error registering request
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> 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 time.
> Any alternate solution to this issue with the current jdk/tomcat/Apache proxy versions instead of upgrading to newer versions?
>  
> Thanks,
> Venkat
> 
> --- On Fri, 6/8/10, Christopher Schultz <ch...@christopherschultz.net> wrote:
> 
> 
> From: Christopher Schultz <ch...@christopherschultz.net>
> Subject: Re: WARNING: Error registering request
> To: "Tomcat Users List" <us...@tomcat.apache.org>
> Date: Friday, 6 August, 2010, 10:59 AM
> 
> 
> On 8/6/2010 5:20 AM, VenkateswaraRao Eswar wrote:
>> With our production application, I am getting
>> "javax.management.InstanceAlreadyExistsException" 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
> occurred:
> 
> 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.
> 
> Resources:
> http://tomcat.apache.org/migration.html
> (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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org








Re: WARNING: Error registering request

Posted by VenkateswaraRao Eswar <ve...@yahoo.com>.
Could you please respond to this mail ASAP?
 
Thanks,
Venkat

--- On Tue, 10/8/10, VenkateswaraRao Eswar <ve...@yahoo.com> wrote:


From: VenkateswaraRao Eswar <ve...@yahoo.com>
Subject: Re: WARNING: Error registering request
To: "Tomcat Users List" <us...@tomcat.apache.org>
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 time.
Any alternate solution to this issue with the current jdk/tomcat/Apache proxy versions instead of upgrading to newer versions?
 
Thanks,
Venkat

--- On Fri, 6/8/10, Christopher Schultz <ch...@christopherschultz.net> wrote:


From: Christopher Schultz <ch...@christopherschultz.net>
Subject: Re: WARNING: Error registering request
To: "Tomcat Users List" <us...@tomcat.apache.org>
Date: Friday, 6 August, 2010, 10:59 AM


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/6/2010 5:20 AM, VenkateswaraRao Eswar wrote:
> With our production application, I am getting
> "javax.management.InstanceAlreadyExistsException" 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
occurred:

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.

Resources:
http://tomcat.apache.org/migration.html
(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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxcI1gACgkQ9CaO5/Lv0PBTNACeKvsYXmJ2doMZptQzJgQg/jot
+ccAnR1YhZ1qywv4imsI61A2qHpzWQd9
=VtD5
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org






Re: WARNING: Error registering request

Posted by VenkateswaraRao Eswar <ve...@yahoo.com>.
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 time.
Any alternate solution to this issue with the current jdk/tomcat/Apache proxy versions instead of upgrading to newer versions?
 
Thanks,
Venkat

--- On Fri, 6/8/10, Christopher Schultz <ch...@christopherschultz.net> wrote:


From: Christopher Schultz <ch...@christopherschultz.net>
Subject: Re: WARNING: Error registering request
To: "Tomcat Users List" <us...@tomcat.apache.org>
Date: Friday, 6 August, 2010, 10:59 AM


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/6/2010 5:20 AM, VenkateswaraRao Eswar wrote:
> With our production application, I am getting
> "javax.management.InstanceAlreadyExistsException" 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
occurred:

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.

Resources:
http://tomcat.apache.org/migration.html
(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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxcI1gACgkQ9CaO5/Lv0PBTNACeKvsYXmJ2doMZptQzJgQg/jot
+ccAnR1YhZ1qywv4imsI61A2qHpzWQd9
=VtD5
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org




Re: WARNING: Error registering request

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/6/2010 5:20 AM, VenkateswaraRao Eswar wrote:
> With our production application, I am getting
> "javax.management.InstanceAlreadyExistsException" 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
occurred:

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.

Resources:
http://tomcat.apache.org/migration.html
(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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxcI1gACgkQ9CaO5/Lv0PBTNACeKvsYXmJ2doMZptQzJgQg/jot
+ccAnR1YhZ1qywv4imsI61A2qHpzWQd9
=VtD5
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org