#50 Out of memory in session storage

Other (6)
Brian Fox

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.


  • Brian Fox

    Brian Fox - 2004-08-04
    • status: open --> open-fixed
  • Brian Fox

    Brian Fox - 2004-08-04

    Logged In: YES

    Fixed in 10a6+.

    Change your web.xml file to have this value to use the new
    storage objects:



    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

  • Philippe Mouawad

    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
    CewolfRenderer servlet.
    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

  • Brian Fox

    Brian Fox - 2005-11-01

    Logged In: YES

    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.

  • Philippe Mouawad

    Logged In: YES

    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.

  • Brian Fox

    Brian Fox - 2005-11-01

    Logged In: YES

    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.

  • Nobody/Anonymous

    Logged In: NO

    Hello Brian,
    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.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks