Re: Interactions with org.apache.coyote.Request/Response
Irving, Dave wrote: 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? There's no reason to use crap stuff like a BAOS. Just append byte arrays to a buffer. - 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. - 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 ;) 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. Rémy - 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
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: Sandbox ?
Costin Manolache wrote: Thanks ! I'll add few things I've worked on in the past - if people don't mind, I'll create a sandbox/java and put everything in one tree, ant and IDEs are smart enough to exclude/include different packages. Let me know if any of this seems wrong: - a smaller commons-logging impl, without any discovery tricks ( for runtime ) Another option is to rewrite using a robust platform (I favor java.util.logging). I don't know if that's really a possibility, though, as I didn't ask my boss about it ;) - attempt to refactor util.buf to use ByteBuffers And CharBuffer, I hope. So you'll be extending (ByteChunk extends ByteBuffer) ? I'd like to add BufferedReader features to CharChunk (marking and readLine, as implementing these without owning the buffer is both hard and inefficient). - coyote standalone - a small demo for coyote standalone, using a rhino adapter. - some additions to coyote - to make it a bit easier to use in standalone mode. I have plans to use it to implement a coyote provider for JBoss remoting. This would be a good use case for your stuff. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sandbox ?
Costin Manolache wrote: And CharBuffer, I hope. So you'll be extending (ByteChunk extends ByteBuffer) ? CharBuffer would go to MessageBytes. I'm thinking more as an 'uses' - you create ByteBuffers ( maybe direct buffers ), and you set it in the ByteChunk. "Extend" is not the best choice - it would be hard to work with direct ( or other ) buffers. I'm actually thinking about adding some static methods as well for all the utils we have in BB. I didn't do any tests, but accessing direct buffers contents seems vastly more expensive. I don't see how they could be used other than for: - buffering (as done in the APR connectors) - transferring bytes without manipulating them in Java (ex: sending a file on a socket) Did you do some microbenchmarks ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sandbox ?
Costin Manolache wrote: On 10/23/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: I'm thinking more as an 'uses' - you create ByteBuffers ( maybe direct buffers ), and you set it in the ByteChunk. "Extend" is not the best choice - it would be hard to work with direct ( or other ) buffers. I'm actually thinking about adding some static methods as well for all the utils we have in BB. I didn't do any tests, but accessing direct buffers contents seems vastly more expensive. I don't see how they could be used other than for: - buffering (as done in the APR connectors) - transferring bytes without manipulating them in Java (ex: sending a file on a socket) Did you do some microbenchmarks ? No - and I'm sure they wouldn't look very good, the current implementation seems to just do JNI on each operation, so they are probably more expensive However - the fact that it is badly implemented now doesn't mean they can't be implemented better in future or in a different VM :-), i.e. with special support from the garbage collector, so it can be backed by an unmovable byte[]. Realtime java JSR requires support for unmovable objects ( afaik ) - so sooner or later we may have such a VM, and then direct buffers would be the fastest way to communicate between java and native. Ok. For sending a file on a socket - I'm sure using apr would be faster ( is sendfile wrapper implemented ? ), you shouldn't have to read the file in java. You need to look a bit into the code ;) There is: - APRized HTTP connector with sendfile and poller usage for keepalive - HTTPS support using OpenSSL - APRized AJP connector with poller usage for keepalive Anyway - this is just a sandbox experiment, we can try different things. An unrelated subject - don't know if you saw http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html I don't like very much the implementation ( with Exceptions to control the flow ), but I think there is a good idea to have support in the thread pool to temporary release the thread for long-running servlets, and then get a thread back on some event. How this is made visible to servlets is debatable - I think there are few better ways than what jetty is doing - but the low level is probably more important. I don't like it: - the naming is bad (this is using a poller to get read events, so it's basically an IO event mechanism) - it shouldn't just reinvoke the service method unless it can actually just continue transparently execution (also, in the "compatibility" mode, the execution path isn't the same), and creates the need for proprietary routing logic - it encourages a design for servlets which will run very badly on other servlet containers - the operations for saving/restoring of the request (basically equivalent to FORM) aren't exactly cheap, as well as the usage of a poller It could be implemented relatively easily in the APRized connectors, but given the cost to process a small request over a keepalive connection (it's cheap; for example, the use case for this being a chat room, I don't see how it would perform bad if using separate requests for each message), I don't see any reason to support this. BTW - where do we deal with keep-alive http connections ? ( I remember you or Mladen added code to not keep the thread busy ). The AprEndpoint does this stuff. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sandbox ?
Costin Manolache wrote: On 10/24/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: For sending a file on a socket - I'm sure using apr would be faster ( is sendfile wrapper implemented ? ), you shouldn't have to read the file in java. You need to look a bit into the code ;) There is: - APRized HTTP connector with sendfile and poller usage for keepalive - HTTPS support using OpenSSL - APRized AJP connector with poller usage for keepalive I tought there is something for keepalive in the java connector as well - I guess I was looking in the wrong place, I know apr can do all the cool things, but I couldn't find the equivalent code. It may be nice - and maybe that would make the apr and java code share more code :-) No, there's nothing for the "pure" Java connectors. I don't see the point of trying to do it in "pure" Java, as: - all the network code is native anyway, so it depends on if you prefer the native network code to come from the ASF or your JVM vendor ;) - the API exposed to do the same thing in "pure" Java (when they exist) are unreasonably complex compared with APR It is a way to do even-based IO for servlets - but regardless of name, the actual feature can be usefull. At least for a sandbox setting :-) Not a big priority for me - I was hoping other people would be interested too. Did you look at SIP and SIP servlets ? (maybe you did at Motorola) I think the specification is complex, but it is actually designed for doing this kind of asynchronous IO processing. I don't really understand the point of trying to hack stuff based on the Servlet API and/or HTTP to do asynchronous processing, since neither has been designed for that. - it encourages a design for servlets which will run very badly on other servlet containers Well, long running servlets ( bound to events or slow IO ) will run bad anyway on pure threads servers. But if more servers support the concept - maybe a good solution would emerge, and become part of a future standard. It would certainly be better than seeing it in the next servlet spec - without enough implementation experimentation. This would make the programming model a lot more complex and would act funny with web frameworks. Honestly, I'm not hot about it right now. It could be implemented relatively easily in the APRized connectors, but given the cost to process a small request over a keepalive connection (it's cheap; for example, the use case for this being a chat room, I don't see how it would perform bad if using separate requests for each message), I don't see any reason to support this. In the chat room case - you can never get 'instant' messages, you depend on the polling frequency. Yes, it does add significant latency. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status/Authority of AJP/1.5
Henri Gomez wrote: AJP 1.5 should support automatic discovery of tomcat backend, new systems and new webapps. That's the current need for many of us when adding tomcats / webapp behind Apache 2 webservers. In such case we need to restart them and it's sad. How could it be accomplished, may be via a master tomcat who will give the tomcat farm topology to Apache HTTP2. What do you think ? I think this is completely useless. This cannot quite work in "real" load balancing or failover deployments, where I doubt admins would use straight mapping for the webapps, or also would want to control the timing of enabling the new deployments (otherwise, servers will go online automagically while stuff is being installed, and other cool side effects like this). The "admin" webapp currently provided by mod_jk and mod_proxy is a far more practical way to do things, as admins will want control over magic. The main use case for this is the dumb 1 Apache <-> 1 Tomcat deployment, which has no future, so breaking compatibility to improve this deployment style is not a good move. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r329053 - in /tomcat/sandbox/java: ./ org/ org/apache/ org/apache/commons/ org/apache/commons/logging/
[EMAIL PROTECTED] wrote: Author: costin Date: Thu Oct 27 19:55:08 2005 New Revision: 329053 URL: http://svn.apache.org/viewcvs?rev=329053&view=rev Log: Implementation of commons-logging that doesn't use any discovery or tricks, just plain java.util.logging. There is a trick actually - at startup it'll try to load a different handler ( without 2-lines logs ) and a different config ( from classpath like log4j ). I'll probably remove this later, but I can't stand the default handler and behavior I'm ok with including your formatter in the JULI bundle, and using it in the default configuration (the one which is in conf/logging.properties). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r329081 [1/2] - /tomcat/sandbox/java/org/apache/tomcat/util/buf/
[EMAIL PROTECTED] wrote: Author: costin Date: Thu Oct 27 21:11:42 2005 New Revision: 329081 URL: http://svn.apache.org/viewcvs?rev=329081&view=rev Log: Import the current version of o.a.t.util.buf, for refactoring. I'm trying to use nio. Added: tomcat/sandbox/java/org/apache/tomcat/util/buf/ tomcat/sandbox/java/org/apache/tomcat/util/buf/Ascii.java tomcat/sandbox/java/org/apache/tomcat/util/buf/B2CConverter.java tomcat/sandbox/java/org/apache/tomcat/util/buf/Base64.java tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java (with props) tomcat/sandbox/java/org/apache/tomcat/util/buf/C2BConverter.java tomcat/sandbox/java/org/apache/tomcat/util/buf/CharChunk.java tomcat/sandbox/java/org/apache/tomcat/util/buf/DateTool.java tomcat/sandbox/java/org/apache/tomcat/util/buf/HexUtils.java tomcat/sandbox/java/org/apache/tomcat/util/buf/MessageBytes.java tomcat/sandbox/java/org/apache/tomcat/util/buf/StringCache.java tomcat/sandbox/java/org/apache/tomcat/util/buf/TimeStamp.java tomcat/sandbox/java/org/apache/tomcat/util/buf/UDecoder.java tomcat/sandbox/java/org/apache/tomcat/util/buf/UEncoder.java tomcat/sandbox/java/org/apache/tomcat/util/buf/UTF8Decoder.java tomcat/sandbox/java/org/apache/tomcat/util/buf/package.html Along with the CharChunk funcionality update, can CharSequence support be added to it as well ? (the JDK regexp engine uses that interface) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rewrite features
Hi, As part of the JBoss Web project, I have developed a URL rewrite valve, more or less cloned on mod_rewrite. It doesn't support everything from mod_rewrite, and there's no docs at the moment, but it's not too hard to figure out how to use it. For looking at it and testing, it's here (of course, it's neither polished nor well tested at the moment): http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jboss/web/rewrite/ Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rewrite features
Yoav Shapira wrote: Hi, Cool, I like it. Two questions: - Why the RewriteMap interface? It does seem to add much over a normal Map, and I doubt you're targeting JDK 1.1 compatibility ;) It's not a map (at least not a Java map). mod_rewrite calls the directive RewriteMap. - Seems like this could be easily done as a Filter instead of Valve. The lifecycle support would be a bit different, start -> init, stop -> destroy, etc, but otherwise it doesn't seem like a stretch... A filter would not work. Doing it this way will (eventually) be a lot more efficient. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rewrite features
Costin Manolache wrote: On 11/3/05, Bill Barker <[EMAIL PROTECTED]> wrote: It probably doesn't matter (since nobody uses it :), but using ThreadLocal won't work with the Nio/AJP Connector. That one doesn't bind a Request instance to a Thread instance, so a particular Request instance will process on many different Threads during its lifecycle. Does the spec say anything about the thread model when executing a servlet ? ( too lazy to search, I know some people on the list have memorized the spec already :-) I'm not sure how this happens - I tought that the request is bound to a thread during service() execution, and kept-alive connections are no longer bound. How do we unbind the service() from the thread ??? There must be a misunderstanding somewhere: the thread is indeed bound during the execution of the adapter process method, so TLs should work the way I am using them. Using notes is difficult for this because there can be "nested" rewrites (one at host level + one at context level, for example). I would have preffered using that for performance, of course; maybe an array would do it, or something, but TLs are cleaner to understand. I do need plenty of TLs anyway, as the regexp engine is per thread. For some reason, it took me a long time to figure out a design that I liked, worked and met the requirements (I suck). As for putting this at a lower level, no, because Mladen wanted to be able to specify per host and per context rules, so mapping has to occur first, and then be performed again (there are other features which need ). Having it as a rule is equivalent to putting it (unless in stupid cases where the rewrite valve is set after another valve that is expensive to invoke). Since it's our product, we have some specific requirements ;) Side effect: if MessageByte and CharChunk were implementing CharSequence, I could just give them to the regexp engine without having to do useless toString calls. Note: this feature is something that I don't want in Tomcat; just imagine the non portable mess that webapps would become if rewrite was readily available ... Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rewrite features
Bill Barker wrote: We don't unbind the service() from the Thread. However, in Coyote Request instances are very long lived objects that (at least for HTTP/1.1) persist over many connections. The APR Connector uses a ThreadLocal to bind the Request instance to a single Thread instance. The next request that it handles may have been received on a different Socket than the last, but it is bound to the Thread. With the Java HTTP/1.1 Connector, the Request is bound to the Thread via the init() method of ThreadPoolRunnable. The Nio/AJP Connector binds the Request instance to a Socket connection (via the SelectionKey.attachment). Personally, I always considered the Request/Response objects were tied to the thread. I don't know for sure, but it could mean that my valve may not work with your connector then (the utility object that resolves special variables uses the request, and it could be an issue). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sloppy, Lazy Tomcat Developers (Was: Persistent "xmlValidation" Problem)
Bob Bronson wrote: Another lazy copout!! Even the web.xml that is distributed w/Tomcat does not validate! Did you even test this before you replied to my note or did you just assume the user was at fault??? When someone criticizes the poor state of an open sores project (as I am doing now), the typical response from the open sores programmer is to shift responsibility to the user -- the user is often told to dig through the change logs or browse the forum archives or even to fix the bug/documentation themselves instead of "complaining". What an unprofessional, lazy attitude from programmers! The open sores programmers try to cast *their* laziness as the user's laziness for "not digging deeply enough" to resolve their own problem, or even fixing the problem themselves by going into the source code. The fact that the Tomcat User mailing list often receives over 150 messages a day is more a testament to Tomcat's crappy documentation than to its popularity. Yes, yes, I know Tomcat is "not for me". You're damned right. I'm happy to pay money for quality. I guess Tomcat bares out the old adage, "you get what you pay for". If you don't feel special enough, I can do it in two seconds and can get you a cool membership to the "dev-deny" list :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rewrite features
Bill Barker wrote: The TomcatResolver instance is holding a reference to the Request instance, and is in a TL. As a result (because of the way the ThreadPool works) it will live very much longer than just during the processing of a given Request. This is all fine for all of the current Connectors except Nio/AJP, since they happen to bind the Request instance to the Thread instance so you always get the right Request instance. Adding a setRequest method to TomcatResolver would "fix" this with the minimal amount of work. Since TomcatResolver is a very simple object, I replaced the thread local by a new TomcatResolver. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sloppy, Lazy Tomcat Developers (Was: Persistent "xmlValidation" Problem)
Costin Manolache wrote: Well, my point was - do we really need this feature ? If nobody is really using it - it doesn't work out of box and we didn't see any major complaint except Bob - it may be simpler to just remove the flag from the docs and server.xml - and maybe even remove the code that does this validation. Or move it to some module that is not distributed by default, in case we have 2-3 users. I believe we no longer include the xerces parser in some of the distros - so even a fix in xerces will be useless, users will need to upgrade the VM. It is silly to depend on a very specific parser and version - and keep options, code, documentation - for a feature that nobody really uses. I'd prefer leaving it, and the user, if he's interested in the feature, will have to find a Xerces build that works (I tested, and the one we ship in the compat package works fine for all webapps; the one from my JDK 1.5 has issues though, with the 2.3 webapps). Don't worry though, we'll deviate from a pure Servlet/JSP server quickly enough ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r331098 - /tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
[EMAIL PROTECTED] wrote:
Author: pero
Date: Sun Nov 6 01:39:26 2005
New Revision: 331098
URL: http://svn.apache.org/viewcvs?rev=331098&view=rev
Log:
Fix NPE when simple use only "GET HTTP/1.0\r\n\r\n"
Why endpoint.getAddress() don't give back local address?
Tested at Windows XP with tomcat 5.5.12.
This patch does not make any sense to me, starting with the modified
condition. I understand it is trying to fix a problem, but this is not a
good way. -1.
Note: Obviously, the HTTP connector has the same code.
Rémy
Modified:
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL:
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java?rev=331098&r1=331097&r2=331098&view=diff
==
--- tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
Sun Nov 6 01:39:26 2005
@@ -830,7 +830,7 @@
*/
public void parseHost(MessageBytes valueMB) {
-if (valueMB == null || valueMB.isNull()) {
+if (valueMB == null || (valueMB != null && valueMB.isNull()) ) {
// HTTP/1.0
// Default is what the socket tells us. Overriden if a host is
// found/parsed
@@ -838,8 +838,14 @@
InetAddress localAddress =
endpoint.getAddress()/*socket.getLocalAddress()*/;
// Setting the socket-related fields. The adapter doesn't know
// about socket.
-request.setLocalHost(localAddress.getHostName());
-request.serverName().setString(localAddress.getHostName());
+if(localAddress != null) {
+request.setLocalHost(localAddress.getHostName());
+request.serverName().setString(localAddress.getHostName());
+} else {
+ log.error("host address " + endpoint.getPort() + " '" +
endpoint.getAddress() + "'");
+ request.setLocalHost("localhost");
+ request.serverName().setString("localhost");
+}
return;
}
-
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: svn commit: r331870 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
[EMAIL PROTECTED] wrote: Author: markt Date: Tue Nov 8 11:32:28 2005 New Revision: 331870 URL: http://svn.apache.org/viewcvs?rev=331870&view=rev Log: Simple part of fix for bug 37150 based on profiler output. Doesn't fix the major culprit. Needs more work. This bug report is nonsense ... Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r331870 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Mark Thomas wrote: Remy Maucherat wrote: [EMAIL PROTECTED] wrote: Author: markt Date: Tue Nov 8 11:32:28 2005 New Revision: 331870 URL: http://svn.apache.org/viewcvs?rev=331870&view=rev Log: Simple part of fix for bug 37150 based on profiler output. Doesn't fix the major culprit. Needs more work. This bug report is nonsense ... No it isn't. If it was, I would have closed it as invalid along with an explanation as to why it is invalid. I have a trivial JMeter test that re-creates the problem and a profiler output that shows where the problems are. The larger the number of files in the directory, the easier it is to reproduce. I have been using 1000. Analysing the output of the profiler, 96% of the time is spent in renderHtml(). Digging deeper 49% of the time is spent in ProxyDirContext.lookupCache() and 26% in rewriteURL(). My patch reduced the rewriteURL() figure from 33%. Not a big help but a simple, obvious fix. I haven't looked further at rewriteURL() yet to see what, if anything, can be done to speed this up. I have been looking at ProxyDirContext.lookupCache(). Every single call to ProxyDirContext.lookupCache() results in a call to ProxyDirContext.revalidate() which in turn calls FileDirContext.file(String). This is an expensive method call, mainly due to File object creation and the call to File.getCanonicalPath(). The cache should take most of the load here but what happens is if the cache isn't valid (eg the first time a directory listing is requested) the calls to ProxyDirContext.revalidate() take so long that by the time the next directory listing is created, the cache is invalid again. On my reasonably powerful dev box, two requests in parallel are enough to slow things down to a crawl for a few minutes. Increasing the TTL on the cache would reduce the frequency of the lock-up, but things are still going to slow down once the cache expires. I have some ideas to optimise the process of looking up the directory contents but nothing concrete and I want to make sure any patch doesn't open up any security holes. It's a directory listing, how can this be fast, or even useful besides for casual users ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r331870 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Mark Thomas wrote: Remy Maucherat wrote: It's a directory listing, how can this be fast, or even useful besides for casual users ? At the moment, directory listings with large numbers of entries = DOS threat. Whatever we do, this is a valid security issue and we need to deal with it. Very funny. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 37150] - denial of service on many and long requests on v5.5.x
Mark Thomas wrote: Looking at the profiler output, I agree that this will always be slow. Closer inspection shows that at best I could reduce the time spent generating the listing by about a third. Not enough to make a major difference to this case. Therefore, a warning in the docs is called for. Something like: "Directory listings of directories containing many entries is an expensive process. Multiple requests for large directory listings can consume significant proportions of server resources. Use this option with caution." The only remaining question is whether we turn directory listings off by default. Thoughts? I am ok with disabling it by default if you like it better, although the problem is not very big. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r332351 - in /tomcat/container/tc5.5.x: catalina/src/bin/catalina.bat webapps/docs/changelog.xml
[EMAIL PROTECTED] wrote: Author: yoavs Date: Thu Nov 10 10:44:53 2005 New Revision: 332351 URL: http://svn.apache.org/viewcvs?rev=332351&view=rev Log: Bugzilla 37319: http://issues.apache.org/bugzilla/show_bug.cgi?id=37319 Modified: tomcat/container/tc5.5.x/catalina/src/bin/catalina.bat tomcat/container/tc5.5.x/webapps/docs/changelog.xml I use Windows, and use exclusively catalina.bat. It works fine (in the code, you'll see that there is replacement code for system properties - the installer uses them, please don't "fix" that occurrence ;) ), and will (hopefully) work just as fine with the fix. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r344145 - in /tomcat/current/tc5.5.x: connectors/ container/ jasper/
Henri Gomez wrote: Thanks :) Somehow it fixed it. I thought it was worth a try. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r332801 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Peter Rossbach wrote: Hey Remy, I have problems with your last ClassLoader changed. When I used following code: protected static final String info = "org.objektpark.catalina.session.LogSessionListener/1.1"; Yes, I know, I have more changes (which may include commenting out the thing). Sorry for the trouble. Unfortunately, I am having problems getting testing done :( Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r345233 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Peter Rossbach wrote: Thanks for the fix and it works for my case. Hibernate developers claim the classloader gets leaked with Hibernate webapps, and also claim it is a Tomcat bug. So I'm trying to find a workaround. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the JSSE15SocketFactory class missing from the standard tomcat 5.5.12 binary distribution?
Yoav Shapira wrote: Hi, Mmm, I'm not sure. The download page is already somewhat cluttered with a bunch of different distributions and their assorted files (zip/tar.gz, PGP and MD5 for each, etc.) I don't want to double the number of binary distributions per release. And I'm even less excited about doing something like retroweaver (http://retroweaver.sourceforge.net/) to cross-compile 1.5 source to 1.4 compatibility. But perhaps it's time we just start building with J2SE 5.0 by default, instead of 1.4? It's a bit risky though. Will the JSSE impl for 1.4 be built properly ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?
Costin Manolache wrote: Check the build.xml files, look for 'unless'. Probably the right solution to avoid this would be to stop using 'unless' and ant checks, and instead move all the 'conditional' code in separate targets and jar files. In particular, the whole SSL stuff is an unpredictible mess. I'm not even sure if/how can we use OpenSSL via APR ( I found some code, and it should work ). The whole connection layer should be It actually works. refactored to allow better abstraction for APR, NIO, old-style sockets/threads... The current approach in APR ( duplicate everything ) may be good for quick tests, but it can't be the long term solution ( some people like to add a NIO equivalent ). I'm perfectly fine with it. I prefer duplicating things than having a complex abstraction layer (if you compare the APR API with the NIO/Java IO API, you'll see APR is simpler, so the connector code can be a bit simpler - for equivalent functionality at least). At this point, I see non APR connectors as having no future production wise. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?
Costin Manolache wrote: So for NIO - we should create another copy of 5 large files ? Most of the functions are complete duplicates - a simple extend would eliminate them. The problems are in few abstractions - like Handler - which can be easily fixed to accomodate NIO / APR or traditional. NIO is a valid solution - and may be as fast as APR, in particular with JDK1.6 - and it avoids the JNI layer. I like APR more too - but I don't think it's wise to say there will be no better solution in the future :-) It just happens that today APR is faster - and has a lot of features beyond NIO. IMO the future is in features integrated at the low-level with the VM - in particular if they can bypass JNI or use non-garbage-collected heaps ( as in real-time java ). It would be hard for any JNI solution to beat this - but of course, that's future, not so easy to predict... I completely disagree. APR is a well accepted IO impl for webservers (obviously), and works very well. There's room for experimentation as separate implementations, but should NIO get better and support the features we need (somehow, I doubt the second one will ever be the case ...), there's going to be ample time to switch to it later (emphasis on later; Java 6 as the Tomcat target is quite far away). In the meantime, I don't see the point of yet another abstraction layer. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?
Costin Manolache wrote: For C++ servers - yes. For Java servers - is anyone else using it besides tomcat ? Even in tomcat - how many people are using the bindings ( compared with the non-apr connector ) ? Unfortunately - NIO is the well-accepted solution for java servers ( all except tomcat are using it ). We know APR is better - but can't pretend it's an 'accepted' solution. The truth is, few people are using Java web servers, and it's not going to change. I'm curious to know how NIO is a well accepted solution for web servers, BTW. Not a new abstraction layer - just adjustments to the current one. For example - add the 'long' socket to TcpConnection - and adjust comments in TcpConnectionHandler - so it can be used instead of the Handler. Then most Apr classes could extend the corresponding non-APR classes, and only override what's different. It's not the perfect abstraction - but if you also add NIO, you could later extract a base class that has none of the apr/nio/classic methods, and avoid duplication. Adding NIO in the same way as APR was added would be a nightmare - the current APR code is already messy ( Sendfile for example ). I'm sorry, I like APR, but I can't like the current implementation ( except as a good initial step ). Again, I completely disagree. The low level code is small enough that an abstraction layer is useless. Similarly, a lot of the code in j-t-c/util should go (starting with the "threads" package). To get down to the root of the problem, I don't like the argument that NIO is any good as an IO API. Besides the (many) utility classes like the buffers, and as a JNI access method, both of which can be used without sencond thoughts (and are actually used right now), all the actual IO code is still all native (no surprise) and the Java API on top is over engineered. It doesn't make sense to me. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] APR or NIO ? (was:Re: Any other functionality missing from Tomcat 5.5.12 that relies on JSDK 5.0?)
Costin Manolache wrote: NIO is used AFAIK by Jetty and Resin, and probably others. And it's the 'standard' solution for select-like operations ( even if the standard is as usual not the best solution ). Selects and stuff like that is the reason why I will vote against NIO, so I find all this quite ironic. This stuff are implementation details: we do not need to use a "standard" if it doesn't make sense, since it is not exposed to users. Well, most java APIs - including the servlet - are over engineered. And most are far from perfect solution ( again, servlet is a good example :-). Yes, I also hate the way buffers flip and you can't know where is the data ( before or after position ), most of the channel and select are more complex than the APR equivalent. But NIO is a valid solution - with 1.6 I'm pretty sure the performance will be comparable ( with poll, etc ). APR is not the only valid solution ( and on top of that - the way we implement the connector on top of APR is far from either simple or right ). I think we need to organize a community vote then, so that I do not waste my time. So here we go: I think the IO design for connectors used by Tomcat should be: [ ] NIO selectors, etc (this means 100% NIO) [ ] APR (this means 50% NIO, where NIO is only used for all the objects exposed at the higher level) Obviously, I vote APR. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] APR or NIO ?
Mladen Turk wrote: No. I would like that we accept in our (Tomcat) community much more pluralism, in a similar way the Apache httpd community does with mpm models. Neither blocking, APR or eventually NIO will ever be the best solution for a particular user needs. Blocking will outperform any solution for a complex applications. APR will outperform any other solution where large static file delivery is required, etc... Let's focus and actually see if the current connector API allows to build those various connectors. I think it does, so it's up to implementor to implement the connector. Then, we can simply have multiple connectors that will allow users to choose the optimal one according to the needs, not to what we think he might need. I do not wish to have any pluralism in this area, as it is not the same as having the httpd pluralism. There's a functional need for this pluralism (process friendly OS, thread unsafe modules, etc), and besides we're talking about the IO API, not the thread pool. The question is: should we redesign the low level stuff *again* to be more abstract, etc, to be able to have as little IO API specific code in the connectors ? (and most likely standardize on the limited NIO feature set) My answer to this is no, APR is the only good solution right now, so there's no need for more abstraction layers. Pluralism in a shipped product is bad: we need to provide one good solution at a given point in time, not 10. That solution may change in the future, however (but I doubt it, since I don't see NIO providing any of the platform specific stuff APR provides), and experimentation using separate connectors is obviously ok. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] APR or NIO ?
Costin Manolache wrote: < > 1. Yes, it's how things should be done < > 2. No, it can be done better My opionion is (2). My opinion is 1. I will not participate in the design of the upcoming Tomcat branch, then. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] APR or NIO ?
Costin Manolache wrote: On 11/19/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: Costin Manolache wrote: < > 1. Yes, it's how things should be done < > 2. No, it can be done better My opionion is (2). My opinion is 1. I will not participate in the design of the upcoming Tomcat branch, then. Well, I'm not planning any 'upcoming branch' - or 'design' for that matter, just small adjustments, in sandbox first. Fair enough. The minute you commit your "refactoring" to the main branch, I will leave this project (besides casual bugfixing). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r345767 - in /tomcat/sandbox/java/org/apache/coyote/http11: Http11AprProcessor.java Http11Processor.java InternalAprInputBuffer.java InternalInputBuffer.java
[EMAIL PROTECTED] wrote: Author: costin Date: Sun Nov 20 10:19:56 2005 New Revision: 345767 URL: http://svn.apache.org/viewcvs?rev=345767&view=rev Log: Remove even more dups. It seems the apr and non-apr were not actually in sync, there are at least 2 places where extra SecurityManager magic was used in non-apr. Modified: tomcat/sandbox/java/org/apache/coyote/http11/Http11AprProcessor.java tomcat/sandbox/java/org/apache/coyote/http11/Http11Processor.java tomcat/sandbox/java/org/apache/coyote/http11/InternalAprInputBuffer.java tomcat/sandbox/java/org/apache/coyote/http11/InternalInputBuffer.java I am not going to bother tetsing this stuff. As you may have noticed, many of the algorithms used behaves in subtly different ways. The result of the merge is of course going to be exponentially more difficult to maintain (and, obviously, I am not going to be the one doing it). Why not removing APR support instead since you (and all the other members of the community, it seems) don't like it ? As for the security manager magic, I refactored some of it. As HTTP on java.io is robust, well tested, but not optimal anyway, I didn't bother porting back those simplifications. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAAS Realm not working since 5.5.10 (possible solution provided)
Markus Plail wrote: Not a single answer? Can't it be reproduced or what's the problem with my problem? If I am right it would be a significant issue wouldn't it? Sorry. Two bug reports about this, and should be fixed in CVS. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] APR or NIO ?
Costin Manolache wrote: I hope you are not serious... Sorry if I sounded too critical of the APR code - it is a great piece of code in many ways, I just didn't like some (probably minor) things. Ok, but it helped make me realize I should maintain my own tree anyway, since my plans are a bit opposed to your refactoring. Also, I have medium term requirements which most likely are going to not fit with what Tomcat needs :( If you have a problem with 'refactoring' - right now it is in sandbox, and I can as well change the package name and make it a completely separate connector. And I'm in no hurry to check anything in the main branch - the sandbox is prefect for me, so no need to worry about this. Yes, I guess I shouldn't complain too much about code which is being designed in the sandbox, sorry about that :) > I don't like 'alghoritms that behave in sublty different ways', or > duplicating extremely complex > classes just for 3-4 lines of code that is different. I know it is > simpler to write and probably maintain the code ( for people who wrote > it ), but not easier to understand for me. Yes, I understand that, but for me the algorithm is already a bit complex since, although it looks similar, the process method is completely different. Hopefully, it has no bugs right now ! Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] APR or NIO ?
Henri Gomez wrote: Well why so much noise about NIO/APR ? Because I don't want to have to support 20 different connector technologies (you can call it a business requirement). So one has to be labelled as "experimental" or something. Similarly, the connector options right now are (for me) a bit too large. If some want to experiment APR or NIO, why can't they do their works on some sort of incubations projets and when stable enough give us benchmarks results. Benchmarks/tesings should give us information on : stability, speed, memory usage, IO usage and of course we should have these on many platforms. For example if the alternative implementation is running fast as hell on Linux but has no gain on Windows or iSeries should we consider it usefull to users ? Also should we depend on APR on a java centric project ? Apparently not ;) I've got no problem with APR, it's a very good piece of code, running well even on exotic platforms like iSeries (and probably BS2000 jfc ?), but should we use a native library as the fundation of Java products ? The code it replaces in the JVM is all native, written by the JVM vendor. For most users, it's written by Sun, and parts of it (java.nio select functionality, for example) have seen reliability issues. Fixing these kind of problems in this key component (at least in the case of a web server) requires updating the whole JVM. Besides Sun, and hopefully the other JVM vendors, I don't see how to actually do support on a NIO Tomcat. APR OTOH is used heavily in a similar production usage on all the platforms that we want to support. Also since we're speaking about a future Tomcat redesign, shouldn't we take care of the future JVM implementations ? Sun, IBM JVMs for now but in the future GJC and upcoming Harmony ? If these use APR or something similar in native land, should we use APR directly ? Unless the said JVMs get certified, I think only a few people are going to use them for real usage. BTW, yes, APR is still needed, as the JVM can only expose a small subset of the functionality through java.nio. I'd like to see here pragmatics informations on gains expected when using NIO/APR/WHATEVER in real life situations which is what users and admins expects. I can give a real life example using AJP where the current connector doesn't work. If you have many front end Apache servers and few Tomcat servers, since the AJP connections are persistent, the backend servers will not be able to serve requests. APR allows using a poller for keepalive, so this solves the problem and the thread count on backend servers will remain sane. Have a good day and peace on Tomcat Dev community Ok :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to turn the Digester off?
anita kulshreshtha wrote: Since there was no reply, I am assuming that turning off the digester is not straightforward. Could someone please point me to the relevant code? Thanks Anita --- anita kulshreshtha <[EMAIL PROTECTED]> wrote: I am using tomcat as an embedded engine and the web.xml is parsed once by Geronimo. I want to avoid the duplicate work. You mean Geronimo does the parsing of web.xml, TLDs, etc, to correctly setup servlets and listeners ? I would find that surprising. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN oddities with "current" link
Costin Manolache wrote: Container, jasper and build are a good start. I think connectors should be included too. Servletapi is obviously different, and even in the current build it's downloaded as a jar AFAIK. You can still have separate releases and release cycles for different components - even if they reside in the same SVN tree ( or even same java/ source tree ). As we learned, labels are cheap, so there's no problem if you release and label different things. I hope more components could follow the 'separate release' model - /admin and most webapps, many other things that could be modules. At least in 6.x timeframe. Yes, I can testify it's easier to work with, and it only took me a few minutes to put together (warning: it's APR only, JNDI is removed, etc, so a full Tomcat repository has to be more complex to build), the setup in Eclipse only takes a few minutes, and building is faster (no webapps, though). http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/ Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Crash with apr when RequestProcessor accessed
Peter Rossbach wrote: Hey, A customer report today a very strange tomcat crash to me and I can simulate this bugs with following releases and OS's: Tested with Suse 9.3, Tomcat 5.5.12 /Apr 1.2.2 / openssl 0.9.8, jdk 1.5.0_03 Also tested with current SVN Head and fresh build tcnative from head and Tomcat 5.5.12 / Maldens tcnative 1.1.0 dll / Windows XP Start Tomcat with APR Http Connector and JSR 160 JMX Adaptor request some pages via http Connector start jconsole / open Mbeans tab Open RequestProcessor tree Open one off the RequestInfo MBeans Can you give the full stack trace just to be sure ? This seems a bit evident though: the HTTP connector has guards for (socket != null) and the APR HTTP connector would need equivalent (socket != 0). Woops, bad Java to APR translation. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Crash with apr when RequestProcessor accessed
Peter Rossbach wrote: Hey, A customer report today a very strange tomcat crash to me and I can simulate this bugs with following releases and OS's: Tested with Suse 9.3, Tomcat 5.5.12 /Apr 1.2.2 / openssl 0.9.8, jdk 1.5.0_03 Also tested with current SVN Head and fresh build tcnative from head and Tomcat 5.5.12 / Maldens tcnative 1.1.0 dll / Windows XP Start Tomcat with APR Http Connector and JSR 160 JMX Adaptor request some pages via http Connector start jconsole / open Mbeans tab Open RequestProcessor tree Open one off the RequestInfo MBeans Let me know if my change fixes the problem, as I didn't even try to reproduce the problem (and during the time I was using it with the APR connector, neither the status servlet nor the JMX proxy crashed on me). I did add guard code like there was in the HTTP connector, which critical here as these are pointers. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Crash with apr when RequestProcessor accessed
Peter Rossbach wrote: Hey Remy, I have tested your patch (suse 9.3) and it fix the jvm crash problem. Currently I have only tested with http apr connector. Cool. AJP can't have the issue (the action method doesn't make any socket access). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN oddities with "current" link
Costin Manolache wrote: Yes, that's what I'm talking about - but on the tomcat svn :-). Can we do the same here ? Only for HEAD ( or at least for 6.0 ), so moving forward we could keep things simpler. BTW - a nice facility in eclipse and ant is the exclude, so the tree can include multiple connectors, and multiple features - but still have full flexibility in what is released and in what packaging. What do you mean by "JNDI removed" - removed from the classloader and file servlet ? That would be really nice ( at least like an option ) :-) What is the license on your changes ? Anything that can be contributed back ? I mean I removed (parts of) the code to support datasources, etc, all of which are provided by JBoss. I don't know what the license is supposed to be at the moment. At the moment, there's nothing to contribute back. I'll try to continue committing interesting things in the future. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: set maxSpareThreads and minSpareThreads and see a next strange APR Connector behaviour
Peter Rossbach wrote: Why we can set maxSpareThreads and minSpareThreads at APR Http and APR AJP threadpools? Because of interdependencies with the regular connector. It won't do anything. I have seen another strange behaviour: After a small load 10 requests and two hour no request the AJP and HTTP Server sockets are closed and threadspools are not running anymore (running jmx attribute say false). It works fine for me, and I've noted reliability was fine. If reliability is in doubt, it's the same as always, get a thread dump. That exception can't be caused by the fact that one connector is used rather than another, anyway. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getContext() - spec interpretation
Mark Thomas wrote: Bill Barker wrote: I can't really dispute the interpretation of the spec, but the change is likely to break many more webapps then it fixes :(. I thought this too. However, I think we should implement the spec as is. If we start relaxing it here, then where else do we relax it? If other Servlet containers start relaxing the specs in their own ways it rapidly defeats the object of having a spec in the first place. As it happens, the SSI functionality depends on the incorrect getContext() implementation and I intend to use the current getContext() implementation as the basis for a fix to the SSI code. This fix should be transferable to other web-apps that have similar dependencies on getContext(). My preference is to post a 'heads-up' to the users list that this change is coming in the next release along with a link to the SSI changes so users can start to look at their apps ahead of the next release. Personally, I don't see any way right now other than keep the current behavior (at least that will be the case in my tree) :( Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross-Context Session Replication
John Lewis wrote: As was discussed here over the summer, there is a need in the JSR-168 Portlet community to use cross-context access so that a portal webapp can communicate with various portlet webapps. Unfortunately, session replication in a Tomcat cluster does not occur when one webapp accesses another webapp's context and changes occur in the session of the target webapp. Unicon now has several clients that are extremely eager to see cross-context session replication support built into Tomcat. Given that this work would be difficult for someone not already familiar with the Tomcat code, are there any experienced Tomcat developers out there who would be interested in doing this work for pay? Of course we are eager to have this change incorporated into the main Tomcat code, so having an existing Tomcat committer do this would be ideal. If anyone qualified is interested, please contact me directly. We will undertake the effort ourselves if necessary, but obviously we would prefer to find a community-oriented solution to the problem. I proposed to use the session.endAccess method to do that, but nobody seemed interested in actually implementing it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cross-Context Session Replication
Peter Rossbach wrote: Hey, I am highly interessed to support cross-context for cluster session replication. The session.endAccess is a neat place for support this. Please, let us discuss how we can use it. In your ClusteredSession, you can override endAccess (don't forget to call the superclass) and populate a thread local structure of some sort, or something like that. Then the valve looks at the structure and replicates all the sessions that need to be replicated. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Host Manager Question
Yoav Shapira wrote: Hi, One way that comes to mind is to do anything (at all) in the Admin webapp, then click its "commit changes" button. This seems like a workaround, but I've used it in the past anyways because usually after deploying a new host I need to tweak some of its configuration... Possibly, this stuff just calls operation "storeConfig" on the server MBean. I didn't fully verify this, and don't really remember. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r354093 - in /tomcat/build/tc5.5.x: build.properties.default tomcat.nsi
[EMAIL PROTECTED] wrote: Author: mturk Date: Mon Dec 5 08:29:19 2005 New Revision: 354093 URL: http://svn.apache.org/viewcvs?rev=354093&view=rev Log: Use tomcat-native-1.1.1 version. Modified: tomcat/build/tc5.5.x/build.properties.default tomcat/build/tc5.5.x/tomcat.nsi There are a couple problems remaining: - the AprEndpoint should be updated to require version number 1.1.1 (I did it, but see point 2) - the binaries on the Ireland download site (http://tomcat.heanet.ie/native/1.1.1/) are still numbered 1.1.0, so the AprEndpoint check always fails Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r354093 - in /tomcat/build/tc5.5.x: build.properties.default tomcat.nsi
Mladen Turk wrote: Remy Maucherat wrote: There are a couple problems remaining: - the AprEndpoint should be updated to require version number 1.1.1 (I did it, but see point 2) - the binaries on the Ireland download site (http://tomcat.heanet.ie/native/1.1.1/) are still numbered 1.1.0, so the AprEndpoint check always fails OK. I've cut a new release and binary builds. They are with correct version number now (1.1.1) Could you double-check? It looks ok. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release 5.5.14 or retag 5.5.13
Yoav Shapira wrote: I'll tag and cut 5.5.14 tomorrow like a new release. I don't want to re-tag 5.5.13, I think that would confuse users more. I'll make the changes clear in the release announcement email (that's why I wanted clarification myself ;)). I'm planning to do it at 9am my time, which is 1400h UTC/GMT tomorrow, December 6th. Sorry for all the trouble. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
5.5.14 packaging
Hi, For some reason, download sizes for 5.5.14 are far bigger than 5.5.13. What's wrong ? I downloaded the zip to have a quik look, and it seems some stuff is back in the main bundles, including for example javadocs. I don't see any relevant changes in the build scripts. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 5.5.14 packaging
Yoav Shapira wrote: Hi, Mmm. I didn't change the build scripts, but I played around a bit with the packaging to get the uncorrupted sample.war in there. That little file is so much more of a pain than it's worth. I'll regenerate the packages and re-upload them now. Good thing I hadn't announced the release yet ;) Unless I missed something, it seems to me now the only difference is the javadocs. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat v5.5.14 Stability
Yoav Shapira wrote: Hi, Tomcat v5.5.14-beta has been out for about a week now. If you have tested it, please vote on its stability below using our usual guidelines. (And if you haven't tested it yet, please give it a whack ;)) Tomcat 5.5.14 is: [ ] Stable [ ] Beta - At least one significant issue preventing stability (please elaborate) [ ] Alpha - Multiple significant issues (please elaborate) As a reminder, only committer votes are binding. Everyone's opinion is welcome, of course. There's that clustering bug that Peter said was critical :( So how critical is it ? Fix Bug 37808 -- 'java.lang.ArrayIndexOutOfBoundsException inside XByteBuffer.java. Very production critical bug, arrgh! Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat v5.5.14 Stability
Bill Barker wrote: "Yoav Shapira" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Tomcat 5.5.14 is: [ ] Stable [X] Beta - At least one significant issue preventing stability (please elaborate) [ ] Alpha - Multiple significant issues (please elaborate) BZ 37852 is about as significant as it gets :). It looks either invalid or very minor (if real) to me, and I will not look into it at all. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving memory efficiency
Tino Schwarze wrote: What do you think about this issue? It's a fine solution for your "problem", I suppose. Thanks for the patch, but we are not going to use it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving memory efficiency
Tino Schwarze wrote: Hi Costin, On Sun, Dec 18, 2005 at 10:01:08AM -0800, Costin Manolache wrote: One of the problems is that jasper is a tricky piece of code, and usually reducing memory this way can have unexpected impact. Maybe a more 'moderate' approach would be more acceptable, like checking the size of the buffers, and only reset it if it is indeed 'huge'. This would take care of the worse case, yet still allow keeping the buffers around for normal use. Don't know what testing you did (to evaluate the performance impact of the change), but try with a very large number of concurent requests. That's where avoiding buffer allocations is most visible, Remy spent a lot of time making sure no buffer is allocated in the critical path under load. Well, performance is probably affected by my proposed patch. I just had a setup to hunt the memory "leaks". Maybe we could introduce a threshold like 4 times the default buffer size. If a buffer is above this, it will be reinitialized when the pageContext is released. It might also be worthwile to not throw away these buffers but to pool them (if they don't get too large), so only the arrays containing the buffers need to be (re)allocated. In the current implementation you might end up with huge buffers hanging around which are unlikely to be used again (e.g. they may have been allocated during a high-load period and are now referenced by tags deeply "hidden" in the tag pools). I don't think tags which use large bodies are going to perform well at all. The API isn't actually designed for that. Discarding the char array will cause every single tag invocation to create a very large amount of garbage arrays and copying around of data. If it works for you, then good, but I think configuring the VM's memory settings appropriately is better. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving memory efficiency
Costin Manolache wrote: One of the problems is that jasper is a tricky piece of code, and usually reducing memory this way can have unexpected impact. Maybe a more 'moderate' approach would be more acceptable, like checking the size of the buffers, and only reset it if it is indeed 'huge'. This would take care of the worse case, yet still allow keeping the buffers around for normal use. I think I will do the following changes: - Use a system property to initialize USE_POOL - maybe switch to using a thread local rather than the current pool (now that the thread count is supposed to correspond to actual concurrency), which I don't like - as for "like checking the size of the buffers, and only reset it if it is indeed 'huge'. This would take care of the worse case", performance of tags using this would really suck since allocating char arrays and System.arraycopying many many times will be needed for every tag invocation (the API design is to be blamed, I guess); I suppose I can add another system property flag to allow using the crap-performance-mode Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving memory efficiency
Costin Manolache wrote: Assuming that most of the pages use 'huge' buffers - you're right. However, if you have few pages that need large buffers - and most don't - this will help. And you would pay the price of System.arraycopy on the bad pages - i.e. normal pages will be faster, and jsps that abuse the buffer will be even slower than before. I think it's a good tradeoff, having bad performance for pages that abuse the tag buffers is a given anyway :-) As I understand it, these pages should have acceptable performance right now. Probably not great, but hopefully not too bad either. Feel free to build a test case that could be ab-ed :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 6 plans (JSP 2.1)
Hi, Besides adding support for Servlet 2.5 which does not seem too overwhelming, most of the specification work is on support of JSP 2.1. I am happy to report that Jacob Hookom is willing to contribute code to add the necessary JSP support in Tomcat (he has done such an implementation already, and owns the copyright on that code). To host the code, a new branch is going to be needed for Jasper (as well as a new folder in servletapi). For testing the implementation, Jacob is going to need access to the JSP 2.1 TCK (I suppose he'll need to be a committer to do that, but it should be ok by then). Comments ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored
Jason Novotny wrote: Hmm, can you tell me where this convention is defined anywhere? This is not just a problem for my portal but a few others out there that have presented instructions that no longer work. If say three portal projects including Pluto and Jetspeed claim this is a problem can it be considered a bug? If you don't like it, you'll have to use a different container. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5.5.12 WARNING: A docBase XXX inside the host appBase has been specified, and will be ignored
Yoav Shapira wrote: If they explain their desired functionality exactly, we can certainly discuss it further. I still wouldn't call it a bug because it's functioning as designed for 5.5 (as noted previously, this is slightly different from 5.0). The point was to remove redundant information to make the deployer reasonably robust. People can develop a new deployer (and associated manager webapp) with more capabilities if they want to, but I am -1 for touching the behavior of the current one in this area, since it will cause it to revert to broken 5.0.x behavior. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jasper in Tomcat 5.0.x
Hi, If new Tomcat 5.0.x releases are made, I would be in favor of using the Jasper from Tomcat 5.5.x. IMO, using a branch for Jasper was only justified while features were being added and stabilization was needed, but in the end, the only significant one was the update to the compiler. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCK Issue with Tomcat 5.5.12
Bill Barker wrote:
AFAICT, this code is assuming that there will always be a message body in
the POST Request. However, this is not necessarily the case (and is
certainly not true for the problem at hand). Eventually,
SocketInputStream.read() is called from within
o.a.coyote.http11.InternalReadBuffer.fill(). This call will throw a
SocketTimeoutException.
Then the test is broken. It should either have a 'Content-Length: 0' header
or a 'Transfer-Encoding: chunked' header with a '0' content delimater. I
don't do NDAs, so I don't know which it is. If Sun can't follow the RFC, I
really don't care.
Or it could close the input of the socket (note: nobody should be crazy
enough to use this method, though, as I suppose it won't work in many
cases). One of the three methods is required, otherwise the request is
invalid. Of course, we could decide that Tomcat should instead consider
these sort of requests (no content-length + no chunking) to have no body
(in the HTTP processor) to get more robust handling, since the client
obviously doesn't know what it's doing at this point. To summarize, this
could break "legitimate" HTTP/1.0 POSTs
In prepareRequest, this block could be modified and the if (keepAlive)
removed:
if (!contentDelimitation) {
// If there's no content length and we're using keep-alive
// (HTTP/1.0 with keep-alive or HTTP/1.1), assume
// the client is not broken and didn't send a body
if (keepAlive) {
inputBuffer.addActiveFilter
(inputFilters[Constants.VOID_FILTER]);
contentDelimitation = true;
}
}
Kevan, please provide a dump of the request causing the problem.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 plans (JSP 2.1)
Henri Gomez wrote: Well a Tomcat will a small memory footprint is also very interesting for me :) How is Tomcat memory usage large ? Personally, I would think it's extremely reasonable given the feature set, at least when using APR. It would seem the base Java runtime would completely offset any gain there. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 plans (JSP 2.1)
Allistair Crossley wrote: Hi, Personally I am less interested in a small footprint Tomcat and more interested in tools that help manage and report on the internals of Tomcat. Instrumentation, JMX, effective and stable debugging and deployment, clustering and load balancing are the types of areas that would help me out with our corporate intranet. I doubt any of these issues are of real concern to the development team because they are supporting of the main container, but they matter on the front-line and often piecing together different technologies via modules which have varying amounts of documentation and stability is tough and time-consuming. I've been fighting getting in WebLogic, WebSphere and Jboss but it looks like it's going that way in 2006 :( Personally, I am also not interested at all in changes to the container architecture either, and I plan to keep using the current codebase to do the Servlet 2.5 support in JBoss. It mostly does what I need, and I think changing it a lot would break more things than what it would fix. - Debugging: No idea, do you have some ? - Deployment: Ok, it's an independent module (HostConfig, and the associated manager webapp, basically); I did it twice already, I think it's half decent, but I am sick of it, so if anyone feels like doing it again, go ahead. - Clustering: We have clustering already. What's wrong with it besides bugs ? (if it had bugs, it's because of not enough users, testing, and bugfix contributors: you can help) - Load balancing: We have mod_jk, and now mod_proxy in Apache 2.2. Do you need more ? I had ideas for an AJP APR client implementation, but I am not sure there's an actual demand for that (I don't see the point of having a Tomcat as a front end server, given it's a single purpose task and exisitng ASF software seem to be doing it just as well). BTW, I am biased, but I don't see a move to JBoss as being that bad. If you use a web oriented configuration, you end up with something that has the same web capabilities as Tomcat, but with a few more robust components for important functionality (TM, datasource, clustering, etc). Unfortunately, it uses more resources ;) May I also take this opportunity to thank those that have helped with any queries I've had this year, Merry Christmas. I'm also very sorry I have not yet been able to accomplish what I wanted to in 2005 which was to rewrite Tomcat's documentation in DocBook. It's still something I am highly interested in as I think documentation is critical and important to everyone on the ground. All the best with Tomcat 6, I would love to help with docs where I can but I will need to see if I can work out some time. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 plans (JSP 2.1)
Jess Holle wrote: The main item you didn't mention is instrumentation/JMX. This is an area that should not require any substantive rearchitecture and could greatly benefit most users. I know JBoss has more JMX stuff, but having the Tomcat end of things quite well instrumented in Tomcat proper seems like the right way to go. Ah ok. Well, I thought you could get a lot of JMX stuff already. I have to support a number of servlet engines, so I ended up doing my own MBeans for things I can get at via the servlet APIs, i.e. so I have portable request and session monitoring/timing/logging, etc. There are, however, things that are not accessible via the servlet APIs or are just a royal pain to do at that level (e.g. accurate per request I/O byte counting/logging). I'm also uncertain what debugging improvements should be made if any -- apart from the fact that precompilation of JSPs does not seem to generate full SMAP information even when told to do so (yes, I filed this on BZ, but I've not had a chance to delve further myself). That's either user error on my part (though I'm baffled as to how this could be) or a plain/simple bug, though. The only bit with deployment I can think of is easing/automating/documenting means of deploying to a cluster of Tomcats at once. I could just be overlooking wonderful capabilities in this regard, however, as I've not really looked all that hard here. Of all the things that I quoted, I guess the biggest one is the deployer. I can't help but notice the JBoss deployer looks more robust to me, but then reinventing it doesn't look to too productive to me. BTW, I am biased, but I don't see a move to JBoss as being that bad. If you use a web oriented configuration, you end up with something that has the same web capabilities as Tomcat, but with a few more robust components for important functionality (TM, datasource, clustering, etc). Unfortunately, it uses more resources ;) There is something to be said for using just enough hammer. Unless you need EJBs, a TM (i.e. other than JOTM), or JMS, it's not clear why you'd add the extra layers. [I suspect someone will pipe in with info on a nice open source, maybe even XA-aware JMS provider that can be used without an app server as well.] I don't see a big difference with Tomcat, which is also an appserver (hopefully, you don't associate EJB <-> appserver, because if you do, I'm not talking to you ever again :) ). Marketting is king, though, and I understand the desire to look like a rebel and refuse the "big fat appserver" in favor of a random set of "independent" components which in the end do and are actually the exact same thing. Unless the appserver is monolithic, but that's not the current trend (but even if it is, sometimes they are actually small). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 plans (JSP 2.1)
Henri Gomez wrote: Well memory is not the only point, faster start and less class to be loaded is also very important for me. In my company we're still using Tomcat 3.3.2 on our production servers (iSeries) since they are quite fast to start and that's very important when you have at the same time not less than 20 or 25 instances of Tomcat starting in its own JVM (one tomcat for a customer since the applications hosted have differents life cycle and constraint). Did you actually compare memory usage of an JVM instance with 3.3.2 with 5.5.14/APR (using APR and AJP will make the thread count much lower which should save you a decent amount of memory - see the appropriate parameters for the connector) ? As for faster start, sorry, there is not much that can be done: the spec requires a lot of stuff now, and modern webapps actually tend to do much more than Tomcat itself. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 plans (JSP 2.1)
Costin Manolache wrote: I understand this doesn't help for JBoss - but tomcat != jboss. I don't see the need for refactorings, and that's my *personal* opinion. It's funny that JBoss does have most of this capability already - so I understand Remy not wanting to reinvent the wheel :-), but I don't think he can deny that this is a good thing to have. Very funny. Who implemented hot deployment in Tomcat ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCK Issue with Tomcat 5.5.12
Bill Stoddard wrote: Nope, that's incorrect. From RFC2616, the official HTTP standard definition: The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A bodyless POST request w/o a TE or CL header field is permitted by RFC2616. Of course, if the POST really does have a body, then bad things are guaranteed to happen. It's a HTTP/1.0 request. Is that still true ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCK Issue with Tomcat 5.5.12
Bill Barker wrote:
Tomcat handles it much the same way for for a 404 ;-).
However, I'm guessing that Httpd sets up an EOS-only bucket-brigade (but am
not interested enough to look it up :), so that if the target existed and
tried to read the body they would just get EOS.
Given that the request is malformed under RFC1945, so Tomcat probably should
do the same thing (which is basically what Remy's patch does).
What patch ? Removing this line ? (I guess it doesn't hurt: if no
content delimitation, assume no body was sent in all cases)
if (!contentDelimitation) {
// If there's no content length and we're using keep-alive
// (HTTP/1.0 with keep-alive or HTTP/1.1), assume
// the client is not broken and didn't send a body
>>if (keepAlive) {
inputBuffer.addActiveFilter
(inputFilters[Constants.VOID_FILTER]);
contentDelimitation = true;
}
}
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCK Issue with Tomcat 5.5.12
Kevan Miller wrote: Bill, Bill, and Remy -- thanks for your help. I've raised bug 38030 -- http://issues.apache.org/bugzilla/show_bug.cgi?id=38030 - I don't read bugzilla - it is not a bug (the request is invalid) So please close your report. FYI, I tested TC behavior with an HTTP 1.1 POST without a message body and no content-length. It worked, properly. However, I noticed an 8 second delay between request and response. I assume TC was blocking in a socket read until it timed out... That doesn't seem very desirable... Possible to target the fix for 5.5.14? No, it's already out. To be honest, I don't really care about the issue, and you should still be challenging the test. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TCK Issue with Tomcat 5.5.12
Kevan Miller wrote: I've also demonstrated that Tomcat's behavior for bodiless HTTP 1.1 POST Requests is terrible (Tomcat will still attempt to read a message body and will not send a Response until the Socket Read times out). Sure, that was a great demonstration. I will not sleep until this imaginary issue is fixed. The TCK test is invalid (this is not a negative test about seeing if an invalid request is handled in a robust way or not), but feel free to be lazy and ignore it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r359753 - /tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Processor.java
[EMAIL PROTECTED] wrote:
Author: billbarker
Date: Wed Dec 28 23:58:51 2005
New Revision: 359753
URL: http://svn.apache.org/viewcvs?rev=359753&view=rev
Log:
Unconditionally return EOS for an attempt to read the body of any request that
doesn't send CL or TE.
I haven't seen any real objections to the patch (and it can't break a working
HTTP/1.0 client :). Also, it brings us in like with what Httpd does in this
case.
Fix for Bug #38030
Submitted By: Remy
I have to do a separate, identical, commit for the HTTP connector people
should be using, then.
In JK, I don't understand the usage of the "read required" field. It
seems to be set according to:
// Check to see if there should be a body packet coming along
// immediately after
int cl=req.getContentLength();
if(cl > 0) {
JkInputStream jkIS = ep.getInputStream();
jkIS.setIsReadRequired(true);
if(!delayInitialRead) {
jkIS.receive();
}
}
Does this work with chunking ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r359753 - /tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Bill Barker wrote: Without actually checking, mod_jk/mod_proxy_ajp should only send an unrequested initial bodyChunk if the client sends a CL. So if there is no CL, Tomcat will send back GET_BODY_CHUNK message, and act on the response from Httpd/IIS/SunOne. The main purpose of the "read required" field is to clean up if the Servlet fails to actually read the (small) Request body, even though Httpd sent it to Tomcat. Now (like the APR/AJP Connector), Tomcat doesn't attempt to actually read (by default) the unrequested initial bodyChunk until the Servlet asks for it. However, if Httpd sent it, and the Servlet didn't ask for it, Tomcat needs to get it out of the the Socket stream, or bad things are going to happen ;-). I have no idea if I need to make a similar change in APR AJP. This stuff is a bit black magic to me. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r360466 - /tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
[EMAIL PROTECTED] wrote: Author: billbarker Date: Sat Dec 31 16:24:57 2005 New Revision: 360466 URL: http://svn.apache.org/viewcvs?rev=360466&view=rev Log: Fix handling of the special first Body-Chunk packet. Somebody that knows the APR interface better than me could probably clean this up (e.g. swallow an unread first Body-Chunk in recycle instead of in process). However, it probably doesn't actually make much difference in terms of processing speed. I haven't actually tested this, but now it's doing much the same thing as the JK/Java Connector, so it should be fine. If it works, then it's really cool since it's so simple. The performance impact should be very small, I think. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cutting Tomcat 5.5.15 tomorrow (Tuesday)
Yoav Shapira wrote: Happy new year everyone ;) Unless I hear a -1 in response to this message, I will tag and cut Tomcat 5.5.15 tomorrow (Tuesday, 3 Jan 2006) at 10am my time (EST), which is 1500h GMT. Are you sure all the needed clustering fixes are in ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cutting Tomcat 5.5.15 tomorrow (Tuesday)
Filip Hanik - Dev Lists wrote: why would you replicate session data across contexts? cross context means different webapps, maybe I'm confused, but an app would never fail over from one webapp to a different webapp. Right now, only the session for the webapp which first recieves the request is checked for replication. If the request dispatches to another webapp, modifications to the sessions in those webapps will not be replicated right now. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EL and JSP 2.1
Mark Thomas wrote: The key questions are: - does 6.0.x become the main development branch? Yes. We did this for 5.5.x and it worked. Ok. - do we merge jasper and container? No. Good to keep them independent. Ok. - do we merge build and container Maybe. If someone wants to take the time to do this and update the build scripts great. Personally, not an itch I feel the need to scratch. The JSP implementation is independent, so there's no change here. - do we maintain servletapi for 6.0? No for the api stuff proper. We don't host it, can't change it and our own implementation would be more trouble than it is worth. Maybe for the examples. It is useful to be able to fix problems with them. The examples could always be merged in with the container module. I think we should have an implementation of the new API. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Mauro Bertapelle wrote: Is it correct that coyote reply with the home page contents on an HTTP OPTIONS method request ? If you post another message on this list that belongs to the user list, I'll ban you. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Mauro Bertapelle wrote: oops, sorry I wasn't sure where to post it Ok. If you have questions about usage of Tomcat, you should post on [EMAIL PROTECTED] Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r367115 - /tomcat/connectors/trunk/coyote/src/java/org/apache/coyote/Response.java
[EMAIL PROTECTED] wrote: Author: markt Date: Sun Jan 8 14:48:43 2006 New Revision: 367115 URL: http://svn.apache.org/viewcvs?rev=367115&view=rev Log: Fix bug 29214. containsHeader() not working for Content-Length and Content-Type I don't like this fix (to a non issue), but since I have the opportunity of not using it, you can leave it in if you want to. Rather than adding complexity in code which is critical, I would have hacked instead the org.apache.catalina.connector.Response.containsHeader method, which is not actually used at all (except by application code, IMO for weird reasons). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial EL/JSP 2.1 Contribution
Jacob Hookom wrote: I've posted an initial contribution of a complete EL-API implementation under Apache 2.0 licensine, along with the EL-API itself (JSR-245-EL).\ EL Implementation (org.apache.el.*) http://www.hookom.net/jacob/tomcat/el.zip EL API (javax.el.*) http://www.hookom.net/jacob/jsr245-el.zip I've been rolling this code base into JSP 2.1 within a local sandbox, but I still have questions about the particulars of the overal project packaging for Tomcat 6. Very good :) Personally, I still would like to "start slow" and for now create a tree or something only inside the jasper module. As for the package names, I don't know. For sure I don't want to leave the el in commons. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r367826 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/Response.java webapps/docs/changelog.xml
[EMAIL PROTECTED] wrote: Author: markt Date: Tue Jan 10 15:06:22 2006 New Revision: 367826 URL: http://svn.apache.org/viewcvs?rev=367826&view=rev Log: Alternative patch for bug 29214 based on Remy's comments I didn't have time to look into it much, but I would have thought using coyoteResponse.getContentLength() != -1 would be more good enough. Otherwise, the code isn't really that much simpler. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial EL/JSP 2.1 Contribution
Mark Thomas wrote: Based on this, I propose the following changes to svn. copy /tomcat/jasper/tc5.5.x/ to /tomcat/jasper/tc6.0.x/ create /tomcat/jasper/tags/tc6.0.x/ Eventually, /tomcat/jasper/tc5.5.x/ will move to /tomcat/jasper/branches/tc5.5.x/ but I think this move should take place when all of the tc5.5.x modules are moved to modulename/branches/ and the full tc6.0.x modules are created. Commits to /tomcat/jasper/tc5.5.x/ will have to be merged with /tomcat/jasper/tags/tc6.0.x/ If I don't get any -1's in the next 72 hours, I'll make the changes set out above. Yes, I think it's the right way for now. Thanks :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r367826 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/Response.java webapps/docs/changelog.xml
Mark Thomas wrote: I thought about doing it that way but I wanted to catch the difference between Content-Length defaulting to -1 and the page developer explicitly setting it to -1. It is an edge case I admit but I don't see any harm in covering it given where the implementation now sits. I don't think Content-Length: -1 is a valid value for the header in the response. Since the header is treated as special, I also don't think a header will be added to the response in that case. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial EL/JSP 2.1 Contribution
Costin Manolache wrote: What about: 1. create tomcat/tomcat6.0 2. mkdir tomcat/tomcat6.0/jasper Or even better: 2. mkdir tomcat/tomcat6.0/java/org/apache/tomcat/jasper You can do all the work on jasper in the tomcat6.0 svn module, and maybe in time other components will move here as well. The build.xml changes for this case will be the same with what you propose, you still need to get jasper from a different place when building tomcat6.0, etc. Personally, unless you really insist, I would still like to keep Jasper as an independent module, with a separate source tree. Same for the API implementations (servletapi right now). These could be the two exceptions. The tree I maintain is like that, and it works well. I think for this new Jasper, Java5 usage for container coding, and possibly code generation (assuming there are places where it adds value), should be acceptable. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r367826 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/connector/Response.java webapps/docs/changelog.xml
[EMAIL PROTECTED] wrote:
Author: markt
Date: Tue Jan 10 15:06:22 2006
New Revision: 367826
URL: http://svn.apache.org/viewcvs?rev=367826&view=rev
Log:
Alternative patch for bug 29214 based on Remy's comments
I am merging the latest version of the patch in my tree, but this change
is a bit sneaky.
@@ -744,7 +747,8 @@
if (index != -1) {
int len = type.length();
index++;
-while (index < len && Character.isSpace(type.charAt(index))) {
+while (index < len
+&& Character.isWhitespace(type.charAt(index))) {
index++;
}
if (index+7 < len
I spent some time eliminating all the warnings that my Eclipse was
reporting sometimes in the past, and saw that isSpace was deprecated.
isWhitespace seemed to be a replacement, but is actually different. HTTP
needs to stay with the non character encoded version. Ie, the deprecated
method is actually useful, since it does exactly what HTTP needs.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat v5.5.15 Stability
Yoav Shapira wrote: Hi, Tomcat v5.5.15-beta was released last week, and hopefully people have had time to test it a bit. If you have, please vote on its stability below. If you haven't, you still can test it a bit and let us know what you think ;) As a reminder, only Tomcat committer votes are binding, but everyone else is welcome to voice their opinion. [X] Stable - no major issues [ ] Beta - at least one significant issue (what is it?) [ ] Alpha - multiple significant issues, not recommended for use (why?) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Newbie quesrion ... how do i attach a file to bugzilla
Mark Thomas wrote: M A wrote: Trying to add a file, in order to describe a bug, Cheers MA. 1. View bug. 2. Click the "Create a New Attachment link" Sure. You guys will have to take care of this nonsensical "bug" as well :) Have fun ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial EL/JSP 2.1 Contribution
Jacob Hookom wrote: What steps would I need to take to get contributor status and develop the JSP 2.1 implementation with the rest of the tomcat-dev team? Do I have to get elected, then complete the ICLA or is it in the reverse order? Yes, you need to be elected as a committer. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Response not flushed before RD.forward() returns
Jan Luehe wrote:
Bill Barker wrote On 01/19/06 18:11,:
-Original Message-
From: Jan Luehe [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 19, 2006 5:57 PM
To: tomcat-dev@jakarta.apache.org
Subject: Response not flushed before RD.forward() returns
Consider the following code snippet of a servlet's service() method:
public class DispatcherServlet extends HttpServlet {
public void service(HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException {
request.getRequestDispatcher("/target").forward(request, response);
try {
Thread.currentThread().sleep(6);
} catch (Exception ex) { }
}
where "target" prints some output to the response.
The code currently returns the output printed by "target" only after
DispatcherServlet's service() method has finished, instead of right
before RD.forward() returns.
This seems to be in violation of the Servlet Spec, which has this:
SRV.8.4 ("The Forward Method"):
Before the forward() method of the RequestDispatcher interface
returns, the response content must be sent and committed, and closed
by the servlet container.
The code at the end of o.a.c.core.ApplicationDispatcher.doForward()
looks like this:
// This is not a real close in order to support error
processing
if ( log.isDebugEnabled() )
log.debug(" Disabling the response for futher output");
if (response instanceof ResponseFacade) {
((ResponseFacade) response).finish();
} else {
// Servlet SRV.6.2.2. The Resquest/Response may have been
wrapped
// and may no longer be instance of RequestFacade
if (log.isDebugEnabled()){
log.debug( " The Response is vehiculed using
a wrapper: "
+ response.getClass().getName() );
}
// Close anyway
try {
PrintWriter writer = response.getWriter();
writer.close();
} catch (IllegalStateException e) {
try {
ServletOutputStream stream =
response.getOutputStream();
stream.close();
} catch (IllegalStateException f) {
;
} catch (IOException f) {
;
}
} catch (IOException e) {
;
}
}
In the above code sample, response will be an instance of
ResponseFacade, meaning it will be suspended instead of being flushed
and closed right away.
Does anyone remember why the "response instanceof ResponseFacade"
check is there? I would have expected the "else" case to always be
executed.
Without ever actually having looked at ResponseFacade, I'd always assumed
that ResponseFacade.finish called Response.finishResponse. And I would have
been wrong ;-). This would have done the commit/send/close properly.
I don't have time right now to dig through the SVN logs to see why it's this
way, but suspended doesn't really look good enough to satisfy the spec.
Yes. I'm afraid it's been like this forever.
And it has to stay like this forever too: this needs to get some post
processing done (like error pages, etc). If this person wants to flush,
let him call flush.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Response not flushed before RD.forward() returns
Bill Barker wrote: Without ever actually having looked at ResponseFacade, I'd always assumed that ResponseFacade.finish called Response.finishResponse. And I would have been wrong ;-). This would have done the commit/send/close properly. It has always been like this: processing for error pages and status report pages has to occur later. It's the same for other similarly worded mechanisms, such as sendError, sendRedirect, etc. I don't have time right now to dig through the SVN logs to see why it's this way, but suspended doesn't really look good enough to satisfy the spec. It is the best and only acceptable behavior from a usability standpoint, however. There are other areas where I think implementing the letter of the specification turned out completely wrong, such as the charset handling that Jan implemented some time before (aka, forcing the addition of a charset even if none was specified whenever a writer is being used). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Response not flushed before RD.forward() returns]
Jan Luehe wrote: Right, but flush does nothing once the response has been suspended. In addition, consider the case where a request has been forward-dispatched into a foreign context. If the target servlet in the foreign context has set a status code on the response, and the response is being suspended before returning from the RD.forward(), the status code will be mapped to an error page using the mappings of the *origin* context as the response travels through the origin context's pipeline (and error valve) on the way out. The origin and target contexts may map the same status code to different error pages, or the origin context may not even contain any mapping for the given status code. In any case, I would find it confusing for the origin context's mappings to be used, since a RD.forward() is supposed to transfer control to the target. I think it is cleaner for the response to be committed before returning from RD.forward(), at the cost of not being mapped to any error page. This is better than mapping the response to a wrong error page. Or we could suspend the response when the origin and target servlets share the same context, and commit it when they reside in different contexts? Clearly, this would require a spec clarification. -1 Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat v5.5.15 Stability
Ok, so I guess 5.5.15 is stable then ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: Response not flushed before RD.forward() returns]
Bill Barker wrote: Yeah, it's pretty much a fatal flaw in the Catalina design. It's currently impossible for Catalina to satisfy both the requirements for error-pages and forwards. Given the amount of people who have complained about this behavior which has been present from the beginning of the Catalina architecture, "fatal" is likely much too strong. However, I don't see any other way to do this stuff, and I also don't see it as being worth even attempting to fix. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: please pickup this bug
Jack wrote: please pick up this bug I report in "There must be a bug in SSL support" in user group. hi, guys don't waste it. By the way, is there anybody know how can i make a link to a specific msg? Another of these useless messages and I will ban you. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Bill Barker wrote:
Author: remm
Date: Mon Jan 23 17:13:19 2006
New Revision: 371765
URL: http://svn.apache.org/viewcvs?rev=371765&view=rev
Log:
- Remove nonsensical systematic inclusion on ISO-8859-1
charset in the content type, which is noth
useless and inefficient.
-1
Sending the charset used by the Writer is very clearly required by the
servlet spec.
Thanks, I expected no less coming from you :) I will revert my patch.
A couple questions for your enjoyment:
1) Is this relevant or irrelevant from the HTTP specification perspective ?
2) Does this mean we're running the following ultra efficient code (I
don't even know why I accepted this stuff back then. It must have been
that this has been done gradually through many many commits) for each
request that uses a writer ?
public String getContentType() {
String ret = contentType;
if (ret != null
&& characterEncoding != null
&& charsetSet) {
ret = ret + ";charset=" + characterEncoding;
}
return ret;
}
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r371765 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/connector/Response.java
Bill Barker wrote: It's relevant to the browser trying to display the code. If you've configured your browser's default encoding to EUC-JP, without the charset you'll see a big mess when you hit a latin-1 page ;-). Obviously, this would only impact the case where ;charset=ISO-8859-1 would be forcefully added to the content-type header for no good reason when the user didn't specify any. This is the HTTP default encoding, and will not change the behavior from the user perspective. Yup, that's what it means :). I'm sure you've played the blame-game by now, and I'm not interested enough to do it myself. It looks like it's trying to avoid computing the entire header value each time the characterEncoding changes. This whole thing is a huge mess right now. Hopefully, it's doing what it should. You can also for example compare o.a.c.connector.Response.setContentType with o.a.coyote.Response.setContentType. I have to suppose substring and concatenation is a very cool activity. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
