Ole V. Villumsen

Greenhorn
+ Follow
since Feb 18, 2010
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ole V. Villumsen

Thank you very much for the suggestion!

When checking the web.xml syntax for specifying a storage in the CeWolf tutorial (on http://cewolf.sourceforge.net/), I also stumpled across the session-timeout setting (1 minute), and copied it. That alone helped much, memory consumption built up much more slowly. Seems I went too quickly through the tutorial the first time. However, I still had thousands of ChartImageDefinition objects on the heap, referenced from a large ConcurrentHashMap in the session with String keys representing integer values, like "-1237369985".

However, additionally specifying LongTermSessionStorage in web.xml and a timeout of 10 (seconds) in each cewolf:img tag on my JSP page seems to have eliminated the leak completely. That's so great!
On the contrary I have showlegend = "false" on both my charts.

Should I use the usecache attribute and what value should I give it?

No such luck; no imgurl tag here. Thanks for looking.
I still have very many ChartImageDefinition objects on the heap long after I've closed down my browser. Wonder if we should implement our own CeWolf storage instead of TransientSessionStorage.

I tried putting <%@ page session="false" %> on the JSP page, but that causes de.laures.cewolf.storage.AbstractSessionStorage to throw a NullPointerException, and the page display breaks.

Since we expect long sessions, we need to find a solution where obsolete charts are thrown away during the session rather than after it ends.
Thanks again! I noticed that attribute too, feel foolish I didn't see ot from the outset. Anyway, it helps noticeably, but my problem doesn't seem to be all gone. I will report back.
From jmap and jhat I gather that my Tomcat Catalina session (an org.apache.catalina.session.StandardSession object) through its attributes holds on to thousands of de.laures.cewolf.taglib.SimpleChartDefinition objects. I suspect that it generates a new one for each page refresh and doesn't let go of the obsolete ones.

I shall try and see what happens if I close and restart my web browser regularly while the application is running. Problem will remain, though, since my boss would like to be able to have our web page open at alle times, even display it on a large screen at the company entrance.

I should very much like to hear from others that have tried using dynamic CeWolf charts in a web application that's supposed to run continuously with minimal downtime. Hear what memory consumptions you have experienced.
Thank you very much, Ulf, for the reply.

It's more or less a separate issue, but I'm confused about the hasExpired method. The Javadoc says "If the data which had already been used for chart rendering is still valid this method should return true." This seems to indicate the opposite of what the method name says. The description of the return value seems to agree with the name: "true if the data which had been produced with the passed in parameters has expired since its creation, false otherwise". Can you help? I have tried returning false always and I have tried returning true always, but as far as I can tell from my log files, the chart is produced anew each time (every 5 seconds) in both cases. I can also reproduce the OutOfMemoryError with both versions. Only it took a little longer with the version that returns true.
In a smaller web application I added two timeseries charts using CeWolf 1.1 and JFreeChart 1.0.13. When we deployed the application, it ran for an hour, then started reporting lots of OutOfMemoryError.

I'm convinced that the problem has to do with the fact that our JSP page automatically refreshes every 5 seconds, which causes the charts to be redrawn. The charts themselves only change once every 5 minutes, but there is information in the page that we need to update within 5 seconds when it changes. I know that the long term solution i AJAX, we will come around to that later this summer.

Still, I had not expected this behaviour, and we would like our application to run 24*7, which it did nicely before. Does anyone know of a memory leak in either CeWolf or JFreeChart? Maybe even of a way to circumvent it? I just wanted to ask before I acquire a profiler.

Our application runs in a Tomcat server. There are 12 data points in each plot. I use two chart postprocessors for each chart, one de.laures.cewolf.cpp.TitleEnhancer and a homegrown one that fixes the range of the y scale (range scale) to be from 0 to 0.25 regardless of the data. For the time being, we have very few users, say 2 or 3, but that is expected to grow.

Any hints appreciated.

anvi kon wrote:



Just a detail: <cewolf:param name="0" value="#00FF00" /> is simpler.
Thanks, Ulf, for cewolf 1.1, and for very helpful interaction here. I've just started using SeriesPaintProcessor.
Thanks all for an enlightning discussion. My other sources confirm that you're supposed to call getNext().invoke() from within your valve if you want the request passed into your servlet.

I'm curious about a detail or too (some of you won't care).

Is it safe to assume that getNext() doesn't return null? Admitted, you can set next to null on your valve, so it's technically possible that getNext() returns null. But as long as you don't do anything like that, my feeling is you should be safe. Which would suggest:


If you think you should take the null into account, Jaikiran Pai's code is the right one. For thread safety, you should call getNext() only once.
14 years ago