An option like that would be ideal. However it would also be nice to have the
ability to determine the fact types so filtering pre
fact-handle-creation/insertion can be done as well.
In the meantime, for our current design at least, it will almost always be
the case that we can scale out if we overload drools. ie, Have a separate
thread/process per device (or subset), as the rules/cep processing is
hierarchical. Higher levels will be consuming events generated by lower
levels, but the rate of creation will decrease up the hierarchy.
Edson Tirelli-4 wrote:
For future versions, I think we
should add a kbase configuration option to tell the engine what to do in
case of facts that don't match any rule: either keep them (as it does
today)
or discard them right away. What do you think?
--
View this message in context:
http://old.nabble.com/Does-Session-effeciently-filter-unused-facts%2C-or....
Sent from the drools - user mailing list archive at
Nabble.com.