It looks really bad.. as in RETE corruption. Can you try 5.6.0-SNAPSHOT or 6.0.0-SNAPSHOT? It would really help to see the ruleset which generated this exception. On Wed, May 1, 2013 at 12:24 PM, dcrissman <dcrissman(a)redhat.com&gt; 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" <dcrissman(a)redhat.com&gt; 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:

Sorry, but I doubt that anyone can benefit from this somewhat obscure description of a use case - but thanks for trying. -W On 06/05/2013, dcrissman <dcrissman(a)redhat.com&gt; wrote:

It wasn't a rule issue. I was effectively re-adding a change set to the knowledge base multiple times. So *IF* there is an issue here, it would only maybe be some kind of error/warning stating that a rule has already been added to the kb. Davide Sottara wrote > &gt; wrote: >>> 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; >>>>>>>>>>> &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 mailing list >>>>>>>>>>>>>>> >>>>> >>>>> >>>>> -- >>>>> 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 mailing list >>>>>>>>> >>> >>> >>> >>> -- >>> 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 >>> -- 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.

Gentlemen, the development team is releasing 6CR2, immediately after that 5.6Final will be released as well. To get this bug fixed, we do need a way to reproduce it. Any hint about the structure of the rule base and its updates would be **really** appreciated Thanks Davide -- 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.

AlphaNode is for literal constraints, BetaNodes for joins (i.e. involves variables). Mark On 7 Aug 2013, at 19:47, AlesD <Ales.Dolecek(a)nextiraone.eu&gt; wrote:

Hi, nice to find this topic, I'm experiencing the same problem. Actually I have that "complex scenario", that was mentioned, like "add and remove rules dynamically from a knowledge base". Does it mean that there is a known bug and it's going to be fixed? At this case is there any temporal workaround? Or it means that adding or removing rules dynamically is not something that should be used at all? The Drools version is 5.5.0.Final Thank you very much in advance, Vlad. Davide Sottara wrote -- 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.