Hi Rainer,
Thanks for jumping in again..
Rainer Jung-3 wrote:
When using big heaps, you need to take extra effort to get your GC
settings right. Do you have GC-Logs? What are the JVM options you use to
start Tomcat?
The JVM options:
-Dcatalina.base=D:\tomcat -Dcatalina.home=D:\tomcat
Am 11.12.2008 09:43, schrieb Jesse Klaasse:
Rainer Jung-3 wrote:
When using big heaps, you need to take extra effort to get your GC
settings right. Do you have GC-Logs? What are the JVM options you use to
start Tomcat?
The JVM options:
-Dcatalina.base=D:\tomcat -Dcatalina.home=D:\tomcat
After two months with a system running smoothly, we are currently
experiencing the same problems again (albeit less often).
A little update:
- The system's memory has been upgraded to 16 GB, Tomcat's memory settings
are Xms4096m and Xmx10240m now.
- We are using commons-dbcp 1.2.2 instead of
Hi Jesse,
Jesse Klaasse schrieb:
After two months with a system running smoothly, we are currently
experiencing the same problems again (albeit less often).
A little update:
- The system's memory has been upgraded to 16 GB, Tomcat's memory settings
are Xms4096m and Xmx10240m now.
When
I will try to remove/increase socket_timeout to see what happens..
Unfortunately, Tomcat hung again today. It managed to work again without
manually restarting, but again, the 503 message for a while..
I attached two thread dumps and an excerpt of today's isapi_redirect.log.
BTW, this is APR
Jesse Klaasse schrieb:
I will try to remove/increase socket_timeout to see what happens..
Unfortunately, Tomcat hung again today. It managed to work again without
manually restarting, but again, the 503 message for a while..
I attached two thread dumps and an excerpt of today's
Last Wednesday, I decided to try to use commons-dbcp (1.2.2) instead of the
included naming-factory-dbcp.jar. Besides that, I have removed the
validationQuery attribute, after reading about some problems with that.
Since then, no problems have arised, Tomcat behaved nicely. I hope this
finally
Jesse Klaasse schrieb:
Last Wednesday, I decided to try to use commons-dbcp (1.2.2) instead of the
included naming-factory-dbcp.jar. Besides that, I have removed the
validationQuery attribute, after reading about some problems with that.
Since then, no problems have arised, Tomcat behaved
Jesse Klaasse schrieb:
Hi Rainer,
We are a week later now, with the changed settings, and while the
environment first seemed to be a little more stable, in the end this
unfortunately is not the case... We still reboot Tomcat every night
automatically, and most of the time once a day manually
Hi Rainer,
We are a week later now, with the changed settings, and while the
environment first seemed to be a little more stable, in the end this
unfortunately is not the case... We still reboot Tomcat every night
automatically, and most of the time once a day manually because of the 503
error.
Hello Rainer,
First of all, thank you for your extensive answer and the time you have
taken to write the answer, this really gives me hope.
Rainer Jung-3 wrote:
Double check: The worker is a member of a load balancer. the member is
*not* in state STOP (because that is a configuration
I'm doing top posting, because this is only a quick and incomplete reply:
The root problem lies within the database connection pool. All 400
Tomcat threads are waiting in getConnection() to get a free DB
connection from the common-dbcp pool.
There are some bugs around dbcp, but I need a
Hi Rainer. Thank you very much for this preliminary information. I had
already noticed the AbandonedObjectPool messages myself.
My resource configuration:
name=bam/jdbc/vip8db
auth=Container
type=javax.sql.DataSource
username=***REMOVED***
password=***REMOVED***
Jesse Klaasse wrote:
Hi Rainer. Thank you very much for this preliminary information. I had
already noticed the AbandonedObjectPool messages myself.
My resource configuration:
name=bam/jdbc/vip8db
auth=Container
type=javax.sql.DataSource
username=***REMOVED***
password=***REMOVED***
Hello Rainer,
Thanks again for your prompt and clear reply. You're helping me a lot!
I have implemented the settings as you suggested (for the datasources of all
8 webapps on my Tomcat server). I need to wait for a restart of the
application before the settings become active, however.
For your
Hi Jesse,
Jesse Klaasse wrote:
Hello Rainer,
Thanks again for your prompt and clear reply. You're helping me a lot!
I have implemented the settings as you suggested (for the datasources of all
8 webapps on my Tomcat server). I need to wait for a restart of the
application before the settings
I have migrated a customer's server system to the following
configuration:
MS IIS 6.0 (port 80)
Unlimited connections
Connection timeout: 120s keep-alive
JK 1.2.25 AJP/1.3 Connector
isapi_redirect.properties:
uri_select=parsed
workers.properties:
connect_timeout=1
prepost_timeout=1
Additional information:
When using version 1.2.26 of the connector, these messages appear in
isapi_redirect.log before the messages I quoted in my previous mail:
[Wed Jul 02 15:39:34.690 2008] [11800:10604] [info] service::jk_lb_worker.c
(1221): Forcing recovery once for 1 workers
[Wed Jul 02
Hi Jesse,
Jesse Klaasse schrieb:
I have migrated a customer's server system to the following
configuration:
MS IIS 6.0 (port 80)
Unlimited connections
Connection timeout: 120s keep-alive
JK 1.2.25 AJP/1.3 Connector
isapi_redirect.properties:
uri_select=parsed
workers.properties:
19 matches
Mail list logo
