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

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