Improving memory efficiency
Hi there,
while hunting down a memory leak (it turned out that some servlets
didn't release PageContexts after use) I came across some places in
tomcat which are a bit memory inefficent.
(I'm talking about Tomcat 5.5 SVN as of tuesday or yesterday.)
The root cause (but not the problem) is that PageContexts are pooled in
JspFactoryImpl. The first interesting spot is the BodyContentImpl[] outs
member of PageContextImpl. It will only grow over time and it will never
release the BodyContentImpls stored in there. As PageContexts are
pooled, a single PageContext instance gets used by a lot of different
JSPs (possibly all JSPs present in the app).
The next interesting spot is the char[] cb member of BodyContentImpl it
will also only grow over time and never release the space occupied by
the buffer.
Let's consider a JSP with a single BodyTag which will buffer a
significant amount of data (say 1 MB). Over time, all
PageContextImpls.out[0].cb-s will grow to this size. The
JspFactoryImpl's PageContext pool contains up to 100 PageContexts, so I
may end up with 100 MB of memory which is basically unused.
I patched Tomcat to re-initialize PageContextImpl.outs on release().
This should increase memory efficiency significantly.
Second, I re-initialized BodyContentImpl.cb[] on clear() - this seems
superfluous but I found tags in the pools which still held
BodyContentImpls as bodyContent therefore possibly locking lots of
memory. Third, I let JspWriterImpl null it's cb on recycle() since I
also found some of these lingering around and still holding parts of the
output. The last two steps might be unneccessary if we could prevent
that tags in the pools still hold BodyContents (as far as
BodyTagSupport.bodyContent is involved).
What do you think about this issue?
Bye, Tino.
PS: Proposed patch attached.
Index: src/share/org/apache/jasper/runtime/PageContextImpl.java
===
--- src/share/org/apache/jasper/runtime/PageContextImpl.java(revision
356603)
+++ src/share/org/apache/jasper/runtime/PageContextImpl.java(working copy)
@@ -203,7 +203,8 @@
autoFlush = true;
request = null;
response = null;
-depth = -1;
+outs = new BodyContentImpl[0];
+depth = -1;
baseOut.recycle();
session = null;
@@ -706,9 +707,7 @@
depth++;
if (depth >= outs.length) {
BodyContentImpl[] newOuts = new BodyContentImpl[depth + 1];
-for (int i=0; i-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving memory efficiency
On Sun, Dec 18, 2005 at 05:02:39PM +0100, Remy Maucherat 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. So could you please give me a hint, why you are not going to use it? My "problem" is a real PROBLEM in production environments. There are Tomcat's starving with OutOfMemoryErrors. What would be your approach to solving this (apart from "give tomcat more memory")? Bye+Thanks! Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving memory efficiency
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). Bye, Tino. - 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
Hi, On Mon, Dec 19, 2005 at 12:24:57PM -0800, Jason Novotny wrote: > Using Tomcat 5.5.12 and my servlet context fragment: > > reloadable="false" crossContext="true"> >prefix="localhost_gridsphere_log." suffix=".txt" timestamp="true"/> > > > doesn't seem to work-- I get this message in my logfile: > > WARNING: A docBase > /Users/novotny/Jakarta/tomcat-5.5.12/webapps/gridsphere ins > ide the host appBase has been specified, and will be ignored > > Navigating to localhost:8080/portal gives me a 403 > > This worked before, I'm wondering if this is a known bug or if there > is now a new way to configure the web app? Look at your tag. It's probably got an appBase="webapps" attribute, so you are trying to configure /Users/novotny/Jakarta/tomcat-5.5.12/webapps/gridsphere to be served as /grindsphere and /portal which is not supported. Either rename the grindsphere directory to portal and skip the attribute or locate it somewhere else and specify the path in Context. BTW: The Logger spec you gave will not work - logging has changed with TC 5.5. HTH! Tino. PS: Question to the developers: I'd like to have a without appBase (only 1 app and outside) - is this supported? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About possible memory leak in Tomcat 5.x
On Tue, Dec 20, 2005 at 12:39:50PM +0300, Andrievsky Dmitry wrote: > P.P.S What seems to me interesting. Although before putting > PageContextImpl into pool JspFactoryImpl calls pc.release(), and > inside the method all links must become null (or not?..) and > referenced objects must become available to gc, they are not. May be > it is the root of the problem?.. I came across this too and it was caused by Servlets calling JspFactory.getPageContext(...) and _not_ releasing the PageContext by calling JspFactory.releasePageContext(...) - which is a real memory leak (not caused by Tomcat but by the application!). Actually, the BodyContent array inside PageContextImpl is not reset so the BodyContents get reused - this might cost significant amounts of memory, depending on the application. We have been discussing this recently and it looks like there will be solution which is useful for everyone: USE_POLL will be made configurable and maybe big BodyContents will be reset on release(). Bye, Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r358036 - in /tomcat/jasper/tc5.5.x/jasper2/src/share/org/apache/jasper/runtime: BodyContentImpl.java JspFactoryImpl.java
Hi there,
On Tue, Dec 20, 2005 at 05:02:37PM -, [EMAIL PROTECTED] wrote:
> Author: remm
> Date: Tue Dec 20 09:02:33 2005
> New Revision: 358036
>
> URL: http://svn.apache.org/viewcvs?rev=358036&view=rev
> Log:
> - Add two system properties (as given the JSP API, there is no easy solution
> to
> retrieve configuration parameters elsewhere) to allow configuring Jasper
> memory management. Note that changing from the defaults may affect
> performance, depending on the application.
[...]
> +private static final boolean LIMIT_BUFFER =
> +
> Boolean.parseBoolean(System.getProperty("org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER",
> "false"));
[...]
> +if (LIMIT_BUFFER && (cb.length >
> Constants.DEFAULT_TAG_BUFFER_SIZE)) {
> +bufferSize = Constants.DEFAULT_TAG_BUFFER_SIZE;
> +cb = new char[bufferSize];
[...]
> +private static final boolean USE_POOL =
> +
> Boolean.parseBoolean(System.getProperty("org.apache.jasper.runtime.JspFactoryImpl.USE_POOL",
> "true"));
Thanks a lot! This gives people nice adjusting screws.
Bye, Tino.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r365858 - /tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java
On Wed, Jan 04, 2006 at 07:48:43AM -, [EMAIL PROTECTED] wrote:
> Modified: tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java
> URL:
> http://svn.apache.org/viewcvs/tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java?rev=365858&r1=365857&r2=365858&view=diff
> ==
> --- tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java (original)
> +++ tomcat/sandbox/java/org/apache/tomcat/util/buf/ByteChunk.java Tue Jan 3
> 23:48:42 2006
> @@ -690,15 +690,19 @@
> int myPos=i+1;
>
> // not enough chars to have a match
> -if( i + srcLen >= end ) {
> +if( myPos + srcLen >= end ) {
> break;
> }
>
> +try {
> for( int srcPos=srcOff + 1; srcPos< srcEnd; ) {
> if( bb.get(myPos++) != src.charAt( srcPos++ ))
> break;
> if( srcPos==srcEnd ) return i-start; // found it
> }
> +} catch( Throwable t ) {
> +t.printStackTrace();
> +}
Argh! Never ever do that!
1) don't catch Throwable - you'll happily consume OutOfMemoryError and
similar bad things here which should certainly be passed along.
2) don't use printStackTrace() - use a suitable logger instead
Just my 2 cents,
Tino.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r376730 - /tomcat/connectors/trunk/util/java/org/apache/tomcat/util/buf/CharChunk.java
On Fri, Feb 10, 2006 at 03:19:58PM -0800, Costin Manolache wrote: > Why not make MessageBytes implement CharSeq as well, for consistency ? > And maybe even ByteChunk - we're doing some (bad) conversions and > toString() inside already. Please don't! It's already a PITA to get character conversions right if the system locale doesn't match your working locale. It will be a desaster waiting to happen and a source of despair. Bye, Tino, having migrated a complex system from "ISO" to UTF-8. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sendRedirect and absolute paths
On Thu, Feb 16, 2006 at 03:24:52PM -0800, Casey Haakenson wrote:
> We have a customer who is hitting our web GUI through a fairly
> complicated SSH proxy scheme. For example, when they hit a page on our
> site such as /redirect.jsp we do a
> response.sendRedirect("/newpage.jsp"). This results in a 302 status
> code and a Location header with the full URI
> (http://somesite.com/newpage.jsp) which is the incorrect URL since the
> proxy has been rewriting the URL's so far and this new one is the one
> that the proxy is hitting not the original one the browser thinks it's
> viewing.
>
> Anyway, I have tested a change to CoyoteResponse.sendRedirect:1114 (we
> are using 4.1.24) to send the "relative absolute" ("/newpage.jsp") path
> back to the browser in the Location header. This appears to solve the
> problem and work in all browsers I've been able to test, but am worried
> that since you guys went to so much trouble making it include the
> protocol, hostname, port, etc that this may break some odd browser or
> case I'm not fully understanding at the moment.
AFAIK it's against HTTP specs. Redirects have to be absolute. For
example, lynx complains ("redirect URL is not absolute" or something
alike). IMO there's only one practical solution: Tell your application
which URLs will be used to access it and prepare the redirect URLs
according to the request (you can evaluate X-Forwarded-Host and similar
headers to get the original hostname).
Bye, Tino.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedback request] session replication
Hi Filip, On Fri, Mar 03, 2006 at 10:44:21AM -0600, Filip Hanik - Dev Lists wrote: > I wrote together a little idea (also emailed to geronimo-dev for > feedback) on how the next generation of session replication should be done. > Today's replication is an all-to-all replication, and within that realm, > its pretty poor. It creates way to much network traffic as each request > results in X number of network transmits (where X is the number of nodes > in the cluster/domain). [...] The drawback of your approach is that you still need an intelligent loadbalancer in front of the cluster. When using all-to-all replication you can use a stupid one, which simply schedules requests round-robin. Bye, Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Strange memory problem
Hi there, I'm currently tracking an OutOfMemory problem. We've got a web app which gets OutOfMemory after some heavy use. I installed Mustang 1.6b62 on the machines and had them dump heap on OOM. Then I looked into the heap dump using jhat. I noticed that there are several objects hanging around with a strange reference: Java Local Reference (from [EMAIL PROTECTED]) : --> some.of.our.classes According to jhat, no other objects are referencing these objects (only Finalizer). Has anybody a clue what might cause this? After all, they don't seem to get garbage collected. Bye+Thanks! Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange memory problem
On Tue, Mar 07, 2006 at 11:12:35PM +0100, Remy Maucherat wrote: > >I'm currently tracking an OutOfMemory problem. We've got a web app which > >gets OutOfMemory after some heavy use. I installed Mustang 1.6b62 on the > >machines and had them dump heap on OOM. Then I looked into the heap dump > >using jhat. > > > >I noticed that there are several objects hanging around with a strange > >reference: > > > >Java Local Reference (from > >[EMAIL PROTECTED]) : > >--> some.of.our.classes > > > >According to jhat, no other objects are referencing these objects (only > >Finalizer). > > > >Has anybody a clue what might cause this? After all, they don't seem to > >get garbage collected. > > Personally, I don't know these new tools, so I don't know how to > interpret what they say. For example, maybe there's a whole reference > chain between the two. This is supposed to show the reference chain. If I include weak references in the display, a lot of Finalizer stuff is shown but this one stays. Thanks, Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister wrote: > You have to consider how (or if) to allow for long-running background > threads. Successive requests for the same user will not use the JVM > (whether this counts as an advantage or disadvantage is debatable). The JVM > isn't going to be optimizing code. The point of using an application server (instead of e.g. PHP) is that it maintains state on the server. You lose this by using fork(). So it's not going to work at all for real applications since your application "returns" to it's previous state after every request. Bye, Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to start a Thread in the same JVM as Tomcat
On Thu, Nov 16, 2006 at 03:47:09PM -, confusionvalley wrote: > I didn't told you earlier but my objective is to test a webapp that I already > have. And I really didn't want to change that webapp or create another webapp > to make all the fault-injection stuff. Do you think that creating another > webapp is really the best solution? > If the best solution is to create a new webapp how should i create that *new* > webapp? A simple servlet with an init() method (starting when the server > starts) that creates the thread and all the fault-injection code? Or do you > have any other idea for me? Make your servlet implement the ServletContextListener, then you may even inject it into the existing webapp by copying the class file there and adding a your.servlet to the web.xml of the webapp. Bye, Tino. -- www.quantenfeuerwerk.de www.spiritualdesign-chemnitz.de www.lebensraum11.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What's about unloading policy of jsp-servlets ?
On Wed, May 17, 2006 at 05:47:16PM +0200, Remy Maucherat wrote: > >So, what are the requirement to getting a patch accepted in tomcat 5.5? > > As I said before, it is very unlikely I would accept such a patch (since > it would give JSP the worst of both worlds: the hassle of compilation > combined with the crap raw performance of templates), and for sure I > will veto it in the 5.5 branch. I see no problem as far as it is switch-on and doesn't interfere with the performance critical code paths. LRU cache for JSP servlets (with configurable size) would be a good thing IMO. Bye, Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Digest Authenticator realm name is clear text right?
On Thu, Aug 10, 2006 at 12:39:48PM -0700, Jalali, Alex wrote: > Hi, Is this is a bug with tomcat or adobe Acrobat in digest auth? I suppose neither. The real is clear text. > But adobe Acrobat (using its upload review tool to publish to a webdav > server) returns with a response header that has, I guess encrypted the > realm name like this > > >>> Authorization: Digest username="user", > realm=""f6b755878fd52d631b890b"" ... I suppose(!) that they are just sending a random value (looks like an MD5 of something). It ensures that the browser will prompt for a password every time. But this is just a wild guess. Bye, Tino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
