[Bug 53895] New: Performance solution for ImplicitObjectELResolver
https://issues.apache.org/bugzilla/show_bug.cgi?id=53895
Priority: P2
Bug ID: 53895
Assignee: dev@tomcat.apache.org
Summary: Performance solution for ImplicitObjectELResolver
Severity: normal
Classification: Unclassified
Reporter: xs...@ebay.com
Hardware: PC
Status: NEW
Version: trunk
Component: Jasper
Product: Tomcat 7
Created attachment 29391
-- https://issues.apache.org/bugzilla/attachment.cgi?id=29391action=edit
New ImplicitObjectELResolverImpl
ImplicitObjectELResolver uses Arrays.binarySearch to check scope name.
It isn't very efficient.
It can be improved by using a map to hold the scope to scopeIndex.
Such as,
private static final MapString, Integer scopeMap = new HashMapString,
Integer();
static {
for (int i = 0; i SCOPE_NAMES.length; i++) { scopeMap.put(SCOPE_NAMES[i],
i); }
}
More detail please check out the attachment
ImplicitObjectELResolverImpl.java.
--
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 53895] Performance solution for ImplicitObjectELResolver
https://issues.apache.org/bugzilla/show_bug.cgi?id=53895 --- Comment #1 from Sheldon Shao xs...@ebay.com --- Created attachment 29392 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29392action=edit Comparison test case Sample test result: New ImplicitObjectELResolver:578 Old ImplicitObjectELResolver:795 New ImplicitObjectELResolver:624 Old ImplicitObjectELResolver:889 New ImplicitObjectELResolver:515 Old ImplicitObjectELResolver:999 New ImplicitObjectELResolver:624 Old ImplicitObjectELResolver:1030 New ImplicitObjectELResolver:546 Old ImplicitObjectELResolver:1108 New ImplicitObjectELResolver:546 Old ImplicitObjectELResolver:982 New ImplicitObjectELResolver:640 Old ImplicitObjectELResolver:1060 -- 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 53895] Performance solution for ImplicitObjectELResolver
https://issues.apache.org/bugzilla/show_bug.cgi?id=53895 Sheldon Shao xs...@ebay.com changed: What|Removed |Added OS||All Severity|normal |enhancement -- 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 53896] New: Optimized Jasper ELResolver
https://issues.apache.org/bugzilla/show_bug.cgi?id=53896 Priority: P2 Bug ID: 53896 Assignee: dev@tomcat.apache.org Summary: Optimized Jasper ELResolver Severity: normal Classification: Unclassified OS: Linux Reporter: jga...@gmail.com Hardware: PC Status: NEW Version: unspecified Component: Jasper Product: Tomcat 7 JspApplicationContextImpl sets up a CompositeELResolver with the standard and application-specific EL resolvers. The CompositeELResolver implementation basically just invokes every ELResolver in the list until a value is successfully resolved. The issue is that in certain situations some ELResolvers are called needlessly. For example, if base != null, calling getValue() on ImplicitObjectELResolver is unnecessary. So there are cases in which certain ELResolvers can be skipped over. In EL heavy applications skipping over certain ELResolvers can quickly add up. -- 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 53897] New: Customized EL resolver to improve the performance of EL resolving
https://issues.apache.org/bugzilla/show_bug.cgi?id=53897 Priority: P2 Bug ID: 53897 Assignee: dev@tomcat.apache.org Summary: Customized EL resolver to improve the performance of EL resolving Severity: enhancement Classification: Unclassified Reporter: xs...@ebay.com Hardware: PC Status: NEW Version: trunk Component: Jasper Product: Tomcat 7 Created attachment 29393 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29393action=edit Comparison test case CustomizedELResolver is to simplify and make it efficient for EL resolving. 1. The code in CustomizedELResolver is copied from CompositeELResolver. 2. Performance tuning is focus on getValue, because it was the big hotspot of one page hit if the page includes many ELs. 3. getValue switchs by base If the base is null, it follows next steps to check value, A. ImplicitObjectELResolverImpl(Optimized from ImplicitObjectELResolverImpl) B. Extended ELResolvers C. ScopedAttributeELResolverImpl(Extends ScopedAttributeELResolverImpl, supports get value by property name) Else the base is not null, it checks extended ELResolvers first, then tries to get value from Map, ResourceBundle, List, Array or Bean one by one until the property was resolved. Q: Why split extSize == 1 to another block ? A: To avoid an additional context.setPropertyResolved(false); Q: Why check value from Map, ResourceBundle, List and Array directly in CustomizedELResolver ? A To avoid extra valiation in ELResolver.getValue. Description for attached files. 1. CustomizedELResolver: The implementation for this fix. 2 JspApplicationContextImpl.diff : Patch for how to apply this new resolver. 3. ScopedAttributeELResolverImpl.java: Extension of ScopedAttributeELResolverImpl. 4. TestPageContext.java: Test case to compare the new ELResolver with CompositeELResolver 5. ImplicitObjectELResolverImpl.java: related with another bugzilla https://issues.apache.org/bugzilla/show_bug.cgi?id=53895 -- 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 53897] Customized EL resolver to improve the performance of EL resolving
https://issues.apache.org/bugzilla/show_bug.cgi?id=53897 --- Comment #1 from Sheldon Shao xs...@ebay.com --- Created attachment 29394 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29394action=edit CustomizedELResolver -- 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 53897] Customized EL resolver to improve the performance of EL resolving
https://issues.apache.org/bugzilla/show_bug.cgi?id=53897 --- Comment #2 from Sheldon Shao xs...@ebay.com --- Created attachment 29395 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29395action=edit Extension of ScopedAttributeELResolver -- 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 53897] Customized EL resolver to improve the performance of EL resolving
https://issues.apache.org/bugzilla/show_bug.cgi?id=53897 --- Comment #3 from Sheldon Shao xs...@ebay.com --- Created attachment 29396 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29396action=edit Patch for how to apply this CustomizdELResolver -- 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 53896] Optimized Jasper ELResolver
https://issues.apache.org/bugzilla/show_bug.cgi?id=53896 --- Comment #1 from Jarek Gawor jga...@gmail.com --- Created attachment 29397 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29397action=edit Optimized Jasper EL resolver I attached an optimized Jasper EL resolver. The resolver extends and functions like a CompositeELResolver but skips over certain resolvers as possible. -- 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 53900] New: hi
https://issues.apache.org/bugzilla/show_bug.cgi?id=53900 Priority: P2 Bug ID: 53900 Assignee: dev@tomcat.apache.org Summary: hi Severity: normal Classification: Unclassified OS: Windows XP Reporter: ily.sncs...@gmail.com Hardware: PC Status: NEW Version: nightly Component: Application Taglib Product: Taglibs -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-taglibs-standard (in module tomcat-taglibs) failed
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 83 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: 21 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]
[Bug 53897] Customized EL resolver to improve the performance of EL resolving
https://issues.apache.org/bugzilla/show_bug.cgi?id=53897 Sheldon Shao xs...@ebay.com changed: What|Removed |Added OS||All --- Comment #4 from Sheldon Shao xs...@ebay.com --- Related with https://issues.apache.org/bugzilla/show_bug.cgi?id=53896 -- 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: r1387487 - /tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
Author: kfujino
Date: Wed Sep 19 08:45:28 2012
New Revision: 1387487
URL: http://svn.apache.org/viewvc?rev=1387487view=rev
Log:
The running flag is moved out of if block.
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java?rev=1387487r1=1387486r2=1387487view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
Wed Sep 19 08:45:28 2012
@@ -64,8 +64,8 @@ public class TcpPingInterceptor extends
@Override
public synchronized void start(int svc) throws ChannelException {
super.start(svc);
+running = true;
if ( thread == null useThread) {
-running = true;
thread = new PingThread();
thread.setDaemon(true);
thread.setName(TcpPingInterceptor.PingThread-+cnt.addAndGet(1));
@@ -86,8 +86,8 @@ public class TcpPingInterceptor extends
@Override
public void stop(int svc) throws ChannelException {
+running = false;
if ( thread != null ) {
-running = false;
thread.interrupt();
thread = null;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1387489 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kfujino Date: Wed Sep 19 08:49:32 2012 New Revision: 1387489 URL: http://svn.apache.org/viewvc?rev=1387489view=rev Log: Additional patch. Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1387489r1=1387488r2=1387489view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Sep 19 08:49:32 2012 @@ -159,6 +159,7 @@ PATCHES PROPOSED TO BACKPORT: * Fix a behavior of TcpPingInterceptor#useThread. If set to false, ping thread is never started. http://svn.apache.org/viewvc?view=revisionrevision=1387073 + http://svn.apache.org/viewvc?view=revisionrevision=1387487 +1: kfujino -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1387073 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java webapps/docs/changelog.xml webapps/docs/config/cluster-interceptor.xml
2012/9/18 Konstantin Kolinko knst.koli...@gmail.com:
2012/9/18 kfuj...@apache.org:
Author: kfujino
Date: Tue Sep 18 09:45:17 2012
New Revision: 1387073
URL: http://svn.apache.org/viewvc?rev=1387073view=rev
Log:
Fix a behavior of TcpPingInterceptor#useThread.
If set to false, ping thread is never started.
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-interceptor.xml
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java?rev=1387073r1=1387072r2=1387073view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
Tue Sep 18 09:45:17 2012
@@ -64,8 +64,8 @@ public class TcpPingInterceptor extends
@Override
public synchronized void start(int svc) throws ChannelException {
super.start(svc);
-running = true;
-if ( thread == null ) {
+if ( thread == null useThread) {
+running = true;
thread = new PingThread();
thread.setDaemon(true);
thread.setName(TcpPingInterceptor.PingThread-+cnt.addAndGet(1));
@@ -86,9 +86,11 @@ public class TcpPingInterceptor extends
@Override
public void stop(int svc) throws ChannelException {
-running = false;
-if ( thread != null ) thread.interrupt();
-thread = null;
+if ( thread != null ) {
+running = false;
+thread.interrupt();
+thread = null;
+}
super.stop(svc);
}
The above changes the meaning of the running flag.
IMHO, the flag is supposed to say whether TcpPingInterceptor itself is
running or not. It does not matter whether you started a thread or
not. So I would move it out of the if block.
Done.
Thanks for the review.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
--
Keiichi.Fujino
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53900] hi
https://issues.apache.org/bugzilla/show_bug.cgi?id=53900 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Mark Thomas ma...@apache.org --- SPAM - user disabled. -- 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 53897] Customized EL resolver to improve the performance of EL resolving
https://issues.apache.org/bugzilla/show_bug.cgi?id=53897 --- Comment #5 from Jarek Gawor jga...@gmail.com --- This is essentially a duplicate of https://issues.apache.org/bugzilla/show_bug.cgi?id=53896. From my reading of the JSP 2.2 spec (section 2.9), it implies that the ELResolver used by JSP application should be an CompositeELResolver (which the JasperELResolver.java in 53896 is). -- 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 53903] New: Embedded Tomcat7 does not process Servlet API3.0 Annotations (WebListener)
https://issues.apache.org/bugzilla/show_bug.cgi?id=53903 Priority: P2 Bug ID: 53903 Assignee: dev@tomcat.apache.org Summary: Embedded Tomcat7 does not process Servlet API3.0 Annotations (WebListener) Severity: normal Classification: Unclassified Reporter: manuelha...@gmail.com Hardware: PC Status: NEW Version: 7.0.29 Component: Catalina Product: Tomcat 7 When starting an embeeded tomcat with an webapp with - web.xml with servlet api3 version - a ServletContextListener implementation with @WebListener Annotation then the ServletContextlistener is ignored (it wont be registered). The same Listener works if added manually to web.xml with a listener-Tag -- 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 53896] Optimized Jasper ELResolver
https://issues.apache.org/bugzilla/show_bug.cgi?id=53896 Mark Thomas ma...@apache.org changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Mark Thomas ma...@apache.org --- Correct priority -- 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: Resources - The need for refactoring
On 14/09/2012 19:12, Mark Thomas wrote: On 09/09/2012 19:34, Mark Thomas wrote: This is issue a) in Konstantin's comments in TOMCAT-NEXT.txt My expectation is that the need for refactoring in some form or another is clear. Currently Tomcat has the following features: - aliases - resource JARs - VirtualDirContext / VirtualLoader and in Servlet 3.1 there will be overlays. [1] Each of these features (except overlays which isn't implemented yet) does almost the same thing each in slightly different ways. The code is already quite messy and adding overlay support is going to be really difficult without some refactoring. The various bugs we have seen in the Virtual[Context|Loader] implementation hasn't been great and I am concerned that an overlay implementation built on the existing code will be fragile. A refactored, coherent resources implementation will make implementing overlays a lot simpler. The new resources implementation I just committed already supports overlays - it just needs plumbing in to whatever API the Servlet EG defines. I view this issue not as what the refactoring should look like but that there is a need for a refactoring of some form before any further features are added for resource handling. I haven't seen any arguments against this point. If none are forthcoming in the next few days, I am going to assume that there is no argument that refactoring of the resource handling is required for Tomcat 8.0.x (although there may well be different views on what that refactoring should look like). There haven't been any views expressed that a refactoring is unnecessary. I am therefore going to consider this issue closed with the agreed position that refactoring - in some form - is required of the resources implementation for Tomcat 8 onwards. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Resources - Is DirContext the right basis for the API?
On 09/09/2012 19:50, Mark Thomas wrote: This is part of issue b) in Konstantin's comments in TOMCAT-NEXT.txt Konstantin has accurately summed up the issues with basing the API on DirContext as: - Unnecessary objects, e.g. NamingException instead of null. - Too many methods. Name vs. String. list() vs. listBindings(). - Limited API. As a workaround, there are non-standard methods that are implemented on BaseDirContext instead, e.g. getRealPath(), doListBindings(..). I do not believe that the resources implementation should be based around DirContext. It adds a lot of unnecessary clutter and complexity to something that is already fairly complex. A comparison of the DirContext based implementation objects with the new implementation demonstrates - in my view - how much simpler this could be. This is the next issue I'd like to resolve. Does anyone have any views one way or the other as to whether or not any refactoring of the Resources implementation should continue to be based around the JNDI DirContext interface? My own view remains that DirContext adds complexity and clutter to code that needs simplicity and clarity. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53905] New: Connection pool not reusing connections.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53905
Priority: P2
Bug ID: 53905
Assignee: dev@tomcat.apache.org
Summary: Connection pool not reusing connections.
Severity: normal
Classification: Unclassified
Reporter: scott.wat...@hybris.com
Hardware: PC
Status: NEW
Version: unspecified
Component: jdbc-pool
Product: Tomcat Modules
I am trying the new jdbc connection pool with tomcat 6.0.35 and I am noticing
some strange behavior.
The info about what I am doing is below.
When the pool starts up I see 5 connections as I would expect, then after about
60 seconds 2 connections get dropped as there has been no activity. Up to this
point everything seems to be working properly.
My test program will do a http get over a fixed number of times for x number of
sessions
So I call all.bat like this
c:\temp all.bat 2 200
which will create two session that will do a wget 200 times each of a random
number.
Now I run my test, this is just 2 clients calling the same url over and over
again in a loop. ( I would expect to see only 2 connections required but on the
first run I see a total of 8 connections. When the test completes in about 20
seconds I run the test again and I see the pool grow to a total of 17
connections.
Also, once I am done my tests I don't see idle connections being released from
the pool either. I have waited over an hour and I don't see the connections
being disconnected.
SQL /
SYSDATE SID USERNAME LOGON_TIME
IDLE
-- --
19-SEP-2012 15:59:06 32 DBA_ 19-SEP-2012
15:45:12 0:0:39
19-SEP-2012 15:59:06 34 DBA_ 19-SEP-2012
15:58:31 0:0:34
19-SEP-2012 15:59:06 54 DBA_ 19-SEP-2012
15:58:55 0:0:11
19-SEP-2012 15:59:06 55 DBA_ 19-SEP-2012
15:58:54 0:0:4
19-SEP-2012 15:59:06 58 DBA_ 19-SEP-2012
15:58:54 0:0:11
19-SEP-2012 15:59:06 69 DBA_ 19-SEP-2012
15:58:57 0:0:8
19-SEP-2012 15:59:06 71 DBA_ 19-SEP-2012
15:59:01 0:0:5
19-SEP-2012 15:59:06 79 DBA_ 19-SEP-2012
15:58:29 0:0:36
19-SEP-2012 15:59:06 81 DBA_ 19-SEP-2012
15:45:12 0:0:49
19-SEP-2012 15:59:06 87 DBA_ 19-SEP-2012
15:59:02 0:0:4
19-SEP-2012 15:59:06 92 DBA_ 19-SEP-2012
15:58:27 0:0:37
19-SEP-2012 15:59:06 94 DBA_ 19-SEP-2012
15:58:29 0:0:37
19-SEP-2012 15:59:06108 DBA_ 19-SEP-2012
15:58:59 0:0:5
19-SEP-2012 15:59:06117 DBA_ 19-SEP-2012
15:58:56 0:0:10
19-SEP-2012 15:59:06119 DBA_ 19-SEP-2012
15:45:12 0:0:37
19-SEP-2012 15:59:06132 DBA_ 19-SEP-2012
15:58:53 0:0:12
19-SEP-2012 15:59:06133 DBA_ 19-SEP-2012
15:58:56 0:0:10
17 rows selected.
all.bat
~~~
echo off
set size=%2
for /L %%x in (1, 1, %1) do (call :sub %%x )
GOTO :eof
:sub
start cmd /k c:\temp\run.bat %1 %size%
GOTO :eof
:eof
run.bat
echo off
set FILE=%1
set SIZE=%2
for /L %%x in (1, 1, %SIZE% ) do (call :sub %%x )
GOTO :eof
:sub
echo Run %1
wget -q --output-document=sess%FILE%.txt http://localhost:8080/test/db
GOTO :eof
:eof
context.xml
?xml version=1.0 encoding=UTF-8?
Context path=/test docBase=test debug=1 reloadable=true
!-- Specify a JDBC datasource --
Resource name=jdbc/testdb auth=Container
type=javax.sql.DataSource username=dba_ password=XX
factory=org.apache.tomcat.jdbc.pool.DataSourceFactory
driverClassName=oracle.jdbc.OracleDriver
url=jdbc:oracle:thin:@test1:1521/DB1
initialSize=5 maxActive=20 maxIdle=4 minIdle=3
maxWait=-1
defaultAutoCommit=false
testOnBorrow=false
testWhileIdle=true
validationQuery=select 1 from dual /
/Context
TestServlet.java
import java.io.IOException;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.sql.DataSource;
import java.io.*;
import javax.servlet.http.*;
import javax.servlet.*;
public class TestServlet extends HttpServlet {
private DataSource dataSource;
private Connection connection;
private Statement statement;
