<br> Well, May 19th I guess you still have Drools 5.0.0. You should at least be using 5.0.1. Anyway, latest artifacts are here:<br><br><a href="https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/">https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/trunk/target/</a><br>
<br>"I am sure there are many ways to get it working on a sharing knowledge base,"<br><br> Yes, and if what you have works for you, go for it. I am just mentioning that the simplest solution would be to load all rules in a single kbase and use ruleflow, by what you described in your 1-3 items.<br>
<br> Cheers,<br> Edson<br><br><div class="gmail_quote">2009/12/22 malkhafaji <span dir="ltr"><<a href="mailto:moe.alkhafaji@medcpu.com">moe.alkhafaji@medcpu.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Edson,<br>
<br>
Thank you for replying to my question. I haven't tried the new release since<br>
May 19th of this year. Are you talking about the binaries (Drools 5.1.0.M1<br>
Binaries)? Should I go ahead and try that?<br>
<br>
To answer your question about not sharing KnowledgeBase for all requests, we<br>
have a very advanced logic outside of the rules engine. To give you some<br>
flavor, we have only one type of object per request. Each request will have<br>
its own data in that object. Now, we have wrapper code around the engine to<br>
do things like:<br>
1. Last time this engine ran for this object, including what rules executed,<br>
etc.<br>
2. Rules within packages loaded by default may load other packages on the<br>
fly because of which rules executed, and this only applies to that object<br>
that triggered the loading of those packages. For example, by default we<br>
have 1 package that is used for all objects. But object A may trigger a rule<br>
that loads another package which becomes available to it besides the main<br>
one. However, this new package is not yet available to all other objects.<br>
So, I did not know how I can load packages but only make them visible to<br>
some of the objects that I push through the session's knowledge base.<br>
3. Our rules engine is either data driven (and the notification does not<br>
come from the rule, but outside the rule in some common logic), or time<br>
driven (run the engine again after n minutes because that is when our logic<br>
has determined that one of the conditions would turn true on a previously<br>
false condition potentially starting a chain of executions), etc.<br>
<br>
And other things. So, I found it to be much easier for me and my sanity to<br>
start using a new instance of a session (having its own knowledge base) per<br>
request. Those requests are very small and take no more than milliseconds on<br>
each object. So, I am using a stateful session that is alive for the life of<br>
the respective object. My objects are finite (you cannot have more than<br>
1,000 in our memory), and they and their respective instances are very light<br>
weight and do not need more than a 1 GB of memory (mostly hovers around<br>
500-600 MB).<br>
<br>
I am sure there are many ways to get it working on a sharing knowledge base,<br>
I just thought this way I don't need to worry about synchronizations or any<br>
other complicated logic on top of what we have. So, I made the decision.<br>
<br>
Please confirm that M1 binaries has your latest fix so I can get testing on<br>
it. Thanks!<br>
<div><div></div><div class="h5"><br>
<br>
Edson Tirelli-4 wrote:<br>
><br>
> Hi,<br>
><br>
> I fixed a problem related to deadlock when sharing packages among<br>
> multiple kbases a couple weeks ago. Not sure if it is the same, but try<br>
> trunk and let me know, plz.<br>
><br>
> Meanwhile, I am curious why you can't simply create a kbase with all<br>
> your<br>
> rules and share the kbase among all your requests, just creating one<br>
> session<br>
> per request?<br>
><br>
> Reason is that adding packages to a kbase for each request still adds<br>
> unnecessary overhead to your application, and kbases are designed to be<br>
> shared in such cases. If you need to orchestrate multiple execution paths<br>
> for your rules, you could use rule flow or any other coordination<br>
> mechanism.<br>
> Finally, Rete is known by performing really well with increasing number of<br>
> rules, since the performance is not dependent on the number of existing<br>
> rules, but on the number of affected constraints.<br>
><br>
> Just my .02c<br>
><br>
> Edson<br>
><br>
><br>
> 2009/12/22 malkhafaji <<a href="mailto:moe.alkhafaji@medcpu.com">moe.alkhafaji@medcpu.com</a>><br>
><br>
>><br>
>> Hello,<br>
>><br>
>> I am trying to create multiple sessions, and for each session I will load<br>
>> one knowledge package representing one drl. Each drl may optionally load<br>
>> additional knowledge packages (drls). Since all sessions will be<br>
>> accessing<br>
>> the same list of knowledge packages, and since they take a long time to<br>
>> compile resources, I decided to create a Map with all possible knowledge<br>
>> packages that all sessions may use. That worked beautifully saving me<br>
>> compilation time (it is done at start up).<br>
>><br>
>> Now, here is how I am creating the static map:<br>
>><br>
>> private static ConcurrentMap<String, KnowledgePackage> knowledgePackages<br>
>> =<br>
>> new<br>
>> ConcurrentHashMap<String, KnowledgePackage>();<br>
>><br>
>> Here is how I am initializing it:<br>
>><br>
>> KnowledgeBuilder kbuilder = null;<br>
>><br>
>> for (MedCPUKnowledgeBase medcpuKnowledgeBase :<br>
>> medcpuKnowledgeBases) {<br>
>> try {<br>
>> kbuilder =<br>
>> KnowledgeBuilderFactory.newKnowledgeBuilder();<br>
>><br>
>> // This call actually compiles the drl<br>
>> file.<br>
>><br>
>><br>
>> kbuilder.add(ResourceFactory.newClassPathResource(medcpuKnowledgeBase.getFileName()),<br>
>> ResourceType.DRL);<br>
>><br>
>> KnowledgeBuilderErrors errors =<br>
>> kbuilder.getErrors();<br>
>><br>
>> if (errors.size() > 0) {<br>
>> .....<br>
>> } else {<br>
>><br>
>> knowledgePackages.put(medcpuKnowledgeBase.getFileName(),<br>
>> [the package just<br>
>> added above]);<br>
>> }<br>
>> } catch(Exception ex) {<br>
>> ....<br>
>> } else {<br>
>> .....<br>
>> }<br>
>> }<br>
>> }<br>
>><br>
>><br>
>> Each session will do this to get the pre-compiled KnowledgePackage:<br>
>><br>
>> KnowledgePackage knowledgePackage = knowledgePackages.get(kb);<br>
>> ......<br>
>> Collection<KnowledgePackage> packages = new<br>
>> ArrayList<KnowledgePackage>();<br>
>> packages.add(knowledgePackage);<br>
>><br>
>> // The problem is this guy (after a relatively small number of requests<br>
>> each<br>
>> opening a new session) just gets stuck!! It does not throw an exception<br>
>> and<br>
>> it does not return.<br>
>> this.knowledgeBase.addKnowledgePackages(packages);<br>
>><br>
>> When I did not share the KnowledgePackages like I did above, I was able<br>
>> to<br>
>> get thousands of requests with each having its own session,<br>
>> knowledgebase,<br>
>> and its own knowledge packages after they compile the respective drls.<br>
>> However, because this was slow compiling the same drls over and over<br>
>> again<br>
>> I<br>
>> switched to the design above which after only 20 or 30 requests it gets<br>
>> stuck on the line above. I still have a knowledgebase per session per<br>
>> request, but now I am sharing the knowledge packages.<br>
>><br>
>> I cannot find anywhere where it says that KnowledgePackage objects are<br>
>> not<br>
>> thread-safe (not safe to be shared between sessions/threads). Any idea<br>
>> why<br>
>> I<br>
>> am stuck on the line above? Thanks!<br>
>> --<br>
>> View this message in context:<br>
>> <a href="http://n3.nabble.com/Sessions-Sharing-KnowledgeBase-tp96894p96894.html" target="_blank">http://n3.nabble.com/Sessions-Sharing-KnowledgeBase-tp96894p96894.html</a><br>
>> Sent from the Drools - User mailing list archive at Nabble.com.<br>
>> _______________________________________________<br>
>> rules-users mailing list<br>
>> <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Edson Tirelli<br>
> JBoss Drools Core Development<br>
> JBoss by Red Hat @ <a href="http://www.jboss.com" target="_blank">www.jboss.com</a><br>
><br>
> _______________________________________________<br>
> rules-users mailing list<br>
> <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
><br>
><br>
<br>
--<br>
</div></div>View this message in context: <a href="http://n3.nabble.com/Sessions-Sharing-KnowledgeBase-tp96894p97452.html" target="_blank">http://n3.nabble.com/Sessions-Sharing-KnowledgeBase-tp96894p97452.html</a><br>
<div><div></div><div class="h5">Sent from the Drools - User mailing list archive at Nabble.com.<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss by Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>