[jboss-jira] [JBoss JIRA] (JBRULES-3237) Unmarshalling a marshalled session fails when using a newly initialized knowledgebase

Edson Tirelli (Issue Comment Edited) (JIRA) jira-events at lists.jboss.org
Fri Nov 4 16:29:45 EDT 2011


    [ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640496#comment-12640496 ] 

Edson Tirelli edited comment on JBRULES-3237 at 11/4/11 4:29 PM:
-----------------------------------------------------------------

Marco,

I think there are a few problems here that we need to address. 

First, the test and usage of the kbase is not correct. A session can only be de-serialized using the same kbase it had when it was serialized. Using a different kbase is not safe and will usually lead to problems as the one reported in this ticked. Line 58 of the test is creating a new kbase:

{code}
        knowledgeBase = initializeKnowledgeBase( whenBenNotVilgaxRule );
{code}

While the kbase is created from the same rules, there is no guarantee that the content will be the same, and in fact it is not. The correct would be to serialize the kbase as well and when deserializing, deserialize both the kbase AND the session. E.g., replacing line 58 of your test by the following makes it work:

{code}
        knowledgeBase = SerializationHelper.serializeObject( knowledgeBase );
{code}

In the above code, the serialization helper is just serializing the kbase and deserializing it again.

Now, the problem that I think we have to fix is that we should "sign" the kbase during the serialization of the session and whenever trying to deserialize a session with a different kbase, we should raise an error with appropriate message instead of raising a NPE.

Do you agree?
                
      was (Author: tirelli):
    Marco,

I think there are a few problems here that we need to address. 

First, the test and usage of the kbase is not correct. A session can only be de-serialized using the same kbase it had when it was serialized. Using a different kbase is not safe and will usually lead to problems as the one reported in this ticked. Line 58 of the test is creating a new session:

        knowledgeBase = initializeKnowledgeBase( whenBenNotVilgaxRule );

While the kbase is created from the same rules, there is no guarantee that the content will be the same, and in fact it is not. The correct would be to serialize the session as well and when deserializing, deserialize both the kbase AND the session. E.g., replacing line 58 of your test by:

        knowledgeBase = SerializationHelper.serializeObject( knowledgeBase );

Where if you check the code, the serialization helper is just serializing the kbase and deserializing it again.

Now, the problem that I think we have is that we should "sign" the kbase during the serialization of the session and whenever trying to deserialize a session with a different kbase, we should raise an error with appropriate message instead of raising a NPE.

Do you agree?
                  
> Unmarshalling a marshalled session fails when using a newly initialized knowledgebase
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3237
>                 URL: https://issues.jboss.org/browse/JBRULES-3237
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.3.0.CR1
>            Reporter: Marco Rietveld
>            Assignee: Marco Rietveld
>         Attachments: UnmarshallingTest.java
>
>
> A marshalled ReteooStatefulSession can not be unmarshalled if it contains an InitialFactHandle node _and_ if the knowledge base has been reinitialized. 
> This bug started appearing because of this change: 
> https://github.com/droolsjbpm/drools/commit/0a3575e8073f2abc035b13e11381464e5ac17306#diff-4
> {code}
> -    public static final ClassObjectType InitialFact_ObjectType = new ClassObjectType( InitialFact.class );
> +    public static final ClassObjectType InitialFact_ObjectType = new ClassObjectType( InitialFactImpl.class );
> {code}
> As far as I can tell, the above change caused the following:
> 1. The OutputMarshaller now marshalls the InitialFactnode: the following line now returns a non-null object, which causes the subsequent if clause to run (which wasn't happening before). 
> Approximately here: 
> - https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/java/org/drools/marshalling/impl/OutputMarshaller.java#L475
> {code}
> ObjectTypeNode initialFactNode = ruleBase.getRete().getEntryPointNode( EntryPoint.DEFAULT ).getObjectTypeNodes().get( ClassObjectType.InitialFact_ObjectType );
> {code}
> 2. When the InputMarshaller tries to unmarshall a marshalled session and it's using a (new) ruleBase that doesn't contain an ObjectTypeNode that descibes the {{InitialFact_ObjectType}}, then a NPE is thrown. 
> - This is caused because the sinks that are given to the {{MarshallerReaderContext}} (used in InputMarshaller.readSession) do not contain the {{InitialFact_ObjectType}}. 
> - These sinks: 
> -- come from KnowledgeBaseImpl.ruleBase which
> --- contains a .rete attribute which
> ---- contains .entrypoints (Map<EntryPoint, EntryPointNode> which
> ----- contains EntryPointNode's which
> ------ contains objectTypeNodes (Map<ObjectType, ObjectTypeNode>) which
> ------- contain objectTypeNodes
> -------- which _should_ contain a ObjectTypeNode describing the InitialFactNode. 
> I can't figure out where to add this information when initializing the KnowledgeSession or KnowledgeBase for unmarshalling -- or whether the unmarshalling process should take care of this. 
> The NPE is thrown here (the {{node}} variable at line 65 is null):  
> {code}
> ConcurrentNodeMemories.getNodeMemory(NodeMemory) line: 65	
> ReteooStatefulSession(AbstractWorkingMemory).getNodeMemory(NodeMemory) line: 1018	
> InputMarshaller.readSession(ReteooStatefulSession, DefaultAgenda, long, boolean, MarshallerReaderContext) line: 237	
> InputMarshaller.readSession(MarshallerReaderContext, int, ExecutorService, Environment, SessionConfiguration) line: 209	
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the jboss-jira mailing list