This is currently not na option. Thanks for advice.
-----Original Message----- From: gabriel quennesson [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 10 de novembro de 2006 10:40 To: user@drools.codehaus.org Subject: Re: [drools-user] Some thoughts about drools If memory consuption is an issue, consider using one of the backward chaining RE around (Mandarax is one of them). Then have an huge repository to handle the data. The problem of such an engine is it will be able to pull data to answer questions, but not to "react" to knew data assertions -altough I was successfull in using queries to simulate a fireAllRules() behaviour. Marcos Tengelmann a écrit : > That is really a real constraint today. > > We are using drools to do a sort of processing where we do have to > assert something around 2MM facts and process around 40 rules. > > The facts are very similar to LOG4J records, and when we are close to > 1MM facts asserted into working memory, we just blow up the memory. > We got a OutofMemorty error during assertion in a 16GB 64 Bits box. > > It means: We are doing the wrong thing OR Drools 3 needs too much > memory OR both. > > You can try, but I think it will not work. > > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey De Smet > Sent: sexta-feira, 10 de novembro de 2006 07:12 > To: user@drools.codehaus.org > Subject: Re: [drools-user] Some thoughts about drools > > As far as I know, the current forward chaining implementation needs to > keep all facts into the RAM memory, so you can't hold 1 TB facts in > 2-4GB RAM memory... > > You could try streaming it into some sort of rules-based filter > configuration to avoid getting to much into the working memory and > then apply a second rule set on all the facts that made it through the > original filter. > > They are currently implementing backwards-chaining, maybe that can > could also be integrated with a database that holds the terrabytes? > > [EMAIL PROTECTED] wrote, On 2006-11-10 9:37 AM: > >> What are you trying to achieve when you say your task is 'log processing' >> >> Will ALL Log entries(objects) be of interest Assuming NOT - you can >> (maybe) write some Rules which filter your input so that ONLY those >> Log entries you need to process are committed to the working memory >> (you will probably have to Load each Log entry into the working >> memory & have your 'Filter Rules' Retract Log entries that you are >> not interested in) >> >> Subsequent Rules can process the 'Real' Log entries however you need >> to >> >> Haven't tried any of this myself - BUT I think you should be able to >> make it work >> >> >> >> >> >> >> > ---------------------------------------------------------------------- > -- > >> *From:* 张茂森 [mailto:[EMAIL PROTECTED] >> *Sent:* Friday, November 10, 2006 2:46 AM >> *To:* user@drools.codehaus.org >> *Subject:* [drools-user] Some thoughts about drools >> >> Hi All: >> >> After I have read the drools user guide, and now my work is about >> log processing. I want to know whether rule engine is proper to be >> used to do log processing. >> >> 1 Log can be a very large “fact” set (even tera-bytes is >> possible). Could Rule Engine achieve the requirement of performance? >> >> 2 As far as I know, I must wrap each log into object then >> send it to workmemory of Rule Engine, Does it need? Could I have >> some more lightweight solution? >> >> Any suggestion would be appreciated >> >> Thank you! >> >> >> >> >> >> > > -- > With kind regards, > Geoffrey De Smet > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > -- ___________________ *Gabriel Quennesson *| CTC/I | *SEAM* Int :* *7 906 6910 | Ext: 04 73 64 69 10 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
