Re: NIO 2 connector
On 03/04/2014 07:26 PM, Mark Thomas wrote: Can you wait until we split 8.0.x from trunk or did you want to get this into 8.0.x? I would like to see it in 8.0.x so we can have it in the talk Chris and I present at the ApacheCon. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56217] New: Regarding Tomcat Manager Application Status Page
https://issues.apache.org/bugzilla/show_bug.cgi?id=56217 Bug ID: 56217 Summary: Regarding Tomcat Manager Application Status Page Product: Tomcat 7 Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P2 Component: Manager Assignee: dev@tomcat.apache.org Reporter: bhatu.m...@gmail.com Created attachment 31366 --> https://issues.apache.org/bugzilla/attachment.cgi?id=31366&action=edit Tomcat Managet Status Page Screenshot In Tomcat Manager Status Page, please make "Request" as Left align. Currently "Request" column is Center align due to which if there are links with larger in length (Links with GET method) could not display in Desktop Screen. To view these links, horizonatal scrollbar has to use. If we could make it Left align, all links could be viewed in screen (atleast starting points of links). Screenshot attached for more clarity and reference. -- 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: r1574229 - /tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/DefaultTestCase.java
Author: markt
Date: Tue Mar 4 22:31:46 2014
New Revision: 1574229
URL: http://svn.apache.org/r1574229
Log:
Handle the maxActive -> maxTotal rename
Modified:
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/DefaultTestCase.java
Modified:
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/DefaultTestCase.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/DefaultTestCase.java?rev=1574229&r1=1574228&r2=1574229&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/DefaultTestCase.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/DefaultTestCase.java
Tue Mar 4 22:31:46 2014
@@ -17,11 +17,15 @@
package org.apache.tomcat.jdbc.test;
import java.lang.reflect.Method;
+import java.util.HashMap;
+import java.util.Map;
import java.util.Properties;
import org.junit.After;
import org.junit.Before;
+//import org.apache.commons.dbcp2.BasicDataSource;
+//import org.apache.commons.dbcp2.BasicDataSourceFactory;
import org.apache.tomcat.dbcp.dbcp2.BasicDataSource;
import org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory;
import org.apache.tomcat.jdbc.pool.PoolConfiguration;
@@ -74,7 +78,11 @@ public abstract class DefaultTestCase {
try {
Properties p = new Properties();
for (int i=0; i< ALL_PROPERTIES.length; i++) {
-String name = "get" +
Character.toUpperCase(ALL_PROPERTIES[i].charAt(0)) +
ALL_PROPERTIES[i].substring(1);
+
+String property = ALL_PROPERTIES[i];
+String dbcpProperty = handleRenames(property);
+
+String name = "get" +
Character.toUpperCase(property.charAt(0)) + property.substring(1);
String bname = "is" + name.substring(3);
Method get = null;
try {
@@ -96,7 +104,7 @@ public abstract class DefaultTestCase {
if (get!=null) {
Object value =
get.invoke(datasource.getPoolProperties(), new Object[0]);
if (value!=null) {
- p.setProperty(ALL_PROPERTIES[i], value.toString());
+ p.setProperty(dbcpProperty, value.toString());
}
}
}
@@ -106,6 +114,13 @@ public abstract class DefaultTestCase {
}
}
+private String handleRenames(String oldName) {
+if (RENAMED.containsKey(oldName)) {
+return RENAMED.get(oldName);
+}
+return oldName;
+}
+
protected void transferPropertiesToC3P0() throws Exception {
//
System.setProperty("com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL",
"WARNING");
//MLog.getLogger().setLevel(MLevel.WARNING);
@@ -250,6 +265,9 @@ public abstract class DefaultTestCase {
PROP_CONNECTIONPROPERTIES
};
+private static final Map RENAMED = new HashMap<>();
-
+static {
+RENAMED.put(PROP_MAXACTIVE, "maxTotal");
+}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NIO 2 connector
2014-03-04 21:51 GMT+01:00 Mark Thomas : > >> Can you wait until we split 8.0.x from trunk or did you want to get this > >> into 8.0.x? > >> > > > > Depends, if you want to branch soon or not. It would have to be > > experimental for a while anyway, but it will likely bring something > useful. > > I would like to branch soon. On the other hand if we hold this back > until 9.0.x then it will be a lot longer before folks can really use it. > It's very early in 8.0, so there would be plenty of time to backport if it is not included before branching. I thought you backported everything anyway. Basically, I can commit it as soon as there's general agreement on it, it's very easy in the meantime to keep rebasing on trunk. I'll try to work on improving the testsuite status as much as possible [I see some websockets tests failing - not a big surprise -, although a lot of it is working], and also see how I can remove that isReady from the AbstractServletInputStream. > > > I think the spec says there should be a /0.0 version number, and I like > the > > Coyote name, but you can change it. > > I'll try to remember to take a look at it. Maybe just change it to match > the Tomcat major/minor version numbers. > Ok. > Thanks for the clarifications. I'm +1 with the following caveats: > - no @author tags > - exclude the change that makes NIO2 the default > - document that the NIO2 connector is currently experimental > > - They came from the NIO1 classes I used as the basis for the new classes, should I remove them anyway ? - I changed that already. - Yes, I copied from the current NIO documentation, but "experimental" is not mentioned anywhere, which is obviously a mistake. I'll add a log during the endpoint start, so that it can't be missed, it's the best way (nobody reads the docs ...). Rémy
ApacheCon North America, Denver, April 7-11
Hello Tomcat enthusiasts, as you are no doubt aware, ApacheCon North America will be held in Denver, Colorado starting on April 7th. Tomcat will be represented there by a full day of content in the following talks: http://apacheconnorthamerica2014.sched.org/overview/type/tomcat We would love to see you in Denver next month. Register soon, as prices go up on March 14th. http://na.apachecon.com/ -- Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ - @apachecon - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NIO 2 connector
On 04/03/2014 19:23, Rémy Maucherat wrote: > 2014-03-04 19:26 GMT+01:00 Mark Thomas : > >> On 04/03/2014 16:16, Rémy Maucherat wrote: >>> Hi, >>> >>> I've been working on porting a NIO2 connector that was originally >> developed >>> for JBoss AS by Nabil Benothman (an intern at Red Hat). Due to the very >>> different connector structure in Tomcat and my preference for basing it >> on >>> the existing NIO1 connector, it is mostly new code, though. >> >> There looks to be opportunities to share code with the current NIO >> connector. >> > > Don't know. I used the structure, but the algorithms are quite different. > You'll have the opportunity to do it if you want of course ;) You are too kind :) >> There are some changes to the existing code, such as >> java/org/apache/coyote/http11/upgrade/AbstractServletInputStream.java >> that I would like to understand. >> > > Nothing special, it needs a first read to start its "polling", so that's > the reason for adding isReady() (normally harmless). I added the third > event method too for consistency, and that's it. > >> >>> So I would now like to contribute this in trunk as a new experimental >>> connector. It should have feature parity with the NIO1 connectors. Of >>> course, while the basics are in, it will need some time to pass the >>> testsuite, fix issues, improve stability, etc. >> >> Can you wait until we split 8.0.x from trunk or did you want to get this >> into 8.0.x? >> > > Depends, if you want to branch soon or not. It would have to be > experimental for a while anyway, but it will likely bring something useful. I would like to branch soon. On the other hand if we hold this back until 9.0.x then it will be a lot longer before folks can really use it. >>> Coyote version number could be moved up to 2.0 with this addition along >>> with all the connector refactorings that Mark did in trunk. >> >> I'd rather drop the version number entirely as it is pretty much >> meaningless. If we are going to do that, we may as well change the >> server header to "Apache Tomcat". I'm neutral on whether to include the >> major or full version number. >> > > I think the spec says there should be a /0.0 version number, and I like the > Coyote name, but you can change it. I'll try to remember to take a look at it. Maybe just change it to match the Tomcat major/minor version numbers. >>> The code is there (rebased to the current trunk): >>> https://github.com/rmaucher/tomcat >>> >>> A quick NIO2 (the API) presentation. >>> >>> Pros: >>> - Significantly faster, although the API looks slower by design >>> - Resources friendly >>> - Seemingly trivial to use >>> - Polling is neatly hidden away >>> - Thread pool is also neatly hidden away >>> - Per operation timeouts >>> - Read/Write is symmetric >>> - Trivial blocking IO >>> >>> Cons: >>> - No real non blocking IO >> >> Hmm. I was considering dropping the BIO connector entirely for Tomcat 9 >> because of its inability to do non-blocking IO and the way the Servlet >> API was heading. Does it make sense to add a different non-blocking >> connector implementation or have I misunderstood your point? >> > > Well, nobody is going for non blocking IO, people are using async IO. > > But then obviously the read(ByteBuffer) call which used to return an int > (possibly 0 with non blocking IO) now returns a Future. And if you > want to know the result you have to wait for it and there's an IO operation > pending the entire time. So that's the "cons". > > It would be nice to have non blocking operations for "peek" scenarios. So > instead to peek a read, you have to read with a completion handler, then > see if it returns inline. And if it doesn't there's an async process now > doing IO (possibly not the greatest thing that could happen). > >> >>> - No concurrency allowed [for the socket impl of NIO2] although the API >>> looks concurrent >> >> Do you mean no concurrent read and writes? That would be a huge issue. >> > > No, don't worry, that works. It's concurrency on the same operation (like > read, write, accept). The API looks relatively magic, so you'd think you > could do it. OK. Thanks. >>> - Simplicity is sometimes misleading, the API doesn't provide some tools >>> for the needed synchronization, check pending operations and their >> possible >>> optimizations >>> - SSL is not integrated any better than with NIO1, it is still SSLEngine >>> which leads to creating the obligatory "AsynchronousSSLSocketChannel" >>> wrapper class yourself >>> - No real sendfile >>> >>> Comments ? >> >> The pros look nice but I am worried about the cons. >> >> The summary is that in the worst case, it's much better. Thanks for the clarifications. I'm +1 with the following caveats: - no @author tags - exclude the change that makes NIO2 the default - document that the NIO2 connector is currently experimental Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.or
Re: NIO 2 connector
2014-03-04 19:26 GMT+01:00 Mark Thomas : > On 04/03/2014 16:16, Rémy Maucherat wrote: > > Hi, > > > > I've been working on porting a NIO2 connector that was originally > developed > > for JBoss AS by Nabil Benothman (an intern at Red Hat). Due to the very > > different connector structure in Tomcat and my preference for basing it > on > > the existing NIO1 connector, it is mostly new code, though. > > There looks to be opportunities to share code with the current NIO > connector. > Don't know. I used the structure, but the algorithms are quite different. You'll have the opportunity to do it if you want of course ;) > > There are some changes to the existing code, such as > java/org/apache/coyote/http11/upgrade/AbstractServletInputStream.java > that I would like to understand. > Nothing special, it needs a first read to start its "polling", so that's the reason for adding isReady() (normally harmless). I added the third event method too for consistency, and that's it. > > > So I would now like to contribute this in trunk as a new experimental > > connector. It should have feature parity with the NIO1 connectors. Of > > course, while the basics are in, it will need some time to pass the > > testsuite, fix issues, improve stability, etc. > > Can you wait until we split 8.0.x from trunk or did you want to get this > into 8.0.x? > Depends, if you want to branch soon or not. It would have to be experimental for a while anyway, but it will likely bring something useful. > > > Coyote version number could be moved up to 2.0 with this addition along > > with all the connector refactorings that Mark did in trunk. > > I'd rather drop the version number entirely as it is pretty much > meaningless. If we are going to do that, we may as well change the > server header to "Apache Tomcat". I'm neutral on whether to include the > major or full version number. > I think the spec says there should be a /0.0 version number, and I like the Coyote name, but you can change it. > > > The code is there (rebased to the current trunk): > > https://github.com/rmaucher/tomcat > > > > A quick NIO2 (the API) presentation. > > > > Pros: > > - Significantly faster, although the API looks slower by design > > - Resources friendly > > - Seemingly trivial to use > > - Polling is neatly hidden away > > - Thread pool is also neatly hidden away > > - Per operation timeouts > > - Read/Write is symmetric > > - Trivial blocking IO > > > > Cons: > > - No real non blocking IO > > Hmm. I was considering dropping the BIO connector entirely for Tomcat 9 > because of its inability to do non-blocking IO and the way the Servlet > API was heading. Does it make sense to add a different non-blocking > connector implementation or have I misunderstood your point? > Well, nobody is going for non blocking IO, people are using async IO. But then obviously the read(ByteBuffer) call which used to return an int (possibly 0 with non blocking IO) now returns a Future. And if you want to know the result you have to wait for it and there's an IO operation pending the entire time. So that's the "cons". It would be nice to have non blocking operations for "peek" scenarios. So instead to peek a read, you have to read with a completion handler, then see if it returns inline. And if it doesn't there's an async process now doing IO (possibly not the greatest thing that could happen). > > > - No concurrency allowed [for the socket impl of NIO2] although the API > > looks concurrent > > Do you mean no concurrent read and writes? That would be a huge issue. > No, don't worry, that works. It's concurrency on the same operation (like read, write, accept). The API looks relatively magic, so you'd think you could do it. > > > - Simplicity is sometimes misleading, the API doesn't provide some tools > > for the needed synchronization, check pending operations and their > possible > > optimizations > > - SSL is not integrated any better than with NIO1, it is still SSLEngine > > which leads to creating the obligatory "AsynchronousSSLSocketChannel" > > wrapper class yourself > > - No real sendfile > > > > Comments ? > > The pros look nice but I am worried about the cons. > > The summary is that in the worst case, it's much better. Rémy
Re: NIO 2 connector
On 04/03/2014 16:16, Rémy Maucherat wrote: > Hi, > > I've been working on porting a NIO2 connector that was originally developed > for JBoss AS by Nabil Benothman (an intern at Red Hat). Due to the very > different connector structure in Tomcat and my preference for basing it on > the existing NIO1 connector, it is mostly new code, though. There looks to be opportunities to share code with the current NIO connector. There are some changes to the existing code, such as java/org/apache/coyote/http11/upgrade/AbstractServletInputStream.java that I would like to understand. > So I would now like to contribute this in trunk as a new experimental > connector. It should have feature parity with the NIO1 connectors. Of > course, while the basics are in, it will need some time to pass the > testsuite, fix issues, improve stability, etc. Can you wait until we split 8.0.x from trunk or did you want to get this into 8.0.x? > Coyote version number could be moved up to 2.0 with this addition along > with all the connector refactorings that Mark did in trunk. I'd rather drop the version number entirely as it is pretty much meaningless. If we are going to do that, we may as well change the server header to "Apache Tomcat". I'm neutral on whether to include the major or full version number. > The code is there (rebased to the current trunk): > https://github.com/rmaucher/tomcat > > A quick NIO2 (the API) presentation. > > Pros: > - Significantly faster, although the API looks slower by design > - Resources friendly > - Seemingly trivial to use > - Polling is neatly hidden away > - Thread pool is also neatly hidden away > - Per operation timeouts > - Read/Write is symmetric > - Trivial blocking IO > > Cons: > - No real non blocking IO Hmm. I was considering dropping the BIO connector entirely for Tomcat 9 because of its inability to do non-blocking IO and the way the Servlet API was heading. Does it make sense to add a different non-blocking connector implementation or have I misunderstood your point? > - No concurrency allowed [for the socket impl of NIO2] although the API > looks concurrent Do you mean no concurrent read and writes? That would be a huge issue. > - Simplicity is sometimes misleading, the API doesn't provide some tools > for the needed synchronization, check pending operations and their possible > optimizations > - SSL is not integrated any better than with NIO1, it is still SSLEngine > which leads to creating the obligatory "AsynchronousSSLSocketChannel" > wrapper class yourself > - No real sendfile > > Comments ? The pros look nice but I am worried about the cons. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1574167 - /tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Author: remm
Date: Tue Mar 4 18:10:56 2014
New Revision: 1574167
URL: http://svn.apache.org/r1574167
Log:
Avoid possible NPE.
Modified:
tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?rev=1574167&r1=1574166&r2=1574167&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java Tue Mar
4 18:10:56 2014
@@ -426,10 +426,12 @@ public class CoyoteAdapter implements Ad
if (!request.isAsync() && !comet) {
request.finishRequest();
response.finishResponse();
-request.getMappingData().context.logAccess(
-request, response,
-System.currentTimeMillis() - req.getStartTime(),
-false);
+if (request.getMappingData().context != null) {
+request.getMappingData().context.logAccess(
+request, response,
+System.currentTimeMillis() - req.getStartTime(),
+false);
+}
}
} catch (IOException e) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1574162 - /tomcat/trunk/java/org/apache/tomcat/util/threads/TaskQueue.java
Author: remm
Date: Tue Mar 4 18:03:41 2014
New Revision: 1574162
URL: http://svn.apache.org/r1574162
Log:
Avoid possible NPE (it really needs to throw a rejected execution instead
anyway).
Modified:
tomcat/trunk/java/org/apache/tomcat/util/threads/TaskQueue.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/threads/TaskQueue.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/threads/TaskQueue.java?rev=1574162&r1=1574161&r2=1574162&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/threads/TaskQueue.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/threads/TaskQueue.java Tue Mar 4
18:03:41 2014
@@ -55,12 +55,12 @@ public class TaskQueue extends LinkedBlo
}
public boolean force(Runnable o) {
-if ( parent.isShutdown() ) throw new
RejectedExecutionException("Executor not running, can't force a command into
the queue");
+if ( parent==null || parent.isShutdown() ) throw new
RejectedExecutionException("Executor not running, can't force a command into
the queue");
return super.offer(o); //forces the item onto the queue, to be used if
the task is rejected
}
public boolean force(Runnable o, long timeout, TimeUnit unit) throws
InterruptedException {
-if ( parent.isShutdown() ) throw new
RejectedExecutionException("Executor not running, can't force a command into
the queue");
+if ( parent==null || parent.isShutdown() ) throw new
RejectedExecutionException("Executor not running, can't force a command into
the queue");
return super.offer(o,timeout,unit); //forces the item onto the queue,
to be used if the task is rejected
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1574163 - in /tomcat/trunk/java/org/apache/catalina/connector: CoyoteInputStream.java InputBuffer.java
Author: remm
Date: Tue Mar 4 18:04:25 2014
New Revision: 1574163
URL: http://svn.apache.org/r1574163
Log:
Fix wrong booleans (which shouldn't change anything in practice, but the code
is wrong).
Modified:
tomcat/trunk/java/org/apache/catalina/connector/CoyoteInputStream.java
tomcat/trunk/java/org/apache/catalina/connector/InputBuffer.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/CoyoteInputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteInputStream.java?rev=1574163&r1=1574162&r2=1574163&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/CoyoteInputStream.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/CoyoteInputStream.java Tue
Mar 4 18:04:25 2014
@@ -250,7 +250,7 @@ public class CoyoteInputStream extends S
private void checkNonBlockingRead() {
-if (ib.isBlocking() && !ib.isReady()) {
+if (!ib.isBlocking() && !ib.isReady()) {
throw new IllegalStateException(
sm.getString("coyoteInputStream.nbNotready"));
}
Modified: tomcat/trunk/java/org/apache/catalina/connector/InputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/InputBuffer.java?rev=1574163&r1=1574162&r2=1574163&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/InputBuffer.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/InputBuffer.java Tue Mar 4
18:04:25 2014
@@ -295,7 +295,7 @@ public class InputBuffer extends Reader
boolean isBlocking() {
-return coyoteRequest.getReadListener() != null;
+return coyoteRequest.getReadListener() == null;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NIO 2 connector
On 03/04/2014 05:16 PM, Rémy Maucherat wrote: Pros: - Significantly faster, although the API looks slower by design Actually I didn't bench it yet but I benched "something similar" on JBossWeb: it performed faster than APR, the implementation is a bit different in that area so I will retest it when I have cycles. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
NIO 2 connector
Hi, I've been working on porting a NIO2 connector that was originally developed for JBoss AS by Nabil Benothman (an intern at Red Hat). Due to the very different connector structure in Tomcat and my preference for basing it on the existing NIO1 connector, it is mostly new code, though. So I would now like to contribute this in trunk as a new experimental connector. It should have feature parity with the NIO1 connectors. Of course, while the basics are in, it will need some time to pass the testsuite, fix issues, improve stability, etc. Coyote version number could be moved up to 2.0 with this addition along with all the connector refactorings that Mark did in trunk. The code is there (rebased to the current trunk): https://github.com/rmaucher/tomcat A quick NIO2 (the API) presentation. Pros: - Significantly faster, although the API looks slower by design - Resources friendly - Seemingly trivial to use - Polling is neatly hidden away - Thread pool is also neatly hidden away - Per operation timeouts - Read/Write is symmetric - Trivial blocking IO Cons: - No real non blocking IO - No concurrency allowed [for the socket impl of NIO2] although the API looks concurrent - Simplicity is sometimes misleading, the API doesn't provide some tools for the needed synchronization, check pending operations and their possible optimizations - SSL is not integrated any better than with NIO1, it is still SSLEngine which leads to creating the obligatory "AsynchronousSSLSocketChannel" wrapper class yourself - No real sendfile Comments ? Rémy
svn commit: r1574052 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Tue Mar 4 12:02:10 2014 New Revision: 1574052 URL: http://svn.apache.org/r1574052 Log: Note DBCP update to a release version. 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=1574052&r1=1574051&r2=1574052&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Tue Mar 4 12:02:10 2014 @@ -172,7 +172,7 @@ Update Commons Pool 2 to 2.2. (markt) -Update Commons DBCP 2 to snapshot 213 dated 28 Feb 2014. (markt) +Update Commons DBCP 2 to the 2.0 release. (markt) 56189: Remove used file cpappend.bat from the distribution. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1573484 - in /tomcat/trunk: build.properties.default build.xml
On 04/03/2014 11:44, Konstantin Kolinko wrote: > 2014-03-03 13:10 GMT+04:00 : >> Author: markt >> Date: Mon Mar 3 09:10:13 2014 >> New Revision: 1573484 >> >> URL: http://svn.apache.org/r1573484 >> Log: >> DBCP 2.0 has been released. >> > > Congratulations, Mark! > > Change log update for this =? Will do. Busy juggling various $work things at the moment and forgot that. Thanks for the reminder. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1573484 - in /tomcat/trunk: build.properties.default build.xml
2014-03-03 13:10 GMT+04:00 :
> Author: markt
> Date: Mon Mar 3 09:10:13 2014
> New Revision: 1573484
>
> URL: http://svn.apache.org/r1573484
> Log:
> DBCP 2.0 has been released.
>
Congratulations, Mark!
Change log update for this =?
> 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=1573484&r1=1573483&r2=1573484&view=diff
> ==
> --- tomcat/trunk/build.properties.default (original)
> +++ tomcat/trunk/build.properties.default Mon Mar 3 09:10:13 2014
> @@ -152,14 +152,10 @@ tomcat-native.win.1=${base-tomcat.loc.1}
>
> tomcat-native.win.2=${base-tomcat.loc.2}/tomcat-connectors/native/${tomcat-native.version}/binaries/tomcat-native-${tomcat-native.version}-win32-bin.zip
>
> # - Commons DBCP, version 2.0 or later -
> -#commons-dbcp.version=1.4
> -#commons-dbcp.home=${base.path}/commons-dbcp-${commons-dbcp.version}-src
> -#commons-dbcp-src.loc.1=${base-commons.loc.1}/dbcp/source/commons-dbcp-${commons-dbcp.version}-src.tar.gz
> -#commons-dbcp-src.loc.2=${base-commons.loc.2}/dbcp/source/commons-dbcp-${commons-dbcp.version}-src.tar.gz
> -commons-dbcp.version=2.0-20140228.204604-213
> -commons-dbcp.home=${base.path}/commons-dbcp2-2.0-SNAPSHOT-src
> -commons-dbcp-src.loc.1=https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-dbcp2/2.0-SNAPSHOT/commons-dbcp2-${commons-dbcp.version}-src.tar.gz
> -commons-dbcp-src.loc.2=https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-dbcp2/2.0-SNAPSHOT/commons-dbcp2-${commons-dbcp.version}-src.tar.gz
> +commons-dbcp.version=2.0
> +commons-dbcp.home=${base.path}/commons-dbcp2-${commons-dbcp.version}-src
> +commons-dbcp-src.loc.1=${base-commons.loc.1}/dbcp/source/commons-dbcp2-${commons-dbcp.version}-src.tar.gz
> +commons-dbcp-src.loc.2=${base-commons.loc.2}/dbcp/source/commons-dbcp2-${commons-dbcp.version}-src.tar.gz
>
> # - Commons Pool, version 2.1 or later -
> commons-pool.version=2.2
> @@ -167,8 +163,6 @@ commons-pool.home=${base.path}/commons-p
>
> commons-pool-src.loc.1=${base-commons.loc.1}/pool/source/commons-pool2-${commons-pool.version}-src.tar.gz
>
> commons-pool-src.loc.2=${base-commons.loc.2}/pool/source/commons-pool2-${commons-pool.version}-src.tar.gz
>
> -
> -
> # - NSIS, version 2.0 or later -
> nsis.home=${base.path}/nsis-2.46
> nsis.exe=${nsis.home}/makensis.exe
>
> Modified: tomcat/trunk/build.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1573484&r1=1573483&r2=1573484&view=diff
> ==
> --- tomcat/trunk/build.xml (original)
> +++ tomcat/trunk/build.xml Mon Mar 3 09:10:13 2014
> @@ -2576,8 +2576,6 @@ Apache Tomcat ${version} native binaries
>description="Deletes the dependencies that are built from source">
>
> -
> -
>
>
>
>
>
> -
> 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 56215] New: sendError doesn't send error page with AsyncContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=56215 Bug ID: 56215 Summary: sendError doesn't send error page with AsyncContext Product: Tomcat 7 Version: 7.0.50 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Servlet & JSP API Assignee: dev@tomcat.apache.org Reporter: alexalta...@gmail.com This bug is closely related to 51197 (sendError/sendRedirect don't work with AsyncContext). It can be reproduced in the test for 51197, which was created by the reporter of that bug and can be found here: https://github.com/dcheckoway/async-test To reproduce this bug, run the test servlet on Tomcat 7, and hit the "/test/error1" endpoint. This should return a 400 and a related error page. It does indeed return a 400, but not an error page. For the record, this isn't tested by the associated test, namely doTestBug51197 on line 1180 on this file: http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/core/TestAsyncContextImpl.java?view=markup&pathrev=1290875 The test only checks that the endpoint returns and that the status code is correct. The problem, though, is that no error page is generated. -- 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 56010] JspFactory.getPageContext with JspWriter.DEFAULT_BUFFER throws IllegalArgumentException
https://issues.apache.org/bugzilla/show_bug.cgi?id=56010 --- Comment #3 from Konstantin Kolinko --- As far as I am reading, such value can only be used when calling the JspFactory.getPageContext() API directly. The buffer size that can be used in JSP configurations (in a page directive or in jsp-property-group) is either "none" (0) or is measured in kilobytes. (ch. JSP.1.10.1, JSP.3.3.10) But I agree that this feature is a part of the API. Proposed for 6.0. -- 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: r1574015 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Tue Mar 4 10:14:28 2014 New Revision: 1574015 URL: http://svn.apache.org/r1574015 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=1574015&r1=1574014&r2=1574015&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Mar 4 10:14:28 2014 @@ -57,6 +57,14 @@ PATCHES PROPOSED TO BACKPORT: +1: kkolinko -1: +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56010 + Allow to use JspWriter.DEFAULT_BUFFER constant with + JspFactory.getPageContext API. + http://svn.apache.org/r1558811 + http://svn.apache.org/r1574004 (documentation) + +1: kkolinko + -1: + PATCHES/ISSUES THAT ARE STALLED: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1574010 - in /tomcat/tc7.0.x/trunk: ./ java/javax/servlet/jsp/JspFactory.java
Author: kkolinko
Date: Tue Mar 4 10:09:49 2014
New Revision: 1574010
URL: http://svn.apache.org/r1574010
Log:
Merged r1574004 from tomcat/trunk:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56010
Documentation part of the fix
The constants mentioned in JspFactory.getPageContext(..) belong to JspWriter.
There are no such constants in PageContext.
Javadoc in JavaEE 7 (as referenced in bug 56010) has been updated.
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspFactory.java
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1574004
Modified: tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspFactory.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspFactory.java?rev=1574010&r1=1574009&r2=1574010&view=diff
==
--- tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspFactory.java (original)
+++ tomcat/tc7.0.x/trunk/java/javax/servlet/jsp/JspFactory.java Tue Mar 4
10:09:49 2014
@@ -102,9 +102,9 @@ public abstract class JspFactory {
* @param errorPageURL the URL of the error page for the requesting JSP, or
* null
* @param needsSession true if the JSP participates in a session
- * @param buffer size of buffer in bytes, PageContext.NO_BUFFER if no
- * buffer, PageContext.DEFAULT_BUFFER if
- * implementation default.
+ * @param buffer size of buffer in bytes, {@link JspWriter#NO_BUFFER}
+ * if no buffer, {@link JspWriter#DEFAULT_BUFFER}
+ * if implementation default.
* @param autoflushshould the buffer autoflush to the output stream on
* buffer overflow, or throw an IOException?
*
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1574004 - /tomcat/trunk/java/javax/servlet/jsp/JspFactory.java
Author: kkolinko
Date: Tue Mar 4 10:08:12 2014
New Revision: 1574004
URL: http://svn.apache.org/r1574004
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=56010
Documentation part of the fix
The constants mentioned in JspFactory.getPageContext(..) belong to JspWriter.
There are no such constants in PageContext.
Javadoc in JavaEE 7 (as referenced in bug 56010) has been updated.
Modified:
tomcat/trunk/java/javax/servlet/jsp/JspFactory.java
Modified: tomcat/trunk/java/javax/servlet/jsp/JspFactory.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/servlet/jsp/JspFactory.java?rev=1574004&r1=1574003&r2=1574004&view=diff
==
--- tomcat/trunk/java/javax/servlet/jsp/JspFactory.java (original)
+++ tomcat/trunk/java/javax/servlet/jsp/JspFactory.java Tue Mar 4 10:08:12 2014
@@ -102,9 +102,9 @@ public abstract class JspFactory {
* @param errorPageURL the URL of the error page for the requesting JSP, or
* null
* @param needsSession true if the JSP participates in a session
- * @param buffer size of buffer in bytes, PageContext.NO_BUFFER if no
- * buffer, PageContext.DEFAULT_BUFFER if
- * implementation default.
+ * @param buffer size of buffer in bytes, {@link JspWriter#NO_BUFFER}
+ * if no buffer, {@link JspWriter#DEFAULT_BUFFER}
+ * if implementation default.
* @param autoflushshould the buffer autoflush to the output stream on
* buffer overflow, or throw an IOException?
*
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
