[Tomcat Wiki] Update of LocalBadContent by KonstantinKolinko
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The LocalBadContent page has been changed by KonstantinKolinko: http://wiki.apache.org/tomcat/LocalBadContent?action=diffrev1=112rev2=113 awesomeindiefilms\.doobious\.org backlinklist\.org beerfactory\.org + bestplace\.ca bettingpro\.com bigorbust\.net bit\.ly - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54178] runtime exception in onComplete of AsyncListener, will make org.apache.catalina.connector.Request not recycled (orginally reported MESSAGE POST to tomcat, but it called doGet)
https://issues.apache.org/bugzilla/show_bug.cgi?id=54178 wan...@126.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- Summary|MESSAGE POST to tomcat, but |runtime exception in |it called doGet |onComplete of ||AsyncListener, will make ||org.apache.catalina.connect ||or.Request not recycled ||(orginally reported MESSAGE ||POST to tomcat, but it ||called doGet) --- Comment #10 from wan...@126.com --- hi Sir, it is reproducible now. after I debug with tomcat source code and my application. first, I will give my analysis; second I will give the opinion that it is a bug, hope I am right; third my question; first: analysis I found that if there is a run-time exception(exclude IOException) in the implication of onComplete, then this exception will be catched in AbstractProtocol$AbstractConnectionHandler.process() in line AbstractProtocol.java:581, and processor is release in line 598 of the same file. but the code assume onComplete successfully returned and released org.apache.catalina.connector.Request in function asyncDispatch; So in this scenario Request is not recycled. when the processor is reused again, the browser request will be the processed by the Request that is not recycled, as there is servlet in it. then the request is handled by the wrong servlet. second: reason; you may tell me that it is the bug of the application; but in fact if this happens in tomcat, request to another application in the same tomcat will got error result it the client request meets the processor which contains the Request that is not recycled; I think tomcat should make sure that one application deployed in it should not be interrupt by others? do you think so? third: I want to know why AsyncContextImpl.fireOnComplete catches only IOException instead of Throwable; then maybe the above is fixed; Sorry for my interrupt. 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
[Bug 54783] New: Tomcat 6 DeltaManager poses significant performance overhead for Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=54783 Bug ID: 54783 Summary: Tomcat 6 DeltaManager poses significant performance overhead for Application Product: Tomcat 6 Version: 6.0.20 Hardware: PC Status: NEW Severity: major Priority: P2 Component: Cluster Assignee: dev@tomcat.apache.org Reporter: abhijit_rajw...@bmc.com Classification: Unclassified We see significant performance degradation for our Web Application when using TCP In-Memory replication with DeltaManager. On looking at Tomcat 6 source, here are possible causes we identified and our suggestions. #1 Need early evaluation of Filters: In ReplicationValve.java method invoke, the Filtering of URI's is done after having done some computation. This should be done at the earliest immediately after the following call. getNext().invoke(request, response); This will avoid unnecessary checks / computations for URI's that are filtered out based on the Filter expression defined for the ReplicationVavve. #2 Minimize Session locking in DeltaManager requestCompleted method In the DeltaManager method public ClusterMessage requestCompleted(String sessionId) the DeltaSession is locked at start of the method and the lock is released towards end of the method. Minimize the DeltaSession locking in this method so that parallelism of Requests fired by Browser for the same User is not impaired. Could a copy / clone of DeltaSession be done so that the interval for which DeltaSession is locked can be minimized? Going further, after a copy / clone of DeltaSession is done, could the Response be sent back to the Browser and the DeltaSession processing for replication done asynchronously in a seperate Thread / by using a seperate Thread Pool? The DeltaSessionManager does extra computation for Session replication using the same Thread that processes the User's request. It also holds up sending back the Response till the extra computation is done. The result is Response times for a Web Application regress with Session Replication enabled compared to a baseline when no Session Replication is used. Both the points noted above and the suggestions on these points can help mitigate the Performance impact on the Application. While the issue is being reported on Tomcat 6.0.20, I think it applies to Tomcat 6 latest version and Tomcat 7 latest version as well. Fixes for the issues mentioned will go a long way in addressing Performance concerns with In Memory Session Replication. --- Abhijit Rajwade -- 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 54783] Tomcat 6 DeltaManager poses significant performance overhead for Application
https://issues.apache.org/bugzilla/show_bug.cgi?id=54783 Abhijit Rajwade abhijit_rajw...@bmc.com changed: What|Removed |Added Priority|P2 |P1 CC||abhijit_rajw...@bmc.com OS||All -- 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 54791] New: No TLD files were found in tools.jar when tools.jar is explicitly added to $CLASSPATH
https://issues.apache.org/bugzilla/show_bug.cgi?id=54791 Bug ID: 54791 Summary: No TLD files were found in tools.jar when tools.jar is explicitly added to $CLASSPATH Product: Tomcat 7 Version: 7.0.39 Hardware: PC OS: Windows XP Status: NEW Severity: minor Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com Classification: Unclassified Since r1448831 (7.0.39) tools.jar is no longer mentioned in jarsToSkip Steps to reproduce 1. Use Eclipse IDE, version for JavaEE developers. I am using 3.7.2 (Indigo SR2) here. 2. Configure it to use a JDK. 3. Configure a new Server from Tomcat 7.0.39 In Java EE perspective, go to Servers view, right-click, choose New - Server from context menu. 4. Examine launch configuration of the server. In Servers view click on the server instance. A new page opens in Editor area. Click on Open launch configuration link there. Go to Classpath tab. Note that the following JARs are in the classpath: * bootstrap.jar * tomcat-juli.jar * tools.jar 5. Deploy a web application on this server and start it. If you have configured logging (with -Djava.util.logging.config.file in the same launch configuration dialog), you may see complaints that there are no TLDs in tools.jar. 02-Apr-2013 18:24:39.637 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet Engine: Apache Tomcat/7.0.39 (...) 02-Apr-2013 23:08:54.355 FINE [tc-http-2] org.apache.jasper.compiler.TldLocationsCache.tldScanJar No TLD files were found in [file:/C:/Program%20Files/Java/jdk1.6.0_43/lib/tools.jar]. Consider adding the JAR to the tomcat.util.scan.DefaultJarScanner.jarsToSkip or org.apache.catalina.startup.TldConfig.jarsToSkip property in CATALINA_BASE/conf/catalina.properties file. There are two ways to fix this a) add tools.jar to jarsToSkip property b) do not scan jars in classpath. In r1448831 in StandardJarScanner.java this b) would be replace stopLoader = ClassLoader.getSystemClassLoader().getParent(); with stopLoader = ClassLoader.getSystemClassLoader(); I see a problem with such a change, though. I think that there is no need to scan SystemClassLoader's classpath when Tomcat is launched via Bootstrap class. I think that we have to scan SystemClassLoader's classpath when launched in embedded mode via Tomcat class. Is is because it does not set up classloaders hierarchy like it is done by Bootstrap. -- 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 54792] New: IllegalStateException with chat sample
https://issues.apache.org/bugzilla/show_bug.cgi?id=54792 Bug ID: 54792 Summary: IllegalStateException with chat sample Product: Tomcat 8 Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: rstoyanc...@yahoo.com Classification: Unclassified This looks related to 54659 and 54724 but possibly a new issue. To reproduce, open the chat sample page, send a message or two, and then close the browser tab. The following exception appears in the log and it doesn't seem to step from anything done in the application: java.lang.IllegalStateException: The WebSocket session has been closed and no method (apart from close()) may be called on a closed session at org.apache.tomcat.websocket.WsSession.checkState(WsSession.java:516) at org.apache.tomcat.websocket.WsSession.getMessageHandlers(WsSession.java:191) at org.apache.tomcat.websocket.pojo.PojoEndpointBase.onClose(PojoEndpointBase.java:113) at org.apache.tomcat.websocket.WsSession.fireEndpointOnClose(WsSession.java:392) at org.apache.tomcat.websocket.WsSession.onClose(WsSession.java:370) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.close(WsHttpUpgradeHandler.java:166) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.access$200(WsHttpUpgradeHandler.java:44) at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsReadListener.onDataAvailable(WsHttpUpgradeHandler.java:192) at org.apache.coyote.http11.upgrade.AbstractServletInputStream.onDataAvailable(AbstractServletInputStream.java:169) at org.apache.coyote.http11.upgrade.AbstractProcessor.upgradeDispatch(AbstractProcessor.java:94) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:618) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1581) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1537) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- 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
[Tomcat Wiki] Trivial Update of Porter29X by Porter29X
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The Porter29X page has been changed by Porter29X: http://wiki.apache.org/tomcat/Porter29X New page: Name: Porter FitzpatrickBR Age: 28BR Country: Great BritainBR Home town: Guiseley BR ZIP: LS20 6QXBR Address: 70 Moulton RoadBR [[http://www.damncovers.com|christian facebook covers]] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of LocalBadContent by ChuckCaldarale
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The LocalBadContent page has been changed by ChuckCaldarale: http://wiki.apache.org/tomcat/LocalBadContent?action=diffrev1=113rev2=114 communitychurchsite\.info computerrental\.biz copdregionalnetwork\.org + damncovers\.com directorysubmitlist\.com do-follow\.info dragonseo - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54770] Add jarsToScan properties to counteract jarsToSkip exclusions; support per-web-app properties; port to Java 7
https://issues.apache.org/bugzilla/show_bug.cgi?id=54770 --- Comment #1 from Nick Williams nicho...@nicholaswilliams.net --- Of course this is an enhancement. By mad for categorizing it incorrectly. I WOULD argue that the priority on this enhancement is high, but it is still an 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 54745] Tomcat JarScanning does not work when Tomcat started with Java Web Start
https://issues.apache.org/bugzilla/show_bug.cgi?id=54745 --- Comment #1 from Nick Williams nicho...@nicholaswilliams.net --- I disagree with categorizing this as an enhancement. I believe this is a major bug. The facts are very simple: In an environment in which Tomcat otherwise runs without issue, JAR scanning incorrectly excludes some JARs that are validly on the classpath and that do not match the excluded JARs patterns, and it does so without any errors, warnings, infos, etc. I fail to see how this isn't a bug. Semantics aside, the patch is extraordinarily trivial. Does anyone see any downsides to it? -- 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 54747] Cluster not work due to registerManager failed
https://issues.apache.org/bugzilla/show_bug.cgi?id=54747 vincentj...@potix.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #16 from vincentj...@potix.com --- I still have the problem, did you really test the session replication with my sample war and not seeing any warning message in catalina.log? -- 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
