[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Marco Rietveld commented on JBRULES-3237: ----------------------------------------- The null pointer is being thrown because: 1. The OutputMarshaller is now writing the InitialFactNode. (See JBRULES-3209). 2. When the InputMarshaller tries to unmarshall a marshalled session that contains one (InputMarshaller, ll. 231-242), a NPE is thrown because a {{InitialFact_ObjectType}} ObjectTypeNode can not be found. -- 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

[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Marco Rietveld updated JBRULES-3237: ------------------------------------ Attachment: UnmarshallingTest.java The attached UnmarshallingTest test can be run in the drools-compiler module. It's a copy of the MarshallingTest with some minor modifications to illustrate this bug. -- 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

[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Marco Rietveld updated JBRULES-3237: ------------------------------------ Description: A marshalled ReteooStatefulSession can not be unmarshalled if it contains an InitialFactHandle node. This bug started appearing because of this change: https://github.com/droolsjbpm/drools/commit/0a3575e8073f2abc035b13e113814... {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). - https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/jav... 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} was: A marshalled ReteooStatefulSession can not be unmarshalled if it contains an InitialFactHandle node. A NullPointerException is thrown here: {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

[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Marco Rietveld updated JBRULES-3237: ------------------------------------ Affects Version/s: 5.3.0.CR1 -- 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

[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Marco Rietveld updated JBRULES-3237: ------------------------------------ Description: 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/0a3575e8073f2abc035b13e113814... {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). - https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/jav... 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} was: A marshalled ReteooStatefulSession can not be unmarshalled if it contains an InitialFactHandle node. This bug started appearing because of this change: https://github.com/droolsjbpm/drools/commit/0a3575e8073f2abc035b13e113814... {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). - https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/jav... 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

[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Edson Tirelli commented on JBRULES-3237: ---------------------------------------- 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? -- 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

[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Edson Tirelli reassigned JBRULES-3237: -------------------------------------- Assignee: Edson Tirelli (was: Marco Rietveld) -- 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

[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Marco Rietveld edited comment on JBRULES-3237 at 11/5/11 6:25 AM: ------------------------------------------------------------------ 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 engine 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. was (Author: marco.rietveld): 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. -- 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

[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Edson Tirelli commented on JBRULES-3237: ---------------------------------------- Marco, I am not sure I understand the problem "in the jBPM side". Why not serialize the kbase with the session if that is the case? Also, we can add a callback to the kbase, so that it notifies the application every time the internal state changes. The application can then serialize the kbase once and do it again only when necessary. Using the signature it is possible to keep the record of which session was serialized with which kbase. I am not sure what you mean by "Drools also has this issue"? -- 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

[ https://issues.jboss.org/browse/JBRULES-3237?page=com.atlassian.jira.plug... ] Edson Tirelli resolved JBRULES-3237. ------------------------------------ Fix Version/s: 5.4.0.Beta1 Resolution: Done After discussing the issue with Mark and Kris, the conclusion was to implement the simple fix as suggested by Marco in the description of this ticket, in order to fix the broken tests in persistence. Later, under a different ticket, we will implement the other features, including kbase signing and the session scoped cache for object types. Closing this ticket. Please let me know if you still face any problems. -- 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