Good and valid suggestions. As usual, please open a JIRA so that
we can track them.
Just FYI:
* It is possible to see the expiration offset through the kbase
MBeans, using any JMX Console.
* It is possible to see the expiration offset in the Eclipse RETE
Viewer by clicking on the respective ObjectTypeNode. Although, this
only takes into account the rules in the corresponding file, so needs
to be used with care.
* It is possible to see the expiration offset through the debuging
reports we discussed on a few e-mails to the list, but that is not a
stable API yet, so needs improvement.
* It is not possible to obtain the expiration offset through APIs at the moment.
* It is possible to disable automatic event expiration by using CLOUD
mode instead of STREAM mode, but that also prevents the use of sliding
windows. So it would be good to have an specific configuration as per
your suggestion.
Edson
Edson
2010/11/12 Wolfgang Laun <wolfgang.l...@gmail.com>:
> On 12 November 2010 18:21, Edson Tirelli <tire...@post.com> wrote:
>>
>> Wolfgang,
>>
>> TypeDeclaration.getExpirationOffset() returns the value of the user
>> defined expiration policy:
>>
>> @expires( 1h )
>
> OK...
>
>>
>> The final, inferred result is stored in the ObjectTypeNodes
>> themselves, as it might be different for different entry points.
>>
>
> There's no simple way to get at 'em, I suppose. So, as a user, how do I
> determine whether my current set of rules implies a finite expiry limit? If
> it isn't finite, I'll have to set an explicit @expires; if I do that, it
> could be too short...
>
> Much along the lines I have carped in another thread: a "clever" system is
> allright, but it must not leave me in the dark about its cleverness.
>
> Getting down to brass tacks: the stable API should provide access to any
> data
>
> set by the user or
> determined by the compiler, and both
> for Java types honed in by DRL declares as well as
> for types declared in the DRL.
>
> Given all that, it might still be useful to have a way of turning the
> inferred expiry time off without setting an @expires for all types, which
> can be done with an @expires(1000000000d) or so). Also, see that hint in a
> recent thread about how easy it is to implement a retraction strategy based
> on data in the events. One use case I was thinking of was with events (or
> even plain facts) having a variable duration attribute, to be retracted at
> timestamp+duration.
>
> Wolfgang
>
>>
>> Edson
>>
>> 2010/11/12 Wolfgang Laun <wolfgang.l...@gmail.com>:
>> > I have tried
>> >
>> > declare EventA
>> > @role( event )
>> > x : Void
>> > end
>> > declare EventB
>> > @role( event )
>> > x : Void
>> > end
>> > rule "mock-A" # only rule for EventA, EventB
>> > when
>> > $b: EventB()
>> > $a: EventA( this after[0,10s] $b )
>> > then
>> > end
>> >
>> > and
>> > org.drools.rule.TypeDeclaration tda =
>> > (org.drools.rule.TypeDeclaration)rpkg.pkg.getTypeDeclaration( "EventA"
>> > );
>> > System.out.println( "EventA expires: " + tda.getExpirationOffset() +
>> > "
>> > role:" + tda.getRole());
>> > org.drools.rule.TypeDeclaration tdb =
>> > (org.drools.rule.TypeDeclaration)rpkg.pkg.getTypeDeclaration( "EventB"
>> > );
>> > System.out.println( "EventB expires: " + tdb.getExpirationOffset() +
>> > "
>> > role:" + tdb.getRole());
>> >
>> > which prints
>> > EventA expires: -1 role:EVENT
>> > EventB expires: -1 role:EVENT
>> >
>> > Since the DRL code is equivalent to example 2.19 ("correlate orders") in
>> > Fusion, this raises the question whether the inferred expiration offset
>> > is
>> > actually computed as described.
>> >
>> > -W
>> >
>> >
>> >
>> > _______________________________________________
>> > rules-dev mailing list
>> > rules-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-dev
>> >
>> >
>>
>>
>>
>> --
>> Edson Tirelli
>> JBoss Drools Core Development
>> JBoss by Red Hat @ www.jboss.com
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
