Is the action in a @ConversationScoped bean or not?
Yes, i should have mentioned that. Its @Stateful and @ConversationScoped.
In the action i can inject the conversation object and read and play with its properties.
Having downloaded sources and doing a bit of debugging it looks to me like the expiring of conversations only takes place after the JSF Lifecycle has completed which would explain this behaviour.
I am on AS7 which uses Mojarra 2.1.7 and Weld 1.1.5.AS71.Final
I find it hard to beleive that this is the desired behaviour. There must be a call to expire conversations before the JSF lifecyle kicks in must'nt there?
1 of 1 people found this helpful
Max, this is a bug in Weld.
Weld destroys expired conversations at the end of a request. Say we have the following scenario:
1. perform request that starts a conversation and sets conversation timeout to 1ms
2. wait for more than 1ms
3. perform request in that same conversation
During #3 the conversation is still active and will only be destroyed after the request is finished. So if #3 issues a redirect, the NonExistentConversationException will occur immediately after the redirect.
If you were to issue another request (let's call it #2b) between #2 and #3, but not in the same conversation, your initial conversation would be destroyed at the end of #2b and you wouldn't have this problem.
The fact that Weld allows the application to use the conversation in a request and then immediately destroys it, violates a part of section 6.7.4 of the CDI spec which states:
The conversation timeout, which may be specified by calling Conversation.setTimeout() is a hint to the container that
a conversation should not be destroyed if it has been active within the last given interval in milliseconds.
Since Weld has just allowed you to use the conversation, the conversation should be considered active and the timeout counter should have been reset.
Ok. Should I create a bug in Jira then?
I think that i can have a go at resolving it... if i manage it i'll make a pull request on github. It looks like the code that activates conversations in the 2.0 branch is the same.
I think that there are two issues to address
1) When conversations are activated an expires check should be implemented.
2) When conversations are activated they should be "touched" to update their last access date.
Does this sound accurate?
I've already created the issue in jira. See https://issues.jboss.org/browse/WELD-1452
Go ahead and try to fix it.
Since the conversation is already touched at the end of a request, all you need to do is make sure the expiration check is performed at the start of the request. It should probably check only the current conversation. Currently, all the conversations in the same session are destroyed at the end of a request. In order to keep the changes to a minimum, I'd only add the expiration check for the current conversation to the beginning of the request and leave the expiration check for other (non-current) conversations at the end for now.
>>all you need to do is make sure the expiration check is performed at the start of the request
This fix will certainly help with "page locking" I get when a conversation has timed out and the user presses any, of numerous, buttons.