Agreed.<br><br>I'll add something.<br><br>I've raised a JIRA to capture a need to shift to a different Excel library too: <a href="https://issues.jboss.org/browse/JBRULES-3549">https://issues.jboss.org/browse/JBRULES-3549</a><br>
<br>With kind regards,<br><br>Mike<br><br><div class="gmail_quote">On 19 June 2012 10:18, Wolfgang Laun <span dir="ltr"><<a href="mailto:wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A recent post on the users list has led me to investigate DTs with<br>
O(10000) rows. While the sample XLS with 26,400 rows and 6 condition<br>
and 1 action columns was still manageable, a (my) system may exhibit<br>
severe memory problems when the number of rows is increased.<br>
<br>
Test indicate that ~25,000 rows is just about manageable if you don't<br>
need lightning startup for your application - serialization doesn't<br>
help here.<br>
<br>
It would appear that Drools users are (not intentionally) led to<br>
believe that Drools' performance is immune against the usual<br>
detriments that arise from "large numbers".<br>
<br>
I think that Section 2.4., Decision Tables in Spreadsheets, should<br>
contain a warning.<br>
<br>
-W<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</blockquote></div><br>