[Bug 54217] New: JDBC connection pool runs out of connections when Context reload=“true” is enabled in Tomcat

2012-11-28 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=54217

Bug ID: 54217
   Summary: JDBC connection pool runs out of connections when
Context reload=“true” is enabled in Tomcat
   Product: Tomcat 7
   Version: 7.0.32
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: informatik0...@gmail.com
Classification: Unclassified

Created attachment 29646
  -- https://issues.apache.org/bugzilla/attachment.cgi?id=29646action=edit
Exception stack trace

I am developing a Java EE web application in Eclipse Juno. I have configured
Tomcat to use JDBC connection pool (org.apache.tomcat.jdbc.pool) along with
PostgreSQL database. Here are the configurations in my project's
META-INF/context.xml:

?xml version=1.0 encoding=UTF-8?
Context
!-- Configuration for the Tomcat JDBC Connection Pool --
Resource name=jdbc/someDB
type=javax.sql.DataSource
auth=Container
factory=org.apache.tomcat.jdbc.pool.DataSourceFactory
driverClassName=org.postgresql.Driver
url=jdbc:postgresql://localhost:5432/somedb
username=postgres
password=12345
maxActive=100
minIdle=10
initialSize=10
validatonQuery=SELECT 1
validationInterval=3
removeAbandoned=true
removeAbandonedTimeout=60
abandonWhenPercentageFull=50 /
/Context

My application is deployed to Tomcat using Eclipse, and in Tomcat's context.xml
an attribute reloadable is set to true to automatically reload the web
application if a change is detected:

Context reloadable=true

I have noticed that every time the above mentioned automatic reload is
happening 10 more connections to PostgreSQL db is reserved (because in webapp's
context.xml initialSize=10). So after 10 changes a PSQLException is thrown:

org.postgresql.util.PSQLException: FATAL: sorry, too many clients already
...
(full stack in attachment)

If I manually restart Tomcat - everything is fine and just 10 connections are
reserved. And I am closing all ResultSets, Statements/PrepareStatements,
Connections in the finally block.

Would be great if this issue could be fixed, so that it could be possible to
develop with reloadable set to true and not cause pooling more connections
every time the context is reloaded.

P.S.
Apache Tomcat 7.0.32
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Eclipse Juno Service Release 1
PostgreSQL version 9.1
DB driver: postgresql-9.1-902.jdbc4.jar

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 54217] JDBC connection pool runs out of connections when Context reload=“true” is enabled in Tomcat

2012-11-28 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=54217

Levan informatik0...@gmail.com changed:

   What|Removed |Added

 OS||Windows 7

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: svn commit: r1414562 - /tomcat/native/branches/1.1.x/native/src/poll.c

2012-11-28 Thread jean-frederic clere

On 11/28/2012 08:28 AM, mt...@apache.org wrote:

Author: mturk
Date: Wed Nov 28 07:28:20 2012
New Revision: 1414562

URL: http://svn.apache.org/viewvc?rev=1414562view=rev
Log:
Fix typo in --enable-maintainer-mode


The comment doesn't fit the commit ;-)

Cheers

Jean-Frederic

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Tomcat8 Cartridge for OpenShift PaaS

2012-11-28 Thread William DeCoste

Hi all,

Development has begun on supporting Tomcat8 on Red Hat's OpenShift PaaS 
(https://openshift.redhat.com). OpenShift supports various development 
frameworks via cartridges. There are currently cartridges for Tomcat6 
(via JBossEWS1.0) and soon will be a cartridge for Tomcat7 (via 
JBossEWS2.0).


The new Tomcat8 community cartridge will be developed here: 
https://github.com/openshift/origin-community-cartridges


The community project for OpenShift Origin is here: 
https://github.com/openshift


Looking forward to working with the TC8 community.

Thanks -Bill

--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdeco...@redhat.com


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



svn commit: r1414889 - in /tomcat/trunk: java/org/apache/catalina/valves/AccessLogValve.java java/org/apache/catalina/valves/LocalStrings.properties java/org/apache/catalina/valves/mbeans-descriptors.

2012-11-28 Thread rjung
Author: rjung
Date: Wed Nov 28 20:04:52 2012
New Revision: 1414889

URL: http://svn.apache.org/viewvc?rev=1414889view=rev
Log:
Add new ALV attribute renameOnRotate (Default:false).

If set to true, the fileDateFormat will not be part
of the current log file. Only at the time of log rotation
the file is renamed to the final name including the
fileDateFormat.

This mimics the behavior e.g. of Log4J and similar frameworks,
where the active file does not have the timestamp in the file
name.

Pro: current file has stable name, all files with
 timestamp in name are old.
Con: Slightly more complex impl.

Modified:
tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
tomcat/trunk/java/org/apache/catalina/valves/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/valves/mbeans-descriptors.xml
tomcat/trunk/webapps/docs/config/valve.xml

Modified: tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java?rev=1414889r1=1414888r2=1414889view=diff
==
--- tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java (original)
+++ tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java Wed Nov 28 
20:04:52 2012
@@ -208,6 +208,12 @@ public class AccessLogValve extends Valv
  */
 protected boolean rotatable = true;
 
+/**
+ * Should we defer inclusion of the date stamp in the file
+ * name until rotate time? Default is false.
+ */
+protected boolean renameOnRotate = false;
+
 
 /**
  * Buffered logging.
@@ -729,6 +735,26 @@ public class AccessLogValve extends Valv
 
 
 /**
+ * Should we defer inclusion of the date stamp in the file
+ * name until rotate time
+ */
+public boolean isRenameOnRotate() {
+return renameOnRotate;
+}
+
+
+/**
+ * Set the value if we should defer inclusion of the date
+ * stamp in the file name until rotate time
+ *
+ * @param renameOnRotate true if defer inclusion of date stamp
+ */
+public void setRenameOnRotate(boolean renameOnRotate) {
+this.renameOnRotate = renameOnRotate;
+}
+
+
+/**
  * Is the logging buffered
  */
 public boolean isBuffered() {
@@ -968,7 +994,7 @@ public class AccessLogValve extends Valv
 
 if (currentLogFile != null) {
 File holder = currentLogFile;
-close();
+close(false);
 try {
 holder.renameTo(new File(newFileName));
 } catch (Throwable e) {
@@ -994,12 +1020,76 @@ public class AccessLogValve extends Valv
 /**
  * Close the currently open log file (if any)
  */
-private synchronized void close() {
+private File getLogFile(boolean useDateStamp) {
+
+// Create the directory if necessary
+File dir = new File(directory);
+if (!dir.isAbsolute()) {
+dir = new File(getContainer().getCatalinaBase(), directory);
+}
+if (!dir.mkdirs()  !dir.isDirectory()) {
+log.error(sm.getString(accessLogValve.openDirFail, dir));
+}
+
+// Calculate the current log file name
+File pathname;
+if (useDateStamp) {
+pathname = new File(dir.getAbsoluteFile(), prefix + dateStamp
++ suffix);
+} else {
+pathname = new File(dir.getAbsoluteFile(), prefix + suffix);
+}
+File parent = pathname.getParentFile();
+if (!parent.mkdirs()  !parent.isDirectory()) {
+log.error(sm.getString(accessLogValve.openDirFail, parent));
+}
+return pathname;
+}
+
+/**
+ * Move a current but rotated log file back to the unrotated
+ * one. Needed if date stamp inclusion is deferred to rotation
+ * time.
+ */
+private void restore() {
+File newLogFile = getLogFile(false);
+File rotatedLogFile = getLogFile(true);
+if (rotatedLogFile.exists()  !newLogFile.exists() 
+!rotatedLogFile.equals(newLogFile)) {
+try {
+if (!rotatedLogFile.renameTo(newLogFile)) {
+log.error(sm.getString(accessLogValve.renameFail, 
rotatedLogFile, newLogFile));
+}
+} catch (Throwable e) {
+ExceptionUtils.handleThrowable(e);
+log.error(sm.getString(accessLogValve.renameFail, 
rotatedLogFile, newLogFile), e);
+}
+}
+}
+
+
+/**
+ * Close the currently open log file (if any)
+ *
+ * @param rename Rename file to final name after closing
+ */
+private synchronized void close(boolean rename) {
 if (writer == null) {
 return;
 }
 writer.flush();
 writer.close();
+if (rename  renameOnRotate) {
+File newLogFile = getLogFile(true);
+ 

[Bug 54220] New: ErrorReportValve invoked on non-error responses too

2012-11-28 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=54220

Bug ID: 54220
   Summary: ErrorReportValve invoked on non-error responses too
   Product: Tomcat 6
   Version: 6.0.36
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: 1983-01...@gmx.net
Classification: Unclassified

If you issue a response.setStatus(404) from a servlet, you expect as per spec
that the response is left untouched. No error page written. There is sendError
for that.

Unfortunately, ErrorReportValve reacts on line 158
 if ((statusCode  400) || (response.getContentCount()  0))
return;

If you take a look at the StandardHostValve, it invokes error handling on line
316
 if (!response.isError())
return;
On errors only (correct behavior).

The ErrorReportValve must react on response.isError() == true only. Regardless
of the status code or the content count.
The Javadoc does not limit this to status codes = 400 but is says that
reponse.sendError() has to clears buffers. As far I understand that, regardless
of the response body is disposed and the error reponse is always written.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[Bug 54217] JDBC connection pool runs out of connections when Context reload=“true” is enabled in Tomcat

2012-11-28 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=54217

Konstantin Kolinko knst.koli...@gmail.com changed:

   What|Removed |Added

  Component|Catalina|Documentation
 OS||All

--- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com ---
You are not closing your connection pool properly. You need to specify
closeMethod=close. Without that the pool would not know when to close those
10 minIdle connections.

The attribute is documented here:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Resource_Definitions


This is going to be close as INVALID. Just holding it open for a while as a
chance to improve documentation: it would be better to add closeMethod to the
examples in jndi-datasource-examples-howto.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



[GUMP@vmgump]: Project tomcat-taglibs-standard (in module tomcat-taglibs) failed

2012-11-28 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-taglibs-standard has an issue affecting its community 
integration.
This issue affects 2 projects,
 and has been outstanding for 212 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-taglibs-standard :  Standard Taglib
- tomcat-taglibs-standard-install :  JSP Taglibs


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Optional dependency httpunit failed with reason build failed
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/tomcat-taglibs/standard/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/gump_work/build_tomcat-taglibs_tomcat-taglibs-standard.html
Work Name: build_tomcat-taglibs_tomcat-taglibs-standard (Type: Build)
Work ended in a state of : Failed
Elapsed: 22 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml 
install 
[Working Directory: /srv/gump/public/workspace/tomcat-taglibs/standard]
M2_HOME: /opt/maven2
-
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/src/test/resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing 
/srv/gump/public/workspace/tomcat-taglibs/standard/spec/target/taglibs-standard-spec-1.2-SNAPSHOT.jar
 to 
/srv/gump/public/workspace/mvnlocalrepo/shared/org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] [bundle:install {execution: default-install}]
[INFO] Parsing 
file:/srv/gump/public/workspace/mvnlocalrepo/shared/repository.xml
[INFO] Installing 
org/apache/taglibs/taglibs-standard-spec/1.2-SNAPSHOT/taglibs-standard-spec-1.2-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO] 
[INFO] Building JSTL Implementation
[INFO]task-segment: [install]
[INFO] 
[INFO] [remote-resources:process {execution: default}]
[INFO] snapshot org.apache.taglibs:taglibs-standard-spec:1.2-SNAPSHOT: checking 
for updates from apache.snapshots
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 14 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 96 source files to 
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
 error: DataSourceWrapper is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource
[INFO] 1 error
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
 error: DataSourceWrapper is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource

[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO]