[#SWF-354] Reloading classes of objects stored in a flow execution scope results in exception - Spring Projects Issue Tracker

Spring Web Flow

Reloading classes of objects stored in a flow execution scope results in exception

Created: 23/Jul/07 08:30 AM Updated: 13/Oct/08 10:30 AM

Component/s:

Core: Flow Execution Repository

Affects Version/s:

2.0 M1

Fix Version/s:

3.0.0

Time Tracking:

Not Specified

Issue Links:

Related

This issue is related to:

SWF-90 Add the ability to monitor in-progress flow executions with JMX

Description

« Hide

Currently if you reload a class that exists in flow/flash/conversation scope the exception below is triggered. This is problematic as it can only be corrected by a server restart. I'm not sure what can be done to workaround the cause of the problem but as workaround it would as a minimum be useful to have the ability to clear or invalidate the flow executions that currently exist in the repository with something like:

{code}
flowRepository.invalidateAll()
{code}

The Exception:

org.springframework.webflow.execution.repository.FlowExecutionRestorationFailureException: A problem occurred restoring the flow execution with key '_c14EB16BC-4442-78AA-139F-54EEA1B24085_k36AE12C7-23F1-602D-96A0-9A0145494C97'; nested exception is org.springframework.webflow.execution.repository.continuation.ContinuationUnmarshalException: IOException thrown deserializing the flow execution stored in this continuation -- this should not happen!; nested exception is java.io.InvalidClassException: BookService; local class incompatible: stream classdesc serialVersionUID = 7711171070262397453, local class serialVersionUID = 1780216400904263477 Caused by: org.springframework.webflow.execution.repository.continuation.ContinuationUnmarshalException: IOException thrown deserializing the flow execution stored in this continuation -- this should not happen!; nested exception is java.io.InvalidClassException: BookService; local class incompatible: stream classdesc serialVersionUID = 7711171070262397453, local class serialVersionUID = 1780216400904263477 Caused by: java.io.InvalidClassException: BookService; local class incompatible: stream classdesc serialVersionUID = 7711171070262397453, local class serialVersionUID = 1780216400904263477 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)

Description

Currently if you reload a class that exists in flow/flash/conversation scope the exception below is triggered. This is problematic as it can only be corrected by a server restart. I'm not sure what can be done to workaround the cause of the problem but as workaround it would as a minimum be useful to have the ability to clear or invalidate the flow executions that currently exist in the repository with something like: {code} flowRepository.invalidateAll() {code} The Exception: org.springframework.webflow.execution.repository.FlowExecutionRestorationFailureException: A problem occurred restoring the flow execution with key '_c14EB16BC-4442-78AA-139F-54EEA1B24085_k36AE12C7-23F1-602D-96A0-9A0145494C97'; nested exception is org.springframework.webflow.execution.repository.continuation.ContinuationUnmarshalException: IOException thrown deserializing the flow execution stored in this continuation -- this should not happen!; nested exception is java.io.InvalidClassException: BookService; local class incompatible: stream classdesc serialVersionUID = 7711171070262397453, local class serialVersionUID = 1780216400904263477 Caused by: org.springframework.webflow.execution.repository.continuation.ContinuationUnmarshalException: IOException thrown deserializing the flow execution stored in this continuation -- this should not happen!; nested exception is java.io.InvalidClassException: BookService; local class incompatible: stream classdesc serialVersionUID = 7711171070262397453, local class serialVersionUID = 1780216400904263477 Caused by: java.io.InvalidClassException: BookService; local class incompatible: stream classdesc serialVersionUID = 7711171070262397453, local class serialVersionUID = 1780216400904263477 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)

Show »

Sort Order:

[ Permalink | « Hide ]

Erwin Vervaet added a comment - 24/Jul/07 02:32 AM

The problem is that the object in the serialized continuation snapshot still refers to the old class, before it was updated. We have seen this issue before and I'm not sure there is much we can do about it.

Objects in conversation scope should not suffer from this since they are not inside the continuation snapshot -- i.e. they are not serialized out.

A simple work around is to restart your browser: this will make sure you get a new session, and avoids hitting the old, 'corrupt' snapshots.

[ Permalink | « Hide ]

Graeme Rocher added a comment - 24/Jul/07 03:51 AM

As I mentioned in the post, a workaround from my perspective would be to be able to invalidate all serialized flows stored in the repository. This is the fix I need to get this working without browser/server restarts

[ Permalink | « Hide ]

Erwin Vervaet added a comment - 25/Jul/07 05:06 AM

Do you think a 'clear' call via JMX would be sufficient? SWF-90 is asking for something like that.

[ Permalink | « Hide ]

Graeme Rocher added a comment - 25/Jul/07 08:27 AM

So you want users to clear flows via some JMX management console? No I need a programmatic way to do it.

[ Permalink | « Hide ]

Antranig Basman added a comment - 12/Sep/07 07:55 PM

The particular root exception class seems "highly recognisable", and it would seem reasonably straightforward to diagnose this situation by walking the "cause" stack and invalidate just the *particular* continuation snapshot that is involved. I'm interested though in how you are managing to reload the class without reloading the entire webapp - do you have Spring held at some higher ClassLoader level?