Add explicit support for expiring flows and detecting flow expiry [SWF-10]

[spring-operator]

Markus Joschko opened SWF-10 and commented

Currently the flow is simply removed from the session by the cleanup filter without the possibility to do additional cleanup work itself.
It would be very helpful if the flowlistener is called before removing the flow from session.
Even better would be if this could somehow be coupled with a session listener (as the cleanup filter expects that the user performs an additional request).

---

Affects: 1.0 RC4

Issue Links:

• Revise conversation package [SWF-175] #1088 Revise conversation package
  ("depends on")

3 votes, 3 watchers

[spring-operator]

Erwin Vervaet commented

It would indeed be very nice to have an 'expired' event that is signaled to the listeners when a flow execution expires.

However, there are a number of problems when implementing this:

• Using the cleanup filter there is no guarantee when, and even if, the 'expired' event would be triggered since the user needs to do additional requests in the same HTTP session for the filter to be able to expire the flow execution.

• When you're using a continuations based flow execution storage, you actually have multiple physical copies of the same 'logical' flow execution. This could lead to situations where you receive multiple 'expired' events for the same logical flow execution.

• When using client side continuations, the flow execution is actually stored on the client side, so we have no way of managing expiry.

So for the time being this seems problematic to implement in a way that the behaviour would be deterministic. Does anybody have any ideas on how to tackle this elegantly?

[spring-operator]

Erwin Vervaet commented

The cleanup filter no longer exists. The execution repository subsystem uses a conversation manager to store state associated with a logical conversation between the user and the server. It's the conversation manager that's responsible for expiring the state (data) it manages.

So the first bullet in my previous remark is no longer a concern: the conversation manager has full control over how and when it decides to expire flow executions. The current implementations use HTTP session expiry.

The second and the third bullet are also no longer a problem since the there might be multiple flow executions that are all part of the same logical conversation and its the conversation that expires. The conversation is always managed centrally on the server so no problem there.

One thing to keep in mind is what this would given in a clustered environment.

[spring-operator]

Erwin Vervaet commented

This issue can be investigated in the context of the revision of the conversation package implementation.

[spring-operator]

Erwin Vervaet commented

For the time being we're not planning on making drastic enhancements to the simple SessionBindingConversationManager that's currently included in the SWF distribution.

Other parties can provide SWF ConversationManager implementations that provide the features discussed in this issue:

• real conversation expiry (i.e. where the ConversationManager has a thread to monitor and expire conversations)
• listener support to get notifications of conversation expiration
• ...

[spring-operator]

Mircea Deaconu commented

In SessionBindingConversationManager:

// hooks for subclassing

protected ConversationContainer createConversationContainer() {
	return new ConversationContainer(maxConversations, sessionKey);
}

but ConversationContainer is package local. So this "hook" is useless. Can anybody give an example of how to implement a ConversationManager (by subclassing SessionBindingConversationManager for instance) that does some of the above mentioned stuff (sends an expired event to the flow)?