6:45 a.m.
Hi,
In my drools implementation I'm inserting all my facts into working memory
and for every fact received I'm also inserting events into notification
stream.
Now the StatefulKnowledgeSession I'm using is static and it is neither
initialized nor disposed after being initialized for first time. My
application will run for months without restarting and so the same session
will be used without being reinitialized or disposed.
Do I have to retract events explicitly or will it handled by drools
internally? If not then how can I retract them say after 5 minutes?
Also I'm using sliding window and I've not explicitly declared expiry time,
for events, in my drl file. Should I define it or will drools remove them
after the maximum sliding window time defined in rules?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
7:55 a.m.
In contrast to what is written in the Fusion manual, section
2.8., Memory Management for Events, an explicit expiry time
set in the declare overrules any implicit expirations calculated
from an event type's usage in rules.
To set an unconditional expiry of 5 minutes, you just use, e.g.,
declare MyEvent
@role( event )
@expires( 5m )
end
You may also rely on an implicit expiry time, but note that
there may be rules that produce an infinite expiry time. In
an application such as you describe, an explicit expiry is
certainly preferable.
-W
On 10 November 2010 13:45, Ayush <ayush.vatsyayan(a)alcatel-lucent.com> wrote:
Hi,
In my drools implementation I'm inserting all my facts into working memory
and for every fact received I'm also inserting events into notification
stream.
Now the StatefulKnowledgeSession I'm using is static and it is neither
initialized nor disposed after being initialized for first time. My
application will run for months without restarting and so the same session
will be used without being reinitialized or disposed.
Do I have to retract events explicitly or will it handled by drools
internally? If not then how can I retract them say after 5 minutes?
Also I'm using sliding window and I've not explicitly declared expiry time,
for events, in my drl file. Should I define it or will drools remove them
after the maximum sliding window time defined in rules?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:16 p.m.
Thanks for your reply.
Also let me know about facts which are loaded into working memory (Keeping
in mind that I'm not calling session.dispose()).
Where should I define their expiry time or how should I retract them after 5
minutes?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
1:12 a.m.
On 11 November 2010 04:16, Ayush <ayush.vatsyayan(a)alcatel-lucent.com> wrote:
Thanks for your reply.
Also let me know about facts which are loaded into working memory (Keeping
in mind that I'm not calling session.dispose()).
Where should I define their expiry time or how should I retract them after 5
minutes?
You declare the class to represent an event and set the expiry time.
import ...MyEventType
declare MyEventType
@role( event )
@expires( 5m )
end
Or you could catch them with a one-shot timer rule where other actions
besides retract would be possible.
rule "kill after 5m"
timer(int: 5m)
when
$f: SomeType()
then
// other actions?!
retract( $f );
end
Using a suitable interface or supertype may reduce the number of
required rules.
-W
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:46 a.m.
Ok so drools will not be garbage collecting the facts (as I'm not calling
dispose()) and I've to retract them manually.
I was wondering cannot there be any way in which I can define expiry time
for facts in the same way I declare for events i.e. @expiry
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
5:39 a.m.
On 11/11/2010 10:46, Ayush wrote:
Ok so drools will not be garbage collecting the facts (as I'm not
calling
dispose()) and I've to retract them manually.
I was wondering cannot there be any way in which I can define expiry time
for facts in the same way I declare for events i.e. @expiry
Use a working memory
listener. Have it store each inserted object in a
time based eviction queue and it'll remove things for you.
Mark
4:31 p.m.
Can you please elaborate on "Have it store each inserted object in a
time based eviction queue and it'll remove things for you." i.e. how can I
do it?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
2:23 a.m.
A time based eviction queue is simply a queue that evicts its content based
upon time-based heuristic. So the WorkingMemoryEventListener would store
facts inserted into the WorkingMemory in an internal queue and evict them
from that queue based upon some time-based heuristic. You could use an
Executor (ScheduledExecutorService) etc to remove facts from the queue and
working memory at set intervals.
With kind regards,
Mike
On 11 November 2010 22:31, Ayush <ayush.vatsyayan(a)alcatel-lucent.com> wrote:
Can you please elaborate on "Have it store each inserted object in a
time based eviction queue and it'll remove things for you." i.e. how can I
do it?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:31 a.m.
There isn't much support Drools provides for this. The listener tells you
about
a new Fact being inserted, and then - what? Unless you are satisfied with
a constant expiry offset, or define expiry times by a Map<Class<?>,Long>
or implement getExpiryOffset in all of your classes, you don't know *when*
to retract.
You can define @expires(...) on a declare even when the @role is not
"event",
but getting at this value isn't simple; you have to use the unstable API
org.drools.definitions.impl.KnowledgePackageImp rpkg =
(org.drools.definitions.impl.KnowledgePackageImp)kBase.getKnowledgePackage(
"some.package" );
org.drools.rule.TypeDeclaration td =
(org.drools.rule.TypeDeclaration)rpkg.pkg.getTypeDeclaration( "FactTYpe" );
System.out.println( "Expires: " + td.getExpirationOffset() );
It's difficult to accept why features which are part of the established user
interface are not accessible via the stable API.
As an aside, notice that the Expert manual teaches me to add metadata to a
Java-defined class:
declare org.drools.examples.Person
@author( Bob )
...
end
Great, and Bob's your uncle! How do I retrieve this author metadata?
Regards
Wolfgang
2010/11/12 Michael Anstis <michael.anstis(a)gmail.com>:
A time based eviction queue is simply a queue that evicts its content
based
upon time-based heuristic. So the WorkingMemoryEventListener would
store
facts inserted into the WorkingMemory in an internal queue and evict them
from that queue based upon some time-based heuristic. You could use an
Executor (ScheduledExecutorService) etc to remove facts from the queue and
working memory at set intervals.
With kind regards,
Mike
On 11 November 2010 22:31, Ayush <ayush.vatsyayan(a)alcatel-lucent.com>
wrote:
>
> Can you please elaborate on "Have it store each inserted object in a
> time based eviction queue and it'll remove things for you." i.e. how can
I
> do it?
> --
> View this message in context:
>
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:48 a.m.
Very true Wolfgang, and I agree your comments re: accessing meta data too.
In this case if Events are raised in response to Facts and the events
themselves expire after 5 mins; I'd assume a constant time expiration policy
on the queue to be acceptable however this is based on assumption rather
than fact.
Edson\Mark are the experts in this realm so I'll defer further comment to
them.
With kind regards,
Mike
2010/11/12 Wolfgang Laun <wolfgang.laun(a)gmail.com>
There isn't much support Drools provides for this. The listener
tells you
about
a new Fact being inserted, and then - what? Unless you are satisfied with
a constant expiry offset, or define expiry times by a Map<Class<?>,Long>
or implement getExpiryOffset in all of your classes, you don't know *when*
to retract.
You can define @expires(...) on a declare even when the @role is not
"event",
but getting at this value isn't simple; you have to use the unstable API
org.drools.definitions.impl.KnowledgePackageImp rpkg =
(org.drools.definitions.impl.KnowledgePackageImp)kBase.getKnowledgePackage(
"some.package" );
org.drools.rule.TypeDeclaration td =
(org.drools.rule.TypeDeclaration)rpkg.pkg.getTypeDeclaration( "FactTYpe" );
System.out.println( "Expires: " + td.getExpirationOffset() );
It's difficult to accept why features which are part of the established
user interface are not accessible via the stable API.
As an aside, notice that the Expert manual teaches me to add metadata to a
Java-defined class:
declare org.drools.examples.Person
@author( Bob )
...
end
Great, and Bob's your uncle! How do I retrieve this author metadata?
Regards
Wolfgang
2010/11/12 Michael Anstis <michael.anstis(a)gmail.com>:
> A time based eviction queue is simply a queue that evicts its content
based
> upon time-based heuristic. So the WorkingMemoryEventListener would store
> facts inserted into the WorkingMemory in an internal queue and evict them
> from that queue based upon some time-based heuristic. You could use an
> Executor (ScheduledExecutorService) etc to remove facts from the queue
and
> working memory at set intervals.
>
> With kind regards,
>
> Mike
>
> On 11 November 2010 22:31, Ayush <ayush.vatsyayan(a)alcatel-lucent.com>
wrote:
>>
>> Can you please elaborate on "Have it store each inserted object in a
>> time based eviction queue and it'll remove things for you." i.e. how
can
I
>> do it?
>> --
>> View this message in context:
>>
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
>> Sent from the Drools - User mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:02 a.m.
Thanks. Actually I did it in different way what I did is I declared my fact
into drl file as declare MyFact and then I'd added an @expires to it. It
works fine but now the problem is that for every fact inserted I'd also
inserted an event for it.
Now as the drl file can be updated by user so say he'd defined expiry time
for events as 1m and for facts as 10s in this case since I'm using sliding
window for events and based on this event I'm fetching the fact. So now I'll
be getting the event but facts will not be available as the 2nd fact came
after 20s hence the rule will not be fired. below is the sample rule.
declare MyEvent
@role(event)
@expires( 1m )
end
declare MyFact
@expires( 10s )
end
rule "MyCorrelation"
no-loop true
dialect "mvel"
lock-on-active
when
$E1 : MyEvent( prop1 == 2, $entityA : entity ) over window:time(60s) from
entry-point NotificationStream
$E2 : MyEvent( this != $E1, prop1 == 1, $entityB : entity ) over
window:time(60s) from entry-point NotificationStream
$F2 : MyFact(this.entity == $entityB)
$F1 : MyFact(this.entity == $entityA)
then
System.out.println("I'm executed successfully");
end
Now what I want is that I can define the @expires time at a single location
or I can verify the logic of these rules?
Also if say I'd defined the @expires for event as 10s while in sliding
window I'm using over:time(1m) then also it is not same.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
4:22 a.m.
Now that I see this code I wonder why you don't simply promote MyFact
to an event?
But, given the current situation, which removes MyEvent facts after 1m,
and assuming that you insert the MyEvent *before* its corresponding
MyFact, you can
rule "fact-without-event"
when
$f: MyFact($entity : entity)
not MyEvent( entity == $entity )
then
retract( $f );
end
and the obsolete MyFact will be gone, too.
-W
On 12 November 2010 11:02, Ayush <ayush.vatsyayan(a)alcatel-lucent.com> wrote:
Thanks. Actually I did it in different way what I did is I declared my fact
into drl file as declare MyFact and then I'd added an @expires to it. It
works fine but now the problem is that for every fact inserted I'd also
inserted an event for it.
Now as the drl file can be updated by user so say he'd defined expiry time
for events as 1m and for facts as 10s in this case since I'm using sliding
window for events and based on this event I'm fetching the fact. So now
I'll
be getting the event but facts will not be available as the 2nd fact came
after 20s hence the rule will not be fired. below is the sample rule.
declare MyEvent
@role(event)
@expires( 1m )
end
declare MyFact
@expires( 10s )
end
rule "MyCorrelation"
no-loop true
dialect "mvel"
lock-on-active
when
$E1 : MyEvent( prop1 == 2, $entityA : entity ) over
window:time(60s) from
entry-point NotificationStream
$E2 : MyEvent( this != $E1, prop1 == 1, $entityB : entity )
over
window:time(60s) from entry-point NotificationStream
$F2 : MyFact(this.entity == $entityB)
$F1 : MyFact(this.entity == $entityA)
then
System.out.println("I'm executed successfully");
end
Now what I want is that I can define the @expires time at a single location
or I can verify the logic of these rules?
Also if say I'd defined the @expires for event as 10s while in sliding
window I'm using over:time(1m) then also it is not same.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:45 a.m.
oh yes Thanks this rule will solve my problem.
I'm wondering is there any way I can actually verify the business logic of
my rules. I'd read about drools-verifier but I've not found enough
information for it to be used with drl. I want that in some way I can check
the business logic from java classes?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
5 a.m.
You can use JUnit, create a session, insert facts, call fireXY(),...
Asserting the correct result may
be done by inspecting the WM or listening to events or whatever your app
suggests.
-W
On 12 November 2010 11:45, Ayush <ayush.vatsyayan(a)alcatel-lucent.com> wrote:
oh yes Thanks this rule will solve my problem.
I'm wondering is there any way I can actually verify the business logic of
my rules. I'd read about drools-verifier but I've not found enough
information for it to be used with drl. I want that in some way I can
check
the business logic from java classes?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4 a.m.
Thanks for replies. Actually what I did now is I declared my fact into drl
file and then I'd added an @expires to it. It works fine but now the problem
is that for every fact inserted I'd also inserted an event for it.
Now as the drl file can be updated by user so say he'd defined expiry time
for events as 1m and for facts as 10s in this case since I'm using sliding
window for events and based on this event I'm fetching the fact. So now I'll
be getting the event but facts will not be available as the 2nd fact came
after 20s hence the rule will not be fired. below is the sample rule.
declare MyEvent
@role(event)
@expires( 1m )
end
declare MyFact
@expires( 10s )
end
rule "MyCorrelation"
no-loop true
dialect "mvel"
lock-on-active
when
$E1 : MyEvent( prop1 == 2, $entityA : entity ) over window:time(60s) from
entry-point NotificationStream
$E2 : MyEvent( this != $E1, prop1 == 1, $entityB : entity ) over
window:time(60s) from entry-point NotificationStream
$F2 : MyFact(this.entity == $entityB)
$F1 : MyFact(this.entity == $entityA)
then
System.out.println("I'm executed successfully");
end
Now what I want is that I can define the @expires time at a single location
or I can verify the logic of these rules?
Also if say I'd defined the @expires for event as 10s while in sliding
window I'm using over:time(1m) then also it is not same.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
Sent from the Drools - User mailing list archive at Nabble.com.
8:56 a.m.
Just in case anybody wonders about the effort for building a mechanism for
retracting facts based on fact attributes or other data, I outline the
solution I have implemented.
My class FactWiper implements WorkingMemoryEventListener and Runnable.
- The implementation of objectInserted( ObjectInsertedEvent event )
determines whether the object needs handling and, if so, the retraction
Date, based upon whatever strategy you care to implement, e.g., reflection
method call, Map<Class,Long>, etc. If it is to be handled, it signals
Condition "change" to the thread.
- A SortedMap<Date,Object> expiry2fact keeps track of pending
retractions.
- The thread loops into an awaitUntil( x ) on the "change" condition,
where x is (generally) the first retraction Date. If reached, it retracts
according to the foremost Map entry; if signalled it reasesses the situation
and reenters the awaitUntil.
-W
2010/11/12 Michael Anstis <michael.anstis(a)gmail.com>
A time based eviction queue is simply a queue that evicts its content
based
upon time-based heuristic. So the WorkingMemoryEventListener would store
facts inserted into the WorkingMemory in an internal queue and evict them
from that queue based upon some time-based heuristic. You could use an
Executor (ScheduledExecutorService) etc to remove facts from the queue and
working memory at set intervals.
With kind regards,
Mike
On 11 November 2010 22:31, Ayush <ayush.vatsyayan(a)alcatel-lucent.com>wrote:
>
> Can you please elaborate on "Have it store each inserted object in a
> time based eviction queue and it'll remove things for you." i.e. how can I
> do it?
> --
> View this message in context:
>
http://drools-java-rules-engine.46999.n3.nabble.com/Removing-facts-from-s...
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5128
days inactive
5130
days old
15 comments
4 participants
participants (4)
-
Ayush -
Mark Proctor -
Michael Anstis -
Wolfgang Laun