Re: tomcat bad encoding
On 10/07/2012 18:03, Thushara Wijeratna wrote: > Is it possible to have tomcat treat bad URI encodings leniently? No. Sorry. > It > currently modifies a buffer in place and if a % sign is followed by > anything other than 2 hexadecimal characters, it gives up decoding and > throws an exception. But if this method was changed to a lenient decoding, > then the buffer would not be corrupt and can be returned to caller. In that scenario the URI would not be decoded properly and therefore would be incomplete so there is no guarantee that it would be correctly mapped. > We get bad encodings due to various truncation issues so it is very helpful > if we can get a lenient decoding. > > Please let me know if this is something that could be looked at. I'd > volunteer dev / test time to get this in the code. You'd be better of fixing the truncation issues. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1360047 - /tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml
Author: markt Date: Wed Jul 11 08:08:43 2012 New Revision: 1360047 URL: http://svn.apache.org/viewvc?rev=1360047&view=rev Log: Add recently applied patches. Modified: tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml Modified: tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml?rev=1360047&r1=1360046&r2=1360047&view=diff == --- tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml (original) +++ tomcat/tc5.5.x/trunk/container/webapps/docs/changelog.xml Wed Jul 11 08:08:43 2012 @@ -53,6 +53,19 @@ 52677: The new SetCharacterEncodingFilter needs to implement Filter to be useful. (markt) + +53050: Fix XOR arithmetics and charset issue when calculating +entropy to initialize random numbers generator in session manager. Based +on a proposal by Andras Rozsa. (kkolinko/jim) + + + + + + +Ensure that the chunked input filter is correctly recycled between +requests. (kkolinko/jim) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1359751 - in /tomcat/tc5.5.x/trunk: STATUS.txt container/catalina/src/share/org/apache/catalina/session/ManagerBase.java
On 10/07/2012 17:12, j...@apache.org wrote: > Author: jim > Date: Tue Jul 10 16:12:46 2012 > New Revision: 1359751 > > URL: http://svn.apache.org/viewvc?rev=1359751&view=rev > Log: > * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53050 > Fix XOR arithmetics and charset issue when calculating entropy to > initialize random numbers generator in session manager. Based on > proposal by Andras Rozsa. > https://issues.apache.org/bugzilla/attachment.cgi?id=28895 > +1: kkolinko, schultz, jim > -1: Jim, When applying approved patches please remember to update the changelog. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1360059 - in /tomcat/trunk: java/org/apache/catalina/connector/Response.java test/org/apache/catalina/connector/TestResponse.java
Author: markt
Date: Wed Jul 11 08:26:26 2012
New Revision: 1360059
URL: http://svn.apache.org/viewvc?rev=1360059&view=rev
Log:
Handle fragments as well as query strings in normalisation of redirects
Modified:
tomcat/trunk/java/org/apache/catalina/connector/Response.java
tomcat/trunk/test/org/apache/catalina/connector/TestResponse.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/Response.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Response.java?rev=1360059&r1=1360058&r2=1360059&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Response.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Response.java Wed Jul 11
08:26:26 2012
@@ -27,6 +27,7 @@ import java.security.PrivilegedActionExc
import java.security.PrivilegedExceptionAction;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
+import java.util.Arrays;
import java.util.Collection;
import java.util.Enumeration;
import java.util.List;
@@ -1654,16 +1655,17 @@ public class Response
* Code borrowed heavily from CoyoteAdapter.normalize()
*/
private void normalize(CharChunk cc) {
-// Strip query string first (doing it this way makes the logic a lot
-// simpler)
-int query = cc.indexOf('?');
-char[] queryCC = null;
-if (query > -1) {
-queryCC = new char[cc.getEnd() - query];
-for (int i = query; i < cc.getEnd(); i++) {
-queryCC[i - query] = cc.charAt(i);
-}
-cc.setEnd(query);
+// Strip query string and/or fragment first as doing it this way makes
+// the normalization logic a lot simpler
+int truncate = cc.indexOf('?');
+if (truncate == -1) {
+truncate = cc.indexOf('#');
+}
+char[] truncateCC = null;
+if (truncate > -1) {
+truncateCC = Arrays.copyOfRange(cc.getBuffer(),
+cc.getStart() + truncate, cc.getEnd());
+cc.setEnd(cc.getStart() + truncate);
}
if (cc.endsWith("/.") || cc.endsWith("/..")) {
@@ -1726,9 +1728,9 @@ public class Response
}
// Add the query string (if present) back in
-if (queryCC != null) {
+if (truncateCC != null) {
try {
-cc.append(queryCC, 0, queryCC.length);
+cc.append(truncateCC, 0, truncateCC.length);
} catch (IOException ioe) {
throw new IllegalArgumentException(ioe);
}
Modified: tomcat/trunk/test/org/apache/catalina/connector/TestResponse.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestResponse.java?rev=1360059&r1=1360058&r2=1360059&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/connector/TestResponse.java (original)
+++ tomcat/trunk/test/org/apache/catalina/connector/TestResponse.java Wed Jul
11 08:26:26 2012
@@ -271,8 +271,7 @@ public class TestResponse extends Tomcat
String result = resp.toAbsolute("./.?x=/../../");
Assert.assertEquals(
-"http://localhost:8080/level1/level2/?x=/../../";,
-result);
+"http://localhost:8080/level1/level2/?x=/../../";, result);
}
@@ -284,9 +283,7 @@ public class TestResponse extends Tomcat
String result = resp.toAbsolute("./..?x=/../../");
-Assert.assertEquals(
-"http://localhost:8080/level1/?x=/../../";,
-result);
+Assert.assertEquals("http://localhost:8080/level1/?x=/../../";, result);
}
@@ -304,6 +301,69 @@ public class TestResponse extends Tomcat
}
+@Test
+public void testBug53062l() throws Exception {
+Request req = new TesterMockRequest();
+Response resp = new Response();
+resp.setRequest(req);
+
+String result = resp.toAbsolute("bar.html#/../");
+
+Assert.assertEquals(
+"http://localhost:8080/level1/level2/bar.html#/../";, result);
+}
+
+
+@Test
+public void testBug53062m() throws Exception {
+Request req = new TesterMockRequest();
+Response resp = new Response();
+resp.setRequest(req);
+
+String result = resp.toAbsolute("bar.html#/../../");
+
+Assert.assertEquals(
+"http://localhost:8080/level1/level2/bar.html#/../../";,
result);
+}
+
+
+@Test
+public void testBug53062n() throws Exception {
+Request req = new TesterMockRequest();
+Response resp = new Response();
+resp.setRequest(req);
+
+String result = resp.toAbsolute("./.#/../../");
+
+Assert.assertEquals(
+"http://localhost:8080/level1/level2/#/../../";, result);
+}
+
+
+@Test
+public void tes
svn commit: r1360060 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/connector/Response.java test/org/apache/catalina/connector/TestResponse.java webapps/docs/changelog.xml
Author: markt
Date: Wed Jul 11 08:27:31 2012
New Revision: 1360060
URL: http://svn.apache.org/viewvc?rev=1360060&view=rev
Log:
Handle fragments as well as query strings in normalisation of redirects
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Response.java
tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestResponse.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1360059
Modified: tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Response.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Response.java?rev=1360060&r1=1360059&r2=1360060&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Response.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/Response.java Wed
Jul 11 08:27:31 2012
@@ -28,6 +28,7 @@ import java.security.PrivilegedActionExc
import java.security.PrivilegedExceptionAction;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
+import java.util.Arrays;
import java.util.Collection;
import java.util.Enumeration;
import java.util.List;
@@ -1752,16 +1753,17 @@ public class Response
* Code borrowed heavily from CoyoteAdapter.normalize()
*/
private void normalize(CharChunk cc) {
-// Strip query string first (doing it this way makes the logic a lot
-// simpler)
-int query = cc.indexOf('?');
-char[] queryCC = null;
-if (query > -1) {
-queryCC = new char[cc.getEnd() - query];
-for (int i = query; i < cc.getEnd(); i++) {
-queryCC[i - query] = cc.charAt(i);
-}
-cc.setEnd(query);
+// Strip query string and/or fragment first as doing it this way makes
+// the normalization logic a lot simpler
+int truncate = cc.indexOf('?');
+if (truncate == -1) {
+truncate = cc.indexOf('#');
+}
+char[] truncateCC = null;
+if (truncate > -1) {
+truncateCC = Arrays.copyOfRange(cc.getBuffer(),
+cc.getStart() + truncate, cc.getEnd());
+cc.setEnd(cc.getStart() + truncate);
}
if (cc.endsWith("/.") || cc.endsWith("/..")) {
@@ -1824,9 +1826,9 @@ public class Response
}
// Add the query string (if present) back in
-if (queryCC != null) {
+if (truncateCC != null) {
try {
-cc.append(queryCC, 0, queryCC.length);
+cc.append(truncateCC, 0, truncateCC.length);
} catch (IOException ioe) {
throw new IllegalArgumentException(ioe);
}
Modified:
tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestResponse.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestResponse.java?rev=1360060&r1=1360059&r2=1360060&view=diff
==
--- tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestResponse.java
(original)
+++ tomcat/tc7.0.x/trunk/test/org/apache/catalina/connector/TestResponse.java
Wed Jul 11 08:27:31 2012
@@ -271,8 +271,7 @@ public class TestResponse extends Tomcat
String result = resp.toAbsolute("./.?x=/../../");
Assert.assertEquals(
-"http://localhost:8080/level1/level2/?x=/../../";,
-result);
+"http://localhost:8080/level1/level2/?x=/../../";, result);
}
@@ -284,9 +283,7 @@ public class TestResponse extends Tomcat
String result = resp.toAbsolute("./..?x=/../../");
-Assert.assertEquals(
-"http://localhost:8080/level1/?x=/../../";,
-result);
+Assert.assertEquals("http://localhost:8080/level1/?x=/../../";, result);
}
@@ -304,6 +301,69 @@ public class TestResponse extends Tomcat
}
+@Test
+public void testBug53062l() throws Exception {
+Request req = new TesterMockRequest();
+Response resp = new Response();
+resp.setRequest(req);
+
+String result = resp.toAbsolute("bar.html#/../");
+
+Assert.assertEquals(
+"http://localhost:8080/level1/level2/bar.html#/../";, result);
+}
+
+
+@Test
+public void testBug53062m() throws Exception {
+Request req = new TesterMockRequest();
+Response resp = new Response();
+resp.setRequest(req);
+
+String result = resp.toAbsolute("bar.html#/../../");
+
+Assert.assertEquals(
+"http://localhost:8080/level1/level2/bar.html#/../../";,
result);
+}
+
+
+@Test
+public void testBug53062n() throws Exception {
+
Re: Unit tests and trunk
On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote:
> Here's what I've found out so far
>
> The patch below does solve the problem. In a rather remarkable way.
> The line
> int cnt = socket.write(buf); //write the data
>
> never returns 0, meaning the writes are always blocking. Even though they
> are not supposed to be.
> Remove this patch, and socket.write(buf) returns 0, and then we never get
> issued the OP_WRITE from the selector itself.
I'm not sure I follow the above. Remove the patch and it returns 0?
Regardless, it seems very strange that the patch below fixes it. I had a
quick look through the Java source and couldn't see anything immediately
obvious. Any ideas what is going on?
Mark
>
> Index: java/org/apache/tomcat/util/net/NioBlockingSelector.java
> ===
> --- java/org/apache/tomcat/util/net/NioBlockingSelector.java(revision
> 1359329)
> +++ java/org/apache/tomcat/util/net/NioBlockingSelector.java(working
> copy)
> @@ -89,6 +89,12 @@
> int keycount = 1; //assume we can write
> long time = System.currentTimeMillis(); //start the timeout timer
> try {
> +
> +synchronized (Selector.class) {
> +Selector s = Selector.open();
> +s.close();
> +}
> +
> while ( (!timedout) && buf.hasRemaining()) {
> if (keycount > 0) { //only write if we were registered for
> a write
> int cnt = socket.write(buf); //write the data
>
>> -Original Message-
>> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
>> Sent: Tuesday, July 10, 2012 10:43 AM
>> To: 'Tomcat Developers List'
>> Subject: RE: Unit tests and trunk
>>
>> Ok, definitely a bug in Java 7/Windows 7.
>> If I turn on ProcMon from sysinternals to try to figure out what is
>> going
>> on, the test succeeds everytime. Shutdown procmon, and it hangs again.
>> The
>> Selector is not registering the OP_WRITE event
>>
>> Filip
>>
>>
>>> -Original Message-
>>> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
>>> Sent: Monday, July 09, 2012 2:31 PM
>>> To: 'Tomcat Developers List'
>>> Subject: RE: Unit tests and trunk
>>>
>>> This failure happens when the write blocks, and we enter the Selector
>>> for a
>>> write operation.
>>>
>>> filip
>>>
-Original Message-
From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
Sent: Monday, July 09, 2012 2:23 PM
To: 'Tomcat Developers List'
Subject: RE: Unit tests and trunk
I'm on Windows 7 and see TestOutputBuffer fail inconsistently with
>>> Java
7
Most runs are failures.
I'll be looking into this this week
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Monday, July 09, 2012 4:33 AM
> To: Tomcat Developers List
> Subject: Unit tests and trunk
>
> With the fixes over the weekend for setting traffic class, I now
>> see
the
> unit tests passing consistently for:
>
> Windows: BIO, NIO, APR
> Linux: BIO, NIO
>
> I do see a consistent failure for Linux and APR with the Comet
>>> tests.
It
> is the connector stop test failing (the one that was failing in
buildbot
> previously with NIO). I'll take a look at this today.
>
> Mark
>
> --
>> --
>>> -
> 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
>>>
>>>
>>>
>>> -
>>> 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
>
>
>
> -
> 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
[Bug 53535] New: Out of memory while performing ContextConfig.webConfig
https://issues.apache.org/bugzilla/show_bug.cgi?id=53535 Priority: P2 Bug ID: 53535 Assignee: dev@tomcat.apache.org Summary: Out of memory while performing ContextConfig.webConfig Severity: normal Classification: Unclassified OS: All Reporter: c_ig...@yahoo.co.uk Hardware: All Status: NEW Version: unspecified Component: Catalina Product: Tomcat 7 Created attachment 29047 --> https://issues.apache.org/bugzilla/attachment.cgi?id=29047&action=edit Suggested solution to improve ContextConfig JavaClassCacheEntry objects are using too much memory causing eventually (all kinds of) out of memory errors during container startup. There is no need to save whole JavaClass in cache since only superclass name and interface names are needed in later processing. Suggested solution is attached. -- 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: Unit tests and trunk
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Wednesday, July 11, 2012 2:45 AM
> To: Tomcat Developers List
> Subject: Re: Unit tests and trunk
>
> On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote:
> > Here's what I've found out so far
> >
> > The patch below does solve the problem. In a rather remarkable way.
> > The line
> > int cnt = socket.write(buf); //write the data
> >
> > never returns 0, meaning the writes are always blocking. Even though
> they
> > are not supposed to be.
> > Remove this patch, and socket.write(buf) returns 0, and then we never
> get
> > issued the OP_WRITE from the selector itself.
>
> I'm not sure I follow the above. Remove the patch and it returns 0?
[Filip Hanik]
Correct, as it should. The buffer should fill up very quick, and when the
buffer is full NIO returns 0, can't write.
So there are two problems:
a) The selector doesn't work the same in Java 7 as it does in Java 5 and 6
b) Starting a new selector turns non blocking writes into blocking, even
when I write 10MB in the TestOutputBuffer test, there is not a single
socket.write that returns 0. Removing the Selector.open call, and
immediately we have a hit return 0 as expected.
>
> Regardless, it seems very strange that the patch below fixes it. I had a
> quick look through the Java source and couldn't see anything immediately
> obvious. Any ideas what is going on?
[Filip Hanik]
Can't think of anything but a bug in the JDK. I'll keep investigating.
Possibly we have to move the async NIO stuff to get it to work
>
> Mark
>
> >
> > Index: java/org/apache/tomcat/util/net/NioBlockingSelector.java
> > ===
> > --- java/org/apache/tomcat/util/net/NioBlockingSelector.java
> (revision
> > 1359329)
> > +++ java/org/apache/tomcat/util/net/NioBlockingSelector.java
> (working
> > copy)
> > @@ -89,6 +89,12 @@
> > int keycount = 1; //assume we can write
> > long time = System.currentTimeMillis(); //start the timeout
> timer
> > try {
> > +
> > +synchronized (Selector.class) {
> > +Selector s = Selector.open();
> > +s.close();
> > +}
> > +
> > while ( (!timedout) && buf.hasRemaining()) {
> > if (keycount > 0) { //only write if we were
> registered for
> > a write
> > int cnt = socket.write(buf); //write the data
> >
> >> -Original Message-
> >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> >> Sent: Tuesday, July 10, 2012 10:43 AM
> >> To: 'Tomcat Developers List'
> >> Subject: RE: Unit tests and trunk
> >>
> >> Ok, definitely a bug in Java 7/Windows 7.
> >> If I turn on ProcMon from sysinternals to try to figure out what is
> >> going
> >> on, the test succeeds everytime. Shutdown procmon, and it hangs
> again.
> >> The
> >> Selector is not registering the OP_WRITE event
> >>
> >> Filip
> >>
> >>
> >>> -Original Message-
> >>> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> >>> Sent: Monday, July 09, 2012 2:31 PM
> >>> To: 'Tomcat Developers List'
> >>> Subject: RE: Unit tests and trunk
> >>>
> >>> This failure happens when the write blocks, and we enter the
> Selector
> >>> for a
> >>> write operation.
> >>>
> >>> filip
> >>>
> -Original Message-
> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> Sent: Monday, July 09, 2012 2:23 PM
> To: 'Tomcat Developers List'
> Subject: RE: Unit tests and trunk
>
> I'm on Windows 7 and see TestOutputBuffer fail inconsistently with
> >>> Java
> 7
> Most runs are failures.
>
> I'll be looking into this this week
>
> > -Original Message-
> > From: Mark Thomas [mailto:ma...@apache.org]
> > Sent: Monday, July 09, 2012 4:33 AM
> > To: Tomcat Developers List
> > Subject: Unit tests and trunk
> >
> > With the fixes over the weekend for setting traffic class, I now
> >> see
> the
> > unit tests passing consistently for:
> >
> > Windows: BIO, NIO, APR
> > Linux: BIO, NIO
> >
> > I do see a consistent failure for Linux and APR with the Comet
> >>> tests.
> It
> > is the connector stop test failing (the one that was failing in
> buildbot
> > previously with NIO). I'll take a look at this today.
> >
> > Mark
> >
> > --
> >> --
> >>> -
> > 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
> >>>
> >>>
> >>>
> >>> -
[Bug 53535] Out of memory while performing ContextConfig.webConfig
https://issues.apache.org/bugzilla/show_bug.cgi?id=53535 --- Comment #1 from Mark Thomas --- Looks like a sensible improvement to me. Can you provide the patch in diff -u format to save me unpicking it please. -- 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 53513] Race condition / out of order operation in session replication at node startup
https://issues.apache.org/bugzilla/show_bug.cgi?id=53513 Mark Thomas changed: What|Removed |Added Component|Cluster |Cluster Version|7.0.26 |6.0.35 Product|Tomcat 7|Tomcat 6 Target Milestone|--- |default --- Comment #4 from Mark Thomas --- Moving to Tomcat 6 since it has been fixed in 7. -- 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: Unit tests and trunk
> -Original Message-
> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> Sent: Wednesday, July 11, 2012 10:13 AM
> To: 'Tomcat Developers List'
> Subject: RE: Unit tests and trunk
>
>
>
> > -Original Message-
> > From: Mark Thomas [mailto:ma...@apache.org]
> > Sent: Wednesday, July 11, 2012 2:45 AM
> > To: Tomcat Developers List
> > Subject: Re: Unit tests and trunk
> >
> > On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote:
> > > Here's what I've found out so far
> > >
> > > The patch below does solve the problem. In a rather remarkable way.
> > > The line
> > > int cnt = socket.write(buf); //write the data
> > >
> > > never returns 0, meaning the writes are always blocking. Even though
> > they
> > > are not supposed to be.
> > > Remove this patch, and socket.write(buf) returns 0, and then we
> never
> > get
> > > issued the OP_WRITE from the selector itself.
> >
> > I'm not sure I follow the above. Remove the patch and it returns 0?
> [Filip Hanik]
> Correct, as it should. The buffer should fill up very quick, and when
> the
> buffer is full NIO returns 0, can't write.
> So there are two problems:
> a) The selector doesn't work the same in Java 7 as it does in Java 5 and
> 6
> b) Starting a new selector turns non blocking writes into blocking, even
> when I write 10MB in the TestOutputBuffer test, there is not a single
> socket.write that returns 0. Removing the Selector.open call, and
> immediately we have a hit return 0 as expected.
>
>
> >
> > Regardless, it seems very strange that the patch below fixes it. I had
> a
> > quick look through the Java source and couldn't see anything
> immediately
> > obvious. Any ideas what is going on?
> [Filip Hanik]
> Can't think of anything but a bug in the JDK. I'll keep investigating.
> Possibly we have to move the async NIO stuff to get it to work
[Filip Hanik]
Btw, this affects the BIO connector too. The write blocks and hangs forever.
Maybe it's just my Windows 7 system. Works fine on linux.
>
> >
> > Mark
> >
> > >
> > > Index: java/org/apache/tomcat/util/net/NioBlockingSelector.java
> > > ===
> > > --- java/org/apache/tomcat/util/net/NioBlockingSelector.java
> > (revision
> > > 1359329)
> > > +++ java/org/apache/tomcat/util/net/NioBlockingSelector.java
> > (working
> > > copy)
> > > @@ -89,6 +89,12 @@
> > > int keycount = 1; //assume we can write
> > > long time = System.currentTimeMillis(); //start the timeout
> > timer
> > > try {
> > > +
> > > +synchronized (Selector.class) {
> > > +Selector s = Selector.open();
> > > +s.close();
> > > +}
> > > +
> > > while ( (!timedout) && buf.hasRemaining()) {
> > > if (keycount > 0) { //only write if we were
> > registered for
> > > a write
> > > int cnt = socket.write(buf); //write the data
> > >
> > >> -Original Message-
> > >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> > >> Sent: Tuesday, July 10, 2012 10:43 AM
> > >> To: 'Tomcat Developers List'
> > >> Subject: RE: Unit tests and trunk
> > >>
> > >> Ok, definitely a bug in Java 7/Windows 7.
> > >> If I turn on ProcMon from sysinternals to try to figure out what is
> > >> going
> > >> on, the test succeeds everytime. Shutdown procmon, and it hangs
> > again.
> > >> The
> > >> Selector is not registering the OP_WRITE event
> > >>
> > >> Filip
> > >>
> > >>
> > >>> -Original Message-
> > >>> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> > >>> Sent: Monday, July 09, 2012 2:31 PM
> > >>> To: 'Tomcat Developers List'
> > >>> Subject: RE: Unit tests and trunk
> > >>>
> > >>> This failure happens when the write blocks, and we enter the
> > Selector
> > >>> for a
> > >>> write operation.
> > >>>
> > >>> filip
> > >>>
> > -Original Message-
> > From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com]
> > Sent: Monday, July 09, 2012 2:23 PM
> > To: 'Tomcat Developers List'
> > Subject: RE: Unit tests and trunk
> >
> > I'm on Windows 7 and see TestOutputBuffer fail inconsistently
> with
> > >>> Java
> > 7
> > Most runs are failures.
> >
> > I'll be looking into this this week
> >
> > > -Original Message-
> > > From: Mark Thomas [mailto:ma...@apache.org]
> > > Sent: Monday, July 09, 2012 4:33 AM
> > > To: Tomcat Developers List
> > > Subject: Unit tests and trunk
> > >
> > > With the fixes over the weekend for setting traffic class, I now
> > >> see
> > the
> > > unit tests passing consistently for:
> > >
> > > Windows: BIO, NIO, APR
> > > Linux: BIO, NIO
> > >
> > > I do see a consistent failure for Linux and APR with the Comet
> > >>> tests.
> > It
> > > is the connector stop test failing (the one that was failing in
> > buildbot
> >
svn commit: r1360358 - /tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java
Author: fhanik
Date: Wed Jul 11 19:16:10 2012
New Revision: 1360358
URL: http://svn.apache.org/viewvc?rev=1360358&view=rev
Log:
Add a test file unit test case. This test case fails with both NIO and BIO on
Windows 7 with JDK 1.7
Added:
tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java (with
props)
Added: tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java?rev=1360358&view=auto
==
--- tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java (added)
+++ tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java Wed Jul
11 19:16:10 2012
@@ -0,0 +1,145 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina.connector;
+
+import static org.junit.Assert.assertEquals;
+
+import java.io.BufferedInputStream;
+import java.io.BufferedReader;
+import java.io.BufferedWriter;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileReader;
+import java.io.FileWriter;
+import java.io.IOException;
+import java.util.Arrays;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+
+import javax.servlet.ServletException;
+import javax.servlet.http.HttpServlet;
+import javax.servlet.http.HttpServletRequest;
+import javax.servlet.http.HttpServletResponse;
+
+import org.apache.catalina.Context;
+import org.apache.catalina.Globals;
+import org.apache.catalina.startup.Tomcat;
+import org.apache.catalina.startup.TomcatBaseTest;
+import org.apache.tomcat.util.buf.ByteChunk;
+import org.junit.Test;
+
+public class TestSendFile extends TomcatBaseTest{
+
+public static final int ITERATIONS = 10;
+public static final int EXPECTED_CONTENT_LENGTH = 10;
+
+@Test
+public void testSendFile() throws Exception {
+Tomcat tomcat = getTomcatInstance();
+
+Context root = tomcat.addContext("", TEMP_DIR);
+
+File[] files = new File[ITERATIONS];
+for (int i=0; i> respHeaders = new HashMap>();
+for (int i=0; ihttp://localhost:"; + getPort() + "/servlet" + i,
bc, null, respHeaders);
+assertEquals(HttpServletResponse.SC_OK, rc);
+System.out.println("Client received "+bc.getLength() + " bytes in
"+(System.currentTimeMillis()-start)+" ms.");
+assertEquals(EXPECTED_CONTENT_LENGTH * (i+1), bc.getLength());
+
+bc.recycle();
+}
+}
+
+public File generateFile(String dir, int size) throws IOException {
+String name = "testSendFile-"+System.currentTimeMillis()+".txt";
+File f = new File(dir,name);
+FileWriter fw = new FileWriter(f, false);
+BufferedWriter w = new BufferedWriter(fw);
+int defSize = 8192;
+while (size > 0) {
+int bytes = Math.min(size, defSize);
+char[] b = new char[bytes];
+Arrays.fill(b, 'X');
+w.write(b);
+size = size - bytes;
+}
+w.flush();
+w.close();
+return f;
+
+}
+
+
+private static class WritingServlet extends HttpServlet {
+
+private static final long serialVersionUID = 1L;
+
+private final File f;
+
+public WritingServlet(File f) {
+this.f = f;
+}
+
+@Override
+protected void doGet(HttpServletRequest req, HttpServletResponse resp)
+throws ServletException, IOException {
+
+
+
+resp.setContentType("'application/octet-stream");
+resp.setCharacterEncoding("ISO-8859-1");
+resp.setContentLengthLong(f.length());
+if (req.getAttribute(Globals.SENDFILE_SUPPORTED_ATTR) ==
Boolean.TRUE) {
+req.setAttribute(Globals.SENDFILE_FILENAME_ATTR,
f.getAbsolutePath());
+req.setAttribute(Globals.SENDFILE_FILE_START_ATTR, new
Long(0));
+req.setAttribute(Globals.SENDFILE_FILE_END_ATTR, new
Long(f.length()));
+} else {
+byte[] c = new byte[8192];
+BufferedInputStream in = new BufferedInputStream(new
FileInputStream(f));
+
svn commit: r1360359 - /tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java
Author: fhanik Date: Wed Jul 11 19:16:31 2012 New Revision: 1360359 URL: http://svn.apache.org/viewvc?rev=1360359&view=rev Log: remove unused imports Modified: tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java Modified: tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java URL: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java?rev=1360359&r1=1360358&r2=1360359&view=diff == --- tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java (original) +++ tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java Wed Jul 11 19:16:31 2012 @@ -19,11 +19,9 @@ package org.apache.catalina.connector; import static org.junit.Assert.assertEquals; import java.io.BufferedInputStream; -import java.io.BufferedReader; import java.io.BufferedWriter; import java.io.File; import java.io.FileInputStream; -import java.io.FileReader; import java.io.FileWriter; import java.io.IOException; import java.util.Arrays; - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53531] ExpandWar.expand does not check the return value of File.mkdirs
https://issues.apache.org/bugzilla/show_bug.cgi?id=53531 Christopher Schultz changed: What|Removed |Added Attachment #29045|Patch against current trunk |Patch against current 5.5.x description|(r1359975) |trunk (r1359975) -- 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: Unit tests and trunk
On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: > > >> -Original Message- >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] >> Sent: Wednesday, July 11, 2012 10:13 AM >> To: 'Tomcat Developers List' >> Subject: RE: Unit tests and trunk >> >> >> >>> -Original Message- >>> From: Mark Thomas [mailto:ma...@apache.org] >>> Sent: Wednesday, July 11, 2012 2:45 AM >>> To: Tomcat Developers List >>> Subject: Re: Unit tests and trunk >>> >>> On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: Here's what I've found out so far The patch below does solve the problem. In a rather remarkable way. The line int cnt = socket.write(buf); //write the data never returns 0, meaning the writes are always blocking. Even though >>> they are not supposed to be. Remove this patch, and socket.write(buf) returns 0, and then we >> never >>> get issued the OP_WRITE from the selector itself. >>> >>> I'm not sure I follow the above. Remove the patch and it returns 0? >> [Filip Hanik] >> Correct, as it should. The buffer should fill up very quick, and when >> the >> buffer is full NIO returns 0, can't write. >> So there are two problems: >> a) The selector doesn't work the same in Java 7 as it does in Java 5 and >> 6 >> b) Starting a new selector turns non blocking writes into blocking, even >> when I write 10MB in the TestOutputBuffer test, there is not a single >> socket.write that returns 0. Removing the Selector.open call, and >> immediately we have a hit return 0 as expected. >> >> >>> >>> Regardless, it seems very strange that the patch below fixes it. I had >> a >>> quick look through the Java source and couldn't see anything >> immediately >>> obvious. Any ideas what is going on? >> [Filip Hanik] >> Can't think of anything but a bug in the JDK. I'll keep investigating. >> Possibly we have to move the async NIO stuff to get it to work > [Filip Hanik] > Btw, this affects the BIO connector too. The write blocks and hangs forever. > Maybe it's just my Windows 7 system. Works fine on linux. Let me see if I can find (or create if necessary) a clean-ish Windows 7 VM to test this on. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53531] ExpandWar.expand does not check the return value of File.mkdirs
https://issues.apache.org/bugzilla/show_bug.cgi?id=53531 --- Comment #3 from Christopher Schultz --- Created attachment 29050 --> https://issues.apache.org/bugzilla/attachment.cgi?id=29050&action=edit Patch for 6.0.x against r1359053 -- 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: r1360369 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: schultz Date: Wed Jul 11 19:41:14 2012 New Revision: 1360369 URL: http://svn.apache.org/viewvc?rev=1360369&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=1360369&r1=1360368&r2=1360369&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Jul 11 19:41:14 2012 @@ -144,6 +144,14 @@ PATCHES PROPOSED TO BACKPORT: +1: kfujino -1: +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53531 + ExpandWar.expand does not check the return value of File.mkdirs + Patch here: https://issues.apache.org/bugzilla/attachment.cgi?id=29050 + This is a similar fix to trunk (http://svn.apache.org/viewvc?view=revision&revision=1359981) + and also includes checking of File.mkdirs() as mentioned in the bug. + +1: schultz + -1: + PATCHES/ISSUES THAT ARE STALLED * Backport JSP unloading patch (BZ48358). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53531] ExpandWar.expand does not check the return value of File.mkdirs
https://issues.apache.org/bugzilla/show_bug.cgi?id=53531 Christopher Schultz changed: What|Removed |Added Attachment #29045|0 |1 is obsolete|| --- Comment #4 from Christopher Schultz --- Comment on attachment 29045 --> https://issues.apache.org/bugzilla/attachment.cgi?id=29045 Patch against current 5.5.x trunk (r1359975) Patch is obsolete: patch proposed for 6.0.x. -- 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 53531] ExpandWar.expand does not check the return value of File.mkdir and File.mkdirs
https://issues.apache.org/bugzilla/show_bug.cgi?id=53531 Christopher Schultz changed: What|Removed |Added Summary|ExpandWar.expand does not |ExpandWar.expand does not |check the return value of |check the return value of |File.mkdirs |File.mkdir and File.mkdirs -- 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: r1360372 - /tomcat/trunk/webapps/docs/aio.xml
Author: fhanik Date: Wed Jul 11 19:51:57 2012 New Revision: 1360372 URL: http://svn.apache.org/viewvc?rev=1360372&view=rev Log: Clarify documentation around send file Modified: tomcat/trunk/webapps/docs/aio.xml Modified: tomcat/trunk/webapps/docs/aio.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?rev=1360372&r1=1360371&r2=1360372&view=diff == --- tomcat/trunk/webapps/docs/aio.xml (original) +++ tomcat/trunk/webapps/docs/aio.xml Wed Jul 11 19:51:57 2012 @@ -343,6 +343,11 @@ public class ChatServlet org.apache.tomcat.sendfile.start: Start offset as a Long org.apache.tomcat.sendfile.end: End offset as a Long + +In addition to setting these parameters it is necessary to set the content-length header. +or set a transfer-encoding like chunked. +Tomcat will not do that for you, since you may have already written data to the + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1360393 - /tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java
Author: fhanik
Date: Wed Jul 11 20:51:13 2012
New Revision: 1360393
URL: http://svn.apache.org/viewvc?rev=1360393&view=rev
Log:
Cleanup and better file naming
Modified:
tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java
Modified: tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java?rev=1360393&r1=1360392&r2=1360393&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java (original)
+++ tomcat/trunk/test/org/apache/catalina/connector/TestSendFile.java Wed Jul
11 20:51:13 2012
@@ -48,38 +48,45 @@ public class TestSendFile extends Tomcat
@Test
public void testSendFile() throws Exception {
+
Tomcat tomcat = getTomcatInstance();
Context root = tomcat.addContext("", TEMP_DIR);
File[] files = new File[ITERATIONS];
for (int i=0; i> respHeaders = new HashMap>();
-for (int i=0; ihttp://localhost:"; + getPort() + "/servlet" + i,
bc, null, respHeaders);
-assertEquals(HttpServletResponse.SC_OK, rc);
-System.out.println("Client received "+bc.getLength() + " bytes in
"+(System.currentTimeMillis()-start)+" ms.");
-assertEquals(EXPECTED_CONTENT_LENGTH * (i+1), bc.getLength());
+ByteChunk bc = new ByteChunk();
+Map> respHeaders = new HashMap>();
+for (int i=0; ihttp://localhost:"; + getPort() + "/servlet" +
i, bc, null, respHeaders);
+assertEquals(HttpServletResponse.SC_OK, rc);
+System.out.println("Client received "+bc.getLength() + " bytes
in "+(System.currentTimeMillis()-start)+" ms.");
+assertEquals(EXPECTED_CONTENT_LENGTH * (i+1), bc.getLength());
-bc.recycle();
+bc.recycle();
+}
+} finally {
+for (File f : files) {
+f.delete();
+}
}
}
-public File generateFile(String dir, int size) throws IOException {
-String name = "testSendFile-"+System.currentTimeMillis()+".txt";
+public File generateFile(String dir, String suffix, int size) throws
IOException {
+String name = "testSendFile-"+System.currentTimeMillis()+suffix+".txt";
File f = new File(dir,name);
FileWriter fw = new FileWriter(f, false);
BufferedWriter w = new BufferedWriter(fw);
@@ -93,6 +100,7 @@ public class TestSendFile extends Tomcat
}
w.flush();
w.close();
+System.out.println("Created file:"+f.getAbsolutePath()+" with
"+f.length()+" bytes.");
return f;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
The idea of creating a VM that is like mine was a good one. I did a clean install of Windows 7 64 bit, and it works like a charm. My network stack must have something installed at the network stack Filip > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Wednesday, July 11, 2012 1:32 PM > To: Tomcat Developers List > Subject: Re: Unit tests and trunk > > On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: > > > > > >> -Original Message- > >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > >> Sent: Wednesday, July 11, 2012 10:13 AM > >> To: 'Tomcat Developers List' > >> Subject: RE: Unit tests and trunk > >> > >> > >> > >>> -Original Message- > >>> From: Mark Thomas [mailto:ma...@apache.org] > >>> Sent: Wednesday, July 11, 2012 2:45 AM > >>> To: Tomcat Developers List > >>> Subject: Re: Unit tests and trunk > >>> > >>> On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: > Here's what I've found out so far > > The patch below does solve the problem. In a rather remarkable way. > The line > int cnt = socket.write(buf); //write the data > > never returns 0, meaning the writes are always blocking. Even > though > >>> they > are not supposed to be. > Remove this patch, and socket.write(buf) returns 0, and then we > >> never > >>> get > issued the OP_WRITE from the selector itself. > >>> > >>> I'm not sure I follow the above. Remove the patch and it returns 0? > >> [Filip Hanik] > >> Correct, as it should. The buffer should fill up very quick, and when > >> the > >> buffer is full NIO returns 0, can't write. > >> So there are two problems: > >> a) The selector doesn't work the same in Java 7 as it does in Java 5 > and > >> 6 > >> b) Starting a new selector turns non blocking writes into blocking, > even > >> when I write 10MB in the TestOutputBuffer test, there is not a single > >> socket.write that returns 0. Removing the Selector.open call, and > >> immediately we have a hit return 0 as expected. > >> > >> > >>> > >>> Regardless, it seems very strange that the patch below fixes it. I > had > >> a > >>> quick look through the Java source and couldn't see anything > >> immediately > >>> obvious. Any ideas what is going on? > >> [Filip Hanik] > >> Can't think of anything but a bug in the JDK. I'll keep > investigating. > >> Possibly we have to move the async NIO stuff to get it to work > > [Filip Hanik] > > Btw, this affects the BIO connector too. The write blocks and hangs > forever. > > Maybe it's just my Windows 7 system. Works fine on linux. > > Let me see if I can find (or create if necessary) a clean-ish Windows 7 > VM to test this on. > > Mark > > - > 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: svn commit: r1360372 - /tomcat/trunk/webapps/docs/aio.xml
> From: fha...@apache.org [mailto:fha...@apache.org] > Subject: svn commit: r1360372 - /tomcat/trunk/webapps/docs/aio.xml > Author: fhanik > Date: Wed Jul 11 19:51:57 2012 > New Revision: 1360372 > URL: http://svn.apache.org/viewvc?rev=1360372&view=rev > +In addition to setting these parameters it is necessary to set the > content-length header. > +or set a transfer-encoding like chunked. You might want to change the period after "content-length header" to a comma for grammatical correctness. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1360408 - /tomcat/trunk/webapps/docs/aio.xml
Author: fhanik Date: Wed Jul 11 21:24:18 2012 New Revision: 1360408 URL: http://svn.apache.org/viewvc?rev=1360408&view=rev Log: correct the sentence. chunked will not work, as the length is fixed and not encoding is added during send file Modified: tomcat/trunk/webapps/docs/aio.xml Modified: tomcat/trunk/webapps/docs/aio.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?rev=1360408&r1=1360407&r2=1360408&view=diff == --- tomcat/trunk/webapps/docs/aio.xml (original) +++ tomcat/trunk/webapps/docs/aio.xml Wed Jul 11 21:24:18 2012 @@ -345,7 +345,6 @@ public class ChatServlet In addition to setting these parameters it is necessary to set the content-length header. -or set a transfer-encoding like chunked. Tomcat will not do that for you, since you may have already written data to the - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53535] Out of memory while performing ContextConfig.webConfig
https://issues.apache.org/bugzilla/show_bug.cgi?id=53535 --- Comment #2 from Cedomir Igaly --- Created attachment 29051 --> https://issues.apache.org/bugzilla/attachment.cgi?id=29051&action=edit diff -u Here it 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
RE: Unit tests and trunk
Ok, I have a resolution to this, it's a IPv6 problem. The reason it worked on my virtual machine, is cause the virtual machine doesn't have IPv6 When I add To the unit tests, it works fine on Windows. Here is what led me to believe in this: http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on-socket.html > -Original Message- > From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > Sent: Wednesday, July 11, 2012 2:54 PM > To: 'Tomcat Developers List' > Subject: RE: Unit tests and trunk > > The idea of creating a VM that is like mine was a good one. > I did a clean install of Windows 7 64 bit, and it works like a charm. > My network stack must have something installed at the network stack > > Filip > > > -Original Message- > > From: Mark Thomas [mailto:ma...@apache.org] > > Sent: Wednesday, July 11, 2012 1:32 PM > > To: Tomcat Developers List > > Subject: Re: Unit tests and trunk > > > > On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: > > > > > > > > >> -Original Message- > > >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > > >> Sent: Wednesday, July 11, 2012 10:13 AM > > >> To: 'Tomcat Developers List' > > >> Subject: RE: Unit tests and trunk > > >> > > >> > > >> > > >>> -Original Message- > > >>> From: Mark Thomas [mailto:ma...@apache.org] > > >>> Sent: Wednesday, July 11, 2012 2:45 AM > > >>> To: Tomcat Developers List > > >>> Subject: Re: Unit tests and trunk > > >>> > > >>> On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: > > Here's what I've found out so far > > > > The patch below does solve the problem. In a rather remarkable > way. > > The line > > int cnt = socket.write(buf); //write the data > > > > never returns 0, meaning the writes are always blocking. Even > > though > > >>> they > > are not supposed to be. > > Remove this patch, and socket.write(buf) returns 0, and then we > > >> never > > >>> get > > issued the OP_WRITE from the selector itself. > > >>> > > >>> I'm not sure I follow the above. Remove the patch and it returns > 0? > > >> [Filip Hanik] > > >> Correct, as it should. The buffer should fill up very quick, and > when > > >> the > > >> buffer is full NIO returns 0, can't write. > > >> So there are two problems: > > >> a) The selector doesn't work the same in Java 7 as it does in Java > 5 > > and > > >> 6 > > >> b) Starting a new selector turns non blocking writes into blocking, > > even > > >> when I write 10MB in the TestOutputBuffer test, there is not a > single > > >> socket.write that returns 0. Removing the Selector.open call, and > > >> immediately we have a hit return 0 as expected. > > >> > > >> > > >>> > > >>> Regardless, it seems very strange that the patch below fixes it. I > > had > > >> a > > >>> quick look through the Java source and couldn't see anything > > >> immediately > > >>> obvious. Any ideas what is going on? > > >> [Filip Hanik] > > >> Can't think of anything but a bug in the JDK. I'll keep > > investigating. > > >> Possibly we have to move the async NIO stuff to get it to work > > > [Filip Hanik] > > > Btw, this affects the BIO connector too. The write blocks and hangs > > forever. > > > Maybe it's just my Windows 7 system. Works fine on linux. > > > > Let me see if I can find (or create if necessary) a clean-ish Windows > 7 > > VM to test this on. > > > > Mark > > > > - > > 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 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1360433 - in /tomcat/trunk: build.properties.default build.xml
Author: fhanik
Date: Wed Jul 11 22:01:17 2012
New Revision: 1360433
URL: http://svn.apache.org/viewvc?rev=1360433&view=rev
Log:
Add IPv4Stack flag one can control from build.properties and
build.properties.default
default value is false but can be overridden even from command line
default compile source/target is 1.7, but has to be changed in
build.properties.default to take into effect
Modified:
tomcat/trunk/build.properties.default
tomcat/trunk/build.xml
Modified: tomcat/trunk/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=1360433&r1=1360432&r2=1360433&view=diff
==
--- tomcat/trunk/build.properties.default (original)
+++ tomcat/trunk/build.properties.default Wed Jul 11 22:01:17 2012
@@ -203,3 +203,5 @@ dojo-js.home=${base.path}/dojo-release-1
dojo-js.loc=http://download.dojotoolkit.org/release-1.1.1/dojo-release-1.1.1.tar.gz
dojo-js.jar=${dojo-js.home}/dojo/dojo.js
+# - JVM settings for unit tests
+java.net.preferIPv4Stack=false
\ No newline at end of file
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1360433&r1=1360432&r2=1360433&view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Wed Jul 11 22:01:17 2012
@@ -74,9 +74,9 @@
-
-
-
+
+
+
@@ -1197,6 +1197,8 @@
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1360372 - /tomcat/trunk/webapps/docs/aio.xml
On 11/07/2012 20:51, fha...@apache.org wrote: > Author: fhanik > Date: Wed Jul 11 19:51:57 2012 > New Revision: 1360372 > > URL: http://svn.apache.org/viewvc?rev=1360372&view=rev > Log: > Clarify documentation around send file > > Modified: > tomcat/trunk/webapps/docs/aio.xml > > Modified: tomcat/trunk/webapps/docs/aio.xml > URL: > http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?rev=1360372&r1=1360371&r2=1360372&view=diff > == > --- tomcat/trunk/webapps/docs/aio.xml (original) > +++ tomcat/trunk/webapps/docs/aio.xml Wed Jul 11 19:51:57 2012 > @@ -343,6 +343,11 @@ public class ChatServlet >org.apache.tomcat.sendfile.start: Start offset as a > Long >org.apache.tomcat.sendfile.end: End offset as a Long > > + > +In addition to setting these parameters it is necessary to set the > content-length header. > +or set a transfer-encoding like chunked. > +Tomcat will not do that for you, since you may have already written data > to the > + Looks like a line / word or two is missing in this commit. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: svn commit: r1360372 - /tomcat/trunk/webapps/docs/aio.xml
Will fix > -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Wednesday, July 11, 2012 4:03 PM > To: Tomcat Developers List > Subject: Re: svn commit: r1360372 - /tomcat/trunk/webapps/docs/aio.xml > > On 11/07/2012 20:51, fha...@apache.org wrote: > > Author: fhanik > > Date: Wed Jul 11 19:51:57 2012 > > New Revision: 1360372 > > > > URL: http://svn.apache.org/viewvc?rev=1360372&view=rev > > Log: > > Clarify documentation around send file > > > > Modified: > > tomcat/trunk/webapps/docs/aio.xml > > > > Modified: tomcat/trunk/webapps/docs/aio.xml > > URL: > http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?rev=13603 > 72&r1=1360371&r2=1360372&view=diff > > > > == > > --- tomcat/trunk/webapps/docs/aio.xml (original) > > +++ tomcat/trunk/webapps/docs/aio.xml Wed Jul 11 19:51:57 2012 > > @@ -343,6 +343,11 @@ public class ChatServlet > >org.apache.tomcat.sendfile.start: Start offset as > a Long > >org.apache.tomcat.sendfile.end: End offset as a > Long > > > > + > > +In addition to setting these parameters it is necessary to set > the content-length header. > > +or set a transfer-encoding like chunked. > > +Tomcat will not do that for you, since you may have already > written data to the > > + > > Looks like a line / word or two is missing in this commit. > > Mark > > - > 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: Unit tests and trunk
On 11/07/2012 22:39, Filip Hanik (mailing lists) wrote: > Ok, I have a resolution to this, it's a IPv6 problem. The reason it worked > on my virtual machine, is cause the virtual machine doesn't have IPv6 > > When I add > > > To the unit tests, it works fine on Windows. > > Here is what led me to believe in this: > http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on-socket.html Hmm. It looks like Oracle failed to reproduce the issue - possibly because the IPv6 part was not clear in the original bug report. Probably time to raise an issue with Oracle with clearer instructions to reproduce. (I have a clean Win 7 VM I am happy to trial any test case on if that helps). Mark > >> -Original Message- >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] >> Sent: Wednesday, July 11, 2012 2:54 PM >> To: 'Tomcat Developers List' >> Subject: RE: Unit tests and trunk >> >> The idea of creating a VM that is like mine was a good one. >> I did a clean install of Windows 7 64 bit, and it works like a charm. >> My network stack must have something installed at the network stack >> >> Filip >> >>> -Original Message- >>> From: Mark Thomas [mailto:ma...@apache.org] >>> Sent: Wednesday, July 11, 2012 1:32 PM >>> To: Tomcat Developers List >>> Subject: Re: Unit tests and trunk >>> >>> On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: > -Original Message- > From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > Sent: Wednesday, July 11, 2012 10:13 AM > To: 'Tomcat Developers List' > Subject: RE: Unit tests and trunk > > > >> -Original Message- >> From: Mark Thomas [mailto:ma...@apache.org] >> Sent: Wednesday, July 11, 2012 2:45 AM >> To: Tomcat Developers List >> Subject: Re: Unit tests and trunk >> >> On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: >>> Here's what I've found out so far >>> >>> The patch below does solve the problem. In a rather remarkable >> way. >>> The line >>> int cnt = socket.write(buf); //write the data >>> >>> never returns 0, meaning the writes are always blocking. Even >>> though >> they >>> are not supposed to be. >>> Remove this patch, and socket.write(buf) returns 0, and then we > never >> get >>> issued the OP_WRITE from the selector itself. >> >> I'm not sure I follow the above. Remove the patch and it returns >> 0? > [Filip Hanik] > Correct, as it should. The buffer should fill up very quick, and >> when > the > buffer is full NIO returns 0, can't write. > So there are two problems: > a) The selector doesn't work the same in Java 7 as it does in Java >> 5 >>> and > 6 > b) Starting a new selector turns non blocking writes into blocking, >>> even > when I write 10MB in the TestOutputBuffer test, there is not a >> single > socket.write that returns 0. Removing the Selector.open call, and > immediately we have a hit return 0 as expected. > > >> >> Regardless, it seems very strange that the patch below fixes it. I >>> had > a >> quick look through the Java source and couldn't see anything > immediately >> obvious. Any ideas what is going on? > [Filip Hanik] > Can't think of anything but a bug in the JDK. I'll keep >>> investigating. > Possibly we have to move the async NIO stuff to get it to work [Filip Hanik] Btw, this affects the BIO connector too. The write blocks and hangs >>> forever. Maybe it's just my Windows 7 system. Works fine on linux. >>> >>> Let me see if I can find (or create if necessary) a clean-ish Windows >> 7 >>> VM to test this on. >>> >>> Mark >>> >>> - >>> 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 > > > > - > 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
svn commit: r1360449 - /tomcat/trunk/webapps/docs/aio.xml
Author: fhanik Date: Wed Jul 11 22:29:08 2012 New Revision: 1360449 URL: http://svn.apache.org/viewvc?rev=1360449&view=rev Log: fix sentence Modified: tomcat/trunk/webapps/docs/aio.xml Modified: tomcat/trunk/webapps/docs/aio.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?rev=1360449&r1=1360448&r2=1360449&view=diff == --- tomcat/trunk/webapps/docs/aio.xml (original) +++ tomcat/trunk/webapps/docs/aio.xml Wed Jul 11 22:29:08 2012 @@ -345,7 +345,7 @@ public class ChatServlet In addition to setting these parameters it is necessary to set the content-length header. -Tomcat will not do that for you, since you may have already written data to the +Tomcat will not do that for you, since you may have already written data to the output stream. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Unit tests and trunk
> -Original Message- > From: Mark Thomas [mailto:ma...@apache.org] > Sent: Wednesday, July 11, 2012 4:28 PM > To: Tomcat Developers List > Subject: Re: Unit tests and trunk > > On 11/07/2012 22:39, Filip Hanik (mailing lists) wrote: > > Ok, I have a resolution to this, it's a IPv6 problem. The reason it > worked > > on my virtual machine, is cause the virtual machine doesn't have IPv6 > > > > When I add > > > > > > To the unit tests, it works fine on Windows. > > > > Here is what led me to believe in this: > > http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on- > socket.html > > Hmm. It looks like Oracle failed to reproduce the issue - possibly > because the IPv6 part was not clear in the original bug report. Probably > time to raise an issue with Oracle with clearer instructions to > reproduce. (I have a clean Win 7 VM I am happy to trial any test case on > if that helps). [Filip Hanik] I wasn't able to reproduce on a Win 7 VM because the VM environment itself doesn't support IPv6 > > Mark > > > > > >> -Original Message- > >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > >> Sent: Wednesday, July 11, 2012 2:54 PM > >> To: 'Tomcat Developers List' > >> Subject: RE: Unit tests and trunk > >> > >> The idea of creating a VM that is like mine was a good one. > >> I did a clean install of Windows 7 64 bit, and it works like a charm. > >> My network stack must have something installed at the network stack > >> > >> Filip > >> > >>> -Original Message- > >>> From: Mark Thomas [mailto:ma...@apache.org] > >>> Sent: Wednesday, July 11, 2012 1:32 PM > >>> To: Tomcat Developers List > >>> Subject: Re: Unit tests and trunk > >>> > >>> On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: > > > > -Original Message- > > From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > > Sent: Wednesday, July 11, 2012 10:13 AM > > To: 'Tomcat Developers List' > > Subject: RE: Unit tests and trunk > > > > > > > >> -Original Message- > >> From: Mark Thomas [mailto:ma...@apache.org] > >> Sent: Wednesday, July 11, 2012 2:45 AM > >> To: Tomcat Developers List > >> Subject: Re: Unit tests and trunk > >> > >> On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: > >>> Here's what I've found out so far > >>> > >>> The patch below does solve the problem. In a rather remarkable > >> way. > >>> The line > >>> int cnt = socket.write(buf); //write the data > >>> > >>> never returns 0, meaning the writes are always blocking. Even > >>> though > >> they > >>> are not supposed to be. > >>> Remove this patch, and socket.write(buf) returns 0, and then we > > never > >> get > >>> issued the OP_WRITE from the selector itself. > >> > >> I'm not sure I follow the above. Remove the patch and it returns > >> 0? > > [Filip Hanik] > > Correct, as it should. The buffer should fill up very quick, and > >> when > > the > > buffer is full NIO returns 0, can't write. > > So there are two problems: > > a) The selector doesn't work the same in Java 7 as it does in Java > >> 5 > >>> and > > 6 > > b) Starting a new selector turns non blocking writes into > blocking, > >>> even > > when I write 10MB in the TestOutputBuffer test, there is not a > >> single > > socket.write that returns 0. Removing the Selector.open call, and > > immediately we have a hit return 0 as expected. > > > > > >> > >> Regardless, it seems very strange that the patch below fixes it. > I > >>> had > > a > >> quick look through the Java source and couldn't see anything > > immediately > >> obvious. Any ideas what is going on? > > [Filip Hanik] > > Can't think of anything but a bug in the JDK. I'll keep > >>> investigating. > > Possibly we have to move the async NIO stuff to get it to work > [Filip Hanik] > Btw, this affects the BIO connector too. The write blocks and hangs > >>> forever. > Maybe it's just my Windows 7 system. Works fine on linux. > >>> > >>> Let me see if I can find (or create if necessary) a clean-ish > Windows > >> 7 > >>> VM to test this on. > >>> > >>> Mark > >>> > >>> > - > >>> 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 > > > > > > > > - > > 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/3183 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1360433 Blamelist: fhanik BUILD FAILED: failed compile_1 sincerely, -The Buildbot
RE: Unit tests and trunk
I opened a new issue pointing back to the old issue http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7183450. It may take a day or two before your bug shows up in this external database. > -Original Message- > From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > Sent: Wednesday, July 11, 2012 4:30 PM > To: 'Tomcat Developers List' > Subject: RE: Unit tests and trunk > > > > > -Original Message- > > From: Mark Thomas [mailto:ma...@apache.org] > > Sent: Wednesday, July 11, 2012 4:28 PM > > To: Tomcat Developers List > > Subject: Re: Unit tests and trunk > > > > On 11/07/2012 22:39, Filip Hanik (mailing lists) wrote: > > > Ok, I have a resolution to this, it's a IPv6 problem. The reason it > > worked > > > on my virtual machine, is cause the virtual machine doesn't have > IPv6 > > > > > > When I add > > > > > > > > > To the unit tests, it works fine on Windows. > > > > > > Here is what led me to believe in this: > > > http://blog.bielu.com/2011/11/hotspot-64bit-server-hangs-on- > > socket.html > > > > Hmm. It looks like Oracle failed to reproduce the issue - possibly > > because the IPv6 part was not clear in the original bug report. > Probably > > time to raise an issue with Oracle with clearer instructions to > > reproduce. (I have a clean Win 7 VM I am happy to trial any test case > on > > if that helps). > [Filip Hanik] > I wasn't able to reproduce on a Win 7 VM because the VM environment > itself > doesn't support IPv6 > > > > > > > Mark > > > > > > > > > >> -Original Message- > > >> From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > > >> Sent: Wednesday, July 11, 2012 2:54 PM > > >> To: 'Tomcat Developers List' > > >> Subject: RE: Unit tests and trunk > > >> > > >> The idea of creating a VM that is like mine was a good one. > > >> I did a clean install of Windows 7 64 bit, and it works like a > charm. > > >> My network stack must have something installed at the network stack > > >> > > >> Filip > > >> > > >>> -Original Message- > > >>> From: Mark Thomas [mailto:ma...@apache.org] > > >>> Sent: Wednesday, July 11, 2012 1:32 PM > > >>> To: Tomcat Developers List > > >>> Subject: Re: Unit tests and trunk > > >>> > > >>> On 11/07/2012 20:13, Filip Hanik (mailing lists) wrote: > > > > > > > -Original Message- > > > From: Filip Hanik (mailing lists) [mailto:devli...@hanik.com] > > > Sent: Wednesday, July 11, 2012 10:13 AM > > > To: 'Tomcat Developers List' > > > Subject: RE: Unit tests and trunk > > > > > > > > > > > >> -Original Message- > > >> From: Mark Thomas [mailto:ma...@apache.org] > > >> Sent: Wednesday, July 11, 2012 2:45 AM > > >> To: Tomcat Developers List > > >> Subject: Re: Unit tests and trunk > > >> > > >> On 11/07/2012 02:27, Filip Hanik (mailing lists) wrote: > > >>> Here's what I've found out so far > > >>> > > >>> The patch below does solve the problem. In a rather remarkable > > >> way. > > >>> The line > > >>> int cnt = socket.write(buf); //write the data > > >>> > > >>> never returns 0, meaning the writes are always blocking. Even > > >>> though > > >> they > > >>> are not supposed to be. > > >>> Remove this patch, and socket.write(buf) returns 0, and then > we > > > never > > >> get > > >>> issued the OP_WRITE from the selector itself. > > >> > > >> I'm not sure I follow the above. Remove the patch and it > returns > > >> 0? > > > [Filip Hanik] > > > Correct, as it should. The buffer should fill up very quick, and > > >> when > > > the > > > buffer is full NIO returns 0, can't write. > > > So there are two problems: > > > a) The selector doesn't work the same in Java 7 as it does in > Java > > >> 5 > > >>> and > > > 6 > > > b) Starting a new selector turns non blocking writes into > > blocking, > > >>> even > > > when I write 10MB in the TestOutputBuffer test, there is not a > > >> single > > > socket.write that returns 0. Removing the Selector.open call, > and > > > immediately we have a hit return 0 as expected. > > > > > > > > >> > > >> Regardless, it seems very strange that the patch below fixes > it. > > I > > >>> had > > > a > > >> quick look through the Java source and couldn't see anything > > > immediately > > >> obvious. Any ideas what is going on? > > > [Filip Hanik] > > > Can't think of anything but a bug in the JDK. I'll keep > > >>> investigating. > > > Possibly we have to move the async NIO stuff to get it to work > > [Filip Hanik] > > Btw, this affects the BIO connector too. The write blocks and > hangs > > >>> forever. > > Maybe it's just my Windows 7 system. Works fine on linux. > > >>> > > >>> Let me see if I can find (or create if necessary) a clean-ish > > Windows > > >> 7 > > >>> VM to test this on. > > >>> > > >>> Mark > > >>> > > >>> ---
access to build environment
How do I get access to the build environment? So we can change the build to default to Java 7 Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Unit tests and trunk
On 11/07/2012 23:30, Filip Hanik (mailing lists) wrote: > I wasn't able to reproduce on a Win 7 VM because the VM environment itself > doesn't support IPv6 Given who we work for, the opportunities for humorous comments is extensive :) I'll settle for saying that I've double checked the VM I have and it does (claim to) support IPv6. I'll try out the test case provided in the original bug report. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: access to build environment
On 11/07/2012 23:40, Filip Hanik (mailing lists) wrote: > How do I get access to the build environment? Which build environment? Gump, buildbot, something else? Mark > > So we can change the build to default to Java 7 > > Filip > > > > > - > 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
svn commit: r1360455 - /tomcat/trunk/webapps/docs/cluster-howto.xml
Author: markt Date: Wed Jul 11 22:45:15 2012 New Revision: 1360455 URL: http://svn.apache.org/viewvc?rev=1360455&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53524 Fix typo Modified: tomcat/trunk/webapps/docs/cluster-howto.xml Modified: tomcat/trunk/webapps/docs/cluster-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/cluster-howto.xml?rev=1360455&r1=1360454&r2=1360455&view=diff == --- tomcat/trunk/webapps/docs/cluster-howto.xml (original) +++ tomcat/trunk/webapps/docs/cluster-howto.xml Wed Jul 11 22:45:15 2012 @@ -337,7 +337,7 @@ should be completed: StaticMembershipInterceptor if you want to extend your membership to points beyond multicasting. The address attribute is the multicast address used and the port is the multicast port. These two together create the cluster separation. If you want a QA cluster and a production cluster, the easiest config is to -have the QA cluster be on a separate multicast address/port combination the the production cluster. +have the QA cluster be on a separate multicast address/port combination than the production cluster. The membership component broadcasts TCP adress/port of itselt to the other nodes so that communication between nodes can be done over TCP. Please note that the address being broadcasted is the one of the Receiver.address attribute. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1360460 - /tomcat/trunk/webapps/docs/cluster-howto.xml
Author: markt Date: Wed Jul 11 22:49:14 2012 New Revision: 1360460 URL: http://svn.apache.org/viewvc?rev=1360460&view=rev Log: Fix spelling Modified: tomcat/trunk/webapps/docs/cluster-howto.xml Modified: tomcat/trunk/webapps/docs/cluster-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/cluster-howto.xml?rev=1360460&r1=1360459&r2=1360460&view=diff == --- tomcat/trunk/webapps/docs/cluster-howto.xml (original) +++ tomcat/trunk/webapps/docs/cluster-howto.xml Wed Jul 11 22:49:14 2012 @@ -47,7 +47,7 @@ Using the above configuration will enable all-to-all session replication using the DeltaManager to replicate session deltas. By all-to-all we mean that the session gets replicated to all the other -nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of tomcat nodes). +nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of Tomcat nodes). Also when using the delta manager it will replicate to all nodes, even nodes that don't have the application deployed. To get around this problem, you'll want to use the BackupManager. This manager only replicates the session data to one backup node, and only to nodes that have the application deployed. Downside of the BackupManager: not quite as battle tested as the delta manager. @@ -147,7 +147,7 @@ should be completed: The all-to-all replication is an algorithm that is only efficient when the clusters are small. For larger clusters, to use a primary-secondary session replication where the session will only be stored at one backup server simply setup the BackupManager. Currently you can use the domain worker attribute (mod_jk > 1.2.8) to build cluster partitions - with the potential of having a more scaleable cluster solution with the DeltaManager(you'll need to configure the domain interceptor for this). + with the potential of having a more scalable cluster solution with the DeltaManager(you'll need to configure the domain interceptor for this). In order to keep the network traffic down in an all-to-all environment, you can split your cluster into smaller groups. This can be easily achieved by using different multicast addresses for the different groups. A very simple setup would look like this: @@ -209,7 +209,7 @@ should be completed: The JvmRouteBinderValve rewrites the session id to ensure that the next request will remain sticky (and not fall back to go to random nodes since the worker is no longer available) after a fail over. The valve rewrites the JSESSIONID value in the cookie with the same name. -Not having this valve in place, will make it harder to ensure stickyness in case of a failure for the mod_jk module. +Not having this valve in place, will make it harder to ensure stickiness in case of a failure for the mod_jk module. By default, if no valves are configured, the JvmRouteBinderValve is added on. @@ -338,7 +338,7 @@ should be completed: The address attribute is the multicast address used and the port is the multicast port. These two together create the cluster separation. If you want a QA cluster and a production cluster, the easiest config is to have the QA cluster be on a separate multicast address/port combination than the production cluster. -The membership component broadcasts TCP adress/port of itselt to the other nodes so that communication between +The membership component broadcasts TCP address/port of itself to the other nodes so that communication between nodes can be done over TCP. Please note that the address being broadcasted is the one of the Receiver.address attribute. For more info, Please visit the reference documentation @@ -382,7 +382,7 @@ should be completed: Tribes uses a stack to send messages through. Each element in the stack is called an interceptor, and works much like the valves do in the Tomcat servlet container. -Using interceptors, logic can be broken into more managable pieces of code. The interceptors configured above are: +Using interceptors, logic can be broken into more manageable pieces of code. The interceptors configured above are: TcpFailureDetector - verifies crashed members through TCP, if multicast packets get dropped, this interceptor protects against false positives, ie the node marked as crashed even though it still is alive and running. MessageDispatch15Interceptor - dispatches messages to a thread (thread pool) to send message asynchrously. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1360461 - in /tomcat/tc7.0.x/trunk: ./ webapps/docs/changelog.xml webapps/docs/cluster-howto.xml
Author: markt Date: Wed Jul 11 22:51:35 2012 New Revision: 1360461 URL: http://svn.apache.org/viewvc?rev=1360461&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53524 Fix typo and spelling Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml Propchange: tomcat/tc7.0.x/trunk/ -- Merged /tomcat/trunk:r1360455,1360460 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=1360461&r1=1360460&r2=1360461&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Jul 11 22:51:35 2012 @@ -107,6 +107,11 @@ Update JSTL version information in the JNDI section of the documentation web application. (markt) + +53524: Correct a typo in the cluster how-to section of the +documentation web application. Also fix a handful of spelling errors. +(markt) + Modified: tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml?rev=1360461&r1=1360460&r2=1360461&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/cluster-howto.xml Wed Jul 11 22:51:35 2012 @@ -47,7 +47,7 @@ Using the above configuration will enable all-to-all session replication using the DeltaManager to replicate session deltas. By all-to-all we mean that the session gets replicated to all the other -nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of tomcat nodes). +nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of Tomcat nodes). Also when using the delta manager it will replicate to all nodes, even nodes that don't have the application deployed. To get around this problem, you'll want to use the BackupManager. This manager only replicates the session data to one backup node, and only to nodes that have the application deployed. Downside of the BackupManager: not quite as battle tested as the delta manager. @@ -147,7 +147,7 @@ should be completed: The all-to-all replication is an algorithm that is only efficient when the clusters are small. For larger clusters, to use a primary-secondary session replication where the session will only be stored at one backup server simply setup the BackupManager. Currently you can use the domain worker attribute (mod_jk > 1.2.8) to build cluster partitions - with the potential of having a more scaleable cluster solution with the DeltaManager(you'll need to configure the domain interceptor for this). + with the potential of having a more scalable cluster solution with the DeltaManager(you'll need to configure the domain interceptor for this). In order to keep the network traffic down in an all-to-all environment, you can split your cluster into smaller groups. This can be easily achieved by using different multicast addresses for the different groups. A very simple setup would look like this: @@ -209,7 +209,7 @@ should be completed: The JvmRouteBinderValve rewrites the session id to ensure that the next request will remain sticky (and not fall back to go to random nodes since the worker is no longer available) after a fail over. The valve rewrites the JSESSIONID value in the cookie with the same name. -Not having this valve in place, will make it harder to ensure stickyness in case of a failure for the mod_jk module. +Not having this valve in place, will make it harder to ensure stickiness in case of a failure for the mod_jk module. By default, if no valves are configured, the JvmRouteBinderValve is added on. @@ -337,8 +337,8 @@ should be completed: StaticMembershipInterceptor if you want to extend your membership to points beyond multicasting. The address attribute is the multicast address used and the port is the multicast port. These two together create the cluster separation. If you want a QA cluster and a production cluster, the easiest config is to -have the QA cluster be on a separate multicast address/port combination the the production cluster. -The membership component broadcasts TCP adress/port of itselt to the other nodes so that communication between +have the QA cluster be on a separate multicast address/port combination than the production cluster. +The membership component broadca
[Bug 53524] Typo in cluster-howto.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=53524 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Thomas --- Thanks for the report. Fixed in trunk and 7.0.x and will be included in 7.0.30 onwards. -- 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: r1360462 - /tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Author: markt Date: Wed Jul 11 22:52:57 2012 New Revision: 1360462 URL: http://svn.apache.org/viewvc?rev=1360462&view=rev Log: Add missing word Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml 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=1360462&r1=1360461&r2=1360462&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Wed Jul 11 22:52:57 2012 @@ -93,7 +93,7 @@ trying to set an invalid option whereas Java 6 silently swallowed them. The option using the problem was soTrafficClass. Investigations showed that this option had no effect for Cluster Channel -Receivers it was removed. (markt) +Receivers so it was removed. (markt) 53513: Fix race condition between the processing of session - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1360468 - /tomcat/trunk/java/org/apache/catalina/connector/ClientAbortException.java
Author: markt
Date: Wed Jul 11 23:10:53 2012
New Revision: 1360468
URL: http://svn.apache.org/viewvc?rev=1360468&view=rev
Log:
Simplify (this class dates from pre-Java 1.4)
Modified:
tomcat/trunk/java/org/apache/catalina/connector/ClientAbortException.java
Modified:
tomcat/trunk/java/org/apache/catalina/connector/ClientAbortException.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/ClientAbortException.java?rev=1360468&r1=1360467&r2=1360468&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/ClientAbortException.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/ClientAbortException.java
Wed Jul 11 23:10:53 2012
@@ -25,7 +25,6 @@ import java.io.IOException;
* @author Glenn L. Nielsen
* @version $Id$
*/
-
public final class ClientAbortException extends IOException {
private static final long serialVersionUID = 1L;
@@ -37,9 +36,7 @@ public final class ClientAbortException
* Construct a new ClientAbortException with no other information.
*/
public ClientAbortException() {
-
-this(null, null);
-
+super();
}
@@ -49,9 +46,7 @@ public final class ClientAbortException
* @param message Message describing this exception
*/
public ClientAbortException(String message) {
-
-this(message, null);
-
+super(message);
}
@@ -61,9 +56,7 @@ public final class ClientAbortException
* @param throwable Throwable that caused this exception
*/
public ClientAbortException(Throwable throwable) {
-
-this(null, throwable);
-
+super(throwable);
}
@@ -75,73 +68,6 @@ public final class ClientAbortException
* @param throwable Throwable that caused this exception
*/
public ClientAbortException(String message, Throwable throwable) {
-
-super();
-this.message = message;
-this.throwable = throwable;
-
-}
-
-
-//-- Instance Variables
-
-
-/**
- * The error message passed to our constructor (if any)
- */
-protected String message = null;
-
-
-/**
- * The underlying exception or error passed to our constructor (if any)
- */
-protected Throwable throwable = null;
-
-
-//-- Public Methods
-
-
-/**
- * Returns the message associated with this exception, if any.
- */
-@Override
-public String getMessage() {
-
-return (message);
-
+super(message, throwable);
}
-
-
-/**
- * Returns the cause that caused this exception, if any.
- */
-@Override
-public Throwable getCause() {
-
-return (throwable);
-
-}
-
-
-/**
- * Return a formatted string that describes this exception.
- */
-@Override
-public String toString() {
-
-StringBuilder sb = new StringBuilder("ClientAbortException: ");
-if (message != null) {
-sb.append(message);
-if (throwable != null) {
-sb.append(": ");
-}
-}
-if (throwable != null) {
-sb.append(throwable.toString());
-}
-return (sb.toString());
-
-}
-
-
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1360470 - in /tomcat/trunk/java/org/apache/catalina: core/AsyncContextImpl.java startup/Tomcat.java
Author: markt
Date: Wed Jul 11 23:15:00 2012
New Revision: 1360470
URL: http://svn.apache.org/viewvc?rev=1360470&view=rev
Log:
Fix a few Eclipse warnings
Modified:
tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java
tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java
Modified: tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java?rev=1360470&r1=1360469&r2=1360470&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/AsyncContextImpl.java Wed Jul 11
23:15:00 2012
@@ -64,7 +64,7 @@ public class AsyncContextImpl implements
private ServletRequest servletRequest = null;
private ServletResponse servletResponse = null;
-private List listeners = new
ArrayList();
+private final List listeners = new
ArrayList();
private boolean hasOriginalRequestAndResponse = true;
private volatile Runnable dispatch = null;
private Context context = null;
@@ -122,7 +122,7 @@ public class AsyncContextImpl implements
return true;
}
-public boolean canWrite() throws IOException {
+public boolean canWrite() {
if
(request.getResponse().getCoyoteResponse().getWriteListener()==null) return
false;
ClassLoader oldCL = Thread.currentThread().getContextClassLoader();
ClassLoader newCL = request.getContext().getLoader().getClassLoader();
Modified: tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java?rev=1360470&r1=1360469&r2=1360470&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/Tomcat.java Wed Jul 11
23:15:00 2012
@@ -812,9 +812,9 @@ public class Tomcat {
public boolean hasAsync() {
if (isAsyncSupported()) return true;
boolean result = false;
-Class clazz = existing.getClass();
+Class clazz = existing.getClass();
if (clazz.isAnnotationPresent(WebServlet.class)) {
-WebServlet ws =
(WebServlet)clazz.getAnnotation(WebServlet.class);
+WebServlet ws = clazz.getAnnotation(WebServlet.class);
result = ws.asyncSupported();
}
return result;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Missing classes in stock 5.5.35 JARs?
All, http://stackoverflow.com/questions/11427522/ssl-configuration-getting-classpuretlsimplementation-jsse15factory-not-foun The SO poster is using 5.5.30 but the problem appears to still exist in 5.5.35 (latest). I downloaded the "core" Tomcat 5.5.35 tarball and none of the .jar files in there contain the PureTLSImplementation class (nor any of the JSSE15*.class files). JSSE14*.class are there, in server/lib/tomcat-util.jar. svn doesn't say anything about those files being removed -- the sources are still in there. Did something get left out in the build, somehow? -chris signature.asc Description: OpenPGP digital signature
Re: Unit tests and trunk
I can reproduce the bug in both our unit tests and the original bug report. further more I can turn non blocking into blocking by opening an closing a selector that is never used. definitely a bug, since a jvm/network flag resolves it. while your vm may support ipv6, there is still an additional software layer. I'm sure there will be more bug reports as more people turn to java 7 on windows/hardware Sent from my iPhone On Jul 11, 2012, at 16:42, Mark Thomas wrote: > On 11/07/2012 23:30, Filip Hanik (mailing lists) wrote: >> I wasn't able to reproduce on a Win 7 VM because the VM environment itself >> doesn't support IPv6 > > Given who we work for, the opportunities for humorous comments is > extensive :) > > I'll settle for saying that I've double checked the VM I have and it > does (claim to) support IPv6. I'll try out the test case provided in the > original bug report. > > Mark > > - > 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: access to build environment
I'd guess those two, do we use anything else for tomcat ci? Sent from my iPhone On Jul 11, 2012, at 16:42, Mark Thomas wrote: > On 11/07/2012 23:40, Filip Hanik (mailing lists) wrote: >> How do I get access to the build environment? > > Which build environment? Gump, buildbot, something else? > > Mark > >> >> So we can change the build to default to Java 7 >> >> Filip >> >> >> >> >> - >> 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 > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
