Conversation time out bug?

[filipe.amaral]

Hi Guys

I was setting up a simple web project with a @ConversationScoped bean and after begining a conversation I noticed that, by logging the conversation time out value, it stands incorrect with the actual disposal time period of the bean.

I'm currently using WildFly 10.0.0.Final with JDK8 on Windows.

The ouput of my test:

As you can see right after creating the bean, the conversation is started with a default timeout value of 600 seconds. Nevertheless, the bean is destroyed just after 60 seconds, since there was no interaction between client and server in the meantime.

Does my analysis stands correct, or am I missing something?

Best regards,

--Filipe

[mkouba]

Hi Filipe,

what's the session timeout in your application? Conversations are scoped to a particular HTTP servlet session so if an HTTP session is invalidated/times out all the relevant conversations are destroyed as well (no matter what the conversation timeout is). See also 6.7.4. Conversation context lifecycle.

[filipe.amaral]

Thanks Martin, for your answer.

You're right. I got confused with it cause I have the session timeout of 1 minute in my web.xml definitions. Feeling quite embarassed now for missing it

Nevertheless, if I got it right, the conversation timeout will kick in if lesser than that of the HTTP session one, right?

Kind regards,

--Filipe Amaral

[mkouba]

Yes, except that the timeout is just a hint for the container, i.e. the conversation does not necessarily have to be destroyed right after it times out. In Weld, if a conversation times out it is destroyed during the processing of the next HTTP request associated with the same HTTP session.