Hi Peter, Thank you very much for your help! The insights you gave will be very useful in our determination.
Do you by chance have any opinion about the other part of my question regarding the use of Fuzzy Rules? I would be interested in hearing your opinions on that subject (if you have any hints or insights you'd like to share). Thanks again, David On Thu, Feb 19, 2009 at 11:12 AM, Peter Lin <[email protected]> wrote: > If you're talking about dynamically loading rules at runtime and doing > fuzzy reasoning. You'll find that using drools in compiled mode won't > scale very well due to PermGen issues with SUN and IBM JDK. > > In a dynamic environment, the system could add tens of thousands of > rules over a long period of time, which means you would need to use > 64bit JVM with permGen heap greater than 2GB or Oracle's 64bit > JRockit. Increasing the heap isn't a real solution though, because the > rules shouldn't be compiled to java classes to begin with for a > dynamic environment. I consider it a design flaw in drools and engines > that compile rules to classes. > > The other issue is that it's harder to dynamically unload/reload a > rule with engines that compile rules to java classes. With interpreted > engines like JESS, removing or modifying a rule is straight forward > and avoids these kinds of issues. > > The only way to allow a engine to modify an existing rule with engines > that compile to java classes is to have 1 classloader per rule. > Clearly, that is not scalable for thousands of rules in a ruleset. > > There are ways around that, like never modifying rules and always > generating a new rule name. Having said that. Use cases that never > need to modify the rules at runtime or load new rules/rulesets work > fine in engines that compile to Java code. There are several "simple > rule engines" out there that compile to java classes, so it's a common > design flaw of engines that take that approach. > > In general, an interpreted rule engine is much more powerful and > flexible for dynamic environments. > > peter > > On Thu, Feb 19, 2009 at 11:02 AM, David Ray <[email protected]> > wrote: >> Hi Ernest, >> >> Thank you very much for addressing my concerns. The time consumed >> for the compilation of rules (as you pointed out) is not a primary >> concern for our applications. I did realize that that phase would only >> occupy startup time, and for a long running system, is not the most >> relevant metric to be concerned with. There is however, an exception >> to this case where data is influencing the creation of new rules which >> may subsequently be inserted into the Rete engine at runtime. I doubt >> however that 10,000 rules would be inserted into the engine >> dynamically - and even so, at 5 or so secs. per 10K the engine's >> performance would not be a hinderance at all. >> >> Since I have your attention :) - I would like to share with you my >> primary use case - and the situation for which I am considering Jess. >> I am highly motivated to show Jess's applicability to my company due >> to the availability of "Fuzzy Rules" for Jess, for use in a highly >> transactional financial application with conceivably large data >> throughput. "Fuzzy Rules" being almost exclusively available in Jess, >> makes it a high priority. Any input or guidance you could share with >> me on this point would be highly appreciated - if you find that there >> are hints or insights that may become important in our usage or >> determination of Jess as an option? >> >> Once again, thanks >> >> David >> >> >> -------------------------------------------------------------------- >> 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]. >> -------------------------------------------------------------------- >> >> > > > -------------------------------------------------------------------- > 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]. > -------------------------------------------------------------------- > > -------------------------------------------------------------------- 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]. --------------------------------------------------------------------
