I had to restart tomcat, but I am not sure if there was a simpler way to
solve the problem at that time.
There were threads that were waiting on loading user from db (for
authentication), which explains why I couldnt login.
I can send the thread dump (of hen the problem occurred) tomorrow from
work..dont have it on me right now.
The settings I sent were on production. only the https threads will make
connections to db.
You suggested setting the debug options. We are using BasicDataSource
from apache dbcp for pooling, and the methods to set the debug options
you mentioned have been deprecated. Would it be ok to set these values
anyways?
Good idea to set the pool to 1 in development. Will try that.
Martin, I am using hibernate and spring to inject the datasource into
the session factory bean. We did not set a maxActive value on the
dataSource, but did on the hibernate properties. Any idea which value
will be used (the default of the datasource, or the hibernate value)?
The settings are shown below, can you recommend ideal/better values?
Thanks,
-Riz.
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>/WEB-INF/hibernate.properties</value>
<value>/WEB-INF/eshipper.properties</value>
</list>
</property>
</bean>
<bean id="dataSource"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName"
value="${hibernate.connection.driver_class}" />
<property name="url" value="${hibernate.connection.url}" />
<property name="username"
value="${hibernate.connection.username}" />
<property name="password"
value="${hibernate.connection.password}" />
</bean>
<!-- Hibernate SessionFactory -->
<bean id="sessionFactory"
class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="mappingDirectoryLocations">
<list>
<value>classpath:com/cwsi/eshipper/model</value>
<value>classpath:com/cwsi/eshipper/carrier/purolator/model</value>
<value>classpath:com/cwsi/eshipper/carrier/cws/model</value>
</list>
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">
${hibernate.dialect}
</prop>
<prop key="hibernate.show_sql">false</prop>
<prop key="hibernate.generate_statistics">true</prop>
<prop key="hibernate.dbcp.maxActive">30</prop>
<prop key="hibernate.dbcp.whenExhaustedAction">20</prop>
<prop
key="hibernate.dbcp.maxWait">${hibernate.connection.maxWait}</prop>
<prop key="hibernate.dbcp.maxIdle">10</prop>
</props>
</property>
<property name="eventListeners">
<map>
<entry key="merge">
<bean
class="org.springframework.orm.hibernate3.support.IdTransferringMergeEventListener"
/>
</entry>
</map>
</property>
</bean>
Christopher Schultz wrote:
Riz,
Basically, we could not log into the system at all (which sounded like
the app could not get a connection to the db to authenticate my user
name and password). I had someone else try to log in, but he could not
either.
That sounds like a wild guess at the problem. Your previous thread dump
only included 3 threads. How many were waiting on DBCP for a JDBC
connection? What did you have to do in order to get the server working
again? Re-start Tomcat? Bounce the database? OR, did it clear itself up
after a while.
Oh, and also: was this in your production or development environment?
<Connector port="8080" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
Note that you have 3 connectors (HTTP, HTTPS, and AJP13) and each of
them have a lot of potential threads in there. Your server will accept
as many as 150 + 150 + 150 connections simultaneously. If they all need
database connections, you're screwed, 'cause you only have between 10
and 30 (right?):
<prop key="hibernate.dbcp.maxActive">30</prop>
<prop key="hibernate.dbcp.whenExhaustedAction">20</prop>
<prop key="hibernate.dbcp.maxWait">1000</prop>
<prop key="hibernate.dbcp.maxIdle">10</prop>
I'm not sure how to set it up using hibernate's wrapper around DBCP, but
I recommend setting the following debug options on the connection pool:
<!-- Some debugging settings -->
<parameter>
<name>removeAbandoned</name>
<value>true</value>
</parameter>
<parameter>
<name>removeAbandonedTimeout</name>
<value>300</value>
</parameter>
<parameter>
<name>logAbandoned</name>
<value>true</value>
</parameter>
Together, these will dump out a stack trace of any code that gets a
database connection and never returns it. This is useful for finding
accidental connections leaks. I also recommend setting your pol size
fixed at 1 (yes, that's ONE) in development. It will help you find any
connection leaks that you might have very quickly.
-chris
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
