DO NOT REPLY [Bug 52651] New: JKSHMFile size limitation
https://issues.apache.org/bugzilla/show_bug.cgi?id=52651 Bug #: 52651 Summary: JKSHMFile size limitation Product: Tomcat Connectors Version: 1.2.32 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: mod_jk AssignedTo: dev@tomcat.apache.org ReportedBy: jea...@gmail.com Classification: Unclassified Hello, config: we are running apache 2.2.15 with mod_jk 1.2.32 (as module) on rhel 5, 64 bit servers. the jk.conf include JkShmSize 256 JkShmFile tmp/jk.shm issue description: Before last week everything was working fine. We then add some more workers in our config (till we had 361 workers configured) and then issue begin: - in the mod_jk log file i saw that sometimes, the apache consider the workers as down. the connection was working 90% of the time, but 10% of the connections were replied with a 503 error. - I saw at tcp level that apache sent SYN to the jboss, jboss replies with the SYN-ACK, then apache directly send a RST package. - when stopping the apache and starting again, it fails with the error "You can remove the JkShmSize directive if you want to use the optimal size" in the mod_jk log I made a lot of tests, removing the jkshmsize directive, setting it to 512, 1024 or even 4096 but without success I had to reduce the numbers of workers configured in order to solve the issue. Sounds like the jkshmfile is limited in size leading to some kind of memory issue when we configure more than +- 325 workers. could you check that ? brgds JF -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52652] New: Bad link to Ant in tools.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=52652 Bug #: 52652 Summary: Bad link to Ant in tools.html Product: Tomcat 7 Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Documentation AssignedTo: dev@tomcat.apache.org ReportedBy: bode...@apache.org Classification: Unclassified Created attachment 28314 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28314 trivial fix to the link for Ant Actually this is a minor bug in the Tomcat site but I can't see a product or component for the website. The link on the Ant logo on tools.html points to apache.com rather than .org, -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
svn commit: r1243508 - in /tomcat/site/trunk: docs/tools.html xdocs/tools.xml
Author: kkolinko Date: Mon Feb 13 13:50:43 2012 New Revision: 1243508 URL: http://svn.apache.org/viewvc?rev=1243508&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52652 Correct typos in tools.html s/licence/license/ seems to be GB vs UK. IDE hilights "licence" as misspelled, event though m dictionary knows this word. Modified: tomcat/site/trunk/docs/tools.html tomcat/site/trunk/xdocs/tools.xml Modified: tomcat/site/trunk/docs/tools.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/tools.html?rev=1243508&r1=1243507&r2=1243508&view=diff == --- tomcat/site/trunk/docs/tools.html (original) +++ tomcat/site/trunk/docs/tools.html Mon Feb 13 13:50:43 2012 @@ -258,7 +258,7 @@ and a committer should be able to fix it -http://ant.apache.com";> +http://ant.apache.org/";> http://ant.apache.org/images/ant_logo_medium.gif";> Apache Tomcat is built using Apache Ant. @@ -293,7 +293,7 @@ and a committer should be able to fix it -http://www.eclipse.org"; rel="nofollow"> +http://www.eclipse.org/"; rel="nofollow"> A variety of IDEs are used by the Tomcat developers. One of them is @@ -329,7 +329,7 @@ and a committer should be able to fix it -http://www.yourkit.com"; rel="nofollow"> +http://www.yourkit.com/"; rel="nofollow"> YourKit, LLC kindly provide free licenses for the YourKit Java Profiler @@ -344,10 +344,10 @@ and a committer should be able to fix it -http://msdn.microsoft.com"; rel="nofollow"> +http://msdn.microsoft.com/"; rel="nofollow"> -Microsoft kindly provide free MSDN licences to Apache committers that +Microsoft kindly provide free MSDN licenses to Apache committers that have a requirement for them. MSDN is primarily used to provide build and test environments for the ISAPI redirector and the Windows APR/native connector but it is also used to provide test platforms for Windows @@ -359,10 +359,10 @@ and a committer should be able to fix it -http://www.structure101.com"; rel="nofollow"> +http://www.structure101.com/"; rel="nofollow"> -Headway software kindly provide free licences for Structure 101 to open +Headway software kindly provide free licenses for Structure 101 to open source projects. Structure 101 is primarily being used in Tomcat trunk to analyze the current package dependencies and identify areas where they may be simplified. Modified: tomcat/site/trunk/xdocs/tools.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/tools.xml?rev=1243508&r1=1243507&r2=1243508&view=diff == --- tomcat/site/trunk/xdocs/tools.xml (original) +++ tomcat/site/trunk/xdocs/tools.xml Mon Feb 13 13:50:43 2012 @@ -24,7 +24,7 @@ and a committer should be able to fix it - http://ant.apache.com";> + http://ant.apache.org/";> http://ant.apache.org/images/ant_logo_medium.gif"/> Apache Tomcat is built using Apache Ant. @@ -35,7 +35,7 @@ and a committer should be able to fix it - http://www.eclipse.org"; rel="nofollow"> + http://www.eclipse.org/"; rel="nofollow"> A variety of IDEs are used by the Tomcat developers. One of them is the Eclipse IDE. @@ -47,7 +47,7 @@ and a committer should be able to fix it - http://www.yourkit.com"; rel="nofollow"> + http://www.yourkit.com/"; rel="nofollow"> YourKit, LLC kindly provide free licenses for the YourKit Java Profiler to open source projects. YourKit Java Profiler is primarily used to @@ -57,9 +57,9 @@ and a committer should be able to fix it - http://msdn.microsoft.com"; rel="nofollow"> + http://msdn.microsoft.com/"; rel="nofollow"> - Microsoft kindly provide free MSDN licences to Apache committers that + Microsoft kindly provide free MSDN licenses to Apache committers that have a requirement for them. MSDN is primarily used to provide build and test environments for the ISAPI redirector and the Windows APR/native connector but it is also used to provide test platforms for Windows @@ -67,9 +67,9 @@ and a committer should be able to fix it - http://www.structure101.com"; rel="nofollow"> + http://www.structure101.com/"; rel="nofollow"> - Headway software kindly provide free licences for Structure 101 to open + Headway software kindly provide free licenses for Structure 101 to open source projects. Structure 101 is primarily being used in Tomcat trunk to analyze the current package dependencies and identify areas where they may be simplified. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52652] Bad link to Ant in tools.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=52652 Konstantin Kolinko changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Konstantin Kolinko 2012-02-13 13:51:34 UTC --- Fixed. Thank you. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51181] Add support for Web Sockets
https://issues.apache.org/bugzilla/show_bug.cgi?id=51181 --- Comment #35 from Lucas Dreyer 2012-02-13 13:53:52 UTC --- +1, Tomcat is an integral part of our system and Web Socket support will be awesome. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: Website refresh
>I like the mockup. It is a step up from what we have already. Thanks, I think it's a good idea to match want Pid created for Tomcat 7. >I think there is some serious re-organising of the docs required as >well. I am happy to take a look at the reorganising if someone else (you >Jeremy?) is able to improve the look and feel (something that I known I >have zero talent for). I think we could start incrementally. Maybe just start the new css and the new header and static menubar for the base pages at first. How is the main content div generated for the main page? Do we have any insight as to what should be on the menubar? If we have any analytics for the site it could help us make the most utilized areas the most accessible. Can I get some access to look around, or is the source somewhere I can checkout? >I'm also happy to apply patches to the site and docs as you develop them. That sounds good since you are aware of the whole structure and I just got here. Pid >I've got mods to the site build that move it in the direction of the >7.0 index page. >If a partial patch is enough to get started I'll submit it. Do you mind sharing what you have started with us? If we can utilize any work you have already done that would preferable to doing it all over. Cheers, Jeremy On Sun, Feb 12, 2012 at 3:54 PM, Pid * wrote: > On 12 Feb 2012, at 16:57, Mark Thomas wrote: > > > On 11/02/2012 22:42, Jeremy Brown wrote: > >> Thanks for letting me know Chuck. > >> > >> Please see the mockup image here. > >> > >> https://s3.amazonaws.com/jjbosstracker/TomcatMockup.jpg > > > > I like the mockup. It is a step up from what we have already. > > > > I think there is some serious re-organising of the docs required as > > well. I am happy to take a look at the reorganising if someone else (you > > Jeremy?) is able to improve the look and feel (something that I known I > > have zero talent for). > > > > I'm also happy to apply patches to the site and docs as you develop them. > > I've got mods to the site build that move it in the direction of the > 7.0 index page. > > I've not had/found the time to work through all the changes to make it > an effective or non-breaking change. > > If a partial patch is enough to get started I'll submit it. > > > p > > > On a related topic, we need to move to svpubsub by the end of this year. > > That means updating the site build script so it pulls in the docs from > > each of the latest Tomcat releases. Again, I am happy to get that > > working. The big advantage this gets us, is the ability to do instant > > updates to the website. > > > > Mark > > > >> > >> Cheers, Jeremy > >> > >> On Sat, Feb 11, 2012 at 4:27 PM, Caldarale, Charles R < > >> chuck.caldar...@unisys.com> wrote: > >> > From: Jeremy Brown [mailto:jjbosstrac...@gmail.com] > Subject: Website refresh > >>> > Check out the attached mockup of a possible web refresh. > >>> > >>> The list strips attachments, so you'll need to post the image > somewhere if > >>> you want anyone other than direct recipients to see it. > >>> > >>> - Chuck > >>> > >>> > >>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY > >>> MATERIAL and is thus for use only by the intended recipient. If you > >>> received this in error, please contact the sender and delete the > e-mail and > >>> its attachments from all computers. > >>> > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >>> For additional commands, e-mail: dev-h...@tomcat.apache.org > >>> > >>> > >> > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Website refresh
On 13/02/2012 15:06, Jeremy Brown wrote: >> I like the mockup. It is a step up from what we have already. > > Thanks, I think it's a good idea to match want Pid created for Tomcat 7. +1 >> I think there is some serious re-organising of the docs required as >> well. I am happy to take a look at the reorganising if someone else (you >> Jeremy?) is able to improve the look and feel (something that I known I >> have zero talent for). > > I think we could start incrementally. Maybe just start the new css and the > new header and static menubar for the base pages at first. +1 > How is the main > content div generated for the main page? Do we have any insight as to what > should be on the menubar? If we have any analytics for the site it could > help us make the most utilized areas the most accessible. Can I get some > access to look around, or is the source somewhere I can checkout? The current site is available in the ASF public svn repo here: http://svn.apache.org/repos/asf/tomcat/site/trunk/ The README.txt file explains how to build the site. Regarding analytics, we have the full access logs. I'll pull a representative sample and generate some stats. Mark >> I'm also happy to apply patches to the site and docs as you develop them. > > That sounds good since you are aware of the whole structure and I just got > here. > > > Pid > >> I've got mods to the site build that move it in the direction of the >> 7.0 index page. >> If a partial patch is enough to get started I'll submit it. > > Do you mind sharing what you have started with us? If we can utilize any > work you have already done that would preferable to doing it all over. > > > Cheers, Jeremy > > > On Sun, Feb 12, 2012 at 3:54 PM, Pid * wrote: > >> On 12 Feb 2012, at 16:57, Mark Thomas wrote: >> >>> On 11/02/2012 22:42, Jeremy Brown wrote: Thanks for letting me know Chuck. Please see the mockup image here. https://s3.amazonaws.com/jjbosstracker/TomcatMockup.jpg >>> >>> I like the mockup. It is a step up from what we have already. >>> >>> I think there is some serious re-organising of the docs required as >>> well. I am happy to take a look at the reorganising if someone else (you >>> Jeremy?) is able to improve the look and feel (something that I known I >>> have zero talent for). >>> >>> I'm also happy to apply patches to the site and docs as you develop them. >> >> I've got mods to the site build that move it in the direction of the >> 7.0 index page. >> >> I've not had/found the time to work through all the changes to make it >> an effective or non-breaking change. >> >> If a partial patch is enough to get started I'll submit it. >> >> >> p >> >>> On a related topic, we need to move to svpubsub by the end of this year. >>> That means updating the site build script so it pulls in the docs from >>> each of the latest Tomcat releases. Again, I am happy to get that >>> working. The big advantage this gets us, is the ability to do instant >>> updates to the website. >>> >>> Mark >>> Cheers, Jeremy On Sat, Feb 11, 2012 at 4:27 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: >> From: Jeremy Brown [mailto:jjbosstrac...@gmail.com] >> Subject: Website refresh > >> Check out the attached mockup of a possible web refresh. > > The list strips attachments, so you'll need to post the image >> somewhere if > you want anyone other than direct recipients to see it. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE >> PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you > received this in error, please contact the sender and delete the >> e-mail and > its attachments from all computers. > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52654] New: Incomplete documentation about DataSource JMX registration outside a container
https://issues.apache.org/bugzilla/show_bug.cgi?id=52654 Bug #: 52654 Summary: Incomplete documentation about DataSource JMX registration outside a container Product: Tomcat Modules Version: unspecified Platform: PC Status: NEW Severity: normal Priority: P2 Component: jdbc-pool AssignedTo: dev@tomcat.apache.org ReportedBy: guenther.dem...@wuerth-phoenix.com Classification: Unclassified In https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html there's written: If you're running outside of a container, you can register the DataSource yourself under any object name you specify... Actually that what you need to register is not the dataSource itself, as the sentence above suggests, but rather is it's jmxPool. Furthermore it may be necessary to force pool creation explicitly by calling dataSource.createPool() before calling mBeanServer.registerMBean(dataSource.getPool().getJmxPool(),objectname) otherwise a NPE exception will raise. Please document this -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50864] Reconfigure pool on the fly using JMX
https://issues.apache.org/bugzilla/show_bug.cgi?id=50864 --- Comment #1 from guenther 2012-02-13 16:06:58 UTC --- To note in this context is also the fact that currently (Tomcat JDBC Connection Pool 1.1.0.0) several setter-methods in org.apache.tomcat.jdbc.pool.jmx.ConnectionPools have an empty body. As long as they are not implemented it is better to remove them (the settermethods, not the getter-methods) from the mbean interface, otherwise the user believes to can change these values, but in truth the changes are not considered at all. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52651] JKSHMFile size limitation
https://issues.apache.org/bugzilla/show_bug.cgi?id=52651 --- Comment #1 from Rainer Jung 2012-02-13 16:54:56 UTC --- Version 1.2.32 is able to comute the needed shared memory size without the need for the JkShmSize configuration directive. It is a leftover from previous versions. Remove it (I think mod_jk now logs an info or warning during startup, that you should remove it). Whether there's a problem with too many workers or not? I wouldn't expect one, but your experience contradicts myexpectation. So let's first see what happens if you remove that configuration directive completely. If it still doesn't work, please post whatever the JK log file contains during the startup and the first test request. It would help, if you could increse the JkLogLevel for this simple test to debug (or even better trace). Regards, Rainer -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
svn commit: r1243655 - in /tomcat/trunk/modules/jdbc-pool/src: main/java/org/apache/tomcat/jdbc/pool/interceptor/ test/java/org/apache/tomcat/jdbc/bugs/ test/java/org/apache/tomcat/jdbc/pool/intercept
Author: fhanik
Date: Mon Feb 13 19:07:30 2012
New Revision: 1243655
URL: http://svn.apache.org/viewvc?rev=1243655&view=rev
Log:
Fix for
https://issues.apache.org/bugzilla/show_bug.cgi?id=51582
Added:
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/pool/interceptor/InduceSlowQuery.java
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java?rev=1243655&r1=1243654&r2=1243655&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java
Mon Feb 13 19:07:30 2012
@@ -49,7 +49,7 @@ public class SlowQueryReport extends Abs
/**
* the queries that are used for this interceptor.
*/
-protected ConcurrentHashMap queries = null;
+protected volatile ConcurrentHashMap queries = null;
/**
* Maximum number of queries we will be storing
*/
@@ -104,7 +104,7 @@ public class SlowQueryReport extends Abs
*/
@Override
public void closeInvoked() {
-queries = null;
+
}
@Override
@@ -186,6 +186,8 @@ public class SlowQueryReport extends Abs
super.reset(parent, con);
if (parent!=null)
queries = SlowQueryReport.perPoolStats.get(parent.getName());
+else
+queries = null;
}
Added:
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java?rev=1243655&view=auto
==
---
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java
(added)
+++
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java
Mon Feb 13 19:07:30 2012
@@ -0,0 +1,121 @@
+package org.apache.tomcat.jdbc.bugs;
+
+import java.sql.CallableStatement;
+import java.sql.Connection;
+import java.sql.SQLException;
+import java.sql.Statement;
+import java.util.ArrayList;
+import java.util.List;
+
+import org.apache.tomcat.jdbc.pool.ConnectionPool;
+import org.apache.tomcat.jdbc.pool.PoolConfiguration;
+import org.apache.tomcat.jdbc.pool.PoolProperties;
+import org.apache.tomcat.jdbc.test.DefaultProperties;
+
+
+public class Bug51582
+{
+
+ /**
+ * @param args
+ * @throws SQLException
+ */
+ public static void main(String[] args) throws SQLException
+ {
+org.apache.tomcat.jdbc.pool.DataSource datasource = null;
+PoolConfiguration p = new DefaultProperties();
+
+p.setJmxEnabled(true);
+p.setTestOnBorrow(false);
+p.setTestOnReturn(false);
+p.setValidationInterval(1000);
+p.setTimeBetweenEvictionRunsMillis(2000);
+
+p.setMaxWait(2000);
+p.setMinEvictableIdleTimeMillis(1000);
+
+datasource = new org.apache.tomcat.jdbc.pool.DataSource();
+datasource.setPoolProperties(p);
+
datasource.setJdbcInterceptors("org.apache.tomcat.jdbc.pool.interceptor.SlowQueryReportJmx(threshold=200)");
+ConnectionPool pool = datasource.createPool();
+
+
+Connection con = pool.getConnection();
+Statement st = con.createStatement();
+try {
+st.execute("DROP ALIAS SLEEP");
+}catch (Exception ignore) {}
+st.execute("CREATE ALIAS SLEEP AS $$\nboolean sleep() {\ntry {\n
Thread.sleep(1);\nreturn true;} catch
(Exception x) {\nreturn false;\n}\n}\n$$;");
+st.close();
+con.close();
+int iter = 0;
+while ((iter++) < 10)
+{
+ final Connection connection = pool.getConnection();
+ final CallableStatement s = connection.prepareCall("{CALL SLEEP()}");
+
+ List threadList = new ArrayList();
+
+ for (int l = 0; l < 3; l++)
+ {
+final int i = l;
+
+Thread thread = new Thread()
+{
+ @Override
+ public void run()
+ {
+try
+{
+ if (i == 0)
+ {
+Thread.sleep(1000);
+s.cancel();
+ }
+ else if (i == 1)
+ {
+//or use some other statement which will block for a longer
time
+long start = System.currentTimeMillis();
+System
DO NOT REPLY [Bug 51582] NPE in SlowQueryReport
https://issues.apache.org/bugzilla/show_bug.cgi?id=51582 Filip Hanik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Filip Hanik 2012-02-13 19:08:19 UTC --- Fixed in r1243655 it was setting the query cache to null when the connection was returned to the pool instead of when the connection was actually closed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51582] NPE in SlowQueryReport
https://issues.apache.org/bugzilla/show_bug.cgi?id=51582 --- Comment #11 from Patric Rufflar 2012-02-13 19:42:40 UTC --- Thanks, Filip and welcome back. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: Tomcat web site UI update (was:WebSocket progress report)
Mark, On 2/9/12 11:04 AM, Mark Thomas wrote: > On 09/02/2012 15:07, Jeremy brown wrote: >> Hi Jonathan and Petr, >> >> I'm an Application Development Graduate Student at Illinois Institute of >> Technology and I'd like to get started contributing to Tomcat. If you have >> any tasks I can help out with please let me know. I'd even be happy to >> start with simple tasks in order begin to familiarize myself with the >> project and code base, such as writing or formatting javadoc or cleaning up >> white space. > > In addition to the WebSocket work, there are ~100 enhancement requests > in various states in Bugzilla. You could also take a look at those and > see if one sparks your interest. If you have an interest in web design > the the Tomcat web site and documentation is long overdue an overhaul. IIRC, Pid did a bunch of work toward that end and it was ultimately vetoed but did result in an update of the documentation that actually ships with Tomcat. Does anyone have any specific parameters within which such a website redesign could/should be done? I don't want someone spending a long time giving us a nice new web design and then have it not accepted for one reason or another: it's not exactly encouraging when a community rejects well-spent time. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: WebSocket progress report
Mark, On 2/10/12 11:49 AM, Mark Thomas wrote: > > I prefer the work pid did on the Tomcat 7 index page for the ROOT webapp. +1 -chris signature.asc Description: OpenPGP digital signature
Re: WebSocket progress report
Jeremy, On 2/10/12 12:08 PM, Jeremy Brown wrote: >> I suspect it will need more than that. The XLST will almost certainly >> need some tweaks too. > > How timely, I'm doing xml transformations in my SOA class right now. If you have any questions about XSLT, I'd be happy to answer them. It's definitely something that you have to have a Zenlike relationship with in order to do properly. Just like Lisp, it's possible to write really awful procedurally-oriented code with it, but then it just sucks horribly. We've been using XSLT for a long time with Apache Cocoon (such a great product) to transform XML into XHTML. I'd be happy to help. -chris signature.asc Description: OpenPGP digital signature
DO NOT REPLY [Bug 46264] Shutting down tomcat with large number of contexts is slow
https://issues.apache.org/bugzilla/show_bug.cgi?id=46264 --- Comment #31 from Christopher Schultz 2012-02-13 20:24:39 UTC --- (In reply to comment #30) > Where do we set the startStopThreads parameter value? In the component: http://tomcat.apache.org/tomcat-7.0-doc/config/engine.html Please use the users' list for questions in the future. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
svn commit: r1243682 - in /tomcat/tc7.0.x/trunk: modules/ webapps/docs/changelog.xml
Author: fhanik Date: Mon Feb 13 20:37:30 2012 New Revision: 1243682 URL: http://svn.apache.org/viewvc?rev=1243682&view=rev Log: Fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=51582 Modified: tomcat/tc7.0.x/trunk/modules/ (props changed) tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/modules/ -- --- svn:externals (original) +++ svn:externals Mon Feb 13 20:37:30 2012 @@ -1 +1 @@ -^/tomcat/trunk/modules/jdbc-pool@1232867 jdbc-pool +^/tomcat/trunk/modules/jdbc-pool@1243655 jdbc-pool Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1243682&r1=1243681&r2=1243682&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Mon Feb 13 20:37:30 2012 @@ -204,6 +204,9 @@ Fix code style issues and enable Checkstyle checks for jdbc-pool when it is built within Tomcat. (kkolinko) + +51582 Correct set and reset the query cache to avoid NPE (fhanik) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51582] NPE in SlowQueryReport
https://issues.apache.org/bugzilla/show_bug.cgi?id=51582 --- Comment #12 from Filip Hanik 2012-02-13 20:38:02 UTC --- Fixed in r1243682 for the Tomcat 7 branch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 46264] Shutting down tomcat with large number of contexts is slow
https://issues.apache.org/bugzilla/show_bug.cgi?id=46264 --- Comment #32 from Chuck Caldarale 2012-02-13 20:41:25 UTC --- (In reply to comment #31) > (In reply to comment #30) > > Where do we set the startStopThreads parameter value? > > In the component: > http://tomcat.apache.org/tomcat-7.0-doc/config/engine.html Also : http://tomcat.apache.org/tomcat-7.0-doc/config/host.html > Please use the users' list for questions in the future. Absolutely. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 52500] Improve client certificate authentication
https://issues.apache.org/bugzilla/show_bug.cgi?id=52500 --- Comment #22 from Christopher Schultz 2012-02-13 20:51:40 UTC --- > Please find attached patch that provide OOTB UserNameRetriever that retrieve > the user name from SubjectDN without any additional dependency. That looks great. > I have added the UserNameRetrieverDecorator class that allows to load the user > provided UserNameRetriever. In addition, I have added the > UserNameRetrieverConfiguration interface that allow to configure the user > provided UserNameRetriever I'm not sure why either of these are necessary. I think that UserNameRetriever (maybe a better name would be X509UserNameRetriever now that I think about it) interface, the SubjectDNRetriever, and minimal changes to RealmBase. Note that no changes are required to the Realm interface: the selection of a UserNameRetriever is an implementation detail that can safely be left in RealmBase. > Please find the attached html file – I promise to convert it to the simple txt > file when the patch fill be finalized. The best thing to do is to have a decent patch against the Tomcat configuration documentation. Look at the file webapps/docs/config/realm.xml for the source to the current "Realm" configuration page: that's the proper place to document the new configuration attributes and describe how they can be used. Also, the javadocs should contain similar information (although obviously not XML-related because XML isn't part of the API itself). Basically, no documentation should be required that isn't part of your patch. I'm happy to commit your patch with the above changes. If you'd like to take another crack at an updated patch, that's fine, too. If you do submit another one, please don't include "@author" tags in the source files: it's been our policy for some time not to include @author tags, though there certainly are many in the code that have been there for a long time and might not be purged just because nobody cares enough to do so. Don't worry, you'll get your name into the change log :) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
Custom rules for commons-digester
All, There are 15 or so custom rule classes in the Tomcat sources for handling various commons-digester events. I've only taken a brief glance at their content, but I'm wondering if we can't replace these classes with an XML-based configuration that the Digester itself can handle for us. Such a change would eliminate those classes form our own code base as well as allow us to remove the package-renamed code from commons-digester in SVN (of course, we'd still have to re-package commons-digester for distribution, but at least we'd have less source to deal with). Other than some logging (I can see, for instance, that ConnectorCreateRule emits warnings when setter methods can't be found on the target class), is there a compelling reason to have source-based rules instead of configuration-based rules? Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Custom rules for commons-digester
2012/2/14 Christopher Schultz : > All, > > There are 15 or so custom rule classes in the Tomcat sources for > handling various commons-digester events. > > I've only taken a brief glance at their content, but I'm wondering if we > can't replace these classes with an XML-based configuration that the > Digester itself can handle for us. > > Such a change would eliminate those classes form our own code base as > well as allow us to remove the package-renamed code from > commons-digester in SVN (of course, we'd still have to re-package > commons-digester for distribution, but at least we'd have less source to > deal with). > > Other than some logging (I can see, for instance, that > ConnectorCreateRule emits warnings when setter methods can't be found on > the target class), is there a compelling reason to have source-based > rules instead of configuration-based rules? They are faster. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Custom rules for commons-digester
On 13.02.2012 22:11, Christopher Schultz wrote: All, There are 15 or so custom rule classes in the Tomcat sources for handling various commons-digester events. I've only taken a brief glance at their content, but I'm wondering if we can't replace these classes with an XML-based configuration that the Digester itself can handle for us. Such a change would eliminate those classes form our own code base as well as allow us to remove the package-renamed code from commons-digester in SVN (of course, we'd still have to re-package commons-digester for distribution, but at least we'd have less source to deal with). Other than some logging (I can see, for instance, that ConnectorCreateRule emits warnings when setter methods can't be found on the target class), is there a compelling reason to have source-based rules instead of configuration-based rules? Just an information snippet: Simone Tripodi is working in commons land on a new major version of the digester. So if we would like to use a "standard" version of the digester now would be a good time to talk to him about our custom additions. I don't know enough about the digester to drive this myself, just noticed some discussion over in commons. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Custom rules for commons-digester
Konstantin, On 2/13/12 4:32 PM, Konstantin Kolinko wrote: > 2012/2/14 Christopher Schultz : >> All, >> >> There are 15 or so custom rule classes in the Tomcat sources for >> handling various commons-digester events. >> >> I've only taken a brief glance at their content, but I'm wondering if we >> can't replace these classes with an XML-based configuration that the >> Digester itself can handle for us. >> >> Such a change would eliminate those classes form our own code base as >> well as allow us to remove the package-renamed code from >> commons-digester in SVN (of course, we'd still have to re-package >> commons-digester for distribution, but at least we'd have less source to >> deal with). >> >> Other than some logging (I can see, for instance, that >> ConnectorCreateRule emits warnings when setter methods can't be found on >> the target class), is there a compelling reason to have source-based >> rules instead of configuration-based rules? > > They are faster. Fair enough, but server.xml is processed only once on startup. Unless you're seeing an insane performance increase, I would suggest that maintainability might be more important than performance. (This also assumes that maintaining an XML-based configuration file represents less effort than maintaining the equivalent source code, but as I said previously, it would allow us to purge our copies of the Digester from our own svn repo as well, which I see as a win). -chris signature.asc Description: OpenPGP digital signature
Re: Tomcat web site UI update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/02/2012 20:11, Christopher Schultz wrote: > Mark, > > On 2/9/12 11:04 AM, Mark Thomas wrote: >> On 09/02/2012 15:07, Jeremy brown wrote: >>> Hi Jonathan and Petr, >>> >>> I'm an Application Development Graduate Student at Illinois >>> Institute of Technology and I'd like to get started >>> contributing to Tomcat. If you have any tasks I can help out >>> with please let me know. I'd even be happy to start with simple >>> tasks in order begin to familiarize myself with the project and >>> code base, such as writing or formatting javadoc or cleaning >>> up white space. >> >> In addition to the WebSocket work, there are ~100 enhancement >> requests in various states in Bugzilla. You could also take a >> look at those and see if one sparks your interest. If you have an >> interest in web design the the Tomcat web site and documentation >> is long overdue an overhaul. > > IIRC, Pid did a bunch of work toward that end and it was > ultimately vetoed Reference please. That is not my recollection at all. My recollection was that pid started down this road but hasn't found the time to finish it, or at least get it to a state where enough was complete that it could be committed. > but did result in an update of the documentation that actually > ships with Tomcat. > > Does anyone have any specific parameters within which such a > website redesign could/should be done? I don't want someone > spending a long time giving us a nice new web design and then have > it not accepted for one reason or another: it's not exactly > encouraging when a community rejects well-spent time. Check the archives. I have spelt out what I see as the minimum requirements several times (to no objections). Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPOY51AAoJEBDAHFovYFnnMRsQAPGTnuh2ZpwwYceWmk9HXm3v 6sA40fsr3NG7MjxBWzRHeBV7ri7s54jR3akodMYlYtZGkq97Tw9dMtXClL5htkdp bMJ30TtZ0IypKUc73cE3A477nMoFpAy6RSSrFCCUykrQGMohhdjZm+PTS965JaWp b0JUBh1kMIwXQschJvEUrXq9WMd0DBEzrqoQRuR1z/fzMEQ5RoQdN1ltEvF0aSLo Oo5BW4tZsGTEXBE2PGrRJJBRjD76Qru2f4O5x9v45HXFL42WYmzCv4kjeHUogcXl TOPGdCPyXycKSFY5A9OnhKJM93MJGV/H6tmbBbhdN0jSTGIum+RGrrAEyElC+rQe aA/qvk1Q75O20O5CCu2QvLrZVbnzE+U4RSfKqx2GDRcoNYwBsnZFWqv3peQxF0Yk la1Cil3cWblv4BIRx6lZuSU6CZGdnYH3Gm1WDsQFHTJWfTUvoxATsbKaOtV2HJ9V FQIZfl2bOn3rGomvTYXr1Ysgc7Z6YR0DEVS0t3riRbLedT1Sgb1dKlSFLROFhvkG B9gHdt2ndq+itPXNmveawL/P0PFkCjBtaCcOVYQZ3MW44JNdqfJ8dLW0XjrozSjs XxDCNkHvLOKn51dREF4ava9Y6GDxMGWq7abr9XEZil43wBRhsB4w5NjWe1AnSF7w geNT1LPhexwag4sVW8rJ =Mp5Q -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Custom rules for commons-digester
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/02/2012 22:01, Christopher Schultz wrote: > Konstantin, > > On 2/13/12 4:32 PM, Konstantin Kolinko wrote: >> 2012/2/14 Christopher Schultz : >>> All, >>> >>> There are 15 or so custom rule classes in the Tomcat sources >>> for handling various commons-digester events. >>> >>> I've only taken a brief glance at their content, but I'm >>> wondering if we can't replace these classes with an XML-based >>> configuration that the Digester itself can handle for us. >>> >>> Such a change would eliminate those classes form our own code >>> base as well as allow us to remove the package-renamed code >>> from commons-digester in SVN (of course, we'd still have to >>> re-package commons-digester for distribution, but at least we'd >>> have less source to deal with). >>> >>> Other than some logging (I can see, for instance, that >>> ConnectorCreateRule emits warnings when setter methods can't be >>> found on the target class), is there a compelling reason to >>> have source-based rules instead of configuration-based rules? >> >> They are faster. > > Fair enough, but server.xml is processed only once on startup. They also process context.xml files and web.xml files. > (This also assumes that maintaining an XML-based configuration > file represents less effort than maintaining the equivalent source > code, but as I said previously, it would allow us to purge our > copies of the Digester from our own svn repo as well, which I see > as a win). Not if we have to replace it with a library that is bigger than the code we are removing. Further, we can't just use commons-digester. We would have to package rename it in the same way we do with pool, dbcp, file-upload, bcel etc. pool and dbcp have had enough bugs that we need to keep up to date with the latest releases. bcel and fileupload haven't needed to be updated for bug fixes but we have kept them up to date anyay - mainly because we can. Digester was forked a long time ago and hasn't been updated - and hasn't needed to be. Absent a bug that needs fixing, I'm struggling to find a benefit to updating it. If you have been following trunk, you'll know I am slowing removing code from digester and modeler that we no longer need. We should end up with something smaller and more focused at the expense of having to maintain it. Noting that there have been few/no bugs in that code. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPOZBKAAoJEBDAHFovYFnnx00P/j1ljXBqJoNn+akP1T/1QAyd jbywsJNf+kT4LxBHUTfbJ9WwmCjI61ViB3HaZHCJo437WZN3dzl0rsnJyYpVEcET 7bYC9gFm6IWlM1XCteN1PVkbuabk54xSLR9ivRCGNl59DwRvrG7Gekyob7FWRGbi QLR304L9EwPbnOzFXqSN22+EUEeh/JYOu65Dv428mXpt/Qc51+7nQE6lIXeuTxd8 7e5z6I0MijdmPQ3BkIPg5ucDKhqbEmRIVsrLyoOSTgf2NG8/Z+y+kMXFwhoocTdF /Au54Z34oTY+AIkUGdI+e5Jm6vq44iOKLjryFMD3iIu8Y3mOkF4/KHy30H5f1RPI OSqMYzSd3zWvWDn7LeI56JC+VH6UhbiowLw382Mcv8ux9NqB0A8ZBozkQtowhqLa UT72ADCu1bglycyjC9rOjyZ5C70wycM7pVrCjGyfsL7njocrgm9eLtsiCeRlZgbF bISLD15cRwty5Nx8N0XIsD/ggeqT/EgCNCilWG1e5FBoQn7V6NhiSmgteCBXefjq K6Ja8qKVLnC5jVdAhUo8kR0IjM+sn5OUgxzkmDbDLYULswY84266HbhBijU3lUzV hd34Ga4b2RPUQGX6ZobI/8icIMfVYB7oLSBv7lw2g6uETML1gsVNJ3Z0uUWDya6J l5qsjoSbd/iucn+Sf3eV =41V0 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Custom rules for commons-digester
2012/2/14 Christopher Schultz : > Konstantin, > > On 2/13/12 4:32 PM, Konstantin Kolinko wrote: >> 2012/2/14 Christopher Schultz : >>> All, >>> >>> There are 15 or so custom rule classes in the Tomcat sources for >>> handling various commons-digester events. >>> >>> I've only taken a brief glance at their content, but I'm wondering if we >>> can't replace these classes with an XML-based configuration that the >>> Digester itself can handle for us. >>> >>> Such a change would eliminate those classes form our own code base as >>> well as allow us to remove the package-renamed code from >>> commons-digester in SVN (of course, we'd still have to re-package >>> commons-digester for distribution, but at least we'd have less source to >>> deal with). >>> >>> Other than some logging (I can see, for instance, that >>> ConnectorCreateRule emits warnings when setter methods can't be found on >>> the target class), is there a compelling reason to have source-based >>> rules instead of configuration-based rules? >> >> They are faster. > > Fair enough, but server.xml is processed only once on startup. Unless > you're seeing an insane performance increase, I would suggest that > maintainability might be more important than performance. > That is not the only XML file parsed by Tomcat. There are context files, web.xml, web fragments, tld files in tag libraries etc. (Maybe JSP Documents as well, but I am not sure whether Digester is involved with them or not. It is likely that it is not.) There is no problem with maintainability that I know about. Some rule sets are used in different situations. E.g. web.xml and web-fragment.xml have much in common, as well as context.xml and Context element in server.xml. In my view having an XML configuration for the digister here adds one more level of indirection. (As in saying that every problem in computer science can be solved by another level of indirection). There are two different rule sets for server.xml (parsing it at startup vs. at shutdown), two different rule sets for context.xml (parsing its root element, vs. parsing it as whole). I think maintaining a yet another set of XML files is harder than the current approach. (But if it is your itch you may try implementing it and we will see how far it can go). > (This also assumes that maintaining an XML-based configuration file > represents less effort than maintaining the equivalent source code, but > as I said previously, it would allow us to purge our copies of the > Digester from our own svn repo as well, which I see as a win). > DBCP and Pool are essentially optional dependencies. Digester, Fileupload and BCEL are core dependencies that you cannot run without. Building them as standalone modules like DBCP might be better, but I do not see much benefits from breaking the current way of things. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52659] New: Shared memory becomes corrupted
https://issues.apache.org/bugzilla/show_bug.cgi?id=52659 Bug #: 52659 Summary: Shared memory becomes corrupted Product: Tomcat Connectors Version: 1.2.32 Platform: PC Status: NEW Severity: normal Priority: P2 Component: isapi AssignedTo: dev@tomcat.apache.org ReportedBy: alex.sa...@yieldbroker.com Classification: Unclassified Hi my platform IIS7.5 on W2008R2 sp1 (thre are 2 setup in a NLB config) 1.2.32 64 connector Connecting to 6.2Final Jboss We have a client programme that opens a connection and uses keep alive to keep the connection open. We typically have 200-300 connections open at one time. Our application pool on IIS was setup in a web garden mode, so for use that mean there was 4 process ids for the virtual web site the plugin was connected to. So when we had a manual recycle happen all hell broke lose, the client were getting 500's back from the server. for any page that was related to the virtual web site... it would fail at the filter entry point. looks like the connector had become corrupt and was failing everything. So from some investigating we fix it by moving to pessimistic locking and changing to non overlapping recycles. we fixed opp locking is really for single processes + multi threading not multi processes and multithreads! I am not 100% sure why the over lapping recycle failed and I believe corrupted the shm memory but i believe it has something to do with IIS restarting the application pool and I presume with the shared memory block. We saw that the error became exasperated when there were more clients attempting to connect. if there was only 20-40 clients, no problem it worked... but 200 and it went haywire. one interesting test we did was to reboot one node of the NLB cluster, and when it restared it went straight into 500 mode, because 200 client were trying to connect. Can you some how make the option for the connection to default to pessimistic mode instead of op.. This i think might be the problem with the over lapping recycle Alex -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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-tc7.0.x-validate (in module tomcat-7.0.x) failed
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-tc7.0.x-validate has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 87 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-tc7.0.x-validate : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-validate/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-validate.html Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-validate (Type: Build) Work ended in a state of : Failed Elapsed: 28 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-7.0.x] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-14022012.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/exec/target/commons-exec-1.1.1-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-14022012.jar:/srv/gump/public/workspace/junit/dist/junit-14022012.jar:/srv/gump /public/workspace/junit/dist/junit-dep-14022012.jar:/srv/gump/public/workspace/google-guava/build/dist/guava-14022012/guava-14022012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-14022012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-14022012.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-14022012.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-14022012-dep.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar - Buildfile: /srv/gump/public/workspace/tomcat-7.0.x/build.xml download-validate: proxyflags: setproxy: testexist: [echo] Testing for /srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar downloadzip: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-7.0.x/output/res/checkstyle [checkstyle] Running Checkstyle 5.6-SNAPSHOT on 2200 files [checkstyle] /srv/gump/public/workspace/tomcat-7.0.x/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java:1: Line does not match expected header line of '^(rem)?\W*Licensed to the Apache Software Foundation \(ASF\) under one or more$'. [checkstyle] /srv/gump/public/workspace/tomcat-7.0.x/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java:12:8: Unused import - org.apache.tomcat.jdbc.pool.PoolProperties. BUILD FAILED /srv/gump/public/workspace/tomcat-7.0.x/build.xml:447: Got 2 errors and 0 warnings. Total time: 27 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-validate/rss.xml - Atom: http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-validate/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1214022012, vmgump.apache.org:vmgump:1214022012 Gump E-mail Identifier (unique within run) #22. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] ---
[GUMP@vmgump]: Project tomcat-trunk-validate (in module tomcat-trunk) failed
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-trunk-validate has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 19 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-validate : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build) Work ended in a state of : Failed Elapsed: 31 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-14022012.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/exec/target/commons-exec-1.1.1-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-14022012.jar:/srv/gump/public/workspace/junit/dist/junit-14022012.jar:/srv/gump /public/workspace/junit/dist/junit-dep-14022012.jar:/srv/gump/public/workspace/google-guava/build/dist/guava-14022012/guava-14022012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-14022012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-14022012.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-14022012.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-14022012-dep.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml download-validate: proxyflags: setproxy: testexist: [echo] Testing for /srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar downloadzip: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle [checkstyle] Running Checkstyle 5.6-SNAPSHOT on 2209 files [checkstyle] /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java:107: Line matches the illegal pattern '\s+$'. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/SlowQueryReport.java:189: Line matches the illegal pattern '\s+$'. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java:1: Line does not match expected header line of '^(rem)?\W*Licensed to the Apache Software Foundation \(ASF\) under one or more$'. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java:12:8: Unused import - org.apache.tomcat.jdbc.pool.PoolProperties. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java:41: Line matches the illegal pattern '\s+$'. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/bugs/Bug51582.java:42: Line
