Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
[EMAIL PROTECTED] wrote: luehe 2004/10/14 17:00:35 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java Log: Expose any errors on an included resource. For example, a JSP with this include action: jsp:include page=nonexistent or jsp:include page=nonexistent.jsp where nonexistent[.jsp] does not exist, currently returns silently, hiding the fact that the resource to be included does not exist. This patch returns a 404 with the name of the nonexistent resource. Yes, SRV.8.3 (The Include Method) mentions that it [the target servlet] cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. but i don't think it is referring to the error case. Let me know if you see any problems. Same as Bill. It would be logical that it refers to the whole HTTP header(all of its elements already are), since the idea is that it might already have been sent. It's true that we have no good way of reporting problems when including. This has always been a problem from a user perspective. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get context realm from servlet and filter.
I'm trying to use this code from withing a JAAS LoginModule (see
yesterday's post from Michael Vorburger) and I have another problem.
My LoginModule class must be in common/lib or in application's
classpath. It uses classes that are (normally) in server/lib (all the
Catalina classes).
How do you make that work without copying the Catalina's jars from
server/lib to common/lib, what I would like to avoid?
Chris Forbis wrote:
I seem to be having an issue :)
I tried the code you provided and did this.
I am getting a null pointer when I ask for service. Also if I do
server.findServices() to get a list of all of them I get nothing back.
This is from withing a Servlet to test getting these objects.
//See if we can get the container object
Server server = ServerFactory.getServer();
Service service = server.findService(Catalina);
//Next line gets NULL Pointer, because service is not found
Engine engine = (Engine) service.getContainer();
Host host = (Host) engine.findChild(engine.getDefaultHost());
Container[] containers = host.findChildren();
for (int i = 0; i containers.length; i++) {
Container container = containers[i];
out.println(!-- Found Container::+container.getName());
}
On Thu, 14 Oct 2004 11:14:31 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote:
Hi,
I've posted this a number of times in the past on the list, so you can
STFA. To summarize, you'd do something like this (most of these classes
are in the org.apache.catalina package):
Server server = ServerFactory.getServer();
Service service = server.findService(Catalina);
Engine engine = (Engine) service.getContainer();
Host host = (Host) engine.findChild(engine.getDefaultHost());
Context context = (Context) host.findChild(myContext);
Realm realm = context.getRealm();
I'm using the default service name of Catalina above: it should match
what's in your server.xml. I'm also using myContext as a dummy:
obviously that should match your webapp name. And finally, I'm getting
the Realm from the context, because that's what you asked for, but in
reality the Realm (or another realm) may be associated with the Host or
Engine as well. So take the above code and modify it to your needs.
As always, I caution you and everyone else to not use Tomcat-specific
(or container-specific in general) code unless absolutely necessary.
Make your app as portable as possible. There's almost no conceivable
good use-case for needing the actual Realm object in your webapp.
Yoav Shapira http://www.yoavshapira.com
-Original Message-
From: Chris Forbis [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 14, 2004 11:02 AM
To: Tomcat Developers List
Subject: Re: How to get context realm from servlet and filter.
Quick follow-up to your post.
I understand what you are saying. But I am not sure how to get access
to the Container, can you point me in the correct direction?
Thanks!
On Thu, 14 Oct 2004 08:43:23 -0400, Shapira, Yoav
[EMAIL PROTECTED]
wrote:
Hi,
A Realm is associated with a Container, not necessarily a Context, so
the method is appropriately placed in the Container interface, a
parent
of the Context interface. Obviously all this is not part of the
Servlet
API, so you'll have to write Tomcat-specific code to get it.
Yoav Shapira http://www.yoavshapira.com
-Original Message-
From: Chris Forbis [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 13, 2004 6:24 PM
To: tomcat-dev
Subject: How to get context realm from servlet and filter.
I am trying to get the current contexts realms from a servlet (and
maybe a filter). I do not see a getContext().getRealm() method. So
I
am guessing there is another way to get to this, but I do not see
it.
Can any one provide some quick direction to me on this. Thank you!
Chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary and/or privileged. This e-mail is intended only for the
individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else. If you are not the(an)
intended
recipient, please immediately delete this e-mail from your computer
system
and notify the sender. Thank you.
-
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]
This e-mail, including any attachments, is a confidential business communication,
and may contain information that is confidential, proprietary and/or privileged. This
e-mail is intended only for the individual(s) to whom it is addressed, and may not be
saved,
DO NOT REPLY [Bug 31725] - File.createTempFile() fails with FNFE because java.io.tmpdir does not exist
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31725. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31725 File.createTempFile() fails with FNFE because java.io.tmpdir does not exist [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 09:56 --- Well, sorry, but no. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31722] - In JNI mode, POST is broken due to bodyMsg.getLen() == 0 not working properly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31722. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31722 In JNI mode, POST is broken due to bodyMsg.getLen() == 0 not working properly --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 12:16 --- Thanks Bill for fixing this for me. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to get context realm from servlet and filter.
Hi, My LoginModule class must be in common/lib or in application's classpath. It uses classes that are (normally) in server/lib (all the Catalina classes). How do you make that work without copying the Catalina's jars from server/lib to common/lib, what I would like to avoid? The classes in common/lib, shared/lib, and WEB-INF/lib cannot see the classes in server/lib (a.k.a the Catalina classloader repository in the Classloader How-To document). So you must copy or move your classes around. Note, however, that according to the same document the classes in server/lib *can* see and use classes in common/lib. So you might be able to plugin something the other way from your current design. I am getting a null pointer when I ask for service. Also if I do server.findServices() to get a list of all of them I get nothing back. This is from withing a Servlet to test getting these objects. That's strange. I typed the code from memory and haven't actually used it in a long time (it used to work, but I hate having container-specific code in my apps, so I don't do it any more). Maybe someone else can correct my code or explain why you're getting a null service. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29917] - Still/again POST data limit in JK2.0.4 ISAPI connector?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29917. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29917 Still/again POST data limit in JK2.0.4 ISAPI connector? --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 12:49 --- I don't know if the following patch still works but it did fix the problem for me in JK2.0.2 (i think): http://marc.theaimsgroup.com/?l=tomcat-devm=103944368410308w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11489] - Scanning JAR files in WEB-INF/lib without temp directory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=11489. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=11489 Scanning JAR files in WEB-INF/lib without temp directory [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 12:52 --- *** This bug has been marked as a duplicate of 9591 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9591] - Creating a temporary file in a servlet throws an IOException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9591 Creating a temporary file in a servlet throws an IOException [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 12:52 --- *** Bug 11489 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31725] - File.createTempFile() fails with FNFE because java.io.tmpdir does not exist
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31725. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31725 File.createTempFile() fails with FNFE because java.io.tmpdir does not exist [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 12:53 --- . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31725] - File.createTempFile() fails with FNFE because java.io.tmpdir does not exist
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31725. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31725 File.createTempFile() fails with FNFE because java.io.tmpdir does not exist [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 12:53 --- *** This bug has been marked as a duplicate of 9591 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9591] - Creating a temporary file in a servlet throws an IOException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9591. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9591 Creating a temporary file in a servlet throws an IOException [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 12:53 --- *** Bug 31725 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get context realm from servlet and filter.
Note, however, that according to the same document the classes in server/lib *can* see and use classes in common/lib. So you might be able to plugin something the other way from your current design. I really don't see how... The LoginModule has to be accessible from my application's classes. Shapira, Yoav wrote: Hi, My LoginModule class must be in common/lib or in application's classpath. It uses classes that are (normally) in server/lib (all the Catalina classes). How do you make that work without copying the Catalina's jars from server/lib to common/lib, what I would like to avoid? The classes in common/lib, shared/lib, and WEB-INF/lib cannot see the classes in server/lib (a.k.a the Catalina classloader repository in the Classloader How-To document). So you must copy or move your classes around. Note, however, that according to the same document the classes in server/lib *can* see and use classes in common/lib. So you might be able to plugin something the other way from your current design. I am getting a null pointer when I ask for service. Also if I do server.findServices() to get a list of all of them I get nothing back. This is from withing a Servlet to test getting these objects. That's strange. I typed the code from memory and haven't actually used it in a long time (it used to work, but I hate having container-specific code in my apps, so I don't do it any more). Maybe someone else can correct my code or explain why you're getting a null service. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
The HTTP response to the user should reflect their request to the named resource. If the user-requested JSP was found, then a 404 Not Found is not an appropriate response, the resource requested was found. If the server is unable to properly form a response, because some component/resource referenced by the user-requested resource is missing/unavailable/exceptioned/whatever, then the server has experienced an error processing the request, and a better response would be 500 Internal Server Error. -Mitchell Fisher -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 4:46 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java [EMAIL PROTECTED] wrote: luehe 2004/10/14 17:00:35 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java Log: Expose any errors on an included resource. For example, a JSP with this include action: jsp:include page=nonexistent or jsp:include page=nonexistent.jsp where nonexistent[.jsp] does not exist, currently returns silently, hiding the fact that the resource to be included does not exist. This patch returns a 404 with the name of the nonexistent resource. Yes, SRV.8.3 (The Include Method) mentions that it [the target servlet] cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. but i don't think it is referring to the error case. Let me know if you see any problems. Same as Bill. It would be logical that it refers to the whole HTTP header(all of its elements already are), since the idea is that it might already have been sent. It's true that we have no good way of reporting problems when including. This has always been a problem from a user perspective. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.0 under load
Last month I took Yoav's advice and attempted to upgrade our production server from 4.1 to 5.0. The production server handles 5 - 10 requests a second across 300 threads. The problem I had then, and the problem I have now is that the server's accept thread will die within a short time after server start. I hate to think I am the only person running tomcat 5 under a heavy load, but it sure looks that way. I initially blamed threadpool's bulletproofing, but because 4.1.31 and 5.0.28 share the same threadpool, and 4.1.31 runs indefinitely, there is a problem in core 5.0 that this load is exercising. I very much want to be able to recommend that tomcat 5.0 is production-ready but since we can't run it, I certainly am not in a position to do that. I have reserved the next day or two for bulletproofing tomcat 5.0, so the point of this is to solicit any comments from those who may have been faced with the same problem and have looked at the problem themselves. Thanks for any input, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to get context realm from servlet and filter.
You can set your context to be privileged so that your login class in WEB-INF\lib can access the \server\lib classes. But keep in mind anything from your context can access tomcat's internal classes, so it is a security risk. Context ... privileged=true Charlie -Original Message- From: Antoine Brocard - Vertical*i S.A. [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 10:10 AM To: Tomcat Developers List Subject: Re: How to get context realm from servlet and filter. Note, however, that according to the same document the classes in server/lib *can* see and use classes in common/lib. So you might be able to plugin something the other way from your current design. I really don't see how... The LoginModule has to be accessible from my application's classes. Shapira, Yoav wrote: Hi, My LoginModule class must be in common/lib or in application's classpath. It uses classes that are (normally) in server/lib (all the Catalina classes). How do you make that work without copying the Catalina's jars from server/lib to common/lib, what I would like to avoid? The classes in common/lib, shared/lib, and WEB-INF/lib cannot see the classes in server/lib (a.k.a the Catalina classloader repository in the Classloader How-To document). So you must copy or move your classes around. Note, however, that according to the same document the classes in server/lib *can* see and use classes in common/lib. So you might be able to plugin something the other way from your current design. I am getting a null pointer when I ask for service. Also if I do server.findServices() to get a list of all of them I get nothing back. This is from withing a Servlet to test getting these objects. That's strange. I typed the code from memory and haven't actually used it in a long time (it used to work, but I hate having container-specific code in my apps, so I don't do it any more). Maybe someone else can correct my code or explain why you're getting a null service. Yoav This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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: Tomcat 5.0 under load
Keith Wannamaker wrote: Last month I took Yoav's advice and attempted to upgrade our production server from 4.1 to 5.0. The production server handles 5 - 10 requests a second across 300 threads. The problem I had then, and the problem I have now is that the server's accept thread will die within a short time after server start. I hate to think I am the only person running tomcat 5 under a heavy load, but it sure looks that way. I initially blamed threadpool's bulletproofing, but because 4.1.31 and 5.0.28 share the same threadpool, and 4.1.31 runs indefinitely, there is a problem in core 5.0 that this load is exercising. I very much want to be able to recommend that tomcat 5.0 is production-ready but since we can't run it, I certainly am not in a position to do that. I have reserved the next day or two for bulletproofing tomcat 5.0, so the point of this is to solicit any comments from those who may have been faced with the same problem and have looked at the problem themselves. First, I didn't see any previous message about any of your problems. Then, why do I even have to ask which OS / VM / connector / etc you are running ? Also mention exactly what the server's accept thread will die mean. BTW, jboss.org is running on Tomcat 4.1 (inside JBoss), with more load than your site, on RedHat EL 3 (we did have many issues on RH 9 that LD_ASSUME_KERNEL solved in a large part). Except when we're making a configuration mistake (it happens more often than I would like), we don't have many issues (we do have annoyance of TC 4.1 compared to 5.0 - we'll upgrade soon, I am being told, so I'll let people know how well it goes). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
Remy/Bill, Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2004/10/14 17:00:35 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java Log: Expose any errors on an included resource. For example, a JSP with this include action: jsp:include page=nonexistent or jsp:include page=nonexistent.jsp where nonexistent[.jsp] does not exist, currently returns silently, hiding the fact that the resource to be included does not exist. This patch returns a 404 with the name of the nonexistent resource. Yes, SRV.8.3 (The Include Method) mentions that it [the target servlet] cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. but i don't think it is referring to the error case. Let me know if you see any problems. Same as Bill. It would be logical that it refers to the whole HTTP header(all of its elements already are), since the idea is that it might already have been sent. I agree the above section needs to be clarified. It's true that we have no good way of reporting problems when including. This has always been a problem from a user perspective. OK, do you think it would be a better idea to return a null RequestDispatcher in this case? In ApplicationContext.getRequestDispatcher(path), we could check if the wrapper that the given path is being mapped to corresponds to the JspServlet or DefaultServlet, and only in that case, call getResource() to make sure the requested resource actually exists. If it doesn't, return null. I really don't like the idea of not reporting anything to the user. Jan Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 5.0 under load
Hi, There are certainly other sites running Tomcat 5.0 under heavy load, such as the ones listed on our wiki. I personally have put Tomcat 5.0-based apps in production that have handled the load you describe (and much higher peak bursty loads) for months at a time without need to restart. However, it could very well be your specific app or configuration is exercising parts of Tomcat in ways other apps aren't. Every app load profile is unique. So this should definitely result in an improvement to Tomcat, or maybe the connectors if you're running Tomcat behind a front-end web server. I have no specific advice beyond the usual, which is to start with something reproducible. Can you get the accept thread to die every time within a given time window after the server start? Does it happen with Tomcat standalone as well as behind a front-end server, or just the latter? Does it happen with the out-of-the-box server.xml or a heavily modified one? Yoav Shapira http://www.yoavshapira.com -Original Message- From: Keith Wannamaker [mailto:[EMAIL PROTECTED] Sent: Friday, October 15, 2004 10:42 AM To: [EMAIL PROTECTED] Subject: Tomcat 5.0 under load Last month I took Yoav's advice and attempted to upgrade our production server from 4.1 to 5.0. The production server handles 5 - 10 requests a second across 300 threads. The problem I had then, and the problem I have now is that the server's accept thread will die within a short time after server start. I hate to think I am the only person running tomcat 5 under a heavy load, but it sure looks that way. I initially blamed threadpool's bulletproofing, but because 4.1.31 and 5.0.28 share the same threadpool, and 4.1.31 runs indefinitely, there is a problem in core 5.0 that this load is exercising. I very much want to be able to recommend that tomcat 5.0 is production-ready but since we can't run it, I certainly am not in a position to do that. I have reserved the next day or two for bulletproofing tomcat 5.0, so the point of this is to solicit any comments from those who may have been faced with the same problem and have looked at the problem themselves. Thanks for any input, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
Jan Luehe wrote: Remy/Bill, Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2004/10/14 17:00:35 Modified:catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java Log: Expose any errors on an included resource. For example, a JSP with this include action: jsp:include page=nonexistent or jsp:include page=nonexistent.jsp where nonexistent[.jsp] does not exist, currently returns silently, hiding the fact that the resource to be included does not exist. This patch returns a 404 with the name of the nonexistent resource. Yes, SRV.8.3 (The Include Method) mentions that it [the target servlet] cannot set headers or call any method that affects the headers of the response. Any attempt to do so must be ignored. but i don't think it is referring to the error case. Let me know if you see any problems. Same as Bill. It would be logical that it refers to the whole HTTP header(all of its elements already are), since the idea is that it might already have been sent. I agree the above section needs to be clarified. It's true that we have no good way of reporting problems when including. This has always been a problem from a user perspective. OK, do you think it would be a better idea to return a null RequestDispatcher in this case? In ApplicationContext.getRequestDispatcher(path), we could check if the wrapper that the given path is being mapped to corresponds to the JspServlet or DefaultServlet, and only in that case, call getResource() to make sure the requested resource actually exists. If it doesn't, return null. That's IMO well beyond the spec. I really don't like the idea of not reporting anything to the user. OTOH, I don't see anything which prevents the default servlet from reporting such an error as plain text This resource foo is not found when invoked from an include, which would likely be good enough for users. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0 under load
Shapira, Yoav wrote: Hi, There are certainly other sites running Tomcat 5.0 under heavy load, such as the ones listed on our wiki. I personally have put Tomcat 5.0-based apps in production that have handled the load you describe (and much higher peak bursty loads) for months at a time without need to restart. However, it could very well be your specific app or configuration is exercising parts of Tomcat in ways other apps aren't. Every app load profile is unique. So this should definitely result in an improvement to Tomcat, or maybe the connectors if you're running Tomcat behind a front-end web server. I have no specific advice beyond the usual, which is to start with something reproducible. Can you get the accept thread to die every time within a given time window after the server start? Does it happen with Tomcat standalone as well as behind a front-end server, or just the latter? Does it happen with the out-of-the-box server.xml or a heavily modified one? Some facts: - the higher level code cannot cause the accept thread to die - the code for the whole threadpool is shared So there's nothing which can be inherently more broken in TC 5. However, what differs is timing: TC 5 will generally be faster, and since this issue would involve sheduling and stuff, this likely matters ... If Keith is feeling like experimenting a little (without too much risk involved, though): try 5.5.3 with strategy=ms on the Connector. This will use the old TC 4.0 thread pool strategy, which is far less fancy, and was never reported as having trouble on stuff like RH 9. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0 under load
The time window is within about 15 minutes. We run tomcat standalone, with the standard http/11 connector. The server.xml is minimal. I agree with the reproduceable angle, that is always a good place to start. Keith Shapira, Yoav wrote: Hi, There are certainly other sites running Tomcat 5.0 under heavy load, such as the ones listed on our wiki. I personally have put Tomcat 5.0-based apps in production that have handled the load you describe (and much higher peak bursty loads) for months at a time without need to restart. However, it could very well be your specific app or configuration is exercising parts of Tomcat in ways other apps aren't. Every app load profile is unique. So this should definitely result in an improvement to Tomcat, or maybe the connectors if you're running Tomcat behind a front-end web server. I have no specific advice beyond the usual, which is to start with something reproducible. Can you get the accept thread to die every time within a given time window after the server start? Does it happen with Tomcat standalone as well as behind a front-end server, or just the latter? Does it happen with the out-of-the-box server.xml or a heavily modified one? Yoav Shapira http://www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationHttpResponse.java
luehe 2004/10/15 09:09:27
Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpResponse.java
Log:
Reverted previous change
Revision ChangesPath
1.7 +3 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java
Index: ApplicationHttpResponse.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpResponse.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ApplicationHttpResponse.java 15 Oct 2004 00:00:35 - 1.6
+++ ApplicationHttpResponse.java 15 Oct 2004 16:09:27 - 1.7
@@ -237,6 +237,7 @@
*/
public void sendError(int sc) throws IOException {
+if (!included)
((HttpServletResponse) getResponse()).sendError(sc);
}
@@ -252,6 +253,7 @@
*/
public void sendError(int sc, String msg) throws IOException {
+if (!included)
((HttpServletResponse) getResponse()).sendError(sc, msg);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Off-Topic] Re: java.io.tempdir Problems
It sounds like maybe there is some confusion between environment variables and system properties. java.io.tempdir is a system property which presumably means it can be set on the Java command line using -Djava.io.tempdir=foo This is different then anything getenv() would return since those would be environment variables. Some of which are reflected as differently named system properties. For example, I think java.io.tempdir defaults to the TEMP environment variable under Windows and perhaps TMP under Unix or something like that. I'd have to drill into javadocs to be sure. -Paul Michael McGrady wrote: I don't know if this is helpful or not, Martin, but if you attempt System.getenv(java.io.tempdir) [which is deprecated], you get as part of the error message getenv no longer supported, use properties and -D instead: java.io.tempdir. Is that helpful? Does the -D there mean as in -Djava.io.tempdir? Michael Martin Gainty wrote: Good Afternoon Michael Perusing the Manual for Jspc at http://64.233.167.104/search?q=cache:pfbfEPvvvHUJ:www.gefionsoftware.com/Lit eWebServer/lws-jsp/ReferenceManual.pdf+TOMCAT+java.io.tempDir+-Djava.io.temp Dirhl=en formal syntax for the JSPC command jspc [options] -webapp web-app-root-dir Where option -d output-dir specifies The -d output-dir specification is the directory specified by the java.io.tempdir system property I see that there are 2 ways to specify java.io.tempdir System Property Anyone else The directory specified by the java.io.tempdirsystem property The directory specified by the java.io.tempdirsystem property The directory specified by the java.io.tempdirsystem property The directory specified by the java.io.tempdir??? Martin - Original Message - From: Michael McGrady [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 11:46 AM Subject: Re: java.io.tempdir Problems Martin, Perhaps I should add, Martin, that if I set the environment variables for java.io.tempdir and -Djava.io.tempdir in the application but not in Tomcat startup, I don't have the problem. I am a bit confused about whether to use java.io.tempdir or -Djava.io.tempdir. Can you explain a bit about that? Michael McGrady Martin Gainty wrote: Michael createTempFile employs 3 steps algorithm to locate/create tempDir 1) Attempt to retrieve the value of javax.servlet.context.tempdir from the ServletContext 2) If that's not found, attempt to retrieve the value of the init-parameter tempDir 3) If that's not found, default to the system-wide temp directory specified by the system property java.io.tempdir A)what is the value of javax.servlet.context.tempdir from the ServletContext? B)what is the value of the init-parameter tempDir? Martin- - Original Message - From: Michael McGrady [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 3:16 AM Subject: java.io.tempdir Problems I hope this is Tomcat related. If not, please accept my apologies, and give me direction. I have removed from my Tomcat 5 (Struts 1.2 using a custom taglib) service the java.io.tempdir setting because when I use the following code: File file = new File(Classpath.WEB_INF + resource+ File.separator + content_type+ File.separator + ttf + File.separator + physicalName); FileInputStream fontStream = new FileInputStream(file); Font font = Font.createFont(Font.TRUETYPE_FONT,fontStream); font = font.deriveFont(attributes); fontStream.close(); I get temp files of around 50 - 150 kilobytes each written to the temp directory. I requested assistance on Tomcat User without an answer. Anyway, I assume that there may be a concurrency issue of somekind. Is that right? Anyone with any assistance out there? Michael McGrady - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31732] New: - TM's list command does not show WAR URL in Japanese localization
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31732.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31732
TM's list command does not show WAR URL in Japanese localization
Summary: TM's list command does not show WAR URL in Japanese
localization
Product: Tomcat 5
Version: 5.0.28
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Can be fixed as follows:
org/apache/catalina/manager/LocalStrings_ja.properties
--
- managerServlet.listitem={0}:{1}:{2}
+ managerServlet.listitem={0}:{1}:{2}:{3}
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to get context realm from servlet and filter.
List a class as a global JNDI resource to arrange the necessary communications? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31733] New: - inconsistent error page returned from Apache when tomcat is started inprocess vs outprocess
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31733. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31733 inconsistent error page returned from Apache when tomcat is started inprocess vs outprocess Summary: inconsistent error page returned from Apache when tomcat is started inprocess vs outprocess Product: Tomcat 5 Version: 5.0.24 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Connector:AJP AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In case of apache/tomcat using socket connection, when apache is up but tomcat is still coming up and a jsp/servlet from tomcat is requested, then the following error status (http status = 503) is returned to the client Service Temporarily Unavailable. The server is temporarily unable to service your request due to maintenance downtime or capacity problems However, when tomcat is started inprocess (I cannot accomplish this thru apache/tomcat combination . for now, I am using aolserver/tomcat to start inprocess which seems to work), the code in mod_jk2.c under jk2_handler() shows /* In case of error, if service() set a status code, send it back */ /* Else fallback to HTTP_INTERNAL_SERVER_ERROR (500). */ if (s-status != 0) return s-status; else return HTTP_INTERNAL_SERVER_ERROR; this returns http status = 500. Shouldn't the webserver return same error status regardless of what communication (jni, socket, etc ) to tomcat was utilized ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0 under load
Hey Remy, Some facts: - the higher level code cannot cause the accept thread to die Thread dump from T0 shows the two expected accepts, from main and from the HttpConnector; thread dump at T(5mins) shows the main accept, many idle Http handler threads waiting for work, and a few long-running uploads downloads, but no Http accept. So, indeed, the thread is either stopping itself with no message or being killed with no message. Interesting note on logging. I tried today to use both jdk14 logger and simple log to show the progress of the accept. The behavior of going through either logger is that init messages come through but runIt messages don't. I thought it was the logger config so I reverted to System.out and still got that behavior. I wonder if the underlying exception causing the problem is being squelched by whatever is squelching my messages. Ever seen this? If Keith is feeling like experimenting a little (without too much risk involved, though): try 5.5.3 with strategy=ms on the Connector. This will use the old TC 4.0 thread pool strategy, which is far less fancy, and was never reported as having trouble on stuff like RH 9. I may try this. Thanks, Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: UserTransaction not working in DefaultContext
Hi, I've confirmed my diagnostic about UserTransactions in a DefaultContext , and I've made a patch for it. So now there are a few questions that I'd gladly request your option on: - Considering that tomcat-5.0.x is in maintenance mode, and DefaultContext stuff has been rewritten in 5.5.x., should I raise this issue as a bug, and propose my patch ? - If yes, there are, at least, two possible solutions for this issue. Which one should be taken ? A) one solution that does not interfere if an UserTransaction has been successfully registered by a Context element (more power to the web-application) even if there is a UserTransaction element in a DefaultContext. This is the solution I've made a patch for. B) if a UserTransaction is present in a DefaultContext, it will be the available one. This behavior is the current behavior for the StandardDefaultContext implementation regarding all resources inside a DefaultContext (yes, the implementation unregisters previous resources from Context initializations from a web-application, and override them with equally named resources if available inside a DefaultContext for a Host). Regards, --- Ricardo -- Forwarded message -- From: Ricardo Matinata [EMAIL PROTECTED] Date: Thu, 14 Oct 2004 16:14:07 -0300 Subject: UserTransaction not working in DefaultContext To: [EMAIL PROTECTED] Hi, As of tomcat-5.0.29, it is not possible to have a java:/comp/UserTransaction resource working if declared from a DefaultContext. (ie) : ... GlobalNamingResources Resource name=UTransaction auth=Container type=javax.transaction.UserTransaction/ ResourceParams name=UTransaction parameter namefactory/name valueorg.objectweb.jotm.UserTransactionFactory/value /parameter parameter namejotm.timeout/name value60/value /parameter /ResourceParams /GlobalNamingResources ... Host DefaultContext ResourceLink name=UserTransaction global=UTransaction type=javax.transaction.UserTransaction/ /DefaultContext /Host . As far as i have investigated the problem, DefaultContext resources are not avaliable as NamingResources when NamingContextListener creates the NamingContext for the Context (NamingContextListener.createNamingContext()). So at the moment NamingContext is created, the java:/comp/UserTransation resource is added with an empty TransactionRef object. Later, in the life cicle, when DefaultContext resources are added to the context, in this case a ResourceLink pointing to the UserTransaction global resource, we get a NameAlreadyBoundException, so the previously registered TransactionRef object remains without config parameters. The UserTransaction works fine if included in each application's own context.xml file. So, as i haven't found any notes regarding this anywhere (manual, list and Bugzilla), it is (probably) an issue to be raised (or is it anticipated behaviour ?). Thanks. --- Ricardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31737] New: - method call setSource does not match the actual signature in MsgContext.setSource()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31737. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31737 method call setSource does not match the actual signature in MsgContext.setSource() Summary: method call setSource does not match the actual signature in MsgContext.setSource() Product: Tomcat 5 Version: 5.0.27 Platform: All OS/Version: All Status: NEW Severity: Blocker Priority: Other Component: Connector:AJP AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] ChannelSocket.java has Public class ChannelSocket extends JkHandler MsgContext ep = new MsgContext() ep.setSource(this); this is fine when MsgContext.java (5.0.19) public final void setSource(JkHandler ch) however you get NoSuchMethod error when MsgContext.java (5.0.27) public final void setSource(JkChannel ch) error output Oct 15, 2004 4:43:46 PM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.NoSuchMethodError: org.apache.jk.core.MsgContext.setSource(Lorg/apache/jk/core/JkHandler;)V) executing [EMAIL PROTECTED], terminating thread - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31737] - method call setSource does not match the actual signature in MsgContext.setSource()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31737. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31737 method call setSource does not match the actual signature in MsgContext.setSource() [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 22:05 --- The actual declaration of ChannelSocket is: public class ChannelSocket extends JkHandler implements NotificationBroadcaster, JkChannel I'm guessing that you have some old version of Tomcat in your classpath that is conflicting with the more recent one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0 under load
Keith Wannamaker wrote: Hey Remy, Some facts: - the higher level code cannot cause the accept thread to die Thread dump from T0 shows the two expected accepts, from main and from the HttpConnector; thread dump at T(5mins) shows the main accept, many idle Http handler threads waiting for work, and a few long-running uploads downloads, but no Http accept. So, indeed, the thread is either stopping itself with no message or being killed with no message. This is the same as the RH 9 bug. Which OS are you using ? Interesting note on logging. I tried today to use both jdk14 logger and simple log to show the progress of the accept. The behavior of going through either logger is that init messages come through but runIt messages don't. I thought it was the logger config so I reverted to System.out and still got that behavior. I wonder if the underlying exception causing the problem is being squelched by whatever is squelching my messages. Ever seen this? Well, no. I have to admit I didn't look in detail at what everything does, since I didn't write that algorithm, and never quite understood why it works. If Keith is feeling like experimenting a little (without too much risk involved, though): try 5.5.3 with strategy=ms on the Connector. This will use the old TC 4.0 thread pool strategy, which is far less fancy, and was never reported as having trouble on stuff like RH 9. I may try this. That algorithm is really stupid. OTOH, it does seem to have more syncing (not that I can see any performance impact from it). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0 under load
Hey Remy, by RH 9 bug do you mean the problem with jdk14 and nptl on RH9? (os is RH9) I am running without nptl. I did some more tracing and what I am seeing is that notify is called, the thread is waiting, but it never wakes up. Keith Remy Maucherat wrote: Keith Wannamaker wrote: Hey Remy, Some facts: - the higher level code cannot cause the accept thread to die Thread dump from T0 shows the two expected accepts, from main and from the HttpConnector; thread dump at T(5mins) shows the main accept, many idle Http handler threads waiting for work, and a few long-running uploads downloads, but no Http accept. So, indeed, the thread is either stopping itself with no message or being killed with no message. This is the same as the RH 9 bug. Which OS are you using ? Interesting note on logging. I tried today to use both jdk14 logger and simple log to show the progress of the accept. The behavior of going through either logger is that init messages come through but runIt messages don't. I thought it was the logger config so I reverted to System.out and still got that behavior. I wonder if the underlying exception causing the problem is being squelched by whatever is squelching my messages. Ever seen this? Well, no. I have to admit I didn't look in detail at what everything does, since I didn't write that algorithm, and never quite understood why it works. If Keith is feeling like experimenting a little (without too much risk involved, though): try 5.5.3 with strategy=ms on the Connector. This will use the old TC 4.0 thread pool strategy, which is far less fancy, and was never reported as having trouble on stuff like RH 9. I may try this. That algorithm is really stupid. OTOH, it does seem to have more syncing (not that I can see any performance impact from it). R?my - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0 under load
Keith Wannamaker wrote: Hey Remy, by RH 9 bug do you mean the problem with jdk14 and nptl on RH9? (os is RH9) I am running without nptl. It doesn't matter which JDK version you're running. On RH 9, you need LD_ASSUME_KERNEL=2.4.1. This disables the nptl backport, which doesn't give any performance increase anyway. jboss.org was very unstable (with TC 4.1 embedded) without it, and is working fine with it. This is not needed on RH EL 3.0, I am told. I did some more tracing and what I am seeing is that notify is called, the thread is waiting, but it never wakes up. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31738] New: - doAfterBody is not being called for some JSP files.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31738. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31738 doAfterBody is not being called for some JSP files. Summary: doAfterBody is not being called for some JSP files. Product: Tomcat 4 Version: 4.1.30 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Oor QA engineer reported this against Tomcat embedded in Borland Enterprise Server. I am not sure if this is a dup or not. A bugzilla query did not show the same bug. There are two jsp files with same content but slightly differet XML syntax. one works correctly, the other one doesn't. The difference of those two files is: easy:myTag number=2 power=3 /easy:myTag vs easy:myTag number=2 power=3 / The first one works. Basically if the Bad one is being used, the function doAfterBody() is not being called even if the doStartTag() is returning EVEL_BODY_INCLUDE value. A test case is attached, you can try by invoking: http://localhost:8080/Power/Good.jsp, or http://localhost:8080/Power/Bad.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31738] - doAfterBody is not being called for some JSP files.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31738. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31738 doAfterBody is not being called for some JSP files. --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 22:47 --- Created an attachment (id=13108) The Test.war file that shows the problem - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31738] - doAfterBody is not being called for some JSP files.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31738.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31738
doAfterBody is not being called for some JSP files.
--- Additional Comments From [EMAIL PROTECTED] 2004-10-15 22:52 ---
One quick way I could find to resolve the problem was to add a empty body like:
if (reader.matches(/)) {
// EmptyElemTag ::= '' Name ( S Attribute )* S? '/'#
Node tagNode = new Node.CustomTag(attrs, start, tagName, prefix,
shortTagName,
tagInfo, tagHandlerClass, parent);
// Changed code
tagNode.body = new Node.Nodes();
return true;
}
in private boolean parseCustomTag(Node parent) of o.a.j.c.Parser.java. There
could be other better ways.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31738] - doAfterBody is not being called for some JSP files.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31738. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31738 doAfterBody is not being called for some JSP files. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-15 23:42 --- DoAfterBody will not be called for actions with empty bodies. For your first case, the body contains a '\n' and is considered non-empty, therefore DoAfterBody will be called. This was not clearly stated in JSP 1.2 spec, though it was hinted at a couple of places. This was clarified in JSP 2.0 spec. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31739] New: - Minor documentation additions for realm-howto and AJP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31739 Minor documentation additions for realm-howto and AJP Summary: Minor documentation additions for realm-howto and AJP Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Realm how-to: Minor addition to describe the enhancements implemented as result of fixing bugs 29406 and 28631 AJP: Adds attributes for minProcessors/maxProcessors, which I for one could have benefited from had they been present a few months back! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31739] - Minor documentation additions for realm-howto and AJP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31739 Minor documentation additions for realm-howto and AJP --- Additional Comments From [EMAIL PROTECTED] 2004-10-16 00:27 --- Created an attachment (id=13109) Patch: realm-howto.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31739] - Minor documentation additions for realm-howto and AJP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31739 Minor documentation additions for realm-howto and AJP --- Additional Comments From [EMAIL PROTECTED] 2004-10-16 00:27 --- Created an attachment (id=13110) Patch: ajp.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31739] - Minor documentation additions for realm-howto and AJP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31739 Minor documentation additions for realm-howto and AJP --- Additional Comments From [EMAIL PROTECTED] 2004-10-16 01:19 --- Created an attachment (id=13111) Replacement for ajp.xml.PATCH (fubar'ed the author tag, sorry, this is the right version) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31741] New: - servlet request forward to jsp with jsp:include tag can cause extra request to be submitted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31741. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31741 servlet request forward to jsp with jsp:include tag can cause extra request to be submitted Summary: servlet request forward to jsp with jsp:include tag can cause extra request to be submitted Product: Tomcat 4 Version: 4.1.30 Platform: PC OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We seem to have found a case where 2 clicks from a browser cause 3 requests to be processed by the servlet. The steps to reproduce are: - Set up the servlet and JSP files as below - Start with the HTML file - Click the Submit button once, wait 1 second (first request will not be complete) and then click it again - You'll see 2 requests (correct) in the Apache log and 3 requests (incorrect) processed in catalina.out We found this while doing some debugging on our application. This was done on a Solaris Intel machine running Apache 2.0.48 and the 2.0.4 JK connectors using the CoyoteConnector config in server.xml. A couple of things that seem to be necessary for this: - The flush must be set to true in the jsp:include directive - There must be some kind of output in the including page before the include directive Log I captured - request 3 seems to be spawned after request 1 completes --- WebappClassLoader: Resource '/WEB- INF/classes/ServletJSPForwardAndIncludeTest.class' was modified; Date is now: Fri Oct 15 21:33:15 EDT 2004 Was: Fri Oct 15 20:42:29 EDT 2004 Request: [EMAIL PROTECTED] reqNum=1: Start Request: [EMAIL PROTECTED] reqNum=1: Sleep Request: [EMAIL PROTECTED] reqNum=2: Start Request: [EMAIL PROTECTED] reqNum=2: Forward Request: [EMAIL PROTECTED] reqNum=2: Finish Request: [EMAIL PROTECTED] reqNum=1: Forward Request: [EMAIL PROTECTED] reqNum=1: Finish Request: [EMAIL PROTECTED] reqNum=3: Start Request: [EMAIL PROTECTED] reqNum=3: Sleep Request: [EMAIL PROTECTED] reqNum=3: Forward Request: [EMAIL PROTECTED] reqNum=3: Finish Oct 15, 2004 9:33:53 PM org.apache.jk.server.JkCoyoteHandler action SEVERE: Error in action code java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:472) at org.apache.coyote.Response.action(Response.java:226) at org.apache.coyote.Response.finish(Response.java:348) at org.apache.coyote.tomcat4.OutputBuffer.close(OutputBuffer.java:324) at org.apache.coyote.tomcat4.CoyoteResponse.finishResponse (CoyoteResponse.java:486) at org.apache.coyote.tomcat4.CoyoteAdapter.service (CoyoteAdapter.java:200) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:324) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:395) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:615) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:786) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) Oct 15, 2004 9:33:53 PM org.apache.jk.server.JkCoyoteHandler action SEVERE: Error in action code java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:457) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:654) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:472) at org.apache.coyote.Response.action(Response.java:226) at org.apache.coyote.Response.finish(Response.java:348) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:329) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:395) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:673) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:615) at
