Re: resource flushDataCache()
Re: resource flushDataCache()
- Subject: Re: resource flushDataCache()
- From: email@hidden
- Date: Tue, 07 Oct 2003 18:25:13 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
I consider the use of WOImage bound to a 'data' binding to be broken for
just the reason you mention. I know of no good way around it, it's a
fundamental flaw in the design.
For a temporary fix, you could simply cycle your application instances.
IF your application uses sessions. Periodically set 'refuse new sessions'
on existing instances in Monitor, at the same time you start new
instances. At this point, all NEW sessions will be to the NEW instances,
and at the point all OLD sessions expire, you can simply shut down those
old instances. (In fact, wotaskd should shut them down for you). But, if
your app does not use sessions, or if, as you say, there are other
reasons you can't cycle instances like this, this isn't available to you.
Unfortuantely, I can't think of any other solutions without recoding.
Personally, I would reccomend re-writing your application to NOT use
WOImage with the 'data' binding. As an alternative, I've written the
following relatively simple component which provides a 'data' binding for
an Image WITHOUT using the WOResourceManager. It seems to work well to
me; I use it in my own production code (although not very extensively)
and it seems to work fine. I'm not even sure WHY Apple used the design
they did, instead of one like mine. It makes me think that there must be
some disadvantage to my design I'm not thinking of, but I haven't found
it yet.
My code can be found at:
http://wocode.com/cgi-bin/WebObjects/WOCode.woa/1/wa/ShareCodeItem?itemId=309
Better yet would be re-writing your application to serve all images from
the file system, with the web server, instead of through WO. But this is
a potentially huge redesign, which you may understandably not want to do.
But personally, I find storing images in the db to have very few
advantages to storing them in the filesystem (with a filepath stored in
the db), and many disadvantages. For new code, I think it's much better
to do it that way.
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.