I've found the issue, its removing the item twice. I'll fix this for the point release next week.
http://jira.jboss.org/jira/browse/JBRULES-1033

Thanks

Mark
Mark Proctor wrote:
hmm that looks like a bug, I'll look into it. We do have unit/integration tests for this, so I'd be interested to know what you are doing to kick this off. Are you just adding a clear agenda after the fireAllRules() in that example?

Mark
tom@bergstein-soraic.de wrote:

Thank you for the hint. I've tried to use clearAgenda() but I've following error:

 

Exception in thread "main" java.lang.NullPointerException

at org.drools.util.LinkedList.remove(LinkedList.java:97)

at org.drools.common.DefaultAgenda.removeScheduleItem(DefaultAgenda.java:150)

at org.drools.common.ScheduledAgendaItem.remove(ScheduledAgendaItem.java:159)

at org.drools.common.DefaultAgenda.clearAgenda(DefaultAgenda.java:362)

at org.drools.common.AbstractWorkingMemory.clearAgenda(AbstractWorkingMemory.java:363)

at org.drools.examples.TroubleTicketExample.main(TroubleTicketExample.java:58)


  

Is there anything special to consider when using clearAgenda()?

 

 

 

----- Edison wrote:  

 Technically it is possible and supported to serialize working memories. Although, we did faced problems with large serializations due to a known recursion issue in JDK. There is a JIRA for that, but I don't have the link right now.

    Now, if you want to reassert objects without firing rules, maybe what you can do is call WorkingMemory.clearAgenda() after reasserting the ob! jects. Not sure if that will give you the results you expect.

    []s
    Edson

2007/7/25, Arjun Dhar <dhar_ar@yahoo.com>:
bergstein-soraic.de> writes:

>
>
> I've a use case that is similar to the TroubleTicketExample that is part of
the drools examples.
> In this examples new tickets are inserted via workingMemory.assertObject
(ticket). However, tickets are usually managed and stored in a ticketing system
(Remedy, Peregrine, etc). When I stop the drools engine, I assume that the
state of the working memory is lost. When I start the engine again, I'd like to
load the working memory with the tickets that are stored in the tic! keting
system, but I don't want to fire all rules, since I'd to avoid that rules are
executed again (e.g., rule "Escalate" -> send a e-mail), which have been
already executed before the drools engine has
>   been stopped. Existing tickets in the ticketing system are important facts
for the rules!
>   and therefore the need to be loaded into the morking memory.
>
>
> Is there a way to build up the working memory with initial facts?
> Can I persist the state of the working memory and load it later again?
>
>
> Many thanks in advance,
> Tom
>

Hey my two bits,

Assuming I dont know much about StatefulSessions holding objects I wanted to
check with you, is this safe? I'm not sure over a period of time if your
objects would be released with a StatefulSession/WorkingMemory, would recommend
you 'soak test' (test over a period of time with consistent l oad)

But here is the possibility:
Well the interface WorkinfgMemory -- extends --> Eventmanager which extends
Serializable.

You could try serializing the object, or query your WorkingMemory for its state
and save it to a database. Am assuming you are using StatefulSession so you
will have access to WorkingMemory.

Conceptually I just think its worng to use a Rule Engine to persist state over
a such a long period of time. Any expert opinion?

regards,
Arjun

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



--
  Edson Tirelli
  Soft! ware Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.jboss.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