Mike,
RE BaseContext.getThreadObjectContext()
Of course, this could be my problem. I was using DataContext until 3.0
then converted over to BaseContext.
2.) BaseContext.getThreadObjectContext() just tells how you're
getting a context. It doesn't tell how it's managed. Do you have a
servlet filter that creates a new ObjectContext at the start of a
request and then clears it out at the end? Or does it do this per
session?
I do not know how it is being initialized in the webapp (in my
experimental non-web apps I explicitly intitialize it, but in the
webapp it is already initialized).
I've never looked at the method, but it might default to
creating one permanent data context per thread if you don't do
anything else (like set up a servlet filter). That could be part of
the problem.
That sounds plausible. I could not find an example of how to
initialize this and manage it as you suggest in a web app. I have not
created a servlet filter but have follow the Cayenne docs for
configuration of the web.xml.
If this is insufficient then I agree, this could be the problem.
Unfortunately, I have not found docs on how to accomplish what you are
recommending.
Joe
On Sep 16, 2009, at 3:10 PM, Mike Kienenberger wrote:
1.) 128 still seems small to me. I don't think I run anything at
less than 256.
On the other hand, We have an app with 1000s of customers that uses
512Mb, I think. So 1500 seems excessive.
2.) BaseContext.getThreadObjectContext() just tells how you're
getting a context. It doesn't tell how it's managed. Do you have a
servlet filter that creates a new ObjectContext at the start of a
request and then clears it out at the end? Or does it do this per
session? I've never looked at the method, but it might default to
creating one permanent data context per thread if you don't do
anything else (like set up a servlet filter). That could be part of
the problem.
On Wed, Sep 16, 2009 at 2:49 PM, Joe Baldwin
<[email protected]> wrote:
Caveat: Apparently I am not as well. :)
1.) I looked at the 65M issue. On my development box (OSX) I set
it to
-Xms128m -Xmx128m (basically arbitrary). So when I went to the
remote
hosting company, I purchase a similar amount.
a. However, we are doing *very* little work (lots of product
fetches
and only a few product inserts and updates) and it runs out of
memory *very*
fast which I *assume* means it is my code, but I don't know.
b. I am doing research and here is a "web
recommendation" (for all
that is worth)
Whenever possible, Unidata recommends
-Xmx1500m for 32-bit systems, and -Xmx2048m --Xmx4096m for
64-bit
systems.
c. Since the host is 64-bit, I am wondering whether my
assumptions
may be off for 64-bit systems.
2. DataContext: Sorry, but I am getting confused on this one. I am
using
BaseContext.getThreadObjectContext() based on recommendations (I
converted
all the old DataContext refs to BaseContext, but I don't really
understand
it from reading the docs) and am *not* releasing it at the end of
session.
Not quite sure of how to do this properly.
3. Don't know how to set the cache to retain N number of objects. I
experimented with
query.setPageSize(RowsPerPage);
query.setCacheStrategy(QueryCacheStrategy.SHARED_CACHE);
query.setCacheGroups("product", "ProductList");
This seemed to help quite a bit but I still eventually ran out of
memory. I
recently removed *all* the SHARED_CACHE and it ran out of memory
very fast.
Thanks for your input
Joe
On Sep 16, 2009, at 2:25 PM, Mike Kienenberger wrote:
Caveat: I'm not really an expert on Cayenne memory management.
1) Are you allocating enough heap memory to the app server to start
with? I don't know what the default is these days, but in the old
days, an application by default only gets 64Mb of memory -- that's
pretty small.
2) Are you using a new DataContext per request? Or at least per
session?
3) I seem to remember that the cache strategy is configurable. Have
you configured a cache that only retains N number of objects for a
suitable value of N?
On Wed, Sep 16, 2009 at 2:11 PM, Joe Baldwin <[email protected]
>
wrote:
Hi,
I have asked this question a number of ways but I still have a very
serious
problem with Cayenne-specific memory management configuration
associated
with Tomcat.
The problem with debugging is that given that I have very little
visibility
into the Cayenne memory management it is extremely difficult to
debug
this
using conventional strategies. Also I am not requesting anything
from
the
system that is terribly exceptional so I am attempting to use
default
settings as much as possible.
My strategy is to ask the experts for a Cayenne configuration and
standard
memory management steps I should take to conform to the new Cayenne
memory
management design intentions.
Problem:
1. I have essentially a webstore, three tier design with Tomcat,
Cayenne
and
MySQL.
2. When after only a few queries of products, tomcat freezes up and
reports
out of memory errors.
I have attempted to configure the caching strategy ask best as I
can
understand from the docks but this only gets me a few more hours
of usage
before the out of memory errors. (I tried the SHARED_CACHE). The
NO_CACHE
strategy is worse.
I would appreciate a set of steps (aka a primer) that should
handle a
website with a lot of fetches of hundreds of data objects (i.e.
products)
and very few updates.
Note: My gut feeling is that I am not properly managing the data
object
array properly and it is leaking memory.
I would appreciate any input, but I would first like to know what
the
minimum require steps are for managing at data object result set
ArrayList
so as to properly cache and then properly free the memory after
it is no
longer needed.
Context: Tomcat, MySQL, Cayenne 3.0M6
Thanks,
Joe Baldwin
