The transient session storage does not work for long
term session storage as the objects get piled up. A new
session storage class needs to be created to handle this.
Logged In: YES
Fixed in 10a6+.
Change your web.xml file to have this value to use the new
Make sure you update your project with the new .tld files.
The new method works like this:
Each image tag has a default timeout of 5 minutes. This can
be changed by adding timeout=[n sec] to your cewolf:img tag
in your jsp.
A new object is stored in the session that will contain all
of that session's charts. A thread is started once objects
are added to the map. The thread checks every 5 seconds for
timed out charts. It's a low priority daemon thread so it
shouldn't have much impact. Once the map is empty, the
thread terminates. New entries to the map will restart the
Logged In: YES
I submitted a year ago a patch for this problem which seems
better to me than your solution :-).
In almost all cases, once the chart is rendered you don't
care about it.
So what I had done was to enhance Storage interface to add a
method to remove a chart by it's key.
I called this method after rendering the image in the
I don't know why you didn't take my solution into account.
I distributed it in production and it has been working for a
year with no problem.
I you're intersted in my solution, send me a mail add a
comment to this thread I will then attach the patch I had
Please send the patch. I will certainly look into it but I
don't think it will solve all use cases. In mine, the users
were pulling up the graphs and trying to paste them into
word. When they did this, the system was copying the url in
the background and when pasting into Word, it was trying to
retrieve the image. If the image was removed immediately
after rendering or had timed out, the image generated said
it was no longer available. This is why I put in a 5 minute
timeout to give them time to paste if they wanted but also
to keep the memory footprint reasonable.
I submited the patch under ID 1345233.
For your particular need, I don't know what you think of it
but my opinion is that LongTermSessionStorage is a rather
dangerous solution, because under a high load of Charts
request, this solution will launch a lot of thread which may
endanger the response time of the server.
Maybe this solution may answer your need if the use case is:
A fixed number of user request a lot of charts.
Why don't you modify the CewolfRenderer to do the following:
After rendering the image, iterate on the Storage Charts and
tests if timestamp exceeds the configured timestamp and then
remove the se.
Thus you don't launch threads.
Of course this solution works only if you are not in the
case where a lot of users request one Chart only.
Another solution which may work but is more complex to
Whenever a chart is registered in the session it registers
it ID to an objet in the application context.
The implementation will also need to implement
HttpSessionBindingListener to remove itself from this object
if it is unbound from the session.
A background thread (only one) will run periodically and
iterate over the ids in the application context scope and
remove all images that have exceeded a configured timeout.
Of course you have to handle synchronization of the object
stored in application context.
This solution will work for all cases.
My solution does only have 1 thread. It contains a map of
the objects to be deleted and periodically checks them all.
When there is nothing, the thread goes away. I think it's a
reasonable solution to the problem.
Naturally there is an issue with a huge load of images. This
can be solved by shortening the timeout to just seconds or
by implementing something else.
The nice thing is that there is an interface to be
implemented and new storage objects can be set in the
web.xml so people can make new ones as they need. If they
are sent to me then I will include them to broaden the choices.
Logged In: NO
I'm sorry to insist but with your solution you launch 1
thread per client so under a high load, the server will be
overwhelmed by user Threads.
To confirm this behaviour, put a breakpoint in the run
method of your thread and open 2 IE browser calling a Chart
generation, you will notice 2 threads running.