[VOTE] Releasing Tomcat Connectors 1.2.22
Hi, Mod_jk 1.2.22 has been available for testing for some days. No new bugs have been reported so far, so it is time to proceed with the release vote. The source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.22/ or http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.22/ Set of Windows binaries is available and can be downloaded from: http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.22/ Set of Windows 64 bit binaries is available and can be downloaded from: http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win64/jk-1.2.22/ The updated documentation can be found at http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs/jk-1.2.22/ So here's the vote, which will be open until Tuesday April 17, 12:00 GMT. Apache Tomcat Connectors 1.2.22 is: [ ] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Mladen Turk wrote: The source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.22/ or http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.22/ May I ask -why-? It's not released (quite yet, has 0 votes) - what on earth is it doing on the mirrors already when it's present in your /dev/ area for the committers to review? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Candidate binaries for 6.0.11
Hi, I also see the APR JMX memory leak with following APR Connector config Connector port=30011 URIEncoding=UTF-8 useExecutor=false minSpareThreads=150 maxSpareThreads=150 maxThreads=150 connectionTimeout=30 protocol=org.apache.coyote.http11.Http11AprProtocol/ pollerSize=1024 / Regards Peter Roßbach [EMAIL PROTECTED] Am 13.04.2007 um 06:26 schrieb Filip Hanik - Dev Lists: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: much appreciated, I'm still working on the deregistering of the JMX resources, somehow they are slipping through the cracks Originally, the purpose of the JMX stuff was to provide thread monitoring. Now that the processors are not tied to threads anymore, it becomes a bit useless IMO. Normally, Java 5+ provides JMX monitoring of threads already, but of course the Tomcat JMX does provide a little more data (that may or may not be worth keeping). I've done the fix for the NIO connector. I believe I have been able to take care of all the problems. In the NIO protocol, I simply got rid of the thread local, and replaced it with a queue. This queue is able to deregister objects, should it be needed. Only time they are deregistered, is if they number exceed the processorCache=int value for max number in the NIO Connector element. The memory leak exists in the APR and JIO connector, when and only when they use the shared Executor and the Executor has a minSpareThreadsmaxThreads. Since these connectors do not use an executor by default, I'd like to get some feedback if these two need to get fixed for the upcoming release. If we are to proceed with the release without fixing these, I would simply note it in the release notes, that to use an executor, use the workaround. I'm open to suggestions...and once again...thanks for your patience (especially since it's me that want this new release) Filip Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
William A. Rowe, Jr. wrote: Mladen Turk wrote: The source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.22/ or http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.22/ May I ask -why-? It's not released (quite yet, has 0 votes) - what on earth is it doing on the mirrors already when it's present in your /dev/ area for the committers to review? Don't understand your question. It was more then a week available for a developers review. The official stable is still 1.2.21 until 1.2.22 gets votes or not, in which case we'll go for 1.2.23. So what's the problem? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Mladen Turk wrote: Don't understand your question. It was more then a week available for a developers review. The official stable is still 1.2.21 until 1.2.22 gets votes or not, in which case we'll go for 1.2.23. So what's the problem? How many times will I repeat to this list that until something has three affirmative votes from PMC members and more affirmative than negative votes, it is not a release from the ASF. And (this might be new to you) anything on www.apache.org/dist/ is official. This primarily protects you - it's your ass (your tarball) until the foundation adopts YOUR tarball as the ASF's release. Ratifying your tarball makes it no longer yours. So any legal fallout was just owned by the ASF. If you want be an RM, or at least play one at an ASF project, let the ASF cover your ass and wait for a vote before hanging yourself out to dry. Look, if it comes up again, I simply won't post here. I'll just point to the archives of the previous warnings/instructions and ask Infra to turn off some group bits as appropriate. The very few, very specific rules were spelled out on THIS dev list at least three times in twelve months. What's the disconnect? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
William A. Rowe, Jr. wrote: Mladen Turk wrote: Don't understand your question. It was more then a week available for a developers review. The official stable is still 1.2.21 until 1.2.22 gets votes or not, in which case we'll go for 1.2.23. So what's the problem? How many times will I repeat to this list that until something has three affirmative votes from PMC members and more affirmative than negative votes, it is not a release from the ASF. And (this might be new to you) anything on www.apache.org/dist/ is official. So shoot me. I suggest you revoke my commit privileges to the www.apache.org/dist/ so it won't happen again and you won't need to repeat this again. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Candidate binaries for 6.0.11
Filip Hanik - Dev Lists wrote: The memory leak exists in the APR and JIO connector, when and only when they use the shared Executor and the Executor has a minSpareThreadsmaxThreads. I know that, I was planning to adapt your patch. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Mladen Turk wrote: I suggest you revoke my commit privileges to the www.apache.org/dist/ so it won't happen again and you won't need to repeat this again. I'm sure infra would be happy to if you would prefer this. I'm assuming the (this might be news to you) was news to you, but this struck me as altogether absurd. I thought everyone grokked why tomcat created the /dev/dist/ in the first place, and I thought everyone at tomcat was altogether with-it now on what constitutes a release. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Candidate binaries for 6.0.11
Peter Rossbach wrote: I also see the APR JMX memory leak with following APR Connector config minSpareThreads=150 maxSpareThreads=150 maxThreads=150 I don't think there's a leak in that connector. For starters minSpareThreads and maxSpareThreads do not do anything. The thread pool used by default never scales back, so processors are never discarded. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
William A. Rowe, Jr. wrote: Mladen Turk wrote: I suggest you revoke my commit privileges to the www.apache.org/dist/ so it won't happen again and you won't need to repeat this again. I'm sure infra would be happy to if you would prefer this. LOL. Man, you really don't like me ;) Is it because I work for Red Hat? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Hi, On 4/13/07, Mladen Turk [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: Mladen Turk wrote: I suggest you revoke my commit privileges to the www.apache.org/dist/ so it won't happen again and you won't need to repeat this again. I'm sure infra would be happy to if you would prefer this. LOL. Man, you really don't like me ;) Is it because I work for Red Hat? Let's try to chill out, please ;) I'm sure putting the candidate binaries on the official mirrors before the vote was an honest mistake. So let's move them to /dev/dist, have a proper vote like we're having right now, and then put the legit release on the mirrors again in a couple of days. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Let's try to chill out, please ;) I'm sure putting the candidate binaries on the official mirrors before the vote was an honest mistake. So let's move them to /dev/dist, have a proper vote like we're having right now, and then put the legit release on the mirrors again in a couple of days. +1 Peace please - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Apache Tomcat Connectors 1.2.22 is: [X] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Thanks for RM. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Apache Tomcat Connectors 1.2.22 is: [x] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
On Apr 13, 2007, at 7:20 AM, Yoav Shapira wrote: Let's try to chill out, please ;) I'm sure putting the candidate binaries on the official mirrors before the vote was an honest mistake. So let's move them to /dev/dist, have a proper vote like we're having right now, and then put the legit release on the mirrors again in a couple of days. ++1 (especially on the chill out part ;) ) !! I think the issue is that, especially with the number of podlings in incubator, the basic release rules for ASF projects are getting kinda relaxed... The main points are that (1) the main legal thing the PMC (and ASF does) is release s/w. It is when almost all aspects of licensing, liability, etc kick in. (2) Therefore the PMC must approve the *exact* distribution being released. For example, if I create tarball A, people test it and say Yep, it's good to go, then tarball A *must* be what is released. I cannot create a new tarball and release that, even if the exact same as tarball A. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
On Apr 13, 2007, at 2:33 AM, Mladen Turk wrote: Hi, Apache Tomcat Connectors 1.2.22 is: [X] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are So let it be written; so let it be done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Jim Jagielski wrote: On Apr 13, 2007, at 7:20 AM, Yoav Shapira wrote: Let's try to chill out, please ;) I'm sure putting the candidate binaries on the official mirrors before the vote was an honest mistake. ++1 (especially on the chill out part ;) ) !! I think the issue is that, especially with the number of podlings in incubator, the basic release rules for ASF projects are getting kinda relaxed... Both of you guys are correct. It was: a) honest mistake b) a mistake So, can we agree I made an mistake? Cheers, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528524 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Author: fhanik
Date: Fri Apr 13 08:32:19 2007
New Revision: 528524
URL: http://svn.apache.org/viewvc?view=revrev=528524
Log:
This write has to be synchronized since comet can write to the buffer and cause
a buffer overflow if more than one thread is writing
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?view=diffrev=528524r1=528523r2=528524
==
---
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Fri Apr 13 08:32:19 2007
@@ -603,7 +603,7 @@
}
int total = 0;
-private void addToBB(byte[] buf, int offset, int length) throws
IOException {
+private synchronized void addToBB(byte[] buf, int offset, int length)
throws IOException {
if (socket.getBufHandler().getWriteBuffer().remaining() length) {
flushBuffer();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528526 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Author: fhanik
Date: Fri Apr 13 08:33:44 2007
New Revision: 528526
URL: http://svn.apache.org/viewvc?view=revrev=528526
Log:
if the flush is not guaranteed, then try again
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?view=diffrev=528526r1=528525r2=528526
==
---
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Fri Apr 13 08:33:44 2007
@@ -604,7 +604,7 @@
int total = 0;
private synchronized void addToBB(byte[] buf, int offset, int length)
throws IOException {
-if (socket.getBufHandler().getWriteBuffer().remaining() length) {
+while (socket.getBufHandler().getWriteBuffer().remaining() length) {
flushBuffer();
}
socket.getBufHandler().getWriteBuffer().put(buf, offset, length);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528528 - /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Author: fhanik
Date: Fri Apr 13 08:39:44 2007
New Revision: 528528
URL: http://svn.apache.org/viewvc?view=revrev=528528
Log:
Prevent NPE on a key that was cancelled by the poller
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?view=diffrev=528528r1=528527r2=528528
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Fri
Apr 13 08:39:44 2007
@@ -1862,7 +1862,7 @@
SelectionKey key =
socket.getIOChannel().keyFor(socket.getPoller().getSelector());
int handshake = -1;
try {
-handshake = socket.handshake(key.isReadable(),
key.isWritable());
+if (key!=null) handshake =
socket.handshake(key.isReadable(), key.isWritable());
}catch ( IOException x ) {
handshake = -1;
if ( log.isDebugEnabled() ) log.debug(Error
during SSL handshake,x);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r528524 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
[EMAIL PROTECTED] wrote: Author: fhanik Date: Fri Apr 13 08:32:19 2007 New Revision: 528524 URL: http://svn.apache.org/viewvc?view=revrev=528524 Log: This write has to be synchronized since comet can write to the buffer and cause a buffer overflow if more than one thread is writing That's reverting 467065. I still don't see how concurrent writing in the servlet is going to work (nothing is synced, and everything is buffered to some extent). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42115] New: - WebappClassLoader.loadClass throws java.lang.ClassNotFoundException: [Ljava.lang.String; in JDK 6.0
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42115. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42115 Summary: WebappClassLoader.loadClass throws java.lang.ClassNotFoundException: [Ljava.lang.String; in JDK 6.0 Product: Tomcat 5 Version: 5.5.23 Platform: Other OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have 2 webapps which communicates using spring remoting. When remote method return type is String, caller web application request fails with the following exception: java.lang.ClassNotFoundException: [Ljava.lang.String; at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1359) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1205) at org.springframework.remoting.rmi.CodebaseAwareObjectInputStream.resolveClass(CodebaseAwareObjectInputStream.java:99) ... etc. This happens only on JDK 6.0. On jdk 5.0 anything works fine. According to Sun, problem is in catalina code. Catalina should load classes using Class.forName(s, false, cl) instead of WebappClassLoader.loadClass(...) Below are references to this problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6434149 https://glassfish.dev.java.net/issues/show_bug.cgi?id=714 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41949] - mod_jk 1.2.21 POST JSP Page SSI JSP sub request does not complete
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41949. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41949 --- Additional Comments From [EMAIL PROTECTED] 2007-04-13 09:23 --- Adding one more comment to bring this bug report to closure. The mod_jk patch listed previously fixed another mod_jk bug but introduced this bug in the Ajp13Connector. By reconfiguring your tomcat server.xml to use the CoyoteConnector with the JkCoyoteHandler instead of the Ajp13Connector fixes this bug on the Tomcat side. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
On Apr 13, 2007, at 10:00 AM, Mladen Turk wrote: Jim Jagielski wrote: On Apr 13, 2007, at 7:20 AM, Yoav Shapira wrote: Let's try to chill out, please ;) I'm sure putting the candidate binaries on the official mirrors before the vote was an honest mistake. ++1 (especially on the chill out part ;) ) !! I think the issue is that, especially with the number of podlings in incubator, the basic release rules for ASF projects are getting kinda relaxed... Both of you guys are correct. It was: a) honest mistake b) a mistake So, can we agree I made an mistake? Hey, I make 'em all the time... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
+1 Am 13.04.2007 um 08:33 schrieb Mladen Turk: So here's the vote, which will be open until Tuesday April 17, 12:00 GMT. Apache Tomcat Connectors 1.2.22 is: [x] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Regards, Mladen
Re: svn commit: r528524 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: fhanik Date: Fri Apr 13 08:32:19 2007 New Revision: 528524 URL: http://svn.apache.org/viewvc?view=revrev=528524 Log: This write has to be synchronized since comet can write to the buffer and cause a buffer overflow if more than one thread is writing That's reverting 467065. I still don't see how concurrent writing in the servlet is going to work (nothing is synced, and everything is buffered to some extent). Lets say you have two threads writing to the response (async write from comet) both of them could end up on the line: socket.getBufHandler().getWriteBuffer().put(buf, offset, length); assuming nothing is synced in the path down to here, hence causing a buffer overflow, Does that makes sense or am I smoking crack? Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528551 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Author: fhanik Date: Fri Apr 13 09:51:54 2007 New Revision: 528551 URL: http://svn.apache.org/viewvc?view=revrev=528551 Log: prevent a timeout when a servlet write is issued, but not flushed Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?view=diffrev=528551r1=528550r2=528551 == --- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java (original) +++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java Fri Apr 13 09:51:54 2007 @@ -609,6 +609,8 @@ } socket.getBufHandler().getWriteBuffer().put(buf, offset, length); total += length; +NioEndpoint.KeyAttachment ka = (NioEndpoint.KeyAttachment)socket.getAttachment(false); +if ( ka!= null ) ka.access();//prevent timeouts for just doing client writes } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42103] - Parans trustStoreType trustStorePass trustStoreFile
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42103. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42103 --- Additional Comments From [EMAIL PROTECTED] 2007-04-13 10:50 --- Created an attachment (id=19954) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19954action=view) Patch to fix parameter name mismatch in Admin webapp -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42103] - Parans trustStoreType trustStorePass trustStoreFile
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42103. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42103 --- Additional Comments From [EMAIL PROTECTED] 2007-04-13 10:51 --- Created an attachment (id=19955) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=19955action=view) Patch to fix parameter name mismatch in Admin webapp This patch plus the one for EditConnectorAction.java should remediate the parameter name mismatch issue in the Admin webapp. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528570 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Author: fhanik
Date: Fri Apr 13 11:08:43 2007
New Revision: 528570
URL: http://svn.apache.org/viewvc?view=revrev=528570
Log:
Use the remaining for the byte buffer as the capacity is the total capacity and
not the limit
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?view=diffrev=528570r1=528569r2=528570
==
---
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Fri Apr 13 11:08:43 2007
@@ -788,8 +788,8 @@
if (socket.getBufHandler().getWriteBuffer().position() ==
socket.getBufHandler().getWriteBuffer().capacity()) {
flushBuffer();
}
-if (thisTime
socket.getBufHandler().getWriteBuffer().capacity() -
socket.getBufHandler().getWriteBuffer().position()) {
-thisTime =
socket.getBufHandler().getWriteBuffer().capacity() -
socket.getBufHandler().getWriteBuffer().position();
+if (thisTime
socket.getBufHandler().getWriteBuffer().remaining()) {
+thisTime =
socket.getBufHandler().getWriteBuffer().remaining();
}
addToBB(b,start,thisTime);
len = len - thisTime;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Jim Jagielski wrote: On Apr 13, 2007, at 10:00 AM, Mladen Turk wrote: Jim Jagielski wrote: On Apr 13, 2007, at 7:20 AM, Yoav Shapira wrote: Let's try to chill out, please ;) I'm sure putting the candidate binaries on the official mirrors before the vote was an honest mistake. ++1 (especially on the chill out part ;) ) !! I think the issue is that, especially with the number of podlings in incubator, the basic release rules for ASF projects are getting kinda relaxed... Both of you guys are correct. It was: a) honest mistake b) a mistake So, can we agree I made an mistake? Hey, I make 'em all the time... Ditto (and sometimes real doozies - the more you help out, the more potholes you can step into :) Futher, it's resolved, I wanted to make sure I hadn't missed something when I posted the first question earlier today. If I knew it was deliberate, I would have simply had Infra resolve it in the first place. I asked first, then Infra solved it, so no crisis. No - I don't dislike you Mladen :) Nor Redhat - work with Marc and Joe all the time on httpd-stuff. Personally - I'm a huge fedora fan, with my work hat on - support hundreds of users on a few orders of magnitude more ES boxes. So not only do I raise this to protect you, but your employer, because I happen to like you both. And it happens to protect the foundation I'm also rather fond of. Yours, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42119] New: - request.getCharacterEncoding misparses charset=UTF-8; xyz=3
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42119. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42119 Summary: request.getCharacterEncoding misparses charset=UTF-8; xyz=3 Product: Tomcat 5 Version: 5.5.23 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Connector:Coyote AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] (This bug is also present in Coyote source 6.0.10.) If there is an HTTP header Content-Type: text/abc; charset=UTF-8; xyz=3 request.getCharacterEncoding() returns UTF-8; xyz=3 but Tomcat 4.1.24 returns UTF-8. In Tomcat 4.1.24, request.getCharacterEncoding uses parseCharacterEncoding defined in jakarta-tomcat-4.1.24-src/catalina/src/share/org/apache/catalina/util/RequestUtil.java and it correctly handles the case of other Content-Type parameters. In Tomcat 5.5.23, however, request.getCharacterEncoding uses getCharsetFromContentType defined in from apache-tomcat-5.5.23-src/connectors/util/java/org/apache/tomcat/util/http/ContentType.java which does not search for a possible terminating semicolon in the charset, thus erroneously including additional characters in the charset. The code in 5.5.23 has a comment begins // Basically return everything after ;charset= Please consider using the code from 4.1.24 This problem showed up when Content-Type was multipart/mixed and a client specified a charset parameter to Content-Type; however, it will occur in any Content-Type where charset is specified and is not the last parameter. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528594 - /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Author: fhanik
Date: Fri Apr 13 12:05:01 2007
New Revision: 528594
URL: http://svn.apache.org/viewvc?view=revrev=528594
Log:
consolidate usage between executor runnables and worker threads
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?view=diffrev=528594r1=528593r2=528594
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Fri
Apr 13 12:05:01 2007
@@ -1836,6 +1836,8 @@
// Process requests until we receive a shutdown signal
while (running) {
+NioChannel socket = null;
+SelectionKey key = null;
try {
// Wait for the next socket to be assigned
Object channel = await();
@@ -1857,10 +1859,10 @@
}
} else {
-NioChannel socket = (NioChannel)channel;
-
-SelectionKey key =
socket.getIOChannel().keyFor(socket.getPoller().getSelector());
+socket = (NioChannel)channel;
+key =
socket.getIOChannel().keyFor(socket.getPoller().getSelector());
int handshake = -1;
+
try {
if (key!=null) handshake =
socket.handshake(key.isReadable(), key.isWritable());
}catch ( IOException x ) {
@@ -1871,30 +1873,32 @@
}
if ( handshake == 0 ) {
// Process the request from this socket
-if ((status != null) (handler.event(socket,
status) == Handler.SocketState.CLOSED)) {
-// Close socket and pool
-try {
-KeyAttachment att =
(KeyAttachment)socket.getAttachment(true);
-
getPoller0().cancelledKey(key,SocketStatus.ERROR,false);
-nioChannels.offer(socket);
-if ( att!=null ) keyCache.offer(att);
-}catch ( Exception x ) {
-log.error(,x);
-}
-} else if ((status == null)
(handler.process(socket) == Handler.SocketState.CLOSED)) {
+boolean closed =
(status==null)?(handler.process(socket)==Handler.SocketState.CLOSED) :
+
(handler.event(socket,status)==Handler.SocketState.CLOSED);
+
+if (closed) {
// Close socket and pool
try {
-KeyAttachment att =
(KeyAttachment)socket.getAttachment(true);
-
getPoller0().cancelledKey(key,SocketStatus.ERROR,false);
+KeyAttachment ka = null;
+if (key!=null) {
+ka = (KeyAttachment) key.attachment();
+if (ka!=null) ka.setComet(false);
+socket.getPoller().cancelledKey(key,
SocketStatus.ERROR, false);
+}
nioChannels.offer(socket);
-if ( att!=null ) keyCache.offer(att);
+if ( ka!=null ) keyCache.offer(ka);
}catch ( Exception x ) {
log.error(,x);
}
-}
+}
} else if (handshake == -1 ) {
-
socket.getPoller().cancelledKey(key,SocketStatus.DISCONNECT);
+KeyAttachment ka = null;
+if (key!=null) {
+ka = (KeyAttachment) key.attachment();
+socket.getPoller().cancelledKey(key,
SocketStatus.DISCONNECT, false);
+}
nioChannels.offer(socket);
+if ( ka!=null ) keyCache.offer(ka);
} else {
final SelectionKey fk = key;
final int intops = handshake;
@@ -1902,6 +1906,8 @@
ka.getPoller().add(socket,intops);
}
svn commit: r528605 - /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Author: fhanik
Date: Fri Apr 13 12:16:08 2007
New Revision: 528605
URL: http://svn.apache.org/viewvc?view=revrev=528605
Log:
remove redundant calls, easier to track usage
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?view=diffrev=528605r1=528604r2=528605
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Fri
Apr 13 12:16:08 2007
@@ -1381,9 +1381,6 @@
else r.reset(socket,ka,OP_REGISTER);
addEvent(r);
}
-public void cancelledKey(SelectionKey key, SocketStatus status) {
-cancelledKey(key, status, true);
-}
public void cancelledKey(SelectionKey key, SocketStatus status,
boolean dispatch) {
try {
if ( key == null ) return;//nothing to do
@@ -1533,10 +1530,10 @@
}
} else {
//invalid key
-cancelledKey(sk, SocketStatus.ERROR);
+cancelledKey(sk, SocketStatus.ERROR,false);
}
} catch ( CancelledKeyException ckx ) {
-cancelledKey(sk, SocketStatus.ERROR);
+cancelledKey(sk, SocketStatus.ERROR,false);
} catch (Throwable t) {
log.error(,t);
}
@@ -1607,9 +1604,9 @@
try {
KeyAttachment ka = (KeyAttachment) key.attachment();
if ( ka == null ) {
-cancelledKey(key, SocketStatus.ERROR); //we don't
support any keys without attachments
+cancelledKey(key, SocketStatus.ERROR,false); //we
don't support any keys without attachments
} else if ( ka.getError() ) {
-cancelledKey(key, SocketStatus.ERROR);
+cancelledKey(key, SocketStatus.ERROR,true);
}else if ((ka.interestOps()SelectionKey.OP_READ) ==
SelectionKey.OP_READ) {
//only timeout sockets that we are waiting for a read
from
long delta = now - ka.getLastAccess();
@@ -1622,14 +1619,14 @@
} else if (isTimedout) {
key.interestOps(0);
ka.interestOps(0); //avoid duplicate timeout calls
-cancelledKey(key, SocketStatus.TIMEOUT);
+cancelledKey(key, SocketStatus.TIMEOUT,true);
} else {
long nextTime = now+(timeout-delta);
nextExpiration = (nextTime
nextExpiration)?nextTime:nextExpiration;
}
}//end if
}catch ( CancelledKeyException ckx ) {
-cancelledKey(key, SocketStatus.ERROR);
+cancelledKey(key, SocketStatus.ERROR,false);
}
}//for
if ( log.isDebugEnabled() ) log.debug(Poller processed
+keycount+ keys through timeout);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r528524 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Filip Hanik - Dev Lists wrote: Lets say you have two threads writing to the response (async write from comet) both of them could end up on the line: socket.getBufHandler().getWriteBuffer().put(buf, offset, length); assuming nothing is synced in the path down to here, hence causing a buffer overflow, Does that makes sense or am I smoking crack? I know, but this doesn't make sense to me, since it will already do thread safety problems in the servlet layer (where there are buffers, etc). If people want to have more than one thread writing, they have to sync. I will not be adding similar checks in the APR connector, but you can leave them in the NIO connector if you feel more comfortable with them. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528702 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors: TcpFailureDetector.java TcpPingInterceptor.java
Author: fhanik
Date: Fri Apr 13 16:26:07 2007
New Revision: 528702
URL: http://svn.apache.org/viewvc?view=revrev=528702
Log:
Added a TCP ping for membership, to be used with static memberships and with
the TCP failure detector
Added:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpPingInterceptor.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java?view=diffrev=528702r1=528701r2=528702
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/tribes/group/interceptors/TcpFailureDetector.java
Fri Apr 13 16:26:07 2007
@@ -180,53 +180,80 @@
}
public void heartbeat() {
+checkMembers(false);
+}
+public void checkMembers(boolean checkAll) {
+
try {
if (membership == null) setupMembership();
synchronized (membership) {
-//update all alive times
-Member[] members = super.getMembers();
-for (int i = 0; members != null i members.length; i++) {
-if (membership.memberAlive( (MemberImpl) members[i])) {
-//we don't have this one in our membership, check to
see if he/she is alive
-if (memberAlive(members[i])) {
-log.warn(Member added, even though we werent
notified: + members[i]);
-super.memberAdded(members[i]);
-} else {
-membership.removeMember( (MemberImpl) members[i]);
-} //end if
-} //end if
-} //for
-
-//check suspect members if they are still alive,
-//if not, simply issue the memberDisappeared message
-MemberImpl[] keys = (MemberImpl[])
removeSuspects.keySet().toArray(new MemberImpl[removeSuspects.size()]);
-for (int i = 0; i keys.length; i++) {
-MemberImpl m = (MemberImpl) keys[i];
-if (membership.getMember(m) != null (!memberAlive(m))) {
-membership.removeMember(m);
-super.memberDisappeared(m);
-removeSuspects.remove(m);
-log.info(Suspect member, confirmed dead.[+m+]);
-} //end if
-}
-
-//check add suspects members if they are alive now,
-//if they are, simply issue the memberAdded message
-keys = (MemberImpl[]) addSuspects.keySet().toArray(new
MemberImpl[addSuspects.size()]);
-for (int i = 0; i keys.length; i++) {
-MemberImpl m = (MemberImpl) keys[i];
-if ( membership.getMember(m) == null (memberAlive(m))) {
-membership.memberAlive(m);
-super.memberAdded(m);
-addSuspects.remove(m);
-log.info(Suspect member, confirmed alive.[+m+]);
-} //end if
-}
+if ( !checkAll ) performBasicCheck();
+else performForcedCheck();
}
}catch ( Exception x ) {
log.warn(Unable to perform heartbeat on the
TcpFailureDetector.,x);
} finally {
super.heartbeat();
+}
+}
+
+protected void performForcedCheck() {
+//update all alive times
+Member[] members = super.getMembers();
+for (int i = 0; members != null i members.length; i++) {
+if (memberAlive(members[i])) {
+if (membership.memberAlive((MemberImpl)members[i]))
super.memberAdded(members[i]);
+addSuspects.remove(members[i]);
+} else {
+if (membership.getMember(members[i])!=null) {
+membership.removeMember((MemberImpl)members[i]);
+removeSuspects.remove(members[i]);
+super.memberDisappeared((MemberImpl)members[i]);
+}
+} //end if
+} //for
+
+}
+
+protected void performBasicCheck() {
+//update all alive times
+Member[] members = super.getMembers();
+for (int i = 0; members != null i members.length; i++) {
+if (membership.memberAlive( (MemberImpl) members[i])) {
+//we don't have this one in our membership, check to see if
he/she is alive
+if (memberAlive(members[i])) {
+
svn commit: r528735 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/core/StandardThreadExecutor.java tomcat/util/net/NioEndpoint.java
Author: fhanik
Date: Fri Apr 13 18:41:35 2007
New Revision: 528735
URL: http://svn.apache.org/viewvc?view=revrev=528735
Log:
Smarter executor, only create threads if no threads are available
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java?view=diffrev=528735r1=528734r2=528735
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardThreadExecutor.java
Fri Apr 13 18:41:35 2007
@@ -219,10 +219,17 @@
}
public boolean offer(Runnable o) {
-if (parent != null parent.getPoolSize()
parent.getMaximumPoolSize())
-return false; //force creation of new threads by rejecting the
task
-else
-return super.offer(o);
+//we can't do any checks
+if (parent==null) return super.offer(o);
+//we are maxed out on threads, simply queue the object
+if (parent.getPoolSize() == parent.getMaximumPoolSize()) return
super.offer(o);
+//we have idle threads, just add it to the queue
+//this is an approximation, so it could use some tuning
+if (parent.getActiveCount()(parent.getPoolSize())) return
super.offer(o);
+//if we have less threads than maximum force creation of a new
thread
+if (parent.getPoolSize()parent.getMaximumPoolSize()) return false;
+//if we reached here, we need to add it to the queue
+return super.offer(o);
}
}
Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?view=diffrev=528735r1=528734r2=528735
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Fri
Apr 13 18:41:35 2007
@@ -2153,8 +2153,17 @@
}
public boolean offer(Runnable o) {
-if ( parent != null
parent.getPoolSize()parent.getMaximumPoolSize() ) return false;//force
creation of new threads
-else return super.offer(o);
+//we can't do any checks
+if (parent==null) return super.offer(o);
+//we are maxed out on threads, simply queue the object
+if (parent.getPoolSize() == parent.getMaximumPoolSize()) return
super.offer(o);
+//we have idle threads, just add it to the queue
+//this is an approximation, so it could use some tuning
+if (parent.getActiveCount()(parent.getPoolSize())) return
super.offer(o);
+//if we have less threads than maximum force creation of a new
thread
+if (parent.getPoolSize()parent.getMaximumPoolSize()) return false;
+//if we reached here, we need to add it to the queue
+return super.offer(o);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528744 - in /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net: NioEndpoint.java SocketProperties.java
Author: fhanik
Date: Fri Apr 13 19:48:45 2007
New Revision: 528744
URL: http://svn.apache.org/viewvc?view=revrev=528744
Log:
Minor optimizations
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/SocketProperties.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?view=diffrev=528744r1=528743r2=528744
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Fri
Apr 13 19:48:45 2007
@@ -1326,7 +1326,7 @@
public void addEvent(Runnable event) {
events.offer(event);
-if ( wakeupCounter.incrementAndGet() 3 ) selector.wakeup();
+if ( wakeupCounter.incrementAndGet() == 1 || wakeupCounter.get()
5 ) selector.wakeup();
}
/**
@@ -1428,7 +1428,10 @@
int keyCount = 0;
try {
if ( !close ) {
-keyCount = selector.select(selectorTimeout);
+if ( wakeupCounter.get() 0 )
+keyCount = selector.selectNow(); //we have
events that need to be processed
+else
+keyCount = selector.select(selectorTimeout);
wakeupCounter.set(0);
}
if (close) {
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/SocketProperties.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/SocketProperties.java?view=diffrev=528744r1=528743r2=528744
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/SocketProperties.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/SocketProperties.java
Fri Apr 13 19:48:45 2007
@@ -82,7 +82,7 @@
* The application write buffer size in bytes
* Default value is txBufSize
*/
-protected int appWriteBufSize = 8192;
+protected int appWriteBufSize = txBufSize;
/**
* NioChannel pool size for the endpoint,
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r528751 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
Author: fhanik Date: Fri Apr 13 20:45:41 2007 New Revision: 528751 URL: http://svn.apache.org/viewvc?view=revrev=528751 Log: minor optimization, go directly to the poller, chances of another request being present at that very time is very slim Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?view=diffrev=528751r1=528750r2=528751 == --- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java (original) +++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Fri Apr 13 20:45:41 2007 @@ -950,7 +950,12 @@ rp.setStage(org.apache.coyote.Constants.STAGE_KEEPALIVE); - +//we're at a keep alive stage, +openSocket = true; +//Add the socket to the poller +socket.getPoller().add(socket); +//free up the thread +break; } rp.setStage(org.apache.coyote.Constants.STAGE_ENDED); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
William A. Rowe, Jr. wrote: So, can we agree I made an mistake? Hey, I make 'em all the time... No - I don't dislike you Mladen :) Nor Redhat - work with Marc and Joe all the time on httpd-stuff. Cool, let's move forward. I'll make sure I don't upload files on random places any more :) Cheers, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r528524 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Lets say you have two threads writing to the response (async write from comet) both of them could end up on the line: socket.getBufHandler().getWriteBuffer().put(buf, offset, length); assuming nothing is synced in the path down to here, hence causing a buffer overflow, Does that makes sense or am I smoking crack? I know, but this doesn't make sense to me, since it will already do thread safety problems in the servlet layer (where there are buffers, etc). If people want to have more than one thread writing, they have to sync. I will not be adding similar checks in the APR connector, but you can leave them in the NIO connector if you feel more comfortable with them. I agree with you, but I'll save the rework of some of this for the next release, I believe I got the connector to a stable point now, don't wanna muck too much with it. Filip Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
