Interactions with org.apache.coyote.Request/Response
Hi, Im currently prototyping a NIO connector for tomcat - using tomcat 5.0.28 as a base. This is to solve a specific issue: We have to support a very high number of concurrent connections in a high latency server - and want to remove the thread per connection dependency. In particular, for my use, the aim is not to provide any direct performance gain over standard tomcat (in fact, it is acceptable for actual performance to be less than that of the standard connector). This connector doesn't have to support everything tomcat does for http (although it will support chunked encoding, persistent connections and 100-continue expectations). My idea was simple: Read in full HTTP requests upfront using NIO - parsing using stateful, piece-meal decoders. We can then offer a ByteArrayInputStream up to tomcat as the request stream - which - of course - will never block. Tomcat and associated WebApps can do their thing - with all response data going to an underlying ByteArrayOutputStream under the hoods. When the request has been fully handled, this can then get written out using NIO. The idea is to try and fit this in at a low level - so that maximum re-use can be made of existing tomcat code. Its going well - I've written the parsers and can handle chunked encoding or explicit content length, persistent connections (keep-alive for http 1.0) and 100-continue expectations. What I would really appreciate help with is how best to slot this in to tomcat code. I suppose Im writing a replacement to the org.apache.coyote.http11.Http11Processor (without supporting the InputFilter stuff I expect). It seems that org.apache.coyote.Request / Response are crucial to this. What I'd find invaluable would be any information covering the following: - Where should the underlying output-stream be slotted in to gather up the response data such that maximum re-use can be made of existing tomcat code? - It looks like I'll have to implement the ActionHook stuff to deal with call-backs from the request / response. Is there anything else I'll need to do? - Im planning to have my NIOHttpProcessor use a CoyoteAdapter the same way the Http11Processor does. Does this sound reasonable enough? - Pointers to any documentation I've missed discussing how org.apache.coyote.Request / Response are interacted with by the rest of tomcat - and what I should do to ensure that all response output goes to my ByteArrayOutputStream buffer Any pointers / help / advice would be gratefully received. Many thanks, Dave This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36548] - First undeploy doesn't work
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=36548. 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=36548 --- Additional Comments From [EMAIL PROTECTED] 2005-10-18 10:57 --- According to your reproduce steps, I can NOT reproduce this bug on the latest build. Can you provide testcase? Thanks -- 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 36548] - First undeploy doesn't work
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=36548. 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=36548 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-10-18 11:24 --- *** This bug has been marked as a duplicate of 26135 *** -- 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 36548] - First undeploy doesn't work
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=36548. 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=36548 --- Additional Comments From [EMAIL PROTECTED] 2005-10-18 11:30 --- I don't think it is the same problem and I don't think this one is related to a memory leak i struts. -- 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: Interactions with org.apache.coyote.Request/Response
Irving, Dave wrote: There's no reason to use crap stuff like a BAOS. Just append byte arrays to a buffer. I'll take a look at how this is done in tomcat at the moment. The lower level code doesn't deal with IS/OS constructs, only with byte arrays. - It looks like I'll have to implement the ActionHook stuff to deal with call-backs from the request / response. Is there anything else I'll need to do? No. That's handy. The thing that's currently puzzling me a little is that the Response seems to have an associated stream, but doesn't really write to it itself. When should I actually go about pushing stuff in to that buffer at the connector level? In response to action call-backs? There's Response.doWrite, and that's it. - Im planning to have my NIOHttpProcessor use a CoyoteAdapter the same way the Http11Processor does. Does this sound reasonable enough? I don't care how how you name your classes ;) I was asking more about whether the existing CoyoteAdapter is likely to be re-usable in such a scenario If it's not reusable, then you are in trouble ;) Any pointers / help / advice would be gratefully received. Obviously, you can feel free to experiment all you want, but such a specific connector will not be included in Tomcat. Scalability will be far more limited with your design than even with the fully threaded Tomcat. If all the server is doing are small requests and responses, then it will work well (however, the hybrid model also likes this scenario, so I don't think it will even improve on that), otherwise it will just break. Sure, there's no way I could see this being included in Tomcat proper. Like I said, its just a prototype to see if it solves a specific problem im experiencing (I just cant configure tomcat with 20,000 threads). However, your reply confuses me somewhat. These are not going to be small requests / responses: In fact, they are likely to be fairly large multi-part messages (SOAP and the like). In addition, the processing latency is going to be large (potentially up to 15 seconds per request). Surely this is a reason ** for ** breaking the thread per connection model? Why would it break with anything other than small requests and responses? (There's nothing to stop parsing to be offloaded to a small - probably CPU count matched - thread pool)? If you get large responses, then I figure GC (and maybe memory usage) is going to be a problem (all your buffers will pile up, and most likely they are not going to be short lived objects). A thread will still be needed to run the servlet, so I hope the amount of time spent in the service method will be lower than 15 seconds. Otherwise, there's no real solution besides having a large amount of threads. Personally, I did experiment and implement a hybrid model for connection handling, which improves on some aspects of the regular thread per connection model, while keeping its benefits. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Interactions with org.apache.coyote.Request/Response
Remy Maucherat wrote: A thread will still be needed to run the servlet, so I hope the amount of time spent in the service method will be lower than 15 seconds. Otherwise, there's no real solution besides having a large amount of threads. Yeah, that's the crux of it I suppose. Do you know how much of tomcat assumes single thread request / response? After the request pops out of tomcat (via axis), the processing on our side is already asyncronous: - Receive request - Pass request on for asyncronous processing - Internal request processing completes - Unblock tomcat thread, allowing response to be handled back through axis and tomcat I appreciate that dealing with axis to handle asyncronous responses is out of the scope of this list, but what about tomcat? Would much need to be changed to remove the assumption that everything has been done when servicing the servlet returns? I.e: If I can make my web-apps behave asyncronously, would a whole load need to be done within tomcat to support this? Many thanks, Dave This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interactions with org.apache.coyote.Request/Response
Irving, Dave wrote: Remy Maucherat wrote: Yeah, that's the crux of it I suppose. Do you know how much of tomcat assumes single thread request / response? After the request pops out of tomcat (via axis), the processing on our side is already asyncronous: - Receive request - Pass request on for asyncronous processing - Internal request processing completes - Unblock tomcat thread, allowing response to be handled back through axis and tomcat I appreciate that dealing with axis to handle asyncronous responses is out of the scope of this list, but what about tomcat? Would much need to be changed to remove the assumption that everything has been done when servicing the servlet returns? I.e: If I can make my web-apps behave asyncronously, would a whole load need to be done within tomcat to support this? The container portion deals with the servlet API, which is synchronous (which is good, as it is a workable programming model). Adding additional async capabilities beyond the servlet API, such as IO events, is also possible, but here there will not be any events. I think the conclusion is that your requirements are outside the use cases for which the servlet API was designed for, so besides reusing portions of the code, most of your request processing cannot quite run inside the main servlet container. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Interactions with org.apache.coyote.Request/Response
Remy Maucherat wrote: I think the conclusion is that your requirements are outside the use cases for which the servlet API was designed for, so besides reusing portions of the code, most of your request processing cannot quite run inside the main servlet container. Yes - and after doing a bit more reading around the net, it seems that this is indeed the general consensus. It would appear that some great minds have spent some serious time trying to see how this model could work - and have decided that it just isn't going to. And Im not going to argue with them :o) Fortunately, it turns out that ditching tomcat for this particular use-case isn't such a bad thing. We just use the messaging model of axis (not RPC), so do much of the parsing ourselves. So, time to throw out the servlet API and Axis (proper) and have asyncronous request / response processing, re-using axis to convert the input stream to SOAP objects for us. I think that is going to be far easier to pull that off than what I was proposing before - which Im now beginning to appreciate was a bit crazy. Will still be using tomcat in other areas though - its superb. Dave This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37144] New: - Jasper precompiler didn't free some TLD jars
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=37144.
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=37144
Summary: Jasper precompiler didn't free some TLD jars
Product: Tomcat 5
Version: 5.5.12
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
When using Jasper, via Ant, to precompile JSP with some taglibs, the some are
jars not free after jasper2 exit which is very problematic when using Ant in the
IDE JVM, in my case Eclipse :
Here is part of the ant build file :
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath id=jspc.classpath
pathelement location=${TOOLS_LIB} /
fileset dir=${TOMCAT55_PATH}/bin
include name=*.jar /
/fileset
fileset dir=${TOMCAT55_PATH}/server/lib
include name=*.jar /
/fileset
fileset dir=${TOMCAT55_PATH}/common/lib
include name=*.jar /
/fileset
/classpath
/taskdef
...
jasper2 validateXml=false
uriroot=${build.dir}/jspc/${wname}
webXmlFragment=${build.dir}/dst/${wname}/WEB-INF/jsp.xml
outputDir=${build.dir}/${wname}-src javaEncoding=ISO-8859-1
trimSpaces=true /
--
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: r326103 - /tomcat/site/trunk/xdocs-faq/cluster.xml
Author: pero Date: Tue Oct 18 06:30:23 2005 New Revision: 326103 URL: http://svn.apache.org/viewcvs?rev=326103view=rev Log: only pooled senders can change the number of senders. Modified: tomcat/site/trunk/xdocs-faq/cluster.xml Modified: tomcat/site/trunk/xdocs-faq/cluster.xml URL: http://svn.apache.org/viewcvs/tomcat/site/trunk/xdocs-faq/cluster.xml?rev=326103r1=326102r2=326103view=diff == --- tomcat/site/trunk/xdocs-faq/cluster.xml (original) +++ tomcat/site/trunk/xdocs-faq/cluster.xml Tue Oct 18 06:30:23 2005 @@ -8,6 +8,7 @@ properties author email=yoavs[at]apache[dot]orgYoav Shapira/author +author email=pero[at]apache[dot]orgPeter Rossbach/author titleCluster/title /properties @@ -29,7 +30,7 @@ lia href=#3How do I turn on transport logging?/a/li lia href=#4How do I use JMX to monitor the cluster?/a/li lia href=#5Can I pause the message sending?/a/li -lia href=#6Can I add more senders?/a/li +lia href=#6Can I add more senders (pooled mode)?/a/li lia href=#7What happens when I pull the network cable?/a/li lia href=#8At my windows laptop without network my cluster doesn't work?/a/li lia href=#9The cluster dosen't work under linux with two nodes at two boxes?/a/li @@ -87,7 +88,7 @@ /answer question -a name=6Can I add more senders?/a +a name=6Can I add more senders (pooled mode)?/a /question answer Yes, with sender attribute codemaxPoolSocketLimit=40/code you can have more than the default - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37121] - HTTP Static Partial Content Bug
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=37121. 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=37121 --- Additional Comments From [EMAIL PROTECTED] 2005-10-18 16:43 --- (In reply to comment #5) (In reply to comment #4) It's not about telnet ... it didn't work on my usual file-downloading client ... and oh, it DID work with telnet and my client with the 2600- range. It's not a problem with telnet or sendfile as such... I suspect something more. You can suspect all you want, I'll be looking at facts. So far, it seems to be going to WONTFIX land. Fine. Put up with it and stay with Non-HTTP-Compliant Land :P -- 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 37121] - HTTP Static Partial Content Bug
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=37121. 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=37121 --- Additional Comments From [EMAIL PROTECTED] 2005-10-18 16:50 --- (In reply to comment #6) Fine. Put up with it and stay with Non-HTTP-Compliant Land :P You know, I had figured already you were a whiner. -- 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: r326153 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Author: yoavs
Date: Tue Oct 18 10:03:28 2005
New Revision: 326153
URL: http://svn.apache.org/viewcvs?rev=326153view=rev
Log:
Typo fix in error message, pointed out to me via private email by Entiaz Inan.
Modified:
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Modified:
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/threads/ThreadPool.java
URL:
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/threads/ThreadPool.java?rev=326153r1=326152r2=326153view=diff
==
---
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/threads/ThreadPool.java
(original)
+++
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Tue Oct 18 10:03:28 2005
@@ -1,5 +1,5 @@
/*
- * Copyright 1999-2004 The Apache Software Foundation
+ * Copyright 1999-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -172,7 +172,7 @@
if (threadPriority Thread.MIN_PRIORITY) {
throw new IllegalArgumentException(new priority MIN_PRIORITY);
} else if (threadPriority Thread.MAX_PRIORITY) {
-throw new IllegalArgumentException(new priority MIN_PRIORITY);
+throw new IllegalArgumentException(new priority MAX_PRIORITY);
}
// Set for future threads
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35552] - JMS destination under Context
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=35552. 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=35552 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2005-10-18 19:33 --- Atanu: - Yes, it would be a Resource element for the JMS Topic. - No, we do not have a sample in the current documentation. We would love to add such a sample and surrounding documentation. If you suggest some text, I'll gladly look at it and apply it. Thank you. -- 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]
tomcat/build/tc5.5.x/resources/build.xml
hi,
This file uses cvs but it should do the same with svn. The question is
how to solve the problem:
1 - using a exec/ like:
+++
target name=checkout
exec dir=${basedir} executable=svn
arg line=checkout ${svnroot}/${dir} ${dir}/
/exec
/target
+++
2 - Using svnant (http://subclipse.tigris.org/svnant.html).
3 - Using AntSvnTask (http://antsvntask.sourceforge.net/subtask.html).
4 - Something else? (like using javasvn: http://tmate.org/svn/).
Comments?
Cheers
Jean-Frederic
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37121] - HTTP Static Partial Content Bug
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=37121. 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=37121 --- Additional Comments From [EMAIL PROTECTED] 2005-10-19 00:09 --- (In reply to comment #8) (In reply to comment #6) Fine. Put up with it and stay with Non-HTTP-Compliant Land :P You know, I had figured already you were a whiner. Guys, can we keep this professional? Karthik: what Remy is saying is that he needs more than just a suspicion, as in a documented, **self-contained**, test case which demonstrates the problem. -- 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: r326292 - in /tomcat: connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java container/tc5.5.x/webapps/docs/changelog.xml
Author: remm
Date: Tue Oct 18 16:04:30 2005
New Revision: 326292
URL: http://svn.apache.org/viewcvs?rev=326292view=rev
Log:
- 37121: Sendfile always needs to be given the length of data to write,
not the end of the range. Ranged requests behaved in a weird way and ended
with an error status because of that.
Modified:
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
Modified:
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=326292r1=326291r2=326292view=diff
==
---
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
(original)
+++
tomcat/connectors/trunk/util/java/org/apache/tomcat/util/net/AprEndpoint.java
Tue Oct 18 16:04:30 2005
@@ -1341,7 +1341,7 @@
Socket.timeoutSet(data.socket, 0);
while (true) {
long nw = Socket.sendfile(data.socket, data.fd, null, null,
- data.pos, data.end, 0);
+ data.pos, data.end - data.pos,
0);
if (nw 0) {
if (!(-nw == Status.EAGAIN)) {
Socket.destroy(data.socket);
Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=326292r1=326291r2=326292view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Oct 18 16:04:30 2005
@@ -71,6 +71,10 @@
add
bug36630/bug: Added extra log output for class instantiation
failure. (yoavs)
/add
+ fix
+bug37121/bug: Sendfile always needs to be given the length of data
to write,
+which fixes ranged requests. (remm)
+ /fix
/changelog
/subsection
subsection name=Jasper
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37121] - HTTP Static Partial Content Bug
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=37121. 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=37121 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-10-19 01:20 --- The issue is now fixed (incorrect length parameter passed to the sendfile call), as submitted by Mladen Turk. -- 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]
