Re: [rules-users] Protobuf Marshaller Question (ScheduledActivation Persistence)

Thanks Edson for your reply. I am really looking forward to work on a solution for this. What you write also makes absolutely sense to me. As far as I can see, the ScheduledActivation is unmarshalled correctly to the Agenda. Moreover, after unmarshalling the agenda my logger says that there is one active and one scheduled activation (interestingly, the agendaSize equals zero, but anyway). logger.info("agenda size: "+agenda.agendaSize()); logger.info("activations: "+agenda.getActivations().length); logger.info("scheduledActivations: "+agenda.getScheduledActivations().length); logger.info("activeActivations: "+agenda.getActiveActivations() ); logger.info("dormantActivations: "+agenda.getDormantActivations()); Since the ProtobufOutputMarshaller seems to use the scheduled job instances (Timers _timers = writeTimers( context.wm.getTimerService().getTimerJobInstances(), context ); I tried to look what's in these list. However, in all cases the list of job instances is empty. logger.info("timer service2: "+((StatefulKnowledgeSessionImpl) this.session).getTimerService()); logger.info("timer service2: "+((StatefulKnowledgeSessionImpl) this.session).getTimerService().getTimerJobInstances()); logger.info("timer service wm: "+((InternalWorkingMemory) ((StatefulKnowledgeSessionImpl) this.session).session).getTimerService()); logger.info("timer service wm: "+((InternalWorkingMemory) ((StatefulKnowledgeSessionImpl) this.session).session).getTimerService().getTimerJobInstances()); As suggested by you, I simply switched to the current 5.5.0.Beta1 deps from nexus (because I don't know where I can get the branch builds from beyond version 5.4.0.Final). However, a quick test run tells me that the problem persists. Therefore, I'm gonna write a self-contained test and file a JIRA accordingly. I keep you updated. Thanks a lot, Philipp 2012/10/1 Edson Tirelli <ed.tirelli(a)gmail.com&gt;: > > Phillip, > > Thanks for investigating this. There are few developers that know this > area of the code, and so it is indeed a bit hard to get extra information. > > Here is a quick recap: although the serialization change on Drools 5.3 > involved a move to use protobuf as the serialization framework, Protobuf is > nothing more than a way to easily handle the actual data persistence. The > whole logic is one layer up in the scale and there is where the > investigation should focus. So, lets forget Protobuf for the moment. > > Before 5.3, we used to serialize all the data structures and intermediate > data inside a session using custom data structures. That was a big problem > because, for instance, if a session was serialized with one version of > Drools, and then someone tried to use any other version of Drools to > deserialize the session, it would not work. Even a simple bug fix could > affect the internal data structures and make a session impossible to > deserialize. To avoid that, from 5.3 and forward, we no longer serialize > everything, but instead we serialize only the necessary raw data that allows > us to reconstruct a session. > > To be more clear, lets imagine that we have a session and a fact A1 in > there, and an activation of rule R1 for fact A1. When the session is > serialized, we will basically serialize fact A1 and a record that R1 was > active for fact A1. When we deserialize the session, we will re-propagate A1 > through the engine, recreating all the data structures and then correlate > the new activation of R1 with the serialized activation of R1. > > Having said that, even scheduled activations should be properly > serialized/deserialized. I think there was a bug fixed related to timer > serialization, so the first thing I would like to suggest is to check your > use case against the 5.4.x branch where fixed bugs are committed. If you > still see the problem there, then please open a JIRA with a self-contained > test showing the problem, and I will take a look as soon as I can. > > Thanks, > Edson > > > On Mon, Oct 1, 2012 at 1:04 PM, Philipp Herzig <pherzig(a)gmail.com&gt; wrote: >> >> Dear developers, >> >> Unfortunately, I was not able to solve this problem yet. However, I >> found another issue that seems to be related. >> More precisely, when I try to delete the rules that led to the >> ScheduledActivations (which are not fired after unmarshalling, i.e., >> there are "orphan" activations on the agenda) I get the following >> trace: >> >> java.lang.NullPointerException >> at >> org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:134) >> at >> org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:524) >> at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:454) >> at org.drools.common.BaseNode.remove(BaseNode.java:106) >> at >> org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:410) >> at org.drools.common.BaseNode.remove(BaseNode.java:106) >> at >> org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:261) >> at >> org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:459) >> at >> org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1106) >> at >> org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1084) >> at >> org.drools.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:208) >> >> Obviously, there is still a connection between the unfired activations >> and the rule. >> >> Since some time ago I've successfully used the JPAKnowledgeService, I >> looked into the code and found a line in initKSession which looks >> promising: >> >> >> ((AcceptsTimerJobFactoryManager) ((InternalKnowledgeRuntime) >> >> ksession).getTimerService()).getTimerJobFactoryManager().setCommandService( >> this ); >> >> >> I kindly wanted to ask, if somebody can explain the implications of >> this codeline with regards to the ScheduledActivations. >> >> >> I would be still happy, if someone could help me. >> >> Thanks, >> >> Philipp >> >> >> 2012/9/3 Philipp Herzig <pherzig(a)gmail.com&gt;: >> > Alright, one step further. >> > >> > I retrieved the current agenda via >> > >> > InternalAgenda agenda = ((AgendaImpl)session.getAgenda()).getAgenda(); >> > >> > before marshalling and after unmarshalling. >> > Now its great, all my example ScheduledActivations are successfully >> > unmarshalled to the agenda. However, they are not fired for some >> > reason? >> > I call fireAllRules after recreating the session. >> > >> > Sorry for spaming but I hope this helps someone to get me into the >> > right direction. >> > >> > Thanks again, >> > >> > Philipp >> > >> > >> > >> > ---------- Forwarded message ---------- >> > From: Philipp Herzig <pherzig(a)gmail.com&gt; >> > Date: 2012/9/3 >> > Subject: Re: Protobuf Marshaller Question (ScheduledActivation >> > Persistence) >> > To: Rules Users List <rules-users(a)lists.jboss.org&gt; >> > >> > >> > Maybe one addition to that. Currently I am working on 5.4.0.CR1 but >> > same applies to me for all versions until 5.3.2.Final including >> > 5.4.0.Final (since obviously the protobuf impl has been introduced in >> > 5.3.2). >> > >> > Thanks again, >> > >> > Philipp >> > >> > 2012/9/3 Philipp Herzig <pherzig(a)gmail.com&gt;: >> >> Dear developers, >> >> >> >> I believe this is a question for Edson. >> >> >> >> I wonder if ScheduledActivations are added to the Agenda when >> >> unmarshalling an existing session and fired as well, e.g., non-expired >> >> timers. >> >> >> >> I guess that this worked with the DefaultMarshaller implementation (at >> >> least I can see LOCs in the InputMarshaller where normal or scheduled >> >> activations are added to the newly created agenda). I cannot find >> >> similar code in the ProtobufMarshaller or, more precisely, the >> >> ProtobufInputMarshaller. >> >> >> >> I also tried to override MarshallerProvider in order to use the >> >> DefaultMarshaller but that is obviously not-consistent >> >> (ClassCastException) with the current codebase anymore. >> >> >> >> Hopefully, I am doing/understanding sth. completely wrong here. >> >> >> >> Thanks for any help regarding this issue, >> >> >> >> Philipp >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss by Red Hat @ www.jboss.com > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users >