svn commit: r1780488 - in /tomcat/trunk: java/org/apache/jasper/compiler/Generator.java java/org/apache/jasper/runtime/JspRuntimeLibrary.java java/org/apache/jasper/runtime/TagHandlerPool.java webapps
Author: markt
Date: Thu Jan 26 22:58:35 2017
New Revision: 1780488
URL: http://svn.apache.org/viewvc?rev=1780488&view=rev
Log:
Refactor generated code so tags require less code
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
tomcat/trunk/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
tomcat/trunk/java/org/apache/jasper/runtime/TagHandlerPool.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/jasper/compiler/Generator.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/Generator.java?rev=1780488&r1=1780487&r2=1780488&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/Generator.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/Generator.java Thu Jan 26
22:58:35 2017
@@ -2614,21 +2614,18 @@ class Generator {
}
// Ensure clean-up takes place
+// Use JspRuntimeLibrary to minimise code in _jspService()
out.popIndent();
out.printil("} finally {");
out.pushIndent();
+
out.printin("org.apache.jasper.runtime.JspRuntimeLibrary.releaseTag(");
+out.print(tagHandlerVar);
+out.print(", _jsp_getInstanceManager(), ");
if (isPoolingEnabled && !(n.implementsJspIdConsumer())) {
-out.printin("if (!");
out.print(tagHandlerVar);
-out.println("_reused) {");
-out.pushIndent();
-}
-out.printin(tagHandlerVar);
-out.println(".release();");
-writeDestroyInstance(tagHandlerVar);
-if (isPoolingEnabled && !(n.implementsJspIdConsumer())) {
-out.popIndent();
-out.printil("}");
+out.println("_reused);");
+} else {
+out.println("false);");
}
out.popIndent();
out.printil("}");
Modified: tomcat/trunk/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/runtime/JspRuntimeLibrary.java?rev=1780488&r1=1780487&r2=1780488&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/runtime/JspRuntimeLibrary.java
(original)
+++ tomcat/trunk/java/org/apache/jasper/runtime/JspRuntimeLibrary.java Thu Jan
26 22:58:35 2017
@@ -32,9 +32,13 @@ import javax.servlet.http.HttpServletReq
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.PageContext;
import javax.servlet.jsp.tagext.BodyContent;
+import javax.servlet.jsp.tagext.Tag;
import org.apache.jasper.JasperException;
import org.apache.jasper.compiler.Localizer;
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.InstanceManager;
/**
* Bunch of util methods that are used by code generated for useBean,
@@ -50,6 +54,8 @@ import org.apache.jasper.compiler.Locali
*/
public class JspRuntimeLibrary {
+private static final Log log = LogFactory.getLog(JspRuntimeLibrary.class);
+
/**
* Returns the value of the javax.servlet.error.exception request
* attribute value, if present, otherwise the value of the
@@ -963,4 +969,31 @@ public class JspRuntimeLibrary {
return false;
}
+
+public static void releaseTag(Tag tag, InstanceManager instanceManager,
boolean reused) {
+// Caller ensures pool is non-null if reuse is true
+if (!reused) {
+releaseTag(tag, instanceManager);
+}
+}
+
+
+protected static void releaseTag(Tag tag, InstanceManager instanceManager)
{
+try {
+tag.release();
+} catch (Throwable t) {
+ExceptionUtils.handleThrowable(t);
+log.warn("Error processing release on tag instance of "
++ tag.getClass().getName(), t);
+}
+try {
+instanceManager.destroyInstance(tag);
+} catch (Exception e) {
+Throwable t = ExceptionUtils.unwrapInvocationTargetException(e);
+ExceptionUtils.handleThrowable(t);
+log.warn("Error processing preDestroy on tag instance of "
++ tag.getClass().getName(), t);
+}
+
+}
}
Modified: tomcat/trunk/java/org/apache/jasper/runtime/TagHandlerPool.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/runtime/TagHandlerPool.java?rev=1780488&r1=1780487&r2=1780488&view=diff
==
--- tomcat/trunk/java/org/apache/jasper/runtime/TagHandlerPool.java (original)
+++ tomcat/trunk/java/org/apache/jasper/runtime/TagHandlerPool.java Thu Jan 26
22:58:35 2017
@@ -22,8 +22,6 @@ import javax.servlet.jsp.JspException;
import javax.servlet.jsp.tagext.Tag;
import o
Re: [VOTE] Release Apache Tomcat 6.0.50
On 26/01/2017 14:38, Rémy Maucherat wrote: > 2017-01-26 15:29 GMT+01:00 Mark Thomas : >> On 26 January 2017 13:53:22 GMT+00:00, Konstantin Kolinko < >> knst.koli...@gmail.com> wrote: >>> It needs some actual numbers - how big of a JSP can be compiled by >>> Tomcat. >> >> It took around 250 tags with a scriplet on a single page to trigger the >> problem. I need to test how much difference the try/finally fix made. >> Working with Tomcat 6 (9 won't be that much different), before the try/finally clean-up code was added a JSP page could handle 299 instances of the foo tag (from the examples webapp) before the method got too big. After adding the try/finally clean-up, that drops to 228. I've been looking at the generated code for a while. One obvious optimisation had no effect (I'm guessing the compiler found it anyway). With a couple a small changes, I got the maximum tag count back up to 249. To take this further, I think the next step is to take the setters and, if the tag processed in _jspService(), move the setters for that tag into a separate method. I intend to explore this in 9.0.x with a view to back-porting if it works. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "FAQ/Monitoring" by EmericVernat
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "FAQ/Monitoring" page has been changed by EmericVernat: https://wiki.apache.org/tomcat/FAQ/Monitoring?action=diff&rev1=17&rev2=18 Comment: fix javamelody links [[http://moskito.org/|MoSKito]], an open source solution by [[http://anotheria.net/home.html|Anotheria]], is a multi-purpose, non-invasive, interval-based monitoring system kit that collects, stores and provides instant analysis of a Tomcat application’s performance and behavior data. - [[http://javamelody.googlecode.com|JavaMelody]] can monitor your JavaEE/Tomcat application from dev to production. It is open-source and easy: get the [[http://code.google.com/p/javamelody/wiki/Screenshots#Charts|first view]] of your application in [[https://code.google.com/p/javamelody/wiki/UserGuide#Setup|about 2 minutes]] from now. + [[https://github.com/javamelody/javamelody/wiki|JavaMelody]] can monitor your JavaEE/Tomcat application from dev to production. It is open-source and easy: get the [[https://github.com/javamelody/javamelody/wiki/Screenshots#charts|first view]] of your application in [[https://github.com/javamelody/javamelody/wiki/UserGuide#javamelody-setup|about 2 minutes]] from now. Other plug-in-based monitoring software like Nagios or Icinga may need some help interacting with Tomcat's JMXProxyServlet. [[tools/check_jmxproxy.pl]] is a Perl script that can be used with these tools to monitor Tomcat via the JMXProxyServlet. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60653] New: remove or make optional output of comment
https://bz.apache.org/bugzilla/show_bug.cgi?id=60653
Bug ID: 60653
Summary: remove or make optional output of comment
Product: Tomcat 8
Version: 8.5.9
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Jasper
Assignee: dev@tomcat.apache.org
Reporter: bmi...@automationdirect.com
Target Milestone:
In Generator.java when generating the setters, it outputs a comment for each
one. This line:
out.printil("// "+m.getFile()+"("+m.getLineNumber()+","+m.getColumnNumber()+")
"+ attrs[i].getTagAttributeInfo());
Can either remove this comment output or make it some type of optional debug
setting? We've got a scenario with some custom tags that causes really large
generated code and much of it is comments due to this line.
thanks.
--
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: [VOTE] Release Apache Tomcat 6.0.50
2017-01-26 15:29 GMT+01:00 Mark Thomas :
> On 26 January 2017 13:53:22 GMT+00:00, Konstantin Kolinko <
> knst.koli...@gmail.com> wrote:
> >2017-01-26 16:00 GMT+03:00 Rémy Maucherat :
> >> 2017-01-26 12:10 GMT+01:00 Mark Thomas :
> >>
> >>> - One TCK test fails because an associated JSP no longer compiles
> >>> because it reaches the 64k method limit. The JSP has a very large
> >>> number of nested tags.
> >>>
> >>> I'm going to take another look at the JSP Generation to see if there
> >is
> >>> anything we can do to make even a small improvement.
> >>>
> >>> :( It could be an option to simply revert the try/finally change in
> >all
> >> branches except 8.5 and 9, after all nobody complained about it.
> >
> >1. I think that try/finally change fixed a real bug. It is better to
> >keep it.
> >
> >
> >2. Looking at java code generated for JSPs by 6.0.50, the additional
> >code is in helper methods ("_jspx_meth_"*), not in the main big
> >_jspService() method.
>
> If you use tags with bodies that contain scriptlets then the code appears
> in the main service method.
>
> >There is not much of that additional code. Just a try/catch and a
> >boolean variable.
> >So I also do not see what can be improved.
> >
> >A "catch (Throwable t)" block at the end of _jspService() could be
> >extracted into a helper method as non-trivial code, but it is only a
> >dozen of lines and it is present only once.
>
> We might be able to save a few bytes with some helper methods but it won't
> be much, if any.
>
> >It needs some actual numbers - how big of a JSP can be compiled by
> >Tomcat.
>
> It took around 250 tags with a scriplet on a single page to trigger the
> problem. I need to test how much difference the try/finally fix made.
>
Yes, the problem is that once you add a scriptlet, there can be a variable
declaration in it (well, of course there is, people don't use scriptlets to
do clean stuff) so there needs to be full visibility of it to build. We had
been trying to remove scriptlets for w very long time, it never worked, we
still have people immediately asking for support of the new Java language
features in JSPs, so brand new code being written right now still features
scriptlets.
Also sad, the original size limits of the JVM were rather low, and never
changed.
Sorry for the complaints ...
Rmy
>
> >3. There are some Jasper options that produce a more compact java
> >code. Especially the option to generates a single out.write() call for
> >a sequence of text instead of separate call for each line of text. A
> >bugzilla report mentions it.
> >
> >
> >mappedfile
> > false
> >
> >
> >http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html
> >
> >I wonder whether the mentioned TCK test will pass with that option.
>
> I'll take a look.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
Re: [VOTE] Release Apache Tomcat 6.0.50
On 26 January 2017 13:53:22 GMT+00:00, Konstantin Kolinko
wrote:
>2017-01-26 16:00 GMT+03:00 Rémy Maucherat :
>> 2017-01-26 12:10 GMT+01:00 Mark Thomas :
>>
>>> - One TCK test fails because an associated JSP no longer compiles
>>> because it reaches the 64k method limit. The JSP has a very large
>>> number of nested tags.
>>>
>>> I'm going to take another look at the JSP Generation to see if there
>is
>>> anything we can do to make even a small improvement.
>>>
>>> :( It could be an option to simply revert the try/finally change in
>all
>> branches except 8.5 and 9, after all nobody complained about it.
>
>1. I think that try/finally change fixed a real bug. It is better to
>keep it.
>
>
>2. Looking at java code generated for JSPs by 6.0.50, the additional
>code is in helper methods ("_jspx_meth_"*), not in the main big
>_jspService() method.
If you use tags with bodies that contain scriptlets then the code appears in
the main service method.
>There is not much of that additional code. Just a try/catch and a
>boolean variable.
>So I also do not see what can be improved.
>
>A "catch (Throwable t)" block at the end of _jspService() could be
>extracted into a helper method as non-trivial code, but it is only a
>dozen of lines and it is present only once.
We might be able to save a few bytes with some helper methods but it won't be
much, if any.
>It needs some actual numbers - how big of a JSP can be compiled by
>Tomcat.
It took around 250 tags with a scriplet on a single page to trigger the
problem. I need to test how much difference the try/finally fix made.
>3. There are some Jasper options that produce a more compact java
>code. Especially the option to generates a single out.write() call for
>a sequence of text instead of separate call for each line of text. A
>bugzilla report mentions it.
>
>
>mappedfile
> false
>
>
>http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html
>
>I wonder whether the mentioned TCK test will pass with that option.
I'll take a look.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 6.0.50
2017-01-26 16:00 GMT+03:00 Rémy Maucherat :
> 2017-01-26 12:10 GMT+01:00 Mark Thomas :
>
>> - One TCK test fails because an associated JSP no longer compiles
>> because it reaches the 64k method limit. The JSP has a very large
>> number of nested tags.
>>
>> I'm going to take another look at the JSP Generation to see if there is
>> anything we can do to make even a small improvement.
>>
>> :( It could be an option to simply revert the try/finally change in all
> branches except 8.5 and 9, after all nobody complained about it.
1. I think that try/finally change fixed a real bug. It is better to keep it.
2. Looking at java code generated for JSPs by 6.0.50, the additional
code is in helper methods ("_jspx_meth_"*), not in the main big
_jspService() method.
There is not much of that additional code. Just a try/catch and a
boolean variable.
So I also do not see what can be improved.
A "catch (Throwable t)" block at the end of _jspService() could be
extracted into a helper method as non-trivial code, but it is only a
dozen of lines and it is present only once.
It needs some actual numbers - how big of a JSP can be compiled by Tomcat.
3. There are some Jasper options that produce a more compact java
code. Especially the option to generates a single out.write() call for
a sequence of text instead of separate call for each line of text. A
bugzilla report mentions it.
mappedfile
false
http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html
I wonder whether the mentioned TCK test will pass with that option.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 6.0.50
2017-01-26 12:10 GMT+01:00 Mark Thomas : > - One TCK test fails because an associated JSP no longer compiles > because it reaches the 64k method limit. The JSP has a very large > number of nested tags. > > I'm going to take another look at the JSP Generation to see if there is > anything we can do to make even a small improvement. > > :( It could be an option to simply revert the try/finally change in all branches except 8.5 and 9, after all nobody complained about it. Rémy
Re: [VOTE] Release Apache Tomcat 6.0.50
2017-01-22 18:59 GMT+03:00 Violeta Georgieva : > The proposed Apache Tomcat 6.0.50 release is now available for voting. > > Note: This is the last Tomcat 6 release. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-6/v6.0.50/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1119/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_50/ > > The proposed 6.0.50 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 6.0.50 Stable "ant download" needs alternating runs with Java 5 and Java 8 for https connection to my closest mirror of sourceforge. Not a new issue, just thought that it is worth noting. Unit tests OK. (Java 5u20, 6u45, 7u80, 8u121), on Windows 32-bit An odd error in a tribes test with BIO + Java 5. Occurred once, not reproduced on a rerun. TEST-org.apache.catalina.tribes.group.TestGroupChannelMemberArrival.BIO.txt [[[ SEVERE: Unable to start cluster receiver java.lang.NullPointerException at sun.nio.ch.Util.atBugLevel(Util.java:326) at sun.nio.ch.SelectorImpl.(SelectorImpl.java:40) at sun.nio.ch.WindowsSelectorImpl.(WindowsSelectorImpl.java:104) at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:26) at java.nio.channels.Selector.open(Selector.java:209) at org.apache.catalina.tribes.transport.nio.NioReceiver.bind(NioReceiver.java:128) at org.apache.catalina.tribes.transport.nio.NioReceiver.start(NioReceiver.java:101) at org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:140) at org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:95) at org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:149) at org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:149) at org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:407) at org.apache.catalina.tribes.group.TestGroupChannelMemberArrival$1.run(TestGroupChannelMemberArrival.java:60) ]]] Not an our issue. It is a known rather rare concurrency problem with Java 5. Java Bug Database knows it and says that it is fixed in Java 7.0 http://bugs.java.com/view_bug.do?bug_id=6427854 Smoke testing OK. Manager, Host Manager, Documentation - ASF icon is OK, issue was fixed. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60632] Last logs lost when running Tomcat with systemd and journald
https://bz.apache.org/bugzilla/show_bug.cgi?id=60632
--- Comment #3 from Jeff Turner ---
> That way the default behaviour doesn't change, those that need to fix it have
> an option to do so and the delay can be set to an appropriate value for each
> system.
Okay, how about:
# If started with systemd, add 'Environment=CATALINA_EXIT_DELAY=0.1' to your
service file to prevent systemd losing the last few log messages. See
https://github.com/systemd/systemd/issues/1347
if [ -n "${CATALINA_EXIT_DELAY:-}" ]; then
trap 'sleep ${CATALINA_EXIT_DELAY}' INT EXIT TERM
fi
--
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: [VOTE] Release Apache Tomcat 6.0.50
On 22/01/2017 15:59, Violeta Georgieva wrote: > The proposed Apache Tomcat 6.0.50 release is now available for voting. > > Note: This is the last Tomcat 6 release. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-6/v6.0.50/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1119/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_50/ > > The proposed 6.0.50 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 6.0.50 Stable I ran the TCKs with the following results. Servlet 2.5: I had to make the following changes from the default configuration - Enabled STRICT_SERVLET_COMPLIANCE - Disabled XML validation else Jasper's web.xml parsing fails which in turn triggers TCK failures. This appears to be mainly due to testing with Java 5. The problems look fixable (use same approach as Digester which does not fail) but I don't plan to fix this since this as a) this is probably the last 6.0.x release and b) I'm fairly sure this is a Java 5 issue - Disabled TLD validation else some TCK tests fail since enabling validation injects some init parameters into the ServletContext which trigger failures because the TCK is not expecting them - Enabled crossContext since the TCK tests that feature - The signature test fails but I have never been able to get it to pass for 2.5. I suspect a local configuration problem . A manual check of the API has previously confirmed it is correct and there have been no changes to the API for the spec classes. JSP 2.1 I had to make the following changes from the default configuration - Enabled STRICT_SERVLET_COMPLIANCE - Disbaled TLD validation since the TLDs that ship with the TCK fail validation - Disable development mode since it changes some exception types which in turn causes test failures. - One TCK test fails because an associated JSP no longer compiles because it reaches the 64k method limit. The JSP has a very large number of nested tags. I'm going to take another look at the JSP Generation to see if there is anything we can do to make even a small improvement. With the exception of the JSP method limit, I have seen all of the above previous 6.0.x releases. I do no consider the JSP method limit a show-stopper since you need a lot of tags on a page before it is an issue. Hence, I'm voting stable. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60615] 20% CPU use while check for modified resource
https://bz.apache.org/bugzilla/show_bug.cgi?id=60615 --- Comment #3 from Yassine EL GHAYANI --- Thx, indeed this feature in tomcat 7.x work better, and never have any probleme with it. NB: our prod servers never use reloadable feature, only test env that have this option activated. -- 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 60615] 20% CPU use while check for modified resource
https://bz.apache.org/bugzilla/show_bug.cgi?id=60615 --- Comment #2 from Mark Thomas --- I've looked back at 7.0.x (before the new resource handling was introduced) and that did only check JARs rather than individual classes in JARs. While in theory a class could be modified in a JAR without changing the JAR's timestamp, that wouldn't happen by accident. Therefore, only checking the JAR's timestamp seems reasonable. I'll take a look at a patch. -- 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: r1780347 - in /tomcat/trunk/test/org/apache/jasper/runtime: TestTagHandlerPool.java TestTagHandlerPoolPerformance.java
Author: markt
Date: Thu Jan 26 10:16:56 2017
New Revision: 1780347
URL: http://svn.apache.org/viewvc?rev=1780347&view=rev
Log:
Rename test since it contains only performance tests
Added:
tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPoolPerformance.java
- copied, changed from r1780346,
tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPool.java
Removed:
tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPool.java
Copied:
tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPoolPerformance.java
(from r1780346,
tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPool.java)
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPoolPerformance.java?p2=tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPoolPerformance.java&p1=tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPool.java&r1=1780346&r2=1780347&rev=1780347&view=diff
==
--- tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPool.java
(original)
+++
tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPoolPerformance.java
Thu Jan 26 10:16:56 2017
@@ -19,7 +19,6 @@ package org.apache.jasper.runtime;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.tagext.Tag;
-import org.junit.Ignore;
import org.junit.Test;
import org.apache.catalina.Wrapper;
@@ -28,12 +27,8 @@ import org.apache.catalina.startup.Tomca
import org.apache.tomcat.unittest.tags.Bug53545;
-public class TestTagHandlerPool extends TomcatBaseTest {
+public class TestTagHandlerPoolPerformance extends TomcatBaseTest {
-/*
- * Performance test. Comment out @Ignore to run the test.
- */
-@Ignore
@Test
public void testConcurrency() throws Exception {
// Create a working TagHandlerPool
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1780262 - /tomcat/trunk/test/org/apache/jasper/runtime/TestTagHandlerPool.java
On 25/01/2017 20:30, Konstantin Kolinko wrote: > 2017-01-25 23:05 GMT+03:00 : >> Author: markt >> Date: Wed Jan 25 20:05:01 2017 >> New Revision: 1780262 >> >> URL: http://svn.apache.org/viewvc?rev=1780262&view=rev >> Log: >> Add a unit test used to investigate https://github.com/apache/tomcat85/pull/5 >> TagHandlerPool is effectively using a SynchronizedStack. This is known to >> perform better than ConcurrentLinkedDeque in some cases and testing >> confirmed that for TagHandlerPool. > > > 1. Rename to TestTagHandlerPoolPerformance ? > > In build.xml there is exclude pattern for such tests: > That would probably be more consistent. > 2. A test class with a single @Ignore'd method -> > I remember that in such case the annotation had to be moved to class level. > > (I do not remember the reason, but I think that we will see it soon enough.) I also remember the problem but not the reason. I was expecting the CI system to highlight the problem overnight. I'll do the rename. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60645] StatementFinalizer is not thread-safe
https://bz.apache.org/bugzilla/show_bug.cgi?id=60645 --- Comment #2 from ba...@semedy.com --- Created attachment 34679 --> https://bz.apache.org/bugzilla/attachment.cgi?id=34679&action=edit A thread-safe variant of the original StatementFinalizer This is a slightly modified version of the original StatementFinalizer. There are only two changes: 1) It uses an ArrayList instead of a LinkedList. 2) The access on the "statements" list is synchronized. Note that I don't think a more sophisticated implementation (e.g. with a concurrent copy-on-write datastructure) is needed because I'd not expect a high thread contention. -- 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
