[
https://issues.apache.org/jira/browse/OWB-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919487#action_12919487
]
Martin Kočí commented on OWB-467:
---------------------------------
> I understand what you mean. But this is the problem of application that gets
> exceptions.
I don't agree. Exception in client code cannot lock or damage context. Just
imagine application, session, request, view or flash scope instead of
conversation. You cannot probably say "user, program your client code without
bugs because they can make contexts unavailable".
Or: in example mentioned above put facesContext.responseComplete() instead of
NPE like:
if (i > 10) {
facesContext.responseComplete();
}
this is legal and conversation gets lock too.
> We have conversation cleaner thread in WebContainerLifecycle. It removes
> timedout conversations. So, used and > locked conversations will be timeout
> and
> removed by the container. Therefore no memory leak occurs.
Yes, that is not memory leak, but consider: user of application starts new
conversation (a wizard for example) and creates ConversationContext with size
for example 10M. Then in last step in wizard an exceptions occurs. User starts
wizards again and this new conversation eats new 10M. Its not memory leak but
in such situation you can exhauste memory very fast.
Does anybody other see this problem too or am I missing something important?
What does WELD in this situation?
> Move init/destroy of conversation from phase listener to servlet filter
> -----------------------------------------------------------------------
>
> Key: OWB-467
> URL: https://issues.apache.org/jira/browse/OWB-467
> Project: OpenWebBeans
> Issue Type: Bug
> Components: Context and Scopes
> Affects Versions: 1.0.0-alpha-2
> Environment: OWB trunk
> Reporter: Martin Kočí
> Assignee: Gurkan Erdogdu
> Priority: Critical
>
> OWB code for init/destroy conversation is in a phase listener. It is not
> safe: see http://markmail.org/message/oz7f7jnchwvrcw65. This phase listener
> approach also does not allow conversation for non faces request, but CDI spec
> says: "The conversation scope is active: during all standard lifecycle phases
> of any JSF faces or non-faces request". So this issue is critical for two
> reasons:
> 1) it does not allow conversation for non-faces request (specification says
> it must)
> 2) it can lock conversation forever (or only for timeout period?) and exhaust
> memory with locked conversations
> Proposed solution: move code to servlet filter as discussed at
> http://markmail.org/message/oz7f7jnchwvrcw65
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
