8:12 p.m.
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> 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>:
> 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>
> Date: 2012/9/3
> Subject: Re: Protobuf Marshaller Question (ScheduledActivation
Persistence)
> To: Rules Users List <rules-users(a)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(a)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(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