Re: [rules-users] In drools what is the exact difference between Insert and Update ??

[Richard Calmbach]

Wolfgang: Are the slides for your presentation online? This would be very
helpful. I have searched repeatedly for a rule design best practices
document and have only found conference agenda items on the topic but no
actual document. After more than a year of working with Drools, I have
figured out key best practices (in particular, secondary facts) myself, but
it sure would have helped to have this information upfront (and, yes, I
have read the manual - the information I'm talking about is not in there).

On Thu, Mar 29, 2012 at 10:38 AM, Wolfgang Laun wrote:

> Even attentive followers of this list may not be aware of my boot camp
> "Rule-Based Programming Design Patterns" I was delivering to a select few
> last October at Rules Fest 2011 .
> I'm convinced that programming with rules follows the same universal
> principles we all have learned about programming since the 1950ies or have
> been taught in the ensuing decades - most notably, design patterns that can
> be applied as the situation demands. It may be a different grass, but it's
> still the grass roots you've got to make your own.
>
> -W
>
>
>
>
> 2012/3/29 Vincent LEGENDRE 
>
>> Drools expert doc has a first chapter that adresses these questions
>> (section 1.2), or at least the questions that must be asked at start of a
>> project.
>> It covers in details the main key question : rules or not ? Using rules
>> implies more constraints on IT because you allow more freedom in business
>> logic part, so you need a more robust IT code.
>>
>> Best pratices are then edicted by the architect, this last one having in
>> mind the requirements of :
>> - business users (most important as they specify rules, at least some
>> representatives samples),
>> - the people who will write the rules (very very important if they
>> are the business users, who are not IT guys, which to me forbid the usage
>> of salience or groups or functions ...)
>> - the other IT guys that will provide data streams to your new
>> application, or who will call your app (it can bring constraints because of
>> data volumetry by instance)
>>
>> In fact, you can't start a real rule project without having enough
>> material in specifications, but this is also true for any project.
>> So there is no (in my opinion) "global best pratices" (as there is no
>> global best pratices for a random IT project...), with eventually an
>> exception for no-loop (its usage generally shows a lack of design, again,
>> it is my opinion, and I already used them anyway...).
>> Once again, as Davide said, it depends of the usage. So it seems barely
>> impossible to edit (and keep up to date) such a section with all potential
>> use-cases ...
>>
>> May be create a rule application that deduce best pratices  ;)  ?
>>
>> --
>> *De: *"Patrik Dufresne" 
>> *À: *"Rules Users List" 
>> *Envoyé: *Jeudi 29 Mars 2012 15:20:21
>> *Objet: *Re: [rules-users] In drools what is the exact difference
>> between Insert and Update ??
>>
>> Sorry to disrupt your discussion,
>>
>> I've start using Drools a while ago and I find your discussion very
>> interesting about how to use what feature when and why. The current Drools
>> Expert user guide is very nice, but it miss this crucial information. May I
>> suggest to create a 'Best Practice' chapter with the recommendation you
>> made.
>>
>> Patrik Dufresne
>>
>>
>> On Thu, Mar 29, 2012 at 8:21 AM, Vincent LEGENDRE <
>> vincent.legen...@eurodecision.com> wrote:
>>
>>> Far much valuable reply than mine  :)
>>> A great summary of common concerns that must be evaluated before
>>> starting coding a rule system.
>>>
>>> Also consider :
>>>   - using rule flow (if you are allowed to)
>>>   - use sequential mode and pipe your data 'in the next rule box'
>>> programmatically (using rules?)
>>>   - ask your architect ? He is true for no-loop, but for others,
>>> re-writing existing DRL code that used all that stuff, and throw all at
>>> once is farly more dangerous ...
>>>
>>> >> "remove all salience from rules and make  the rules independent
>>> (don't decide its execution flow)"
>>>
>>> This is all the question.
>>> It mainly depends of the usage, as Davide said.
>>> It also depends of who is authoring/specifying rules : if the guy
>>> supposes some flow, he is not writing independant rules ...
>>>
>>> these other rules depend of the first :
>>>2.no drools functions
>>>3.Activation group / ruleflow / salience ...
>>>5.don't call any java function (thus no functions at all, no
>>> predicates/utils methods, only DSL? only POJO?).
>>>
>>> this one is suspect ...
>>> 4.Don't use UPDATE and Global in drools .
>>> ___
>>> rules-users mailing list
>>> rules-users@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>>
>> ___
>> rules-users mailing list
>> rules-users@lists.jboss.org
>> ht

Re: [rules-users] Streaming mode

[Richard Calmbach]

For context: My observations were made with Drools 5.2.0 or earlier.
Basically, rule consequences were not executed atomically, leading to bad
interactions between multiple threads that were inserting events into
different entry points. Due to my findings, I got cautious and just always
synchronize on the session. I simply concluded that sessions are not
thread-safe.

It is conceivable that later versions have fixes for the thread-safety
issues I was seeing.

I cannot use any version of Drools later than 5.2.0 because the later
versions (to the extent that I have tested them, including Drools 5.2.1)
break about 46 of my unit tests. My application makes heavy use of Fusion,
the complex event processing features. I reported the bugs in this thread
(note: these are not thread safety bugs, as far as I can tell):

http://lists.jboss.org/pipermail/rules-users/2011-November/022826.html

which also contains a post where I link to the JIRA issues I created,
following Edson's advice. The most critical bug here is
https://issues.jboss.org/browse/JBRULES-3285. This bug prevents me from
upgrading. Frankly, I'm surprised there aren't more reports of Fusion
problems with post-5.2.0 versions.

Going back to thread-safety: As you can imagine, since the behavior I was
seeing was due to a race condition, it was not always reproducible. Were
the thread safety features you mention introduced post-5.2.0?

I know it is unsatisfying, but I cannot promise that I have the bandwidth
to construct and verify an example that isolates the thread safety issue. I
have found a workaround for that. The above issue with breaking unit tests
is what I'm really concerned about - one rabbit hole at a time...

My intent with my post was to point out a possible reason for unexpected
behavior in a multi-threaded setting and to describe a viable workaround.
If this helps someone else overcome an obstacle, then there is value in it
even if the underlying question of thread-safety remains unanswered. If the
OP continues to see the same problem even after my suggested rewrite, he
can rule out thread-safety issues, but for them, it may be worth a shot.

Thank you for your interest in resolving user issues. I'm sorry I can't be
of more help this time, but as you can see from my JIRA history, I try to
do my part. That's what an open source community is all about.

Thanks,
-Richard

2012/3/4 Mark Proctor 

>  If you have found an area where it is not thread safe, then please let us
> know so we can fix it. The example you have is redundant (possibly out of
> date), those areas are covered:
>
> fireAllRules and fireUntilHalt both have an atomic boolean, to ensure they
> can never be called more than once at the same time.
> if ( this.firing.compareAndSet( false, true ) ) {
>.
> }
>
> Each method that undertakes a working memory operation; such as insert,
> update, retract creates a read lock on the KnowledgeBase and also a
> read/write lock on the session.
> FactHandle insert(final Object object,
> final boolean dynamic,
> boolean logical,
> final Rule rule,
> final Activation activation) throws
> FactException {
> 
> 
> try {
> this.ruleBase.readLock();
> this.lock.lock();
> .
> } finally {
>     this.lock.unlock();
> this.ruleBase.readUnlock();
>
> }
>
>
> On 04/03/2012 04:36, Richard Calmbach wrote:
>
> 2012/3/2 Matteo Cusmai 
>
>> i see that there are some other threads that insert new event and some
>> others retract them.
>> How is the thread model?
>>
>
> Contrary to claims made on this mailing list, StatefulKnowledgeSession is
> not thread-safe (this may be due to bugs, but bottomline is: it's not
> thread-safe). In order to avoid errors due to multi-threading, don't use
> fireUntilHalt(), instead synchronize on the session and only call insert()
> and fireAllRules() while synchronized on the session:
>
> synchronized (session) {
> entryPoint.insert(event);
> session.fireAllRules();
> }
>
> -Richard
>
>
> ___
> rules-users mailing 
> listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Streaming mode

[Richard Calmbach]

2012/3/2 Matteo Cusmai 

> i see that there are some other threads that insert new event and some
> others retract them.
> How is the thread model?
>

Contrary to claims made on this mailing list, StatefulKnowledgeSession is
not thread-safe (this may be due to bugs, but bottomline is: it's not
thread-safe). In order to avoid errors due to multi-threading, don't use
fireUntilHalt(), instead synchronize on the session and only call insert()
and fireAllRules() while synchronized on the session:

synchronized (session) {
entryPoint.insert(event);
session.fireAllRules();
}

-Richard
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Multiple threading

[Richard Calmbach]

Sorry to burst your bubble, but stateful knowledge sessions are most
definitely not thread-safe. I have seen hard evidence to this effect in the
form of incorrect execution results and log statements that clearly show
that two threads were interacting in unexpected ways. In a nutshell: Rule
consequences are not executed atomically. This can cause unexpected working
memory changes (e.g., fact insertion) to happen on one thread in one rule
consequence before another thread has finished executing another rule
consequence. Note that I'm not talking about whatever threads Drools may be
creating internally. I'm talking about application threads.

I have found synchronizing on the session object to be a reliable safeguard
against unwanted thread interactions. Basically, this way all external fact
insertions and calls to fireAllRules() are serialized.

If this is not supposed to be necessary (synchronizing on the session),
then there is a thread-safety bug in Drools.

-Richard

2012/2/10 Mark Proctor 

>  On 10/02/2012 03:36, Apache wrote:
>
> Hey,
> I am trying to get multiple threads to insert events and run rules against 
> the union of events inserted ( an as soon as they are inserted, a timer 
> drools thread kicking of fireallrules() is not an option because that would 
> introduce a delay ) and wanted some opinion on the following:
>
> 1. Stateless session is basically a wrapper around statefulsession and since 
> per doc  statefulsession is not threadsafe is it  safe to assume 2 threads 
> cannot insert and run fireallrules to compare against a union of objects 
> inserted by multiple threads without some synchronication on event insertion 
> and ESP fireallrulesrules ? ( would the answer still hold despite a 
> drools-camel endpoint reading and storing exchanges from multiple threads ? )
>
>  stateful sessions are thread safe, they just aren't multi-threaded. Each
> of the working memory actions hold a lock, so only one thread at a time can
> enter.
>
> 2. If in the above point we simplify the case where the rule uses the "from" 
> keyword and reads from a cache or a Db ( is reading from
> A cache supported out of the box ? ) then will drools bhaviour will be bound 
> by the thread which invokes fireallrules() ?
>
>
>
> ___
> rules-users mailing 
> listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] Drools-server KnowledgeSessions

[Richard Calmbach]

Here is how I create StatefulKnowledgeSession instances dynamically, while
still leveraging Spring config:

[...]

  

  

  

  

  

  

Read [1,2] for background on Spring method injection and how to use it to
get a factory method for Spring-configured prototype beans without your
code (here: CompositeKnowledgeSessionGateway) needing to be Spring-aware.
Note that conceptually, kSessionParent is an abstract bean, but the
"abstract" attribute does not seem to be supported on .
Class CompositeKnowledgeSessionGateway has a

protected StatefulKnowledgeSession createSession() {
return null;
}

method (that could be abstract) that gets overridden in a Spring-generated
subclass.

Ref.:
[1]
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-method-injection
[2] http://blog.springsource.com/2004/08/06/method-injection/

-Richard

On Wed, Jan 11, 2012 at 4:37 PM, Hrumph  wrote:

> Is it possible to dynamically create a KnowledgeSession using the
> Drools-server API, or must the be statically declared in the Spring config?
>
> Thanks
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/Drools-server-KnowledgeSessions-tp3652344p3652344.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

Re: [rules-users] StatefulKnowledgeSession and multi-threaded processing

[Richard Calmbach]

When you are dealing with events, the processing works a bit differently.
First, we have to clarify: Are you inserting events or plain facts? If it
has a timestamp, it has to be handled as an event. The distinction matters
because in an event-driven scenario, only events would be inserted "from
the outside" (i.e., from outside the session), and then plain facts
(representing the system state) get inserted/updated/deleted in response to
these incoming events (via rule consequences). The only time you *might*
insert plain facts "from the outside" is at the beginning, before the start
of event processing, to define an initial state of the system. (If anyone
can think of a good reason to insert plain facts *during* event processing
other than in response to events, please let us know - always willing to
learn something new :-).)

In your example, rather than inserting an object (that represents system
state) again with modified state, you would insert a "StateChangeEvent"
into the session, and a rule would update the object (fact) in response to
this event - that's what is meant by event-driven processing or
event-driven architecture. Think of your system state as getting updated in
response to external events, and the rule engine is in charge of performing
the updates.

So, if your objects (object[ABC]) are events, then the situation of
inserting the same event (as in reference identity: ref1 == ref2) twice
doesn't make sense. Honestly, I don't know what the rule engine would do in
this case, but I'd say you have to consider the behavior undefined. Each
state change should be represented by a separate, new event.

I strongly recommend calling fireAllRules() after every single event
insertion (event != fact, event is a special kind of fact). It may be
possible to do batched inserts of events, but the overhead of calling
fireAllRules() after every single event insertion should be minimal. Keep
in mind, either way the rule engine has to process each event in turn in
order to maintain the event-driven semantics. In an event-driven setting,
you would not find yourself doing batch inserts like this, anyway. Events
are processed as they arrive. If you have multiple event streams and
inevitable delays due to messaging, then it is on you as the rule author to
ensure that your rules don't break due to unpredictable event ordering. I
also recommend synchronizing on the session in case you are inserting
events from multiple threads (I have empirical evidence that the
StatefulKnowledgeSession is *not* thread-safe). In a single-event-stream
scenario, where events arrive in chronological order (and even if not), you
want to insert and fire immediately upon event arrival (and, yes, events
could come from an asynchronous messaging queue).

At least this approach has worked well for me. Happy to hear feedback from
others.

-Richard

On Thu, Dec 22, 2011 at 10:45 AM, Skiddlebop  wrote:

> Thanks for the link :) 'Twas an interesting view! A few complexities still
> remain. I may be ill-informed about this matter so please correct me if I'm
> totally off-base in any of these statements.
>
> Alexandre states that the KnowledgeSession is thread safe, which is
> contrary
> to the documentation (if he is is referring to a StatefulKnowledgeSession).
> However, it seems like he is actually using a StatelessKnowledgeSession
> pulling his facts from Redis. Our requirements are different, we are
> dealing
> with real-time data, not historical data, and this real-time data will all
> be stored in a long-running StatefulKnowledgeSession. So every fact in that
> StatefulKnowledgeSession will be an active real-time representation of an
> object's state. However, we do share a similar approach in that we are also
> "going async" using queues. The reasoning for choosing the queue for us is
> based on a variety of considerations, the most relevant for this
> conversation is the fact that, based on the un-thread-safe nature of the
> StatefulKnowledgeSession, we anticipate processing one record at a time
> (one
> call to fireAllRules() per event). Does this seem like a reasonable
> approach?
>
> I have considered inserting multiple events (as facts) per call to
> FireAllRules(), but am uncertain of how the conflict resolution should work
> if say for instance two of those facts correspond to the same field of the
> same object. Here's a pseudo-code example outlining my concern:
>
> Key assumption: It is NOT possible to concurrently access a
> StatefulKnowledgeSession from multiple threads or separate parallel REST
> service calls.
>
> //Assume KnowledgeBase has already been built and sks is our long-running
> global singleton //StatefulKnowledgeSession which has continuity between
> individual REST web-service sessions.
>
> //Begin Pseudo-Code Snippet.
>
> //objectA with Data Member "Integer A" Value 1
> sks.insert(objectA);
> sks.insert(objectB);
> sks.insert(objectC);
> //objectA with Data Member "Integer A" Value 2 (this is an update to the
> s

Re: [rules-users] Bugs in Drools 5.3.0 break Fusion event processing

[Richard Calmbach]

Edson: Thanks for the quick reply. I created these JIRA issues:

F1: Duplicate job scheduling in
org.drools.time.impl.DefaultTimerJobInstance.call()
- https://issues.jboss.org/browse/JBRULES-3284

F2: NullPointerException in
org.drools.time.impl.DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance)
- https://issues.jboss.org/browse/JBRULES-3285

F3: org.drools.time.TimerService.scheduleJob(Job, JobContext, Trigger)
suddenly requires non-null JobContext
- https://issues.jboss.org/browse/JBRULES-3286

While you are working on the event scheduling system, you may also want to
look at these two earlier bug reports for Drools 5.2.0:

Long.MAX_VALUE duration for "A and not(B after A)" type rules causes
invalid session clock time in rule RHS when running with pseudo clock
- https://issues.jboss.org/browse/JBRULES-3100

"A and not(B after A)" type rules don't fire when session clock has
negative values (pre Unix epoch)
- https://issues.jboss.org/browse/JBRULES-3103

I have not checked their status in Drools 5.3.0, but the description should
tell you whether they still apply.

FWIW, among all of these, F2 (JBRULES-3285) has the highest priority (as
it's breaking my unit tests), followed by F1 (JBRULES-3284). Thanks!

Vincent: Yes, I think there is risk. Even if you don't use jobs explicitly,
Drools uses the same event scheduling system for both internal events and
application-defined events and jobs. The main problem is this: How do you
establish correctness of your code and the overall system? Well, you make
sure your unit tests and functional tests pass. As it stands, I cannot get
my tests to pass with Drools 5.3.0, so I cannot put Drools 5.3.0 in
production. No matter which version you use, only good test coverage will
give you the assurance that your system is functioning properly. I
encourage you to try out Drools 5.3.0 (in a test environment) and to report
any issues you run into. It can only help make Drools better.

2011/11/9 Vincent LEGENDRE 

> Just wondering : does these problems happends because you use clocks and
> jobs, or is it general to fusion 5.3 ?
> Did not migrate my project on 5.3 for now.
> So do you think there is a risk, knowing that I only use very basic fusion
> features ?
>
> --
> *De: *"Edson Tirelli" 
> *À: *"Rules Users List" 
> *Envoyé: *Mercredi 9 Novembre 2011 14:53:00
> *Objet: *Re: [rules-users] Bugs in Drools 5.3.0 break Fusion event
> processing
>
>
>
>Richard,
>
>This is great info. Yes, please open JIRA's for all 3 issues and we
> will make sure this is fixed for the next release.
>
>Thank you,
>Edson
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

[rules-users] Bugs in Drools 5.3.0 break Fusion event processing

[Richard Calmbach]

I am making extensive use of the event processing features of the Drools
rule engine. Upgrading from Drools 5.2.0.Final to Drools 5.3.0.Final broke
47 of my unit tests and also broke my functional tests. There seem to be
multiple changes in Drools 5.3.0 that cause incorrect behavior and/or break
backward compatibility. Here are the results of my investigation so far.

Issue F1:
While tracking down the failures of my unit tests, I experimented with the
Broker example, and while probably not finding the root cause of the broken
unit tests, I nonetheless came across what clearly seems to be incorrect
behavior in the DefaultTimerJobInstance.call() method. The bug only reveals
itself after all input has been processed, so it is masked by the fact that
running the Broker demo through the entire sequence in stocktickstream.dat
(1100 lines) takes a long time. In order to reveal the problem more
quickly, run the demo with only the first 14 lines in stocktickstream.dat.
Do so for both the 5.2.0 Broker demo (against Drools 5.2.0) and the 5.3.0
Broker demo (against Drools 5.3.0). The Broker example code in both
versions is identical, so only the Drools-internal code changes matter.

When running the 5.2.0 Broker demo to the end, you get one
java.text.ParseException (given the structure of the example code, that's
expected, albeit not elegant, and not the focus of our investigation). In
particular, no matter how many lines stocktickstream.dat contains, you
always get exactly one ParseException at the end.

Contrast this with running the 5.3.0 Broker demo: At the end you get N
occurrences of java.text.ParseException, where N is the number of lines in
stocktickstream.dat. So for 14 lines you get 14 occurrences of
ParseException. Looking at two specific methods shows us why:

Method
org.drools.examples.broker.events.EventFeeder.FeedJob.execute(JobContext):

public void execute(JobContext context) {
this.sink.receive( ((FeedContext) context).event );
if ( this.source.hasNext() ) {
((FeedContext) context).setEvent( this.source.getNext() );
this.trigger.setNextFireTime( ((FeedContext)
context).getEvent().getDate() );
clock.scheduleJob( this,
   context,
   trigger );
}
}

Note in particular how this method already takes care of scheduling the
next job execution by updating the next fire time of the job's existing
FeedTrigger instance. Unfortunately, in Drools 5.3.0,
DefaultTimerJobInstance.call() does a duplicate scheduling of the same job:

Method org.drools.time.impl.DefaultTimerJobInstance.call():

public Void call() throws Exception {
this.trigger.nextFireTime(); // need to pop
if ( handle.isCancel() ) {
return null;
}
this.job.execute( this.ctx );
if ( handle.isCancel() ) {
return null;
}

// our triggers allow for flexible rescheduling
Date date = this.trigger.hasNextFireTime();
if ( date != null ) {
scheduler.internalSchedule( this );
}

return null;
}


So, every job is duplicated and that's why there are 2*N calls to
org.drools.examples.broker.events.StockTickPersister.load() instead of N.

I think the rescheduling inside DefaultTimerJobInstance.call() is
incorrect. For one, it breaks backward compatibility, and it is unexpected.
The job should be in charge of deciding whether there is another job to
schedule or what to do. Implicitly scheduling the next job just by updating
the trigger time is a little too much magic.

Issue F2:
This is the bug that causes my unit tests to fail. I have not pinpointed
the root cause, but it seems to have to do with the event scheduling Drools
does as part of its job execution mechanism. Its symptom is a
NullPointerException during insertion of an event. What makes it so tricky
is that with the out-of-the-box configuration, Drools catches such
exceptions in org.drools.time.impl.PseudoClockScheduler.runCallBacks() and
passes them to the aptly named "DoNothingSystemEventListener", which
literally does nothing, not so much as logging (the methods are empty). So
you don't actually know that the event insertion failed, you only wonder
why your mock WorkingMemoryEventListener is telling you that your
expectations are not met. The stack trace (as copied from the Eclipse Debug
view, hence the unusual formatting) inside Drools is:

Date.getMillisOf(Date) line: 939
Date.compareTo(Date) line: 959
DefaultTimerJobInstance.compareTo(DefaultTimerJobInstance) line: 38
DefaultTimerJobInstance.compareTo(Object) line: 13
PriorityQueue.siftUpComparable(int, E) line: 582
PriorityQueue.siftUp(int, E) line: 574
PriorityQueue.offer(E) line: 274
PriorityQueue.add(E) line: 251
PseudoClockScheduler.internalSchedule(TimerJobInstance) line: 136
PseudoClockScheduler.scheduleJob(Job, JobContext, Trigger) line: 126
ObjectTyp

Re: [rules-users] Help with troubleshooting rules/Drools

[Richard Calmbach]

Robert Crawford wrote:
> 
> Any advice on how to troubleshoot problems? I have a fairly simple set of
> rules (a couple dozen), but keep having problems with fatal exceptions.
> The most recent was:
> 
> org.drools.RuntimeDroolsException: Unexpected exception executing action
> org.drools.reteoo.PropagationQueuingNode$PropagateAction@1e60aa7
>  at
> org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:977)
>  at
> org.drools.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1231)
>  at
> org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:753)
>  at
> org.drools.common.AbstractWorkingMemory.fireUntilHalt(AbstractWorkingMemory.java:729)
>  at
> org.drools.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:234)
>  at
> com.kroger.tempmonitor.app.service.RuleService$1.run(RuleService.java:214)
>  at java.lang.Thread.run(Thread.java:662)
> Caused by: java.util.NoSuchElementException
>  at java.util.LinkedList.remove(LinkedList.java:788)
>  at java.util.LinkedList.removeFirst(LinkedList.java:134)
>  at
> org.drools.common.PropagationContextImpl.evaluateActionQueue(PropagationContextImpl.java:264)
>  at
> org.drools.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:357)
>  at
> org.drools.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:238)
>  at
> org.drools.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:502)
>  at
> org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:975)
>  ... 6 more
> 
> 
> No mention of a rule name, so where do I begin?
> 

The exception may happen during working memory operations (e.g., an insert),
so there isn't even a rule active.

Which version of Drools are you using? In my case, switching from Drools
5.2.0.Final to Drools 5.3.0.Final broke 47 of my unit tests (1 error and 46
failures). The one that now gives an error, shows this stacktrace (similar
to yours):

org.drools.RuntimeDroolsException: Unexpected exception executing action
org.drools.reteoo.PropagationQueuingNode$PropagateAction@7a9b777a
at
org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:977)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:315)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:291)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:886)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:845)
at
org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255)
at com.acme.das.fraud.RulesTestBase.sendEot(RulesTestBase.java:139)
at com.acme.das.fraud.RulesTestBase.advanceTime(RulesTestBase.java:131)
at com.acme.das.fraud.RulesTestBase.advanceTime(RulesTestBase.java:135)
at
com.acme.das.fraud.RulesTest.testUdrAndThenStartCdrWithinTimeout(RulesTest.java:1061)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:66)
at org.jmock.integration.junit4.JMock$1.invoke(JMock.java:37)
at
org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
at
org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:94)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
at
org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:98)
at
org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:61)
at
org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:54)
at
org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
at 
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
at
org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:52)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteT

Re: [rules-users] Online 5.3.0 javadocs

[Richard Calmbach]

Martin A wrote:
> 
> Hello,
> I'm looking for the online 5.3.0 javadocs, but can't find it... Would you
> point me to a reference?
> 

I have not been able to find online (as opposed to download) javadoc for any
version of Drools after 5.1.1 either. I created an issue about that here:
https://issues.jboss.org/browse/JBRULES-3276 .

--
View this message in context: 
http://drools.46999.n3.nabble.com/rules-users-Online-5-3-0-javadocs-tp3467657p3469837.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users