Re: [ANN] New committer: Konstantin Preißer
2013/9/25 Mark Thomas > On behalf of the Tomcat committers I am pleased to announce that > Konstantin Preißer has been voted in as a new Tomcat committer. > > In addition to a number of high quality bug reports and patches, > Konstantin is also responsible for the makeover the Tomcat web site and > Tomcat 8 documentation has received. > > Please join me in welcoming him. > > Welcome Konstantin! -- Keiichi.Fujino
Re: [VOTE] Release Apache Tomcat 7.0.45
2013/9/25 Violeta Georgieva > The proposed Apache Tomcat 7.0.45 release is now available for voting. > This release candidate contains JSR-356 Java WebSocket 1.0 implementation. > Note that use of this functionality requires Java 7. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.45/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-098/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_45/ > > The proposed 7.0.45 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 7.0.45 Stable > > > +1 Tested on my test app (enable session replication). -- Keiichi.Fujino
Re: [VOTE] Release Apache Tomcat 7.0.45
Violeta, On 25.9.2013 15:37, Violeta Georgieva wrote: The proposed Apache Tomcat 7.0.45 release is now available for voting. This release candidate contains JSR-356 Java WebSocket 1.0 implementation. Note that use of this functionality requires Java 7. I have problems when I test Tomcat 7.0.45 with APR (tcnative-1.1.28), using Oracle JDK 1.7.0_40 on Windows 7. I am able to reproduce that on Tomcat 8.0.0-RC3 + tcnative-1.1.28, but NOT on 7.0.42 + tcnative-1.1.28. NIO and BIO connectors work fine on all tested versions of Tomcat. Ne changes were made to default Tomcat .zip installation. The problem is that after couple of seconds/minutes after Tomcat startup while I am manually reading (with Firefox) or automaticly crawling (with custom Java web crawler) local Tomcat docs, Tomcat crashes. I will refrain from voting, since I really don't have a lot of experience with APR, so I assume it might be also my local configuration problem. But, since the problem does not exist on 7.0.42, but it does exist on 7.0.45, I find it appropriate to report it on this thread. Crash report for Tomcat 7.0.45 + tcnative-1.1.28 is at the end of this message. -Ognjen # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x000180007e23, pid=3028, tid=3272 # # JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b56 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [tcnative-1.dll+0x7e23] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x0cc5e800): JavaThread "http-apr-8080-Poller" daemon [_thread_in_native, id=3272, stack(0x0e56,0x0e66)] siginfo: ExceptionCode=0xc005, reading address 0x Registers: RAX=0x, RBX=0x0e8e44f0, RCX=0x003fecc8, RDX=0x00c0 RSP=0x0e65f2a0, RBP=0x, RSI=0x, RDI=0x0040fcd8 R8 =0x, R9 =0x003f7d20, R10=0x0060, R11=0x003f7d78 R12=0x0008, R13=0x0040fd20, R14=0x0004e74402162131, R15=0x0001 RIP=0x000180007e23, EFLAGS=0x00010246 Top of Stack: (sp=0x0e65f2a0) 0x0e65f2a0: 0040fcd8 0x0e65f2b0: 0e65f318 0e65f320 0x0e65f2c0: 0e65f348 02516274 0x0e65f2d0: 0cc5e800 0e65f370 0x0e65f2e0: 035a 0x0e65f2f0: 0001 0e65f380 0x0e65f300: 0400 02597e48 0x0e65f310: 0cc5e9e8 0006 0x0e65f320: 00407cd8 ef9d43dd 0x0e65f330: 0e65f350 0001 0x0e65f340: 00077dbfe2a0 0e65f388 0x0e65f350: 0007d7b9d2c0 0x0e65f360: 00077dbfe308 0x0e65f370: 0007d7b9d128 0007d7b74760 0x0e65f380: 026673ec 0x0e65f390: 01ceba86ea1bcbef 0e65f388 Instructions: (pc=0x000180007e23) 0x000180007e03: 47 18 49 89 1c 04 45 84 ff 74 69 48 8b 94 24 80 0x000180007e13: 00 00 00 48 8b 4f 10 e8 61 53 01 00 48 8b 43 38 0x000180007e23: 48 8b 10 48 8b 43 38 48 8b 48 08 48 89 11 48 8b 0x000180007e33: 43 38 48 8b 50 08 48 8b 43 38 48 8b 08 48 89 51 Register to memory mapping: RAX=0x is an unknown value RBX=0x0e8e44f0 is an unknown value RCX=0x003fecc8 is an unknown value RDX=0x00c0 is an unknown value RSP=0x0e65f2a0 is pointing into the stack for thread: 0x0cc5e800 RBP=0x is an unknown value RSI=0x is an unknown value RDI=0x0040fcd8 is an unknown value R8 =0x is an unknown value R9 =0x003f7d20 is an unknown value R10=0x0060 is an unknown value R11=0x003f7d78 is an unknown value R12=0x0008 is an unknown value R13=0x0040fd20 is an unknown value R14=0x0004e74402162131 is an unknown value R15=0x0001 is an unknown value Stack: [0x0e56,0x0e66], sp=0x0e65f2a0, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [tcnative-1.dll+0x7e23] [error occurred during error reporting (printing native stack), id 0xc005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
svn commit: r1526408 - /tomcat/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java
Author: kfujino Date: Thu Sep 26 08:03:03 2013 New Revision: 1526408 URL: http://svn.apache.org/r1526408 Log: Add support for notify periodic event of cluster. Modified: tomcat/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java Modified: tomcat/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java?rev=1526408&r1=1526407&r2=1526408&view=diff == --- tomcat/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java (original) +++ tomcat/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java Thu Sep 26 08:03:03 2013 @@ -32,6 +32,7 @@ import org.apache.catalina.Container; import org.apache.catalina.Context; import org.apache.catalina.Engine; import org.apache.catalina.Host; +import org.apache.catalina.Lifecycle; import org.apache.catalina.LifecycleEvent; import org.apache.catalina.LifecycleException; import org.apache.catalina.LifecycleListener; @@ -506,6 +507,9 @@ public class SimpleTcpCluster extends Li //send a heartbeat through the channel if ( isHeartbeatBackgroundEnabled() && channel !=null ) channel.heartbeat(); + +// periodic event +fireLifecycleEvent(Lifecycle.PERIODIC_EVENT, null); } - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1526409 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java webapps/docs/changelog.xml
Author: kfujino Date: Thu Sep 26 08:07:48 2013 New Revision: 1526409 URL: http://svn.apache.org/r1526409 Log: Add support for notify periodic event of cluster. Modified: tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java?rev=1526409&r1=1526408&r2=1526409&view=diff == --- tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java (original) +++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java Thu Sep 26 08:07:48 2013 @@ -32,6 +32,7 @@ import org.apache.catalina.Container; import org.apache.catalina.Context; import org.apache.catalina.Engine; import org.apache.catalina.Host; +import org.apache.catalina.Lifecycle; import org.apache.catalina.LifecycleEvent; import org.apache.catalina.LifecycleException; import org.apache.catalina.LifecycleListener; @@ -633,6 +634,9 @@ public class SimpleTcpCluster extends Li //send a heartbeat through the channel if ( isHeartbeatBackgroundEnabled() && channel !=null ) channel.heartbeat(); + +// periodic event +fireLifecycleEvent(Lifecycle.PERIODIC_EVENT, null); } Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1526409&r1=1526408&r2=1526409&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu Sep 26 08:07:48 2013 @@ -55,6 +55,15 @@ They eventually become mixed with the numbered issues. (I.e., numbered issues to not "pop up" wrt. others). --> + + + + +Add support for notify periodic event of cluster. (kfujino) + + + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1526410 - /tomcat/trunk/java/org/apache/catalina/Lifecycle.java
Author: kfujino
Date: Thu Sep 26 08:10:41 2013
New Revision: 1526410
URL: http://svn.apache.org/r1526410
Log:
Correct the javadoc for Lifecycle interface.
Modified:
tomcat/trunk/java/org/apache/catalina/Lifecycle.java
Modified: tomcat/trunk/java/org/apache/catalina/Lifecycle.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/Lifecycle.java?rev=1526410&r1=1526409&r2=1526410&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/Lifecycle.java (original)
+++ tomcat/trunk/java/org/apache/catalina/Lifecycle.java Thu Sep 26 08:10:41
2013
@@ -83,7 +83,7 @@ package org.apache.catalina;
* the component as soon as {@link #start()} exits. It is typically used when a
* component has failed to start.
*
- * MUST_DESTROY is used to indicate that the {@link #stop()} should be called
on
+ * MUST_DESTROY is used to indicate that the {@link #destroy()} should be
called on
* the component as soon as {@link #stop()} exits. It is typically used when a
* component is not designed to be restarted.
*
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1526412 - in /tomcat/tc7.0.x/trunk: java/org/apache/catalina/Lifecycle.java webapps/docs/changelog.xml
Author: kfujino
Date: Thu Sep 26 08:14:14 2013
New Revision: 1526412
URL: http://svn.apache.org/r1526412
Log:
Correct the javadoc for Lifecycle interface.
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/Lifecycle.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc7.0.x/trunk/java/org/apache/catalina/Lifecycle.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/Lifecycle.java?rev=1526412&r1=1526411&r2=1526412&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/Lifecycle.java (original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/Lifecycle.java Thu Sep 26
08:14:14 2013
@@ -83,7 +83,7 @@ package org.apache.catalina;
* the component as soon as {@link #start()} exits. It is typically used when a
* component has failed to start.
*
- * MUST_DESTROY is used to indicate that the {@link #stop()} should be called
on
+ * MUST_DESTROY is used to indicate that the {@link #destroy()} should be
called on
* the component as soon as {@link #stop()} exits. It is typically used when a
* component is not designed to be restarted.
*
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1526412&r1=1526411&r2=1526412&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu Sep 26 08:14:14 2013
@@ -63,6 +63,14 @@
+
+
+
+Correct the javadoc for org.apache.catalina.Lifecycle.
+(kfujino)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Issue in AprEndpoint detected by TestCoyoteAdapter
Hi Mark, On 25.09.2013 01:50, Mark Thomas wrote: > On 24/09/2013 16:19, Mark Thomas wrote: >> On 24/09/2013 08:16, Mark Thomas wrote: >>> On 23/09/2013 00:54, Rainer Jung wrote: >>> I agree that there's probably another problem further up the stack. >>> >>> I'm looking at this now. >> >> I've found a couple of issues. Not sure if either of these are the root >> cause of the remaining issues we see but I'll look into fixing them. >> >> - AprEndpoint.destroySocket() calls Poller.removeFromPoller() but that >> call isn't thread safe. I think we need a remove process similar to >> the add process. >> - sockets are not always removed from the timeout list when they are >> destroyed > > Fixed. > > Rainer, over to you. The TestCoyoteAdapter now neither fails with tcnative 1.1.28 nor with the additional APR_NOTFOUND change. I did 50 runs for each of the two versions and also for bio/nio/apr and none failed. Good! I'm still a bit nervous about coupling the connection count decrement with the successful removal from the poller. I ran TestCoyoteAdapter with an additional log message which would tell me whether Poll.remove returned APR_NOTFOUND and also whether a remove wasn't successful for any reason. During 50 runs for bio/nio/apr each no such log output was written, so there were not unsuccessful or unneeded calls to Poll.remove. The TestCoyoteOutputStream still fails relatively often. This failure happens for bio, nio and apr. With the patched tcnative, I get 7/3/7 failures out of 50 runs each for bio/nio/apr. Except for one failure all of them are hangs. For apr the hang always happens in testNonBlockingWriteNoneBlockingWriteNone, for bio half of them in testNonBlockingWriteTwiceBlockingWriteOnce and the other half in testNonBlockingWriteNoneBlockingWriteNone, for nio one in testNonBlockingWriteOnceBlockingWriteOnce and one in testNonBlockingWriteTwiceBlockingWriteOnce, the third nio failure is a non-hang with failure: Testcase: testNonBlockingWriteTwiceBlockingWriteNone took 4.146 sec Caused an ERROR Bogus chunk size java.io.IOException: Bogus chunk size at sun.net.www.http.ChunkedInputStream.processRaw(ChunkedInputStream.java:319) at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:572) at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:609) at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:696) at java.io.FilterInputStream.read(FilterInputStream.java:133) at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:3053) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:264) at org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:219) at org.apache.catalina.connector.TestCoyoteOutputStream.doNonBlockingTest(TestCoyoteOutputStream.java:91) at org.apache.catalina.connector.TestCoyoteOutputStream.testNonBlockingWriteTwiceBlockingWriteNone(TestCoyoteOutputStream.java:54) The hangs, the common case, always have the following exception: Exception in thread "http-apr-127.0.0.1-auto-3-exec-3" java.lang.IllegalStateException: Calling [asyncDispatch()] is not valid for a request with Async state [READ_WRITE_OP] at org.apache.coyote.AsyncStateMachine.asyncDispatch(AsyncStateMachine.java:282) at org.apache.coyote.http11.Http11AprProcessor.actionInternal(Http11AprProcessor.java:483) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:838) at org.apache.coyote.Request.action(Request.java:373) at org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:234) at org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:191) at org.apache.catalina.connector.TestCoyoteOutputStream$NonBlockingWriteServlet.doAsyncWrite(TestCoyoteOutputStream.java:143) at org.apache.catalina.connector.TestCoyoteOutputStream$NonBlockingWriteServlet.access$000(TestCoyoteOutputStream.java:107) at org.apache.catalina.connector.TestCoyoteOutputStream$NonBlockingWriteServlet$AsyncTask.run(TestCoyoteOutputStream.java:163) at org.apache.catalina.core.AsyncContextImpl$RunnableWrapper.run(AsyncContextImpl.java:568) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) The thread dumps shows the main thread hanging in waiting for an http answer: "main" prio=3 tid=0x00029800 nid=0x2 runnable [0xfdf7d000
Broken links
Hi, I noticed several broken links in Tomcat 7.0 trunk. 1. On page: http://tomcat.apache.org/tomcat-7.0-doc/proxy-howto.html URL: http://tomcat.apache.org/tomcat-7.0-doc/config/coyote.html 2. On page: http://localhost:8080/docs/ URL: http://localhost:8080/tomcat-7.0-doc/comments.html 3. On page: http://localhost:8080/examples/jsp/jsptoserv/jts.html URL: http://localhost:8080/examples/jsp/jsptoserv/servletToJsp.java.html All of them are visible in default Tomcat installation docs and examples contexts, while the first one is also visible on Tomcat website. Regards, Ognjen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55595] Request parameter parsing is not thread-safe
https://issues.apache.org/bugzilla/show_bug.cgi?id=55595
--- Comment #3 from Tim Funk ---
In user land - the simple solution is to perform a
request.getParameter("anything") before the multithreaded logic is executed.
This will trigger the parsing of the request parameters.
Then the multithreaded logic can run. (But it is still a use at your own risk
since HttpServletRequest was never meant to be thread safe)
--
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: r1526460 - /tomcat/trunk/webapps/docs/tomcat-docs.xsl
Author: kpreisser Date: Thu Sep 26 12:37:07 2013 New Revision: 1526460 URL: http://svn.apache.org/r1526460 Log: Fix broken link to comments.html page when the directory of the docs is not "tomcat-x.x-doc", as reported on the users list. Modified: tomcat/trunk/webapps/docs/tomcat-docs.xsl Modified: tomcat/trunk/webapps/docs/tomcat-docs.xsl URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/tomcat-docs.xsl?rev=1526460&r1=1526459&r2=1526460&view=diff == --- tomcat/trunk/webapps/docs/tomcat-docs.xsl (original) +++ tomcat/trunk/webapps/docs/tomcat-docs.xsl Thu Sep 26 12:37:07 2013 @@ -50,7 +50,7 @@ - /comments.html + /comments.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1526466 - /tomcat/tc7.0.x/trunk/webapps/docs/tomcat-docs.xsl
Author: kpreisser Date: Thu Sep 26 12:39:36 2013 New Revision: 1526466 URL: http://svn.apache.org/r1526466 Log: Fix broken link to comments.html page when the directory of the docs is not "tomcat-x.x-doc", as reported on the users list. Modified: tomcat/tc7.0.x/trunk/webapps/docs/tomcat-docs.xsl Modified: tomcat/tc7.0.x/trunk/webapps/docs/tomcat-docs.xsl URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/tomcat-docs.xsl?rev=1526466&r1=1526465&r2=1526466&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/tomcat-docs.xsl (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/tomcat-docs.xsl Thu Sep 26 12:39:36 2013 @@ -61,7 +61,7 @@ - /comments.html + /comments.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1526470 - /tomcat/tc7.0.x/trunk/webapps/docs/proxy-howto.xml
Author: kpreisser Date: Thu Sep 26 12:51:14 2013 New Revision: 1526470 URL: http://svn.apache.org/r1526470 Log: Fix broken link to HTTP connector in the Proxy HowTo, as reported on the users list. Modified: tomcat/tc7.0.x/trunk/webapps/docs/proxy-howto.xml Modified: tomcat/tc7.0.x/trunk/webapps/docs/proxy-howto.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/proxy-howto.xml?rev=1526470&r1=1526469&r2=1526470&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/proxy-howto.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/proxy-howto.xml Thu Sep 26 12:51:14 2013 @@ -38,7 +38,7 @@ Using standard configurations of Tomcat, web applications can ask for the server name and port number to which the request was directed for processing. When Tomcat is running standalone with the -Coyote HTTP/1.1 Connector, it will generally +HTTP/1.1 Connector, it will generally report the server name specified in the request, and the port number on which the Connector is listening. The servlet API calls of interest, for this purpose, are: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1526469 - /tomcat/trunk/webapps/docs/proxy-howto.xml
Author: kpreisser Date: Thu Sep 26 12:51:00 2013 New Revision: 1526469 URL: http://svn.apache.org/r1526469 Log: Fix broken link to HTTP connector in the Proxy HowTo, as reported on the users list. Modified: tomcat/trunk/webapps/docs/proxy-howto.xml Modified: tomcat/trunk/webapps/docs/proxy-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/proxy-howto.xml?rev=1526469&r1=1526468&r2=1526469&view=diff == --- tomcat/trunk/webapps/docs/proxy-howto.xml (original) +++ tomcat/trunk/webapps/docs/proxy-howto.xml Thu Sep 26 12:51:00 2013 @@ -38,7 +38,7 @@ Using standard configurations of Tomcat, web applications can ask for the server name and port number to which the request was directed for processing. When Tomcat is running standalone with the -Coyote HTTP/1.1 Connector, it will generally +HTTP/1.1 Connector, it will generally report the server name specified in the request, and the port number on which the Connector is listening. The servlet API calls of interest, for this purpose, are: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Broken links
Hi Ognjen, > -Original Message- > From: Ognjen Blagojevic [mailto:ognjen.d.blagoje...@gmail.com] > Sent: Thursday, September 26, 2013 12:13 PM > To: dev@tomcat.apache.org > Subject: Broken links > > Hi, > > I noticed several broken links in Tomcat 7.0 trunk. > > 1. On page: http://tomcat.apache.org/tomcat-7.0-doc/proxy-howto.html > URL: http://tomcat.apache.org/tomcat-7.0-doc/config/coyote.html > > 2. On page: http://localhost:8080/docs/ > URL: http://localhost:8080/tomcat-7.0-doc/comments.html > > 3. On page: http://localhost:8080/examples/jsp/jsptoserv/jts.html > URL: > http://localhost:8080/examples/jsp/jsptoserv/servletToJsp.java.html > > All of them are visible in default Tomcat installation docs and examples > contexts, while the first one is also visible on Tomcat website. Thanks for reporting these. I have fixed 1) and 2) in trunk and tc7.0.x. When looking at 3) and browsing in SVN history, it seems there never was such a HTML page that contains the source for servletToJsp.java. However, as I'm working on improving the HTML markup, I'm looking if we can get rid of those static HTML pages that duplicate the source code of other files (with adding syntax highlighting using legacy elements etc.), and use a programmatic solution to generate source code with syntax highlighting instead. Regards, Konstantin Preißer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat 7.0.45
Hi, > -Original Message- > From: Ognjen Blagojevic [mailto:ognjen.d.blagoje...@gmail.com] > Sent: Thursday, September 26, 2013 9:42 AM > I have problems when I test Tomcat 7.0.45 with APR (tcnative-1.1.28), > using Oracle JDK 1.7.0_40 on Windows 7. > > I am able to reproduce that on Tomcat 8.0.0-RC3 + tcnative-1.1.28, but > NOT on 7.0.42 + tcnative-1.1.28. > > NIO and BIO connectors work fine on all tested versions of Tomcat. > > Ne changes were made to default Tomcat .zip installation. > > The problem is that after couple of seconds/minutes after Tomcat startup > while I am manually reading (with Firefox) or automaticly crawling (with > custom Java web crawler) local Tomcat docs, Tomcat crashes. I get the same crash in tcnative-1.dll on Windows 8 64-bit with Java 1.7.0_40, when trying the Tomcat 7.0.45 release candidate for Windows-x64 with default configuration (APR connector) and browsing the local Tomcat docs with Firefox, approximately after a minute of browsing. Regards, Konstantin Preißer Crash log: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x000180007e23, pid=3700, tid=4652 # # JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b56 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [tcnative-1.dll+0x7e23] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x0cb5b800): JavaThread "http-apr-8080-Poller" daemon [_thread_in_native, id=4652, stack(0x0eb2,0x0ec2)] siginfo: ExceptionCode=0xc005, reading address 0x Registers: RAX=0x, RBX=0x0ea3e3d0, RCX=0x0de5d598, RDX=0x0060 RSP=0x0ec1f060, RBP=0x, RSI=0x, RDI=0x0de6e5a8 R8 =0x, R9 =0x0de565f0, R10=0x0030, R11=0x0de56648 R12=0x0008, R13=0x0de6e5f0, R14=0x0004e749054454dd, R15=0x0001 RIP=0x000180007e23, EFLAGS=0x00010246 Top of Stack: (sp=0x0ec1f060) 0x0ec1f060: 0de6e5a8 0x0ec1f070: 0ec1f0d8 0ec1f0e0 0x0ec1f080: 0ec1f108 02256274 0x0ec1f090: 0cb5b800 0ec1f130 0x0ec1f0a0: 0x0ec1f0b0: 0001 0ec1f140 0x0ec1f0c0: 0400 023bc648 0x0ec1f0d0: 0cb5b9e8 0003 0x0ec1f0e0: 0de665a8 ef6d43dd 0x0ec1f0f0: 0ec1f110 0001 0x0ec1f100: 00077c3c8658 0ec1f148 0x0ec1f110: 0007d7ff80e0 0x0ec1f120: 00077c3c86c0 0x0ec1f130: 00078181be70 0007d7ff2250 0x0ec1f140: 023ce964 0x0ec1f150: 01cebab909e9d0ab 00077b602758 Instructions: (pc=0x000180007e23) 0x000180007e03: 47 18 49 89 1c 04 45 84 ff 74 69 48 8b 94 24 80 0x000180007e13: 00 00 00 48 8b 4f 10 e8 61 53 01 00 48 8b 43 38 0x000180007e23: 48 8b 10 48 8b 43 38 48 8b 48 08 48 89 11 48 8b 0x000180007e33: 43 38 48 8b 50 08 48 8b 43 38 48 8b 08 48 89 51 Register to memory mapping: RAX=0x is an unknown value RBX=0x0ea3e3d0 is an unknown value RCX=0x0de5d598 is an unknown value RDX=0x0060 is an unknown value RSP=0x0ec1f060 is pointing into the stack for thread: 0x0cb5b800 RBP=0x is an unknown value RSI=0x is an unknown value RDI=0x0de6e5a8 is an unknown value R8 =0x is an unknown value R9 =0x0de565f0 is an unknown value R10=0x0030 is an unknown value R11=0x0de56648 is an unknown value R12=0x0008 is an unknown value R13=0x0de6e5f0 is an unknown value R14=0x0004e749054454dd is an unknown value R15=0x0001 is an unknown value Stack: [0x0eb2,0x0ec2], sp=0x0ec1f060, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [tcnative-1.dll+0x7e23] [error occurred during error reporting (printing native stack), id 0xc005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J org.apache.tomcat.jni.Poll.poll(JJ[JZ)I J org.apache.tomcat.util.net.AprEndpoint$Poller.run()V j java.lang.Thread.run()V+11 v ~StubRoutines::call_s
[jira] [Commented] (MTOMCAT-127) tomcat:run - Configuring Logging with JULI
[ https://issues.apache.org/jira/browse/MTOMCAT-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778796#comment-13778796 ] Xavier Dury commented on MTOMCAT-127: - Same problem here: I'm trying to use a custom logging.properties through in order to use SLF4J jul-to-slf4j bridge but it doesn't work (logs are still forwarded to SLF4J). > tomcat:run - Configuring Logging with JULI > --- > > Key: MTOMCAT-127 > URL: https://issues.apache.org/jira/browse/MTOMCAT-127 > Project: Apache Tomcat Maven Plugin > Issue Type: New Feature > Components: tomcat6, tomcat7 >Affects Versions: 2.0 >Reporter: Cédric Couralet >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Fix For: backlog > > > The configuration for a custom logging.properties is not taken into account > with the tomcat6-7:run goal. > From what I've seen, the reason is that the configuration for > java.util.logging is done before setting the system properties in the same > class loader. > I think it could be fixed by putting a call to > LogManager.getLogManager().readConfiguration(); right after setting the > system properties. I'm not confident enough on the possible side effects to > say it is the best solution. -- 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
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/5011 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1526460 Blamelist: kpreisser BUILD FAILED: failed compile_1 sincerely, -The Buildbot
[jira] [Comment Edited] (MTOMCAT-127) tomcat:run - Configuring Logging with JULI
[ https://issues.apache.org/jira/browse/MTOMCAT-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778796#comment-13778796 ] Xavier Dury edited comment on MTOMCAT-127 at 9/26/13 1:56 PM: -- Same problem here: I'm trying to use a custom logging.properties through in order to use SLF4J jul-to-slf4j bridge but it doesn't work (logs are not forwarded to SLF4J). was (Author: kalgon): Same problem here: I'm trying to use a custom logging.properties through in order to use SLF4J jul-to-slf4j bridge but it doesn't work (logs are still forwarded to SLF4J). > tomcat:run - Configuring Logging with JULI > --- > > Key: MTOMCAT-127 > URL: https://issues.apache.org/jira/browse/MTOMCAT-127 > Project: Apache Tomcat Maven Plugin > Issue Type: New Feature > Components: tomcat6, tomcat7 >Affects Versions: 2.0 >Reporter: Cédric Couralet >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Fix For: backlog > > > The configuration for a custom logging.properties is not taken into account > with the tomcat6-7:run goal. > From what I've seen, the reason is that the configuration for > java.util.logging is done before setting the system properties in the same > class loader. > I think it could be fixed by putting a call to > LogManager.getLogManager().readConfiguration(); right after setting the > system properties. I'm not confident enough on the possible side effects to > say it is the best solution. -- 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] [Updated] (MTOMCAT-127) tomcat:run - Configuring Logging with JULI
[ https://issues.apache.org/jira/browse/MTOMCAT-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Dury updated MTOMCAT-127: Attachment: mtomcat-127.zip Sample project to demonstrate the problem. Run "mvn" and open http://localhost:8080 In the console, all logs should go through SLF4J. > tomcat:run - Configuring Logging with JULI > --- > > Key: MTOMCAT-127 > URL: https://issues.apache.org/jira/browse/MTOMCAT-127 > Project: Apache Tomcat Maven Plugin > Issue Type: New Feature > Components: tomcat6, tomcat7 >Affects Versions: 2.0 >Reporter: Cédric Couralet >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Fix For: backlog > > Attachments: mtomcat-127.zip > > > The configuration for a custom logging.properties is not taken into account > with the tomcat6-7:run goal. > From what I've seen, the reason is that the configuration for > java.util.logging is done before setting the system properties in the same > class loader. > I think it could be fixed by putting a call to > LogManager.getLogManager().readConfiguration(); right after setting the > system properties. I'm not confident enough on the possible side effects to > say it is the best solution. -- 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: Issue in AprEndpoint detected by TestCoyoteAdapter
On 26/09/2013 02:47, Rainer Jung wrote: > The TestCoyoteAdapter now neither fails with tcnative 1.1.28 nor with > the additional APR_NOTFOUND change. I did 50 runs for each of the two > versions and also for bio/nio/apr and none failed. Good! +1 > I'm still a bit nervous about coupling the connection count decrement > with the successful removal from the poller. I ran TestCoyoteAdapter > with an additional log message which would tell me whether Poll.remove > returned APR_NOTFOUND and also whether a remove wasn't successful for > any reason. During 50 runs for bio/nio/apr each no such log output was > written, so there were not unsuccessful or unneeded calls to Poll.remove. I wrote it that way as there were times during testing when Poll.remove was called twice for the same socket. This only happened rarely. Because blocking writes in WebSocket require a socket to have concurrent read and write threads there were error conditions where both threads would try to close the socket. Other concurrency fixes may have reduced / removed the chances of multiple Poll.remove calls but I'd prefer to leave the check in place. > The TestCoyoteOutputStream still fails relatively often. This failure > happens for bio, nio and apr. With the patched tcnative, I get 7/3/7 > failures out of 50 runs each for bio/nio/apr. Except for one failure all > of them are hangs. OK. Still some work to do here then. I haven't been able to reproduce this yet. I want to fix the TLD issue for 8.0.0-RC3 reported on the users list first then I'll take a look at these issues. If someone wants to take a look at fixing these before I get to them - I'm not going to complain :) > For apr the hang always happens in > testNonBlockingWriteNoneBlockingWriteNone, for bio half of them in > testNonBlockingWriteTwiceBlockingWriteOnce and the other half in > testNonBlockingWriteNoneBlockingWriteNone, for nio one in > testNonBlockingWriteOnceBlockingWriteOnce and one in > testNonBlockingWriteTwiceBlockingWriteOnce, the third nio failure is a > non-hang with failure: > > Testcase: testNonBlockingWriteTwiceBlockingWriteNone took 4.146 sec > Caused an ERROR > Bogus chunk size > java.io.IOException: Bogus chunk size > at > sun.net.www.http.ChunkedInputStream.processRaw(ChunkedInputStream.java:319) > at > sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:572) > at > sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:609) > at > sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:696) > at java.io.FilterInputStream.read(FilterInputStream.java:133) > at > sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:3053) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) > at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) > at java.io.BufferedInputStream.read(BufferedInputStream.java:334) > at java.io.FilterInputStream.read(FilterInputStream.java:107) > at > org.apache.catalina.startup.TomcatBaseTest.methodUrl(TomcatBaseTest.java:264) > at > org.apache.catalina.startup.TomcatBaseTest.getUrl(TomcatBaseTest.java:219) > at > org.apache.catalina.connector.TestCoyoteOutputStream.doNonBlockingTest(TestCoyoteOutputStream.java:91) > at > org.apache.catalina.connector.TestCoyoteOutputStream.testNonBlockingWriteTwiceBlockingWriteNone(TestCoyoteOutputStream.java:54) > > > > The hangs, the common case, always have the following exception: > > Exception in thread "http-apr-127.0.0.1-auto-3-exec-3" > java.lang.IllegalStateException: Calling [asyncDispatch()] is not valid > for a request with Async state [READ_WRITE_OP] > at > org.apache.coyote.AsyncStateMachine.asyncDispatch(AsyncStateMachine.java:282) > at > org.apache.coyote.http11.Http11AprProcessor.actionInternal(Http11AprProcessor.java:483) > at > org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:838) > at org.apache.coyote.Request.action(Request.java:373) > at > org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:234) > at > org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:191) > at > org.apache.catalina.connector.TestCoyoteOutputStream$NonBlockingWriteServlet.doAsyncWrite(TestCoyoteOutputStream.java:143) > at > org.apache.catalina.connector.TestCoyoteOutputStream$NonBlockingWriteServlet.access$000(TestCoyoteOutputStream.java:107) > at > org.apache.catalina.connector.TestCoyoteOutputStream$NonBlockingWriteServlet$AsyncTask.run(TestCoyoteOutputStream.java:163) > at > org.apache.catalina.core.AsyncContextImpl$RunnableWrapper.run(AsyncContextImpl.java:568) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(Thread
svn commit: r1526510 - in /tomcat/trunk/webapps/examples/websocket: chat.xhtml echo.xhtml index.xhtml snake.xhtml
Author: kpreisser Date: Thu Sep 26 14:29:33 2013 New Revision: 1526510 URL: http://svn.apache.org/r1526510 Log: r1524838 broke the history of the WebSocket Example HTML files. This is because my patch file didn't contain the info that the XHTML files were copied from the HTML files (maybe this is not possible in a patch file). This commit should restore the history of the files while applying the same changes and renaming them to .xhtml. Added: tomcat/trunk/webapps/examples/websocket/chat.xhtml - copied, changed from r1524837, tomcat/trunk/webapps/examples/websocket/chat.html tomcat/trunk/webapps/examples/websocket/echo.xhtml - copied, changed from r1524837, tomcat/trunk/webapps/examples/websocket/echo.html tomcat/trunk/webapps/examples/websocket/index.xhtml - copied, changed from r1524837, tomcat/trunk/webapps/examples/websocket/index.html tomcat/trunk/webapps/examples/websocket/snake.xhtml - copied, changed from r1524837, tomcat/trunk/webapps/examples/websocket/snake.html Copied: tomcat/trunk/webapps/examples/websocket/chat.xhtml (from r1524837, tomcat/trunk/webapps/examples/websocket/chat.html) URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/websocket/chat.xhtml?p2=tomcat/trunk/webapps/examples/websocket/chat.xhtml&p1=tomcat/trunk/webapps/examples/websocket/chat.html&r1=1524837&r2=1526510&rev=1526510&view=diff == --- tomcat/trunk/webapps/examples/websocket/chat.html (original) +++ tomcat/trunk/webapps/examples/websocket/chat.xhtml Thu Sep 26 14:29:33 2013 @@ -1,3 +1,4 @@ + - - +http://www.w3.org/1999/xhtml"; xml:lang="en"> Apache Tomcat WebSocket Examples: Chat - + +