Just an update on what I'm up to:
The existing cvs configuration makes it hard to work with Eclipse (my ide of choice) because everything is just dropped into the root of the cewolf project. I submitted a request to SF to have everything moved into a new folder. This is a cleaner tree and will make further development easier.
Once this is done, I will update it with the code I've been using since April...it currently works with jfc .9.18.
Most pressing on my plate is a solution to the memory leak problem. That will happen first, likely next week as it's currently causing problems for some of my deployed customers at my FT job. Once that's done, I will update the system to work with the latest jfc.
If you are seriously interested in contributing development time to this project, please email me.
I would be interesting in supporting your development plans.
Do you have any ideas what could cause the memory leaks. As far as I remember Cewolf does not hold any variables except the session based caches which should be cleaned up by the container automatically. BTW the caching is the most tricky implementation inside of Cewolf. Do you have a full overview on how it works? Otherwise I could help you if you want. We could even have a phone call about that if it helps.
Let me know how I could help.
I'm mostly concerned about the session storage. The chartimage objects are being stored, but never removed. After a while, if I enumerate the session, I see tons of charts stuck in there. I'm guessing the transient session storage is meant for short lived sessions. My particular application has long lived sessions, so the objects need to be cleaned up at some point, probably using the timeout that can be set. I did notice somewhere else that every object was getting the same unique key, but I have to look closer to find where I saw that.
your're right. Chart images are removed when the session dies. Til then they remain in memory.
The key generation is the most tricky thing in Cewolf's storage mechanism.
Every chart gets the same unique key if and only if all the attributes that determine the chart's rendering remain the same. How is this implemented?
The key generation (taglib.util.KeyGemerator) serializes the ChartImage (implemented by taglib.ChartImageDefinition) object returns the hashcode of the serialized object as the object's id. Thus a chart if the same attributes and parameters produces the same id even if it is a different instance. As the ChartImageDefinition holds the image attributes as well as the chart attributes (ChartHolder implemented by a concrete definition of AbstractChartDefinition) it contains all information needed to reproduce the chart image.
The ChartHolder knows about the DatasetProducer (DataContainer) used to produce the data and the time when the data for this chart has been produced (datasetProduceTime) (used by the cache to proof expiry of data). It is assumed that the same DatasetProducer produces the same values when passed in the same paramters (this is a point where many forum postings complained about because their DatasetProducer broke this reasonable contract).
If the data for a chart expired a new produceTime is stored.
This mechanism avoids the storage of the data itself!
Amen to the CVS issue!
Another suggestion I would make along those lines would be to "mavenize" the project which would serve three purposes:
1. Eliminate the need to store jar dependencies in the CVS repository.
2. Integrate the project website, API docs, source code, CVS repo, dependencies and unit testing into a seamless whole.
3. Give a slick professional front-end to the website....Nothing wrong with your site, Guido. Maven just reduces the work developers need to perform to ensure that the website is a reflection of current development status.
To this end, I've got a reasonably complete project.xml put together for Cewolf and am inclined to hold off on it until you submit your updated code.
Yeah, I'm interested in being a part of Cewolf. :)
Can you send me more info about maven or mavenize? I've never heard of it and a cursory google didn't find anything obvious.
I'm less inclined to spend time messing with the project website at this point...the over whelming demand is for updates to the code. However if someone else wants to update it, then I'm all for that.
Maven is an Apache project (http://maven.apache.org) that is designed to permit easier management of all aspects of a Java project. It's similar to Ant but works at a higher level. Maven works by way of many plugins, most of which are currently developed as subprojects of the Maven project. The plugins define goals that can be invoked on the project. Ant has "targets", Maven has "goals"...similar idea, but a Maven goal essentially rolls numerous "targets" into a single set of functionality, like building a war file or generating the project website. Of course, things can be customized but the majority of typical Java project operations are there without requiring customization.
The project.xml file is the key document that Maven uses to govern the project. It defines the project details, developers, license(s), dependencies, and reports (coverage, unit testing, cvs stats, etc.).
As for dependencies, Maven uses a .maven folder in your HOME folder to store JARs, TLDs, etc. that the project is dependent on. If you were to add a new dependency to the project.xml (or switch to a newer version of a dependency), Maven automatically downloads the dependency from http://ibiblio.org/maven and stores it in your local repository (.maven/).
Maven takes into consideration your disinclination to mess the website by essentially making the website yet another build product. Maven's own site is a generated product of Maven and shows the default look and feel of the "maven site:generate" command.
As for "mavenize", that was just me being cute with the Maven name. :D Geez, can you tell I'm sold on Maven?
First, I would just like to say that it is great that the project continues! It would be sad to see a usefull library like this die.
I totally support Chris Lennert's idea about "mavenizing" the project. The last couple of months I have been mavenizing all the projects I'm working on on my day-job, and it has really paid off. Not only has the build and development process become cleaner and simpler, project documentation availability has increased because of the brilliant maven site-goal. Maven makes building project artifacts like jar files and documentation easier than anything I have ever seen. And, of course, as Maven builds on Ant, you can customize as much of the build process you want - although you will not have to most of the times.
Using mavenized CeWolf in my project would just be a matter of specifying a couple of dependencies, and Maven would handle the rest - even generating and maintaining the Eclipse .classpath - file (through the Maven Eclipse Plugin).
I can seriously recommend giving Maven a look for the CeWolf developers.
Bent Andr Solheim
Has the Mavenizing effort began? Will it begin?
I haven't had much time to look at maven yet, but I did manage to update cvs.
I created a new file release in the unstable package. This represents the code I've been running since ~April. The only known problem is the memory leak and that's next on the list. This version comes with .9.20.
CVS looks good, Brian!
ah, "cvs update..."
Thanks. Hopefully tomorrow I'll be able to release the fix for the memory leak.
I would be very interested in your strategy to fix the memory leak. Because it might not be that easy or I have missed something.
When will you remove the chart objects out of the memory? After their first retrieval? What if a user navigates back and wants to retrieve the chart twice? Will you use a timeout? What will it be and what will you do if someone requests the chart after timeout?
I implemented a new storage class and a few minor changes else where to support it. It's going to have a timeout, probably several minutes (I'd like to make the default timeout configurable in the web.xml). I added a timeout parameter to the img tag so each chart can have a different timeout if needed. Then a single extended hashmap is stored in the session. The extended class implements runnable, so it will have a thread to periodically check for expired charts and remove them.
My ongoing work is in the pr1002248 branch if you're interested.
I would propose not to use a runnable (or at least make it configurable to do so) because some web container might not permit to open a new thread. As an alternative you could check the removal of cached object every time a new thread is added or even better: use a LRU queue with a configurable amount of object and always remove the last recently used chart.
Just some ideas.
I'm very glad that some one with your skills is going to lead the project!
I had considered using a fifo to store the objects as well. Since it's configurable which storage object people choose, I decided to create this one for now and probably write another one after. It's really easy to implement a new one using the storage interface.
Good to hear this brilliant project is not dead yet! I was wondering if the new version solves the memory leak problem. I stopped using Cewolf some months ago but I remember the problem occurred even when not using the Session storage implementation, which indicates it might not only be related to resource management at the session level. Try replacing the session implementation with Guido's file system storage impl and simulate a few concurrent users and you will also see the same OutOfMemory you get with the session storage impl.
Hope this helps somehow.
10a7 solves this problem with a new storage option. In addition, cewolf now supports the latest jfreechart.
I just tried the new version 10a7 with the LongTermSessionStorage implementation and I still get OutOfMemory errors, though it seems tolerance is a bit better than previous versions. I only need to try 4-5 users displaying 5-10 charts simultaneously, each chart with mid-sized datasets. All this both on a XP box and on a Linux RH box both w/ 512Meg RAM.
How are you guys testing the memory performance anyways?
Try changing the default timeout for each chart to a shorter time period. If your system simply can't handle all those charts simultaneously, then I don't know how it can be solved. The only solution might be to have it delete the file immediately after sending it. I tried that, but it wasn't very user friendly. (couldn't cut and paste, etc)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.