[rules-users] Protobuf Marshaller Question (ScheduledActivation Persistence)
Philipp Herzig
pherzig at gmail.com
Tue Oct 2 05:45:03 EDT 2012
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 <pherzig at gmail.com>:
> 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 at gmail.com>:
>>
>> 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 at gmail.com> 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 at gmail.com>:
>>> > 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 at gmail.com>
>>> > Date: 2012/9/3
>>> > Subject: Re: Protobuf Marshaller Question (ScheduledActivation
>>> > Persistence)
>>> > To: Rules Users List <rules-users at lists.jboss.org>
>>> >
>>> >
>>> > 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 at gmail.com>:
>>> >> 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
More information about the rules-users
mailing list