11:52 a.m.
[
https://issues.jboss.org/browse/DROOLS-1030?page=com.atlassian.jira.plugi...
]
Artur Kronenberg edited comment on DROOLS-1030 at 2/5/16 12:51 PM:
-------------------------------------------------------------------
For the people coming here with the same issue, this is the workaround I implemented:
1. Add a new Interface with say one method isExpired(). This method determines whether or
not the fact can go.
2. Add a rule to match that interface. For me the Interface is called Expirable. This is
my rule:
rule "fact_expiry_automation"
when
$e : Expirable( expired == true );
then
retract($e);
end
3. Have all your facts implement that interface.
4. Add a timer task manually that calls fireAllRules. Use an AgendaFilter in case you want
to only match this rule exactly.
5. Run the task as often as you wish.
You will also have to remove the expires annotation on the original facts to stop drools
from also trying to expire facts.
This solution has an issue where the expiry for the facts only work if the facts are
inserted on session level. For example, I had to restructure my rules to not use
entrypoints so that these facts could also expire programatically.
Hope that helps
UPDATE: not actually working because a fact is not reevaluated. My new workaround:
The timer task inserts a new ExpiryFact each time it runs. That way there's a new fact
that must be evaluated. The fact caries an expiryTimestamp that i can then compare with
the expiry field on my other facts.
was (Author: pandaadb):
For the people coming here with the same issue, this is the workaround I implemented:
1. Add a new Interface with say one method isExpired(). This method determines whether or
not the fact can go.
2. Add a rule to match that interface. For me the Interface is called Expirable. This is
my rule:
rule "fact_expiry_automation"
when
$e : Expirable( expired == true );
then
retract($e);
end
3. Have all your facts implement that interface.
4. Add a timer task manually that calls fireAllRules. Use an AgendaFilter in case you want
to only match this rule exactly.
5. Run the task as often as you wish.
You will also have to remove the expires annotation on the original facts to stop drools
from also trying to expire facts.
This solution has an issue where the expiry for the facts only work if the facts are
inserted on session level. For example, I had to restructure my rules to not use
entrypoints so that these facts could also expire programatically.
Hope that helps
Nullpointer in JpaTimerJobInstance.call on startup
---------------------------------------------------
Key: DROOLS-1030
URL: https://issues.jboss.org/browse/DROOLS-1030
Project: Drools
Issue Type: Bug
Components: core engine
Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
Reporter: Artur Kronenberg
Assignee: Mario Fusco
Fix For: 6.4.0.CR1
Attachments: test-standalone.zip
Hi,
I have noticed Nullpointer exceptions when I try and reload a persisted session on
startup. It is a bit hard to recreate (I am actually not managing it now since I deleted
all old sessions to attempt recreation) but I figured maybe someone has an idea.
Essentially I am getting this NPE twice:
java.lang.NullPointerException: null
at
org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:50)
[drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
at
org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:30)
[drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_51]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[na:1.8.0_51]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[na:1.8.0_51]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_51]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
When debugging I noticed the following behaviour which points to a race condition:
If I start my server and try to recreate the session, those NPEs happen 2x.
If I start my server and put a breakpoint BEFORE creating the CommandService for
execution, I can wait for a few seconds and the service can be found.
It appears that the scheduler's timerJobFactoryManager is not fully there at the time
the sessions is being loaded? Or something else is racing with the service creation.
Is there a way for me to make sure everything is fully instantiated before I use drools?
Does a workaround exist? Is this even a bug?
Thanks and let me know your thoughts. If I run into this again I will attempt to try and
reproduce it. Let me know if more info is needed!
UPDATE:
I noticed that the reason I can't reproduce it at the moment is that the
JpaTimerJobInstance is never called with the newly persisted session. It appears that that
timer job depends on something else to happen so that it thinks it needs to start the
timerJob
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
3199
days inactive
3199
days old
0 comments
1 participants
participants (1)
-
Artur Kronenberg (JIRA)