OK Edson, please find the JIRA w/ sources here: https://issues.jboss.org/browse/JBRULES-3644?page=com.atlassian.jirafisheyeplugin:fisheye-issuepanel
Thanks again for your time, Philipp 2012/10/2 Philipp Herzig <[email protected]>: > 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 <[email protected]>: >> >> 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 <[email protected]> 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 <[email protected]>: >>> > 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 <[email protected]> >>> > Date: 2012/9/3 >>> > Subject: Re: Protobuf Marshaller Question (ScheduledActivation >>> > Persistence) >>> > To: Rules Users List <[email protected]> >>> > >>> > >>> > 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 <[email protected]>: >>> >> 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 >>> [email protected] >>> 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 >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users >> _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
