DO NOT REPLY [Bug 50685] New: Big memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=50685
Summary: Big memory leak
Product: Tomcat 7
Version: 7.0.6
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: major
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: tnik...@mail.ru
1) Download apache-tomcat-7.0.6-windows-x86.zip and unzip to
C:\apache-tomcat-7.0.6 . But this bug with all tomcat versions.
2) Create simple jsp C:\apache-tomcat-7.0.6\webapps\ROOT\test.jsp :
AAA<%=7+8%>
3) Add SET JAVA_HOME=C:\Program Files\Java\jdk1.6.0_23\ to
C:\apache-tomcat-7.0.6\bin\startup.bat and run startup.bat
4) Open http://localhost:8080/test.jsp in browser - it works and shows AAA15.
5) Do 10 requests to http://localhost:8080/test.jsp. Create new c# windows
forms app. Put one button with code:
private void button1_Click(object sender, EventArgs e)
{
StringBuilder sb = new StringBuilder();
byte[] buf = new byte[8192];
for (int i = 0; i < 10; i++)
{
HttpWebRequest request =
(HttpWebRequest)WebRequest.Create("http://localhost:8080/test.jsp";);
using(HttpWebResponse response = (HttpWebResponse)request.GetResponse())
using (Stream resStream = response.GetResponseStream())
{
string tempString = null; int count = 0;
count = resStream.Read(buf, 0, buf.Length);
if (count != 0) tempString = Encoding.ASCII.GetString(buf, 0, count);
}
}
}
6) It takes 15 seconds - test success. But tomcat process java.exe used 5mb
memory before test, after test 270mb. If run test again java.exe take 286mb and
crashed: Exception in thread ""http-apr-8080"-exec-2"
java.lang.OutOfMemoryError: Java heap space
7) run MemoryAnalyzer. It shows 2 problem:
One instance of "org.apache.catalina.session.StandardManager" loaded by
"org.apache.catalina.loader.StandardClassLoader @ 0x7f00638" occupies 3,112,280
(56.61%) bytes. The memory is accumulated in one instance of
"java.util.concurrent.ConcurrentHashMap$HashEntry[]" loaded by "".
The classloader/component "org.apache.catalina.loader.StandardClassLoader @
0x7f00638" occupies 637,728 (11.60%) bytes. The memory is accumulated in one
instance of "java.lang.Object[]" loaded by "".
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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: r1064992 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: rjung Date: Sat Jan 29 10:21:52 2011 New Revision: 1064992 URL: http://svn.apache.org/viewvc?rev=1064992&view=rev Log: Silly me, forgot to vote when proposing. Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=1064992&r1=1064991&r2=1064992&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Sat Jan 29 10:21:52 2011 @@ -88,6 +88,5 @@ PATCHES PROPOSED TO BACKPORT: * Fix permissions of version.sh in bin tarball Also reorder sh file list to make completeness check more easy. http://people.apache.org/~rjung/patches/fix-perms-version_sh.patch - (by rjung) - +1: kkolinko + +1: rjung, kkolinko -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50685] Big memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=50685 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50685] Big memory leak
https://issues.apache.org/bugzilla/show_bug.cgi?id=50685 --- Comment #1 from Mark Thomas 2011-01-29 07:09:45 EST --- Please use the users mailing list if you require further advice. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 48208] allow client certificate with any issuer: server.xml connector attribute "acceptAllCerts"
https://issues.apache.org/bugzilla/show_bug.cgi?id=48208 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #3 from Mark Thomas 2011-01-29 07:19:18 EST --- Then we disagree. Regardless of the complexity of the rules you may wish to apply, for there to be any security at all the client certificates have to be issued by a trusted certificate authority. The AcceptAllTrustManager is sufficiently insecure and its use sufficiently dangerous that I do not believe it should be part of the standard Tomcat distribution. There should be sufficient scope within the current configuration options to install a custom trust manager although I haven't investigated this. If that process is excessively painful then I think an acceptable approach would be to add support for a trustManagerClassName attribute that would override the call to TrustManagerFactory.getTrustManagers() in a similar way to the above patch. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: RemoteIpValve advices
> FWIW, Paul Fremantle gave a talk at ApacheCon NA this year where he > demonstrated Tomcat running behind AWSLB. I'm sure they have figured out > what changes are necessary to Tomcat to get it running in that environment. > Perhaps he's got some code he would be willing to share. Or, perhaps > he's not thought if this and would love to hear about this discussion. You got it, it's for AWLSB, in our case with used with Elastic Beanstalk instances. I'll send you a dump all all headers Tomcat receive when behind AWLSB. If you're interested I could even produce a complete AWLSB Valve, it could be usefull for Tomcat users, especially those using Elastic Beanstalk. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1065087 - /tomcat/trunk/test/org/apache/catalina/startup/TomcatBaseTest.java
Author: kkolinko
Date: Sat Jan 29 18:08:37 2011
New Revision: 1065087
URL: http://svn.apache.org/viewvc?rev=1065087&view=rev
Log:
When running the tests use log configuration specified by
conf/logging.properties
Modified:
tomcat/trunk/test/org/apache/catalina/startup/TomcatBaseTest.java
Modified: tomcat/trunk/test/org/apache/catalina/startup/TomcatBaseTest.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/startup/TomcatBaseTest.java?rev=1065087&r1=1065086&r2=1065087&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/startup/TomcatBaseTest.java (original)
+++ tomcat/trunk/test/org/apache/catalina/startup/TomcatBaseTest.java Sat Jan
29 18:08:37 2011
@@ -94,6 +94,8 @@ public abstract class TomcatBaseTest ext
// Need to use JULI so log messages from the tests are visible
System.setProperty("java.util.logging.manager",
"org.apache.juli.ClassLoaderLogManager");
+System.setProperty("java.util.logging.config.file", new File(
+getBuildDirectory(), "conf/logging.properties").toString());
tempDir = new File(System.getProperty("tomcat.test.temp",
"output/tmp"));
if (!tempDir.exists() && !tempDir.mkdirs()) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1065089 - /tomcat/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
Author: kkolinko
Date: Sat Jan 29 18:23:12 2011
New Revision: 1065089
URL: http://svn.apache.org/viewvc?rev=1065089&view=rev
Log:
Implement debug logging in InternalNioInputBuffer. Log what we got with the
first read.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java?rev=1065089&r1=1065088&r2=1065089&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java Sat
Jan 29 18:23:12 2011
@@ -39,6 +39,11 @@ import org.apache.tomcat.util.net.NioSel
*/
public class InternalNioInputBuffer extends AbstractInputBuffer {
+/**
+ * Logger.
+ */
+private static org.apache.juli.logging.Log log
+=
org.apache.juli.logging.LogFactory.getLog(InternalNioInputBuffer.class);
// -- Constants
@@ -228,6 +233,11 @@ public class InternalNioInputBuffer exte
if ( readSocket(true, false)==0 ) return false;
}
parsingRequestLinePhase = 2;
+if (log.isDebugEnabled()) {
+log.debug("Received ["
++ new String(buf, pos, lastValid - pos, "ISO-8859-1")
++ "]");
+}
}
if ( parsingRequestLinePhase == 2 ) {
//
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: RemoteIpValve advices
On 29/01/2011 12:38, Henri Gomez wrote: >> FWIW, Paul Fremantle gave a talk at ApacheCon NA this year where he >> demonstrated Tomcat running behind AWSLB. I'm sure they have figured out >> what changes are necessary to Tomcat to get it running in that environment. > >> Perhaps he's got some code he would be willing to share. Or, perhaps >> he's not thought if this and would love to hear about this discussion. > > You got it, it's for AWLSB, in our case with used with Elastic > Beanstalk instances. > I'll send you a dump all all headers Tomcat receive when behind AWLSB. > > If you're interested I could even produce a complete AWLSB Valve, it > could be usefull for Tomcat users, especially those using Elastic > Beanstalk. I'd certainly like to see some more information on this usage. With more info we can figure out what solution makes the most sense. Anything we can do to make Beanstalk easier to use is good although I would prefer to keep it generic if we can. Amazon - if you're reading this - your input to this discussion (or any other feedback) is welcome. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Failure of TestFormAuthenticator with NIO in trunk
Hi!
In r1063366 [1] there was a check added to Nttp11NioProtocol class that
now causes 3 of 5 tests in TestFormAuthenticator to fail with Nio connector.
I do not know whether you will be able to reproduce them. It somehow depends
on timing: I am not able to reproduce it when debugging, and out
buildbot [2] is green:
Anyway, it fails for me reliably when running without debugger.
>From TestFormAuthenticator the following three tests are failing:
testGet
testPostNoContinue
testPostWithContinue
The following two tests run successfully:
testPostNoContinuePostRedirect
testPostWithContinuePostRedirect
The failure happens when the first read in InternalNioInputBuffer
returns headers with a single CRLF following them. The test sends the
second CRLF with some delay.
I wonder why it is not reproducible on the build bot. Different OS? I
am running with WinXP SP3.
To reproduce:
1. Add the following into build.properties:
execute.test.bio=false
execute.test.nio=true
test.entry=org.apache.catalina.authenticator.TestFormAuthenticator
2. Add the following to logging.properties:
org.apache.coyote.level = FINE
3. Run "ant test"
The following is in
logs/TEST-org.apache.catalina.authenticator.TestFormAuthenticator.NIO.txt
(...)
29.01.2011 21:13:46 org.apache.coyote.AbstractProtocolHandler start
INFO: Starting ProtocolHandler ["http-nio-8001"]
29.01.2011 21:13:46
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler
register
FINE: Register [org.apache.coyote.http11.Http11NioProcessor@c09554] count=1
29.01.2011 21:13:46 org.apache.coyote.http11.InternalNioInputBuffer
parseRequestLine
FINE: Received [GET /examples/jsp/security/protected/index.jsp HTTP/1.1
Host: localhost
Connection: close
]
29.01.2011 21:13:46
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler
process
FINE: IOException reading request
java.io.IOException: Error processing request. Socket is in the long
poll state but neither Servlet 3.0+ async or Comet is being used
at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:379)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1569)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
If I remove the check added in r1063366, the test runs successfully:
Index: java/org/apache/coyote/http11/Http11NioProtocol.java
===
--- java/org/apache/coyote/http11/Http11NioProtocol.java(revision
1065026)
+++ java/org/apache/coyote/http11/Http11NioProtocol.java(working copy)
@@ -374,10 +374,7 @@
// complete or dispatch)
state = processor.asyncPostProcess();
} else {
-// Error condition. A connection in this state should
-// by using one of async or comet
-throw new IOException(sm.getString(
-"http11protocol.state.long.error"));
+socket.getPoller().add(socket);
}
}
if (state == SocketState.LONG || state ==
SocketState.ASYNC_END) {
[1] http://svn.apache.org/viewvc?view=revision&revision=1063366
[2] http://ci.apache.org/builders/tserver-trunk
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Failure of TestFormAuthenticator with NIO in trunk
On 29/01/2011 18:48, Konstantin Kolinko wrote:
> Hi!
>
> In r1063366 [1] there was a check added to Nttp11NioProtocol class that
> now causes 3 of 5 tests in TestFormAuthenticator to fail with Nio connector.
That'll be my fault. I'll revisit that patch.
Mark
> I do not know whether you will be able to reproduce them. It somehow depends
> on timing: I am not able to reproduce it when debugging, and out
> buildbot [2] is green:
>
> Anyway, it fails for me reliably when running without debugger.
>
> From TestFormAuthenticator the following three tests are failing:
> testGet
> testPostNoContinue
> testPostWithContinue
>
> The following two tests run successfully:
> testPostNoContinuePostRedirect
> testPostWithContinuePostRedirect
>
> The failure happens when the first read in InternalNioInputBuffer
> returns headers with a single CRLF following them. The test sends the
> second CRLF with some delay.
>
> I wonder why it is not reproducible on the build bot. Different OS? I
> am running with WinXP SP3.
>
> To reproduce:
> 1. Add the following into build.properties:
> execute.test.bio=false
> execute.test.nio=true
> test.entry=org.apache.catalina.authenticator.TestFormAuthenticator
> 2. Add the following to logging.properties:
> org.apache.coyote.level = FINE
> 3. Run "ant test"
>
> The following is in
> logs/TEST-org.apache.catalina.authenticator.TestFormAuthenticator.NIO.txt
> (...)
> 29.01.2011 21:13:46 org.apache.coyote.AbstractProtocolHandler start
> INFO: Starting ProtocolHandler ["http-nio-8001"]
> 29.01.2011 21:13:46
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler
> register
> FINE: Register [org.apache.coyote.http11.Http11NioProcessor@c09554] count=1
> 29.01.2011 21:13:46 org.apache.coyote.http11.InternalNioInputBuffer
> parseRequestLine
> FINE: Received [GET /examples/jsp/security/protected/index.jsp HTTP/1.1
> Host: localhost
> Connection: close
> ]
> 29.01.2011 21:13:46
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler
> process
> FINE: IOException reading request
> java.io.IOException: Error processing request. Socket is in the long
> poll state but neither Servlet 3.0+ async or Comet is being used
> at
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:379)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1569)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
>
>
> If I remove the check added in r1063366, the test runs successfully:
>
> Index: java/org/apache/coyote/http11/Http11NioProtocol.java
> ===
> --- java/org/apache/coyote/http11/Http11NioProtocol.java (revision
> 1065026)
> +++ java/org/apache/coyote/http11/Http11NioProtocol.java (working copy)
> @@ -374,10 +374,7 @@
> // complete or dispatch)
> state = processor.asyncPostProcess();
> } else {
> -// Error condition. A connection in this state should
> -// by using one of async or comet
> -throw new IOException(sm.getString(
> -"http11protocol.state.long.error"));
> +socket.getPoller().add(socket);
> }
> }
> if (state == SocketState.LONG || state ==
> SocketState.ASYNC_END) {
>
>
> [1] http://svn.apache.org/viewvc?view=revision&revision=1063366
> [2] http://ci.apache.org/builders/tserver-trunk
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: RemoteIpValve advices
> I'd certainly like to see some more information on this usage. With more > info we can figure out what solution makes the most sense. Anything we > can do to make Beanstalk easier to use is good although I would prefer > to keep it generic if we can. Amazon - if you're reading this - your > input to this discussion (or any other feedback) is welcome. Here's a dump from a basic Dump servlet, URL was : http://exoide.elasticbeanstalk.com/Dump --- getAuthType=null getCharacterEncoding=null getContentLength=-1 getContextPath= getLocalAddr=127.0.0.1 getLocalName=localhost getLocalPort=8080 getMethod=GET getPathInfo=null getPathTranslated=null getProtocol=HTTP/1.1 getRequestURI=/Dump getQueryString=null getRemoteAddr=127.0.0.1 getRemoteHost=127.0.0.1 getRemotePort=59657 getRemoteUser=null getRequestedSessionId=null getRequestURI=/Dump getRequestURL=http://localhost:8080/Dump getScheme=http getServerName=localhost getServerPort=8080 getServletPath=/Dump headers= host: localhost:8080 accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 accept-encoding: gzip,deflate,sdch accept-language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4 cookie: _chartbeat2=jf6k6glwwlc9huuy user-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_6; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.237 Safari/534.10 x-forwarded-for: 1.2.3.4, 10.122.47.36 x-forwarded-port: 80 x-forwarded-proto: http x-forwarded-host: exoide.elasticbeanstalk.com x-forwarded-server: domU-12-31-38-00-B2-08.compute-1.internal connection: Keep-Alive Notice x-forwarded-host, x-forwarded-port and x-forwarded-for remoteAddr/Host should be grabbed from first entry in x-forwarded-for, ie 1.2.3.4 serverName/serverPort get from x-forwarded-host/x-forwarded-port - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1065091 - in /tomcat/trunk/java/org/apache/coyote/http11: Http11NioProtocol.java LocalStrings.properties
Author: markt
Date: Sat Jan 29 19:27:07 2011
New Revision: 1065091
URL: http://svn.apache.org/viewvc?rev=1065091&view=rev
Log:
Fix breaking tests after recent comet fixes
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java?rev=1065091&r1=1065090&r2=1065091&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java Sat Jan
29 19:27:07 2011
@@ -17,7 +17,6 @@
package org.apache.coyote.http11;
-import java.io.IOException;
import java.nio.channels.SelectionKey;
import java.nio.channels.SocketChannel;
import java.security.AccessController;
@@ -361,23 +360,23 @@ public class Http11NioProtocol extends A
// socket associated with the processor.
connections.put(socket, processor);
-if (processor.comet) {
-// May receive more data from client
-SelectionKey key =
socket.getIOChannel().keyFor(socket.getPoller().getSelector());
-NioEndpoint.KeyAttachment att =
(NioEndpoint.KeyAttachment)socket.getAttachment(false);
-key.interestOps(SelectionKey.OP_READ);
-att.interestOps(SelectionKey.OP_READ);
-} else if (processor.isAsync()) {
+if (processor.isAsync()) {
NioEndpoint.KeyAttachment att =
(NioEndpoint.KeyAttachment)socket.getAttachment(false);
att.setAsync(true);
// longPoll may change socket state (e.g. to trigger a
// complete or dispatch)
state = processor.asyncPostProcess();
} else {
-// Error condition. A connection in this state should
-// by using one of async or comet
-throw new IOException(sm.getString(
-"http11protocol.state.long.error"));
+// Either:
+// - this is comet request
+// - the request line/headers have not been completely
+//read
+SelectionKey key = socket.getIOChannel().keyFor(
+socket.getPoller().getSelector());
+NioEndpoint.KeyAttachment att =
+
(NioEndpoint.KeyAttachment)socket.getAttachment(false);
+key.interestOps(SelectionKey.OP_READ);
+att.interestOps(SelectionKey.OP_READ);
}
}
if (state == SocketState.LONG || state ==
SocketState.ASYNC_END) {
Modified: tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties?rev=1065091&r1=1065090&r2=1065091&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties Sat Jan
29 19:27:07 2011
@@ -20,7 +20,6 @@ http11protocol.proto.ioexception.info=IO
http11protocol.proto.socketexception.debug=SocketException reading request
http11protocol.proto.socketexception.info=SocketException reading request,
ignored
http11protocol.start=Starting Coyote HTTP/1.1 on {0}
-http11protocol.state.long.error=Error processing request. Socket is in the
long poll state but neither Servlet 3.0+ async or Comet is being used
http11processor.regexp.error=Error parsing regular expression {0}
http11processor.filter.unknown=Unknown filter {0}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Failure of TestFormAuthenticator with NIO in trunk
2011/1/29 Mark Thomas : > On 29/01/2011 18:48, Konstantin Kolinko wrote: >> Hi! >> >> In r1063366 [1] there was a check added to Nttp11NioProtocol class that >> now causes 3 of 5 tests in TestFormAuthenticator to fail with Nio connector. > > That'll be my fault. I'll revisit that patch. > OK. Your fix in r1065091 fixed it. All is green now. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50689] New: FormAuthenticator does not respond property to 'Expect: 100-Continue' header
https://issues.apache.org/bugzilla/show_bug.cgi?id=50689 Summary: FormAuthenticator does not respond property to 'Expect: 100-Continue' header Product: Tomcat 6 Version: 6.0.20 Platform: PC Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: rich...@kennardconsulting.com Hi guys, First, thank you for creating Tomcat! I've used it over and over again for more than a decade and it's been a wonderful help to me. I've been tracking a bug in my app which seemed like a bug in HttpClient and now (according to the HttpClient guys) appears to be a bug in Tomcat. Details of the bug, including analysis and test case, attached here: https://issues.apache.org/jira/browse/HTTPCLIENT-1048 Essentially if FormAuthenticator receives an HTTP request containing a 'Expect: 100-Continue' header, it is meant to respond with either a 100 or a 417 in order to request the body of the request. But instead, Tomcat is not responding at all. Luckily a 'fallback' use case of the spec is that the client should wait, say, 2 seconds then send the body anyway. The result is that logging in takes much longer (2 longers versus 10ms) than expected, which can be a problem for people doing automated testing against FormAuthenticator. Note the issue may affect use cases beyond FormAuthenticator too. Regards, Richard. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50689] FormAuthenticator does not respond property to 'Expect: 100-Continue' header
https://issues.apache.org/bugzilla/show_bug.cgi?id=50689 Richard Kennard changed: What|Removed |Added CC||richard@kennardconsulting.c ||om OS/Version||All -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50689] FormAuthenticator does not respond property to 'Expect: 100-Continue' header
https://issues.apache.org/bugzilla/show_bug.cgi?id=50689 --- Comment #1 from Konstantin Kolinko 2011-01-29 16:21:20 EST --- Reproducible with the current 6.0.x with Bio and Nio HTTP connectors. Does not happen with the current trunk with Bio and Nio HTTP connectors. Does not happen with the 7.0.6 with Bio, Nio and APR HTTP connectors. The relevant test was added to TC7 testsuite in r987948 So, it looks like backporting r987948 is the way to go. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50689] FormAuthenticator does not respond property to 'Expect: 100-Continue' header
https://issues.apache.org/bugzilla/show_bug.cgi?id=50689 --- Comment #2 from Konstantin Kolinko 2011-01-29 16:51:26 EST --- Created an attachment (id=26576) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26576) 2011-01-30_tc6_50689.patch Patch for tc6.0.x. It is backport of r987948. Confirming that it fixes the issue. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: r1065119 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Sat Jan 29 21:54:53 2011 New Revision: 1065119 URL: http://svn.apache.org/viewvc?rev=1065119&view=rev Log: proposal 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=1065119&r1=1065118&r2=1065119&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Sat Jan 29 21:54:53 2011 @@ -106,3 +106,11 @@ PATCHES PROPOSED TO BACKPORT: http://svn.apache.org/viewvc?rev=1064652&view=rev +1: markt -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50689 + Provide 100 Continue responses at appropriate points during FORM + authentication if client indicates that they are expected. + (It is backport of r987948.) + https://issues.apache.org/bugzilla/attachment.cgi?id=26576 + +1: kkolinko + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1065120 - /tomcat/trunk/webapps/docs/changelog.xml
Author: kkolinko Date: Sat Jan 29 21:57:32 2011 New Revision: 1065120 URL: http://svn.apache.org/viewvc?rev=1065120&view=rev Log: Add bug number to an already fixed issue. Arrange issues in ascending numeric order. Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1065120&r1=1065119&r2=1065120&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Sat Jan 29 21:57:32 2011 @@ -1090,6 +1090,10 @@ enable GZIP compressed output streams to be flushed. Based on a patch provided by Jiong Wang. (markt) + +48967: Replace strings "catalina.base" and "catalina.home" +by globally defined constants. Patch provided by Marc Guillemot. (rjung) + 49195: Don't report an error when shutting down a Windows service for a Tomcat instance that has a disabled shutdown port. (markt) @@ -1149,10 +1153,6 @@ provided by Gábor. (markt) -Provide 100 Continue responses at appropriate points during FORM -authentication if client indicates that they are expected. (markt) - - 49779: Improve handling of POST requests and FORM authentication, particularly when the user agent responds to the 302 response by repeating the POST request including a request body. Any @@ -1172,10 +1172,6 @@ is being destroyed, the destroy method is only called once on each child component. (markt) - -48967: Replace strings "catalina.base" and "catalina.home" -by globally defined constants. Patch provided by Marc Guillemot. (rjung) - Keep the MBean names for web applications consistent between Tomcat 6 and Tomcat 7. (markt) @@ -1247,6 +1243,11 @@ current servlet-mappings that map the default servlet to a subpath. (timw) + +50689: Provide 100 Continue responses at appropriate points +during FORM authentication if client indicates that they are expected. +(markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
