Re: PermGen space
Il giorno ven, 16/02/2007 alle 14.42 +0100, Jost Richstein ha scritto: You assume a memory leak...well, that depends on the application. 64m as PermSize is not always enough for server site applications. But I agree: if there is a memory leak you will find it most likely in the application. I'm too have this problem, it arises because for some reason the Tomcat WebAppClassloader cannot be garbage collected after undeploy. I made a lot of tests and didn't find any solution, also very simple and small webapps, when loaded/unloaded frequently, caused the problem... :-( Bye, Davide Romanini signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: R: PROBLEMS CONNECTING TO TOMCAT MANAGER
Il giorno ven, 27/10/2006 alle 11.31 +0200, Daniela Marangoni ha
scritto:
Hi
I have tried with user test
?xml version='1.0' encoding='utf-8'?
tomcat-users
role rolename=tomcat/
role rolename=role1/
role rolename=manager/
role rolename=admin/
user username=tomcat password=tomcat roles=tomcat/
user username=both password=tomcat roles=tomcat,role1/
user username=role1 password=tomcat roles=role1/
user username=admin password=admin roles=admin,manager,tomcat/
user username=teste password=teste roles=manager/
/tomcat-users
but I still have the same problems . After trying to connect three times to:
Site: 127.0.0.1
Port : 8080
Realm : XDB
Username=test
Password=test
I receive as answer:
Unauthorized
Usually this error is generated because of the
security-constraintauth-constraint in
${catalina.home}/server/webapps/manager/WEB-INF/web.xml. Have you tried
to remove the constraint to see if you can access without any
user/password?
What about the admin application? Do you have the same problem with that
or does it work?
Check also that:
* in conf/server.xml there's a GlobalNamingResource named
UserDatabase (org.apache.catalina.UserDatabase) referencing the
file conf/tomcat-users.xml
* the default service/engine contains a Realm of type
org.apache.catalina.realm.UserDatabaseRealm referencing the
UserDatabase above.
* the file conf/[your-engine]/localhost/manager.xml contains a
ResourceEnvRef referencing the UserDatabse above (to be honest
this should not be an issue with authentication, but... just to
be sure).
Ciao,
Davide Romanini
Ciao,
Davide Romanini
signature.asc
Description: Questa è una parte del messaggio firmata digitalmente
Re: JDBC Pool exhaustion
Il giorno mer, 11/10/2006 alle 16.02 +0200, DE VINZELLES, Guillaume (ext.) ha scritto: Hello there, We are running a Tomcat 5.5.17 on a Sun Solaris system (SunFire V240) with a Sun JVM 1.5, and we are facing unavoidable JDBC pool exhaustions. We are using an Oracle 9i database. Here is the JDBC entry from our server.xml: Resource name=jdbc/Signup auth=Container type=javax.sql.DataSource driverClassName=oracle.jdbc.driver.OracleDriver url=jdbc:oracle:thin:@address:port:schema username=user password=pass maxActive=120 maxIdle=10 maxWait=5000 removeAbandoned=true removeAbandonedTimeout=60 / The Tomcat manager shows around 1000 sessions on the server, which seems to be pertinent. We can see with the JMXProxy that the JDBC pool connections are never recycled, e.g. the active connections number is going higher and higher and never stays at the same level, which is strange because the amount of active sessions isn't growing. From my understanding of the DBCP docs I see that the removeAbandoned mechanism is triggered only when numIdle 2 ( numActive maxActive - 3 ). So I think that if some application code doesn't release a connection you *could* see the numActive grow until maxActive but you *shouldn't* have a pool exahustion (that force you to manually close() the connection pool or restart Tomcat) because when you reach the limit the pool will check if some active connection is eligible for removal. But I'm not sure of this... the docs are not so clear... Recently I've experienced a pool exhaustion problem with Oracle JDBC thin driver 10.2.0.1.0. The problem arised when for some unexpected network problem all idle connections was resetted. At the time I made a getConnection() the (unusable) connection became active and then... no more released by the pool (still the application throwed an Exception and returned, cleaning up in finally blocks). I solved using the validationQuery and testOnBorrow=true options of DBCP. Do you have any idea about what we can do to 'force' the Tomcat server to release the unused JDBC connections? Via JMX you can do a close() on the pool that will close all active and idle connections. Ciao, Davide Romanini signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: EJB
Il giorno ven, 07/04/2006 alle 12.52 +0530, Vivek Mohan ha scritto: Can you do that? I thought Tomcat doesn't support EJBs! You can embed the EJB container (like OpenEJB), or simply refer EJB in a running container through JNDI. I read some tutorial, try starting from http://openejb.codehaus.org/Tomcat However, I really can't find any good reason to add EJB bloat to an existing web application, it really doesn't add benefit, if you need to access an existing external EJB I think you can through JNDI with appropriate configuration, if you want to add some service without using a full application server (like JBoss), there are many better alternatives like Spring container or Hivemind. Bye, Davide Romanini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaking on [un|re]load: WebappClassLoader isn't GC'ed
Il giorno mer, 25/01/2006 alle 11.12 -0800, Wade Chandler ha scritto: Don't use shared libraries and you shouldn't have this problem. If all of the statics are in your WEB-INF directory then you won't have an issue with unloading classes and class loaders. It would be great if could be so simple. But it is not, trust me, my shared folder is empty, and the common/lib folder contains only jdbc drivers and javamail implementation (needed by Tomcat if you want to use JNDI mail sessions). All the libraries of the webapp are in WEB-INF/lib folder. As I said in previous mail, I tried to reload the distribution version of Axis (just as is, without other libs) and it causes the problem. It seems that something occuring during AxisServlet startup (it looks for his configuration using a complex discovery process) causes some class of a parent classloader to hold a reference to WebappClassloader so it cannot be GC'ed when it's reloaded. Surely it's not a Tomcat problem anyway... Bye, Davide Romanini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leaking on [un|re]load: WebappClassLoader isn't GC'ed
Il giorno gio, 26/01/2006 alle 06.23 -0500, Kevan Miller ha scritto: Davide, If you're using Axis, you might be interested in two Axis issues that I uncovered. They both caused ClassLoader memory leaks within Geronimo. The problems are described here: http://issues.apache.org/jira/browse/AXIS-2232 http://issues.apache.org/jira/browse/AXIS-2278 The changes are committed in SVN. However, there hasn't been an official Axis release, since then. The following binary contains the updates and is the version delivered by Geronimo: http://cvs.apache.org/repository/axis/jars/axis-1.4-356167.jar Thanks, I'll take a try. I hope to solve the problem. Bye, Davide Romanini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
