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

Marco Rietveld (Commented) (JIRA) jira-events at lists.jboss.org
Sat Nov 5 06:25:45 EDT 2011


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

Marco Rietveld commented on JBRULES-3237:
-----------------------------------------


On one hand, that makes sense on the Drools side: "sign"ing the kbase during serialization/persistence would make sure that an appropriate message is thrown. 

On the jBPM side, this is a problem, at the very least because of the problem described in JBPM-3383: an appserver restart when not all processes have been completed. The server that the jBPM server runs on, needs to be able to recover correctly from a crash, and thus be able to restart processes -- which includes unmarshalling/deserializing a session without being able to access the knowledgeBase instance used to serialize the session. 

Given the, well, procedural nature of jBPM, I also have the strong suspicion that there are also other cases (besides a server restart) in which this occurs. Unfortunately, I don't know enough about the jBPM 5 engine yet to say with any certainty (question for Kris?).  

This might just mean that we need to serialize/marshall the knowledgeBase in the jbpm persistence code.. 

(Although I'm curious as to whether or not Drools also has this issue?) 

----

One thing that would, regardless, help me very much is adding a (transient) KnowledgeBase field to the SessionInfo object. Would that be possible? 

The reason that this would help is because we want to test the backward compatibility of marshalling in jBPM. The test framework that I've written to do this hooks into persistence and makes a copy of all marshalled information that's persisted. However, given that I need the same knowledgeBase instance to _unmarshall_ the information later (when comparing and checking backwards compatibility), I need some way to grab the knowledgeBase out of the SessionInfo instance and save it for later use when my "persistence hook"[1] saves the marshalled session information. 

[1] The test framework works by supplying a proxyied EntityManager and EntityManagerFactory to unit tests. The proxy classes ensure that whenever a persistence operation is called, the marshalled information is extracted, uniquely identified and saved for later. When the unit test is then run later, the marshalled information "snapshots" are compared against the snapshots that the same unit test in previous versions of jBPM have generated.  


                
> 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: Edson Tirelli
>         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