So your app isn't leaking memory?, the GC is just taking longer, or are you
running out of heap space due to a memory leak, etc. and requiring more GC
runs? How do you heap sizes, etc. look over time. What objects are occupying
the most memory?
Also, while I'm thinking about it, it seems like it would be best practice
to put the stateful session release in a try - finally block as a best
practice? ( I haven't seen this in the docs/code samples)
Mike
sburrows wrote:
Yes, we have a YourKit license. If I watch certain objects like the
StateFulSession I can see one created for each web session and deleted
each time the session expires. I've run thousands of transactions through
my dev server in an all night test. The morning results after all
sessions had expired showed little difference from my starting point and
nothing significant in the rules related objects.
We also have a JMX-based free-memory logger in our production environment.
The release that introduced the rule engine in a minimal capacity shows
some memory degradation as well as much higher volatility and a much
greater 'swing' when the garbage collector runs. This indicates to me
that something is generating a LOT of temporary objects that are all
collected at the next GC run.
It would be nice to get a confirmation that we have implemented this
correctly. Also I wanted to know of any other connections between a
StatefulSession or the objects added to working memory and the RuleBase.
My concern is that data might be held longer than it should be (ie: data
created in on session is held onto after that session expires) but
eventually does get collected - at least by the time all sessions expire.
Thanks for your help!
sburrows
--
View this message in context:
http://www.nabble.com/Significant-memory-degradation-in-high-transaction-...
Sent from the drools - user mailing list archive at
Nabble.com.