Re: [rules-users] java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory

While working on a sanitized version of the code, I discovered my issue. I am using a StatefulKnowledgeSession essentially statelessly. I am doing this because in the past I have found StatefulKnowledgeSession to be more feature rich. Regardless, each execution created a new StatelessKnowledgeSession instance which is built from a single instance of a KnowledgeBase. During the setup for each run, I was adding my change_set to that KnowledgeBase, causing the error I was getting. I'd like to think that my mistake could be recycled and benefit someone else in the future. Davide - Thank you for your time. Sorry that this turned out to be user error. -Dennis Davide Sottara wrote > Could you post **at least** the unit test throwing the exception, > the one that "enables" it and the code you are using to run them? > This may be yet another blocker for 5.6, so I'd like to investigate it > as soon as possible > Thanks! > Davide > > On 05/02/2013 07:20 AM, dcrissman wrote: >> Yes, I am getting this exception (sadly, not something that I am just >> worried >> about). >> >> I am checking for rule complication errors before running the rules, and >> no >> errors are being given. >> >> I am not dynamically adding or removing rules once I have my knowledge >> base >> setup, it does not change though the duration of the run. >> >> I am using a StatefulKnowledgeSession, and I make sure that after each >> run >> that I am calling dispose in a finally block. So shouldn't be any >> strange >> memory issues. >> >> To add to the original description, I am getting these exceptions in my >> unit >> tests. There is one unit test suite that when disabled the exception >> goes >> away, but when enabled the exceptions happen in other suites. Which of >> course is odd and led me to believe that there is a problem with the >> unit >> tests (which is still not ruled out). But the suites are using different >> sessions, same rules, but totally different instances of everything. >> >> The only thing I am doing that may be a little funny is consolidating a >> collection of objects into one then retracting the collection, but when >> I >> comment out this rule I still am getting this exception. Aside from this >> one >> case, I am not doing anything crazy. >> >> [code] >> //ArrayList provided by drools seems to dynamically adjust with the >> retractions, this safeguards us against that. >> ArrayList safetyArr = new ArrayList($attrs); >> >> ArrayList values = new ArrayList(); >> for (int i=0; i < safetyArr.size(); i++){ >> Attribute attr = ((Attribute) safetyArr.get(i)); >> values.add(attr.getValue()); >> retract(attr); >> } >> >> insert(newAttribute($redHatName, StringUtils.join(values, ","))); >> [/code] >> >> Any other thoughts you may have would be appreciated. >> >> Thanks! >> >> >> Davide Sottara wrote >>> The original thread was for a bug in 5.0.x, fixed in 5.1, but it would >>> be >>> a >>> very serious issue in 5.5. It basically means that the local memory of >>> a >>> beta node has been assigned to an alpha node, or that the wrong memory >>> had >>> been retrieved. In any case, the rete is broken: wrong facts or types >>> would >>> be joined in a different order or way than stated by the rules. >>> >>> Is this something you're experiencing , or just worried that it may >>> happen? >>> >>> Causes could be an invalid rule in the first place (running the engine >>> without checking for compilation errors), a bug in the construction >>> process >>> (unlikely, unless the rule is a very rare edge case), or a complex >>> scenario >>> where you add and remove rules dynamically from a knowledge base. >>> On May 1, 2013 2:25 PM, "dcrissman" &lt; >>> dcrissman@ >>> &gt; wrote: >>> >>>> Could you explain what you mean by rete corruption? I am familiar with >>>> rete, >>>> but hardly an expert. I am not really doing anything too complicated, >>>> I >>>> guess some runtime inserts and retracts. >>>> >>>> I tried 6.0.0.Beta2, but that has more api changes then I am prepared >>>> to >>>> handle, I'll wait until the Final version. >>>> >>>> As for 5.6.0-SNAPSHOT, I am having trouble pulling it down. I will >>>> pick >>>> that >>>> up tomorrow. >>>> >>>> In the meantime, any clarification to the rete question would be >>>> appreciated. >>>> >>>> Thanks, >>>> Dennis >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://drools.46999.n3.nabble.com/java-lang-ClassCastException-org-drools... >>>> Sent from the Drools: User forum mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> rules-users mailing list >>>> >>> rules-users@.jboss >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users@.jboss >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> >> -- >> View this message in context: >> http://drools.46999.n3.nabble.com/java-lang-ClassCastException-org-drools... >> Sent from the Drools: User forum mailing list archive at Nabble.com. >> _______________________________________________ >> rules-users mailing list >> > rules-users@.jboss >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > _______________________________________________ > rules-users mailing list > rules-users@.jboss > https://lists.jboss.org/mailman/listinfo/rules-users -- View this message in context: http://drools.46999.n3.nabble.com/java-lang-ClassCastException-org-drools... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users