Haha! While I haven't run extensive tests, the problem appears to be solved. By only defining a query once, things seem to be proceeding normally. The heap dump still has JESS's token's on top, but they no longer hold a large majority share of resources.
I was under the impression that if a defquery was defined under the same name as another, the older one would be overwritten. Perhaps this is a bug, or perhaps I was simply misled towards this impression. Thanks for your help in this. I hope the rest of my JESS use stays problem-free. Sam Sarjant wrote: > > Well, I'm really just being a lazy programmer. I don't really need to > redefine the same query; I could just use a map to point to previously > defined queries. The queries come about because an interactive agent uses > a policy to make decisions. This policy is made up of rules, the > conditions of which I use to query the state to see if the rule is > applicable. > > 'Why not just use rules?' you may ask. Well rules are checked when run is > called (which BTW is at each state of the environment to assert extra > information kept by environment rules), whereas queries are only checked > when they are manually called. If an agent's policy was asserted as a > rule, it would have to be retracted again when the policy changes. > > In any case, I'll stop being lazy with the query definitions and see what > happens on that front. > > The environment in which that heap dump was generated from should have > about 25 facts (thereabouts) and approximately 10 rules. And about 10 > templates. So something is amiss here. > > The (facts) command only shows the facts that should be there (the approx > 25 or so), so something internal is going on. I'll investigate the query > redefinition problem and send my results. > > > Ernest Friedman-Hill-3 wrote: >> >> Hmmm. The numbers don't mean anything specifically -- they're just a >> way of creating unique symbols -- but the fact that they come one >> after another this way finally makes me realize that you really did >> mean you are redefining a query over and over again, hundreds of >> times. Perhaps you *have* found a memory leak, because you're doing >> something highly atypical. Why do you need to redefine the identical >> query over and over again? >> >> On the other hand, perhaps the redefinition a red herring: if you're >> automatically generating these, perhaps you're creating many, many >> rules or queries that are *not* duplicates, and therefore running out >> of memory? >> >> Looking at your heap dump info, it seems to suggest that you have >> 47,000 live facts in working memory, and maybe somewhere between >> 200-600 rules and/or queries. Does that align with your expectations? >> >> >> On Feb 20, 2010, at 9:24 PM, Sam Sarjant wrote: >> >>> >>> Hmm. I just came across something that could be the culprit. When >>> creating >>> the new queries which overwrite the old ones, upon examination of the >>> 'ppdefquery <queryname>', I noticed that the '?' variable is >>> assigned a new >>> JESS name (an internal process). >>> >>> The possible problem I noticed was that this internal variable was >>> incrementing with every redefinition of the query. For instance: >>> >>> "(defquery MAIN::polRule0 >>> (on ?X ?_blank_396) >>> (above ?X ?_blank_397) >>> (clear ?X) >>> (block ?X))" >>> "(defquery MAIN::polRule0 >>> (on ?X ?_blank_398) >>> (above ?X ?_blank_399) >>> (clear ?X) >>> (block ?X))" >>> "(defquery MAIN::polRule0 >>> (on ?X ?_blank_400) >>> (above ?X ?_blank_401) >>> (clear ?X) >>> (block ?X))" >>> etc. >>> >>> Perhaps it's nothing, but if JESS is hanging on to these variables, >>> it could >>> become bloated. >>> >>> >>> Ernest Friedman-Hill-3 wrote: >>>> >>>> The best thing to do would be to try to figure out where the memory >>>> is >>>> going, and whether it's a bug, or a normal consequence of how you're >>>> operating. There's no reason why, given what you've described, memory >>>> usage should increase over time, so there's either something you're >>>> not telling me, or there's a bug someplace. Can you try to check it >>>> out using any kind of a heap profiler? >>>> >>>> On Feb 17, 2010, at 10:43 PM, Sam Sarjant wrote: >>>> >>>>> >>>>> Hi. I am using JESS to represent a relational environment for an >>>>> agent to >>>>> interact in (Blocks World, to be specific, if that helps). >>>>> >>>>> At each state, I am first resetting the Rete object and then >>>>> asserting the >>>>> state of the environment. From these assertions, further assertions >>>>> are made >>>>> by using rules which define extra predicates. For example, if I >>>>> assert (on a >>>>> b), I also create the (above a b) and possibly (clear a), depending >>>>> on the >>>>> exact state of the environment when (run) is called. >>>>> >>>>> Anyway, the agent receives this information, chooses an action to >>>>> take, and >>>>> the environment is updated again by resetting and re-asserting. >>>>> >>>>> While I could contain all operations within JESS in this particular >>>>> environment, some Java code is required to be run during the process >>>>> for >>>>> other environments, so this is why I don't simply operate using >>>>> assert and >>>>> retract. >>>>> >>>>> Obviously this doesn't fit the idea that generally rule bases remain >>>>> static, >>>>> but the performance I get is reasonable. My problem lies in the fact >>>>> that >>>>> after several hundred (or perhaps thousand) of these assertion, >>>>> resetting >>>>> loops, Java or JESS runs out of memory and throws an >>>>> OutOfMemoryException. >>>>> The rules for defining extra predicates are asserted only once, but >>>>> queries >>>>> are asserted roughly each iteration for state matching, though they >>>>> should >>>>> be asserting over one-another (defqueries of the same name). >>>>> >>>>> Is there something I can do to 'flush' JESS, or stop it storing >>>>> these reset >>>>> assertions? Or would it be better to periodically create a new Rete >>>>> object, >>>>> load in the rules and continue? >>>>> >>>>> - Sam Sarjant >>>>> -- >>>>> View this message in context: >>>>> http://old.nabble.com/OutOfMemory-after-multiple-assertions-resets-tp27634092p27634092.html >>>>> Sent from the Jess mailing list archive at Nabble.com. >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> To unsubscribe, send the words 'unsubscribe jess-users >>>>> [email protected]' >>>>> in the BODY of a message to [email protected], NOT to the list >>>>> (use your own address!) List problems? Notify >>>>> [email protected] >>>>> . >>>>> -------------------------------------------------------------------- >>>> >>>> --------------------------------------------------------- >>>> Ernest Friedman-Hill >>>> Informatics & Decision Sciences, Sandia National Laboratories >>>> PO Box 969, MS 9012, Livermore, CA 94550 >>>> http://www.jessrules.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> To unsubscribe, send the words 'unsubscribe jess-users [email protected] >>>> ' >>>> in the BODY of a message to [email protected], NOT to the list >>>> (use your own address!) List problems? Notify >>>> [email protected] >>>> . >>>> -------------------------------------------------------------------- >>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/JESS%3A-OutOfMemory-after-multiple-assertions-resets-tp27634200p27662584.html >>> Sent from the Jess mailing list archive at Nabble.com. >>> >>> >>> >>> -------------------------------------------------------------------- >>> To unsubscribe, send the words 'unsubscribe jess-users >>> [email protected]' >>> in the BODY of a message to [email protected], NOT to the list >>> (use your own address!) List problems? Notify >>> [email protected] >>> . >>> -------------------------------------------------------------------- >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/JESS%3A-OutOfMemory-after-multiple-assertions-resets-tp27634200p27672530.html >>> Sent from the Jess mailing list archive at Nabble.com. >>> >>> >>> >>> -------------------------------------------------------------------- >>> To unsubscribe, send the words 'unsubscribe jess-users >>> [email protected]' >>> in the BODY of a message to [email protected], NOT to the list >>> (use your own address!) List problems? Notify >>> [email protected] >>> . >>> -------------------------------------------------------------------- >> >> --------------------------------------------------------- >> Ernest Friedman-Hill >> Informatics & Decision Sciences, Sandia National Laboratories >> PO Box 969, MS 9012, Livermore, CA 94550 >> http://www.jessrules.com >> >> >> >> >> >> >> >> -------------------------------------------------------------------- >> To unsubscribe, send the words 'unsubscribe jess-users [email protected]' >> in the BODY of a message to [email protected], NOT to the list >> (use your own address!) List problems? Notify >> [email protected]. >> -------------------------------------------------------------------- >> >> >> > > -- View this message in context: http://old.nabble.com/JESS%3A-OutOfMemory-after-multiple-assertions-resets-tp27634200p27696537.html Sent from the Jess mailing list archive at Nabble.com. -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [email protected]' in the BODY of a message to [email protected], NOT to the list (use your own address!) List problems? Notify [email protected]. --------------------------------------------------------------------
