Re: resource flushDataCache()
Re: resource flushDataCache()
- Subject: Re: resource flushDataCache()
- From: email@hidden
- Date: Tue, 07 Oct 2003 18:30:45 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
Actually, another kind of hacky solution occurs to me too.
The WOImage with 'data' binding optionally uses a 'key' binding. If you
bind this 'key' binding, then images are NEVER removed from memory, until
you manually remove them. You could generate a 'key' (this needs to be
unique accross the entire app instance!), and then store this key
somewhere in your app. You could store it in your Session, and then
manually remove data for a given Session's keys when the Session
terminates(). You could store it in the Application, along with the time
that it was cached, and then periodically run a task that removes all
keys older than X minutes, or whatever.
But keep in mind that the data will then NEVER be removed until you
manually remove it. Is there some way to have things behave as normal,
with resources being removed upon access, but you can still manually
remove 'leftover' ones at a given time? I can't think of one.
For me, the fact that the image URL was only good for ONE access, that
has always been a problem for me. Javascript, page reloading, user
choosing to save the image to disk, any second access of the image URL
will result in blank data. Actually, some might consider this a feature,
but it used to cause all sorts of problems for me, when I used WOImage
with 'data' binding.
--Jonathan
On Tue, 07 Oct 2003 13:23:57 -0400 Tom Pelaia wrote:
> Hi,
>
> We have built and have been deploying an electronic logbook written
> using WebObjects 5.1 and deployed under J2EE via OC4J. The only problem
> is that after about one month of 24x7 operation, the application server
> runs out of memory. Since the logbook is rich in images and attachments
> which are all submitted and viewed by users and stored in a databases,
> the most likely culprit is the known memory leak of the resource manager
> which occurs when images don't make it from the server to the client for
> whatever reason. The recommended fix is to call flushDataCache() on the
> resource manager. The only problem is that I can't figure out when to
> call it. The logbook runs 24x7 and it runs the sessions are all
> concurrent. The version of OC4J that we are using for deployment does
> not have any auto recovery or periodic shutdown of instances, so I must
> find a way to clean up memory internal to the application. Whenever I
> call flushDataCache() images and attachments don't make it to active
> sessions.
>
> Where is the safest place to call flushDataCache()?
>
> thanks,
> -tom
>
> --
> Tom Pelaia
> SNS Project, 701 Scarboro Road, MS-6473, Oak Ridge, TN 37830
> phone: (865)574-6421, fax: (865)574-6617
> _______________________________________________
> webobjects-dev mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.