-
You're right on both, the question being: how long do you want to keep these events in the Flow Engine Context or Inference Engine Working Memory? Can you process with a clean memory and add new facts to evaluate or do you need to keep previous events?
Note that for event processing, I encourage people to consider NEsper, which is way more suited than a general rules engine like NxBRE.
HTH.
2009-11-06 20:20:36 UTC in NxBRE
-
1. Check the knowledge base, where I documented all the gotchas people have encountered in the past 5 years: http://nxbre.org/kb
2. I have never envisioned this but, since you can basically perform any method call from the Flow Engine rules, there is no reason why not.
3. In fact, none of the engine flavours are able to handle state evolution: you have to detect changes on your own and...
2009-11-06 04:03:36 UTC in NxBRE
-
Hey Pedro,
Thanks for reporting this problem.
As a first step towards resolving it, it would be nice if you could use the BRECloneFactory, which is the one intended for production.
With this factory, the model is: load it then when a processing is needed: clone, process and discard the clone.
Thanks your reporting here your further findings.
Cheers,
D.
PS. Out of curiosity...
2009-11-05 17:39:34 UTC in NxBRE
-
Yes, you get it 100%! No fireman in room means that no non-naf (ie no producing atom) is present hence the absence of danger conditions (the naf atoms) can't be useful.
2009-11-05 15:58:02 UTC in NxBRE
-
The Detector in Room is there to provide values for the "Room number" variables in the following atoms.
This is discussed here: https://sourceforge.net/apps/trac/nxbre/wiki/TheNafChallenge.
2009-11-05 06:01:37 UTC in NxBRE
-
Why do you find these results to be strange? Isn't a linear time and memory usage expected in this case ;-)
For quite a few releases in v2, the FactBase backing storage was swappable but I abandoned the design, as the Dictionary based implementation outperformed the DataTable based one.
For v3, the "easiest" way to unbind the FactBase from RAM would be to replace the 4...
2009-10-15 20:48:00 UTC in NxBRE
-
The Inference Engine backing storage has been designed for this exact scenario: huge number of facts and limited number of rules. This said, I never went above several hundred of thousands of facts: though I suspect RAM is the limit in your case, I suggest you give it a shot and let us know what happened.
Cheers,
D.
2009-10-15 14:57:16 UTC in NxBRE
-
The sole idea of deserializing XML into objects gives me goose bumps...
Anyway, as far as NxBRE is concerned:
- The Flow Engine is able to, via reflection, manipulate XML related objects, so there is no need to create objects (you would need to reflectively access fields on your objects anyway).
- The Inference Engine works on facts: you would have the hardest times mapping random XML...
2009-09-17 17:59:46 UTC in NxBRE
-
Thanks for the info, I corrected the page on AP's wiki.
Unfortunately, NxBRE's wiki has been savagely damaged when SF converted it to Trac. All the structure, all the tags are gone...
D.
2009-09-17 16:27:14 UTC in NxBRE
-
Hi Rick,
I doubt that NxBRE, nor any BRE, would be the best option for validating XML entities, no matter how complex the rules. This because BRE's have a very generic rules language that would require a lot of hoops jumping to apply to XML validation.
Have you considered using [Schematron][1]? As an advanced XML validation language, it looks way more fit to solve your problem than a...
2009-09-16 23:50:57 UTC in NxBRE
