[GUMP@vmgump]: Project tomcat-taglibs-standard (in module tomcat-taglibs) 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-taglibs-standard has an issue affecting its community
integration.
This issue affects 2 projects,
and has been outstanding for 93 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: 20 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] ---
[jira] [Commented] (MTOMCAT-176) Make deploy/redeploy (upload) less verbose for --batch-mode / --quiet
[ https://issues.apache.org/jira/browse/MTOMCAT-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461653#comment-13461653 ] Olivier Lamy (*$^¨%`£) commented on MTOMCAT-176: You must have a look at TomcatManager class there is an inner class called RequestEntityImplementation. See the method: transferProgressed. An idea could be to passed the batchMode flag from mojos to the class to write or not the status. > Make deploy/redeploy (upload) less verbose for --batch-mode / --quiet > - > > Key: MTOMCAT-176 > URL: https://issues.apache.org/jira/browse/MTOMCAT-176 > Project: Apache Tomcat Maven Plugin > Issue Type: Wish > Components: commons-lib >Affects Versions: 2.0 >Reporter: Thomas GL >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > > Hi, > Using maven-tomcat-plugin:2.0 for integration testing deployments results in > some Jenkins job logs where 99% of the lines comes from the upload "progress > meter" (implemented in > "TomcatManager.RequestEntityImplementation.transferProgressed"). > In some other plugins with similar HTTP activity, this kind of output can be > turned off by launching Maven with "-B/--batch-mode" (and probably "--quiet" > too, although I never do that). This seems to be standard behavior for > plugins which uses Wagon or Aether. Would it be possible to implement a > similar behavior in the maven-tomcat-plugin? > Actually, I gave it a try today, but I couldn't find how to get the Maven > batch/quiet options through the plugin API. My other attempt was to reuse > the Wagon "TransferListener" instance (the implementation, which can be a > verbose or quiet progress meter, seems to be chosen depending on the Maven > CLI option), but I couldn't find a path to there neither. But it's my first > time in some Maven code, I probably have missed something. > Sure, if it's actually not possible to implement a quiet mode based on the > Maven CLI options, then an alternative would be to add a plugin-specific > parameter. But I think it would be a bit less convenient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1389145 - in /tomcat/trunk/java/org/apache: catalina/connector/CoyoteAdapter.java tomcat/util/collections/ConcurrentWeakHashMap.java
Konstantin Kolinko wrote: >2012/9/24 : >> Author: markt >> Date: Sun Sep 23 21:09:22 2012 >> New Revision: 1389145 >> >> URL: http://svn.apache.org/viewvc?rev=1389145&view=rev >> Log: >> Some more low(ish) hanging fruit from the allocation hit list. This >accounts for ~8% due to the way Thread stores names. >-1 for ReadWriteLock. >The problem with WeakHashMap is that its get() operation can modify it >(as it processes referencequeue). Thus you cannot use ReadWriteLock, >but must use plain synchronization here. Yep. I'll remove that class. ThreadLocal is a better solution for this problem anyway. Not sure why I didn't think of that the first time. I'll fix this later today. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Recent performance tweaks in trunk
On Sun, 2012-09-23 at 12:35 +0100, Mark Thomas wrote: > ab -c 4 -k -n 100 http://localhost:8080/test-1k.txt The concurrency of the test is very low, there will be only 4 threads used with that test, which means decent sync performance. Although with NIO the executor count can remain lower than on java.io, many webapps will still need a significant amount of them, so in practice it is simply not possible to have any syncing (for example, there's one needed sync in the APR connector for adding sockets back to the poller, and it hurts a lot - essentially, the connector works well enough only with a "small" thread pool). So adding caches like this is likely not a good idea. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Recent performance tweaks in trunk
On 24/09/2012 13:19, Remy Maucherat wrote: > On Sun, 2012-09-23 at 12:35 +0100, Mark Thomas wrote: >> ab -c 4 -k -n 100 http://localhost:8080/test-1k.txt > > The concurrency of the test is very low, there will be only 4 threads > used with that test, which means decent sync performance. Once you increase the number of threads beyond the number of cores in the machine you aren't going to see much different as most of the threads will be waiting rather than doing any real work. I have been testing on an 8 core machine and SyncronizedStack is consistently faster than ConcurrentLinkedQueue for any number of threads from 1 to 40. As I mentioned yesterday, I want to do some testing on a machine with more cores. I have a much better connection to people.a.o (with 48 cores) today so I plan to do some more testing with people. I'll report back when I have some results. As an aside, I rarely see Tomcat deployed on machines with more than 8 cores. Most folks I see go for horizontal scaling. > Although with NIO the executor count can remain lower than on java.io, > many webapps will still need a significant amount of them, so in > practice it is simply not possible to have any syncing (for example, > there's one needed sync in the APR connector for adding sockets back to > the poller, and it hurts a lot - essentially, the connector works well > enough only with a "small" thread pool). I haven't see any change either way in my tests so far. I can certainly increase the concurrency of the test client but on my machine that is just going to put more threads into a wait state. I'll confirm that with the profiler. > So adding caches like this is likely not a good idea. The evidence so far says the opposite. I'm happy to keep looking for more evidence. There will nearly always be a test scenario that can make one implementation look good and another look bad and there are always going to be trade-offs. As long as Tomcat doesn't perform badly in what might be considered normal/typical/valid/etc usage scenarios then I'm going to be happy. Mark > > Rémy > > > > - > 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
[Bug 53930] New: allow capture of catalina stdout/stderr to a command instead of just a file
https://issues.apache.org/bugzilla/show_bug.cgi?id=53930 Priority: P2 Bug ID: 53930 Assignee: dev@tomcat.apache.org Summary: allow capture of catalina stdout/stderr to a command instead of just a file Severity: enhancement Classification: Unclassified OS: Mac OS X 10.4 Reporter: clu...@e-miles.com Hardware: Macintosh Status: NEW Version: trunk Component: Catalina Product: Tomcat 8 Created attachment 29414 --> https://issues.apache.org/bugzilla/attachment.cgi?id=29414&action=edit patch to catalina.sh adding support for CATALINA_OUT_CMD catalina.sh currently supports passing in a value for CATALINA_OUT. If supplied the stdout/stderr of the java process will be redirected to this file. This single file scenario makes it difficult to keep file contents for long running process separated on a per day basis as is typical for production logging scenarios. We use cronolog (http://http://cronolog.org/) to do automatic log rolling but others may have different needs. The attached patch adds support to catalina.sh for an optional CATALINA_OUT_CMD variable. If this variable is defined, the stdout and stderr of the java process will be piped to the command. We use it as in: CATALINA_OUT_CMD="cronolog $CATALINA_BASE/logs/catalina.%Y-%m-%d.out >/dev/null 2>&1" export CATALINA_OUT_CMD catalina.sh start $@ Of course long-running, server-side applications should typically not be writing to stdout/stderr but sometimes this is out of your control. -- 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 53930] allow capture of catalina stdout/stderr to a command instead of just a file
https://issues.apache.org/bugzilla/show_bug.cgi?id=53930 Casey Lucas changed: What|Removed |Added CC||clu...@e-miles.com -- 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
[jira] [Created] (MTOMCAT-177) tomcat7:deploy ignores proxy settings
Brad Larson created MTOMCAT-177: --- Summary: tomcat7:deploy ignores proxy settings Key: MTOMCAT-177 URL: https://issues.apache.org/jira/browse/MTOMCAT-177 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.0 Reporter: Brad Larson Assignee: Olivier Lamy (*$^¨%`£) Using these settings: org.apache.tomcat.maven tomcat7-maven-plugin 2.0-SNAPSHOT When running tomcat7:deploy behind a network proxy (specified in ~/.m2/settings.xml), the deploy will fail with a very generic error message. Running outside of the proxy (with no proxy settings in ~/.m2/settings.xml) works fine. The error message is simply "Connection refused", no other details provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-177) tomcat7:deploy ignores proxy settings
[ https://issues.apache.org/jira/browse/MTOMCAT-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461882#comment-13461882 ] Olivier Lamy (*$^¨%`£) commented on MTOMCAT-177: same with 2.0 released version ? > tomcat7:deploy ignores proxy settings > - > > Key: MTOMCAT-177 > URL: https://issues.apache.org/jira/browse/MTOMCAT-177 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.0 >Reporter: Brad Larson >Assignee: Olivier Lamy (*$^¨%`£) > Labels: proxy > > Using these settings: > org.apache.tomcat.maven > tomcat7-maven-plugin > 2.0-SNAPSHOT > When running tomcat7:deploy behind a network proxy (specified in > ~/.m2/settings.xml), the deploy will fail with a very generic error message. > Running outside of the proxy (with no proxy settings in ~/.m2/settings.xml) > works fine. > The error message is simply "Connection refused", no other details provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Recent performance tweaks in trunk
On 24/09/2012 16:04, Mark Thomas wrote: > On 24/09/2012 13:19, Remy Maucherat wrote: >> On Sun, 2012-09-23 at 12:35 +0100, Mark Thomas wrote: >>> ab -c 4 -k -n 100 http://localhost:8080/test-1k.txt >> >> The concurrency of the test is very low, there will be only 4 threads >> used with that test, which means decent sync performance. > > Once you increase the number of threads beyond the number of cores in > the machine you aren't going to see much different as most of the > threads will be waiting rather than doing any real work. > > I have been testing on an 8 core machine and SyncronizedStack is > consistently faster than ConcurrentLinkedQueue for any number of threads > from 1 to 40. > > As I mentioned yesterday, I want to do some testing on a machine with > more cores. I have a much better connection to people.a.o (with 48 > cores) today so I plan to do some more testing with people. I'll report > back when I have some results. And the results are in [1]. Short version : SynchronizedStack wins by a mile. The test case [2] was a Java 6, standalone version of the test case currently in trunk. As the number of threads increase, the differential between the two increases. There is also a marked difference in CPU usage. For SynchronizedStack with 64 threads CPU usage (measured with top) was around 7%. For ConcurrentLinkedQueue it was around 99%. The differential in performance seems to level off at SynchronizedStack being 10x faster than ConcurrentLinkedQueue for this particular use case. >> So adding caches like this is likely not a good idea. > > The evidence so far says the opposite. I'm happy to keep looking for > more evidence. Given the above and the way that the stack is used (the time in the sync block represents a very small percentage of the overall request processing time) I think the likelihood of getting anywhere near 64 concurrent threads is very low even with several thousand concurrent requests. Even if the concurrency does get this high, I am now confident that SynchronizedStack will perform better. In the absence of a test case that demonstrates that - for the way it is used - SynchronizedStack is slower than ConcurrentLinkedQueue then I intend to keep the recent changes. I would add that ConcurrentLinkedQueue has a lot of functionality we don't need in this particular case. The performance gain is simply from implementing a focused class that does one thing very well. It is by no means a replacement for ConcurrentLinkedQueue. Mark [1] http://people.apache.org/~markt/random/SynchronizedStack.java [2] http://people.apache.org/~markt/random/SynchronizedStack-results.txt - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-177) tomcat7:deploy ignores proxy settings
[ https://issues.apache.org/jira/browse/MTOMCAT-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461911#comment-13461911 ] Brad Larson commented on MTOMCAT-177: - Yes same result > tomcat7:deploy ignores proxy settings > - > > Key: MTOMCAT-177 > URL: https://issues.apache.org/jira/browse/MTOMCAT-177 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.0 >Reporter: Brad Larson >Assignee: Olivier Lamy (*$^¨%`£) > Labels: proxy > > Using these settings: > org.apache.tomcat.maven > tomcat7-maven-plugin > 2.0-SNAPSHOT > When running tomcat7:deploy behind a network proxy (specified in > ~/.m2/settings.xml), the deploy will fail with a very generic error message. > Running outside of the proxy (with no proxy settings in ~/.m2/settings.xml) > works fine. > The error message is simply "Connection refused", no other details provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1389493 - in /tomcat/trunk: java/org/apache/catalina/connector/CoyoteAdapter.java java/org/apache/tomcat/util/collections/ConcurrentWeakHashMap.java test/org/apache/tomcat/util/collection
Author: markt
Date: Mon Sep 24 17:44:31 2012
New Revision: 1389493
URL: http://svn.apache.org/viewvc?rev=1389493&view=rev
Log:
Better solution to multiple calls to Thread.getName()
- ThreadLocal is cleaner
- ConcurrentWeakHashMap wasn't concurrent (as per kkolinko's review)
Removed:
tomcat/trunk/java/org/apache/tomcat/util/collections/ConcurrentWeakHashMap.java
Modified:
tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
tomcat/trunk/test/org/apache/tomcat/util/collections/TesterPerformanceSynchronizedStack.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?rev=1389493&r1=1389492&r2=1389493&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java Mon Sep
24 17:44:31 2012
@@ -42,7 +42,6 @@ import org.apache.tomcat.util.buf.B2CCon
import org.apache.tomcat.util.buf.ByteChunk;
import org.apache.tomcat.util.buf.CharChunk;
import org.apache.tomcat.util.buf.MessageBytes;
-import org.apache.tomcat.util.collections.ConcurrentWeakHashMap;
import org.apache.tomcat.util.http.Cookies;
import org.apache.tomcat.util.http.ServerCookie;
import org.apache.tomcat.util.net.SSLSupport;
@@ -79,6 +78,16 @@ public class CoyoteAdapter implements Ad
Boolean.valueOf(System.getProperty("org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH",
"false")).booleanValue();
+private static final ThreadLocal THREAD_NAME =
+new ThreadLocal() {
+
+@Override
+protected String initialValue() {
+return Thread.currentThread().getName();
+}
+
+};
+
// --- Constructors
@@ -104,9 +113,6 @@ public class CoyoteAdapter implements Ad
private final Connector connector;
-private final ConcurrentWeakHashMap threadNames =
-new ConcurrentWeakHashMap<>();
-
/**
* The string manager for this package.
*/
@@ -431,13 +437,7 @@ public class CoyoteAdapter implements Ad
// Parse and set Catalina and configuration specific
// request parameters
-Thread t = Thread.currentThread();
-String threadName = threadNames.get(t);
-if (threadName == null) {
-threadName = t.getName();
-threadNames.put(t, threadName);
-}
-req.getRequestProcessor().setWorkerThreadName(threadName);
+req.getRequestProcessor().setWorkerThreadName(THREAD_NAME.get());
boolean postParseSuccess = postParseRequest(req, request, res,
response);
if (postParseSuccess) {
//check valves if we support async
Modified:
tomcat/trunk/test/org/apache/tomcat/util/collections/TesterPerformanceSynchronizedStack.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/collections/TesterPerformanceSynchronizedStack.java?rev=1389493&r1=1389492&r2=1389493&view=diff
==
---
tomcat/trunk/test/org/apache/tomcat/util/collections/TesterPerformanceSynchronizedStack.java
(original)
+++
tomcat/trunk/test/org/apache/tomcat/util/collections/TesterPerformanceSynchronizedStack.java
Mon Sep 24 17:44:31 2012
@@ -23,7 +23,7 @@ import org.junit.Test;
public class TesterPerformanceSynchronizedStack {
-private static final int THREAD_COUNT = 8;
+private static final int THREAD_COUNT = 40;
private static final int ITERATIONS = 100;
private static final SynchronizedStack STACK =
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53930] allow capture of catalina stdout/stderr to a command instead of just a file
https://issues.apache.org/bugzilla/show_bug.cgi?id=53930 Christopher Schultz changed: What|Removed |Added Attachment #29414|0 |1 is patch|| Attachment #29414|application/octet-stream|text/plain mime type|| -- 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
