Incorrect serialization of Drools STREAM KieSession with expirable events causes NPE

+++ This bug was initially created as a clone of Bug #1118449 +++

Platform BZ for Jira https://issues.jboss.org/browse/DROOLS-551

There is an issue in Drools 6, both in PHREAK and RETEOO mode, which causes NPEs to be thrown when a session is serialized and deserialized.
The problem occurs when running a stateful KieSession in STREAM mode and using Events with @expires annotations. When you insert an event with an @expires annotation, and you explicitly retract that Event again from the engine (i.e. KieSession.delete), and after that serialize the session, you end up with an invalid serialized session.

When you later deserialize the session, and immediately serialize it again, a NPE is thrown at: org.drools.core.reteoo.ObjectTypeNode$ExpireJobContextTimerOutputMarshaller.serialize(ObjectTypeNode.java:669). When you deserialize the session and then advance the pseudo clock to a moment where the original event (which we've already retracted from the working memory) should have expired, a NPE is thrown at: org.drools.core.common.AbstractWorkingMemory$WorkingMemoryReteExpireAction.execute(AbstractWorkingMemory.java:1524)

So, it seems that when the Event is explicitly retracted with KieSesion.delete(event), the event is removed from the WM, but the Expiry Timer Job is not. That ExpiryJob gets serialized with a 'null' fact handle, which does not give issues on de-serialization, but on the next serialization of the session, or when an action is peformed that triggers the expire action (i.e. move the pseudo-clock).

A reproducer can be found here: http://www.github.com/DuncanDoyle/DroolsSerializationIssue . To reproduce:

git clone http://www.github.com/DuncanDoyle/DroolsSerializationIssue
cd DroolsSerializationIssue/DroolSerializationIssue
mvn clean test -P phreak (runs the test with Drools in PHREAK mode)
mvn clean test -P reteoo (runs the test with Drools in RETEOO mode)

In both modes 2 of the 3 tests produce an NPE.

— Additional comment from Alessandro Lazarotti on 2014-07-10 14:08:06 EDT —

I know that it is fixed in Master, but keep it opened because customer can request it to roll up patch

— Additional comment from Mario Fusco on 2014-07-11 02:44:45 EDT —

Fixed by https://github.com/droolsjbpm/drools/commit/ccd415f20

— Additional comment from Alessandro Lazarotti on 2014-07-11 09:39:50 EDT —

Hi Mario,

I am including this BZ in a Roll Up patch and One-off patch release.
So, could you please backport it to 6.0.x branch asap ?
Thanks,
Alessandro

— Additional comment from Mario Fusco on 2014-07-11 09:47:37 EDT —

Cherry-picked to 6.0.x with https://github.com/droolsjbpm/drools/commit/7b1331c26