[rules-users] Conflict resolution strategy - before vs after Phreak impl

In version 5.x of Drools I see that it offered configurable conflict resolver strategies. I also read a few different Drools documentation sources that discussed varieties of complex conflict resolution strategies. One source discussed a tiered implementation by the name of

Re: [rules-users] Conflict resolution strategy - before vs after Phreak impl

Thanks Mark for that explanation! I'd say that certainly addresses the questions I had and I can understand the points you make. We do intend to move to the Phreak implementation still. I was just looking for some clarity on this topic as we dealt with things, which I now have. -- View

Re: [rules-users] Equality semantics of logical assertions and stated assertions

Thanks a lot for the detailed response. This line of reasoning makes sense to me. I can see now why the behavior is the way that it is. I appreciate the quick feedback too! -- View this message in context:

Re: [rules-users] Equality semantics of logical assertions and stated assertions

Add - Mike Rodriguez On Jul 2, 2014, at 10:18 AM, mikerod [via Drools] ml-node+s46999n4030228...@n3.nabble.com wrote: Thanks a lot for the detailed response. This line of reasoning makes sense to me. I can see now why the behavior is the way that it is. I appreciate the quick

Re: [rules-users] Upgrade to protobuf 2.5 - Prevents Upgrading to Drools 6.x

Upgrading Hadoop is not possible for sometime still. It requires a fairly large coordinated effort. I don't suppose there is any chance that there will be a workaround for this in Drools 6? Perhaps a configuration options or something? -- View this message in context:

Re: [rules-users] CompositiveClassLoader$CachingLoader$load method intermittently hangs

Thanks for the response. I thought I had read that the CompositeClassLoader was not being used in v6.x. I'd like to be able to experiment with the current version of Drools v6.x, but I'm still trying to work past the issue I have with the non-passive changes of protobuf v.2.5.0 that Drools v6.x

Re: [rules-users] CompositiveClassLoader$CachingLoader$load method intermittently hangs

I was finally able to take some time and find out where multiple threads could be showing up in the environment where my application was not doing any multithreaded work with the Drools knowledge base or session. One example I have can be seen by looking at the

Re: [rules-users] CompositiveClassLoader$CachingLoader#load method intermittently hangs

Does anyone have any thoughts on this issue? I still haven't been able to get to the root of the concurrency issue. Digging through some of the Drools implementations, but no luck. :) -- View this message in context:

[rules-users] CompositiveClassLoader$CachingLoader$load method intermittently hangs

I cannot easily reproduce an issue that I'm seeing. This is an intermittent issue that happens probably 3% of the time or less. This is observed behavior in * Drools v5.6.0.Final, using * Janino compiler v2.5.16 transitively Drools brings * mvel2 v2.1.8.Final We have an environment that loads

[rules-users] Upgrade to protobuf 2.5 - Prevents Upgrading to Drools 6.x

Note: I originally tried posting this as a reply to this http://drools.46999.n3.nabble.com/Upgrade-to-protobuf-2-5-and-how-to-work-with-Protobuf-td4023028.html , before I realized it was the wrong mailing list. _ It looks like moving from protobuf-java v.2.4.1 to v.2.5.0 has non-passive

[rules-users] Nested negation constraints behavior change from Drools 5.x to 6.x

With both Drools v5.5.0.Final and v5.6.0.Final I observe a different behavior than in both v6.0.0.Final and v6.0.1.Final. in certain rules with negation wrapped around nested constraints. I have tried to make the simplest rules to demonstrate the situation. With a kb consisting of the following

Re: [rules-users] Nested negation constraints behavior change from Drools 5.x to 6.x

I made a basic jar that only depends on Drools. All the rules do is output to standard out to demonstrate. This can just be ran with: `mvn exec:java -Dexec.mainClass=example.drools.TestingNestedNegation` This is with v6.0.1.Final; so switching this in the pom.xml to 5.6.0.Final, for example,

Re: [rules-users] Nested negation constraints behavior change from Drools 5.x to 6.x

No problem. Thanks for the quick feedback on this. -Mike -- View this message in context: http://drools.46999.n3.nabble.com/Nested-negation-constraints-behavior-change-from-Drools-5-x-to-6-x-tp4028390p4028400.html Sent from the Drools: User forum mailing list archive at Nabble.com.

Re: [rules-users] Object size affect on session insertion performance

@laune You are correct that I actually put an incorrect time up before. Thanks for pointing that out and sorry for the confusion. The behavioral difference I have found was actually much large between the 2 classes, SimpleClass and ComplexClass, than I originally thought. The SimpleClass

[rules-users] Object size affect on session insertion performance

Does the size of objects inserted into the session as facts directly affect performance? I have ran some very simple tests, with a kb with 1 rule that accumulated/collected over all facts in working memory of a type. If I have a really simple/small class, say SimpleClass It looks like: ```

Re: [rules-users] Incorrect resolution of global symbols in LHS rule constraint (Java dialect)

Ah, yes indeed a Boolean cast works for the issue of returning an Object. I'm glad to hear the root cause has already been addressed though. I appreciate the quick feedback on this! -- View this message in context:

[rules-users] Incorrect resolution of global symbols in LHS rule constraint (Java dialect)

I upgraded from 5.5.0.Final of Drools (rule engine) to 5.6.0.Final and I am now seeing errors with globals. We have rule constraints that access globals in a DRL; like this: some.classpath.package2.MyType ( global_instance.invoke(this) == true ) I have `some.classpath.package.SomeType

Re: [rules-users] Unexpected behavior of accumulate() and insertLogical() when the result() goes from matching a constraint to not matching

I appreciate your input. I understand what you are saying regarding the design of the activations caused by the accumulate. Unfortunately, this is making it hard to express the logic I'm going for in a concise manner. I'll give a bit more of a real, but similar example here. With my example

Re: [rules-users] Unexpected behavior of accumulate() and insertLogical() when the result() goes from matching a constraint to not matching

I understand that there is no concept within the engine of latest. I the surprising behavior to me here was that the rule seems to become invalidated in the LHS when the fact is matched with the a version than the previous one. Using insertLogical, I generally expect the rule to retract

Re: [rules-users] Unexpected behavior of accumulate() and insertLogical() when the result() goes from matching a constraint to not matching

I agree that it is bad form to introduce unnecessary nulls. I mostly did that for the sake of simplicity in the example. I tried out your initial proposal of how to implement this, where you put the logic previously in my `result` segment of the `accumulate` into the result pattern segment of

[rules-users] Unexpected behavior of accumulate() and insertLogical() when the result() goes from matching a constraint to not matching

This is a follow up from my original post @ http://drools.46999.n3.nabble.com/rules-users-Question-about-custom-accumulation-functions-tp3280838p4026505.html Using Drools version 5.5.0.Final I am experiencing behavior I did not expect, regarding Drools accumulate functionality. The following

Re: [rules-users] Question about custom accumulation functions

I started the question in a new thread @ http://drools.46999.n3.nabble.com/Unexpected-behavior-of-accumulate-and-insertLogical-when-the-result-goes-from-matching-a-constraint-g-tp4026507.html -- View this message in context:

Re: [rules-users] Question about custom accumulation functions

On a somewhat related note: I have a rule, where the value of #getResult may match the constraint at some point during the accumulation, but later on will result in a value that does not match the constraint anymore. So in my scenario, the LHS of the rule is true at some point during the