[seam-issues] [JBoss JIRA] (JBSEAM-4863) Memory Leak when calling @Destroy (with SFSBs)
Marek Novotny (JIRA)
jira-events at lists.jboss.org
Mon Sep 24 16:03:43 EDT 2012
[ https://issues.jboss.org/browse/JBSEAM-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marek Novotny closed JBSEAM-4863.
I am closing the issue. All issues has to be filed against 2.3.0.Final from now.
> Memory Leak when calling @Destroy (with SFSBs)
> Key: JBSEAM-4863
> URL: https://issues.jboss.org/browse/JBSEAM-4863
> Project: Seam 2
> Issue Type: Bug
> Affects Versions: 2.2.2.Final
> Environment: JBoss AS 5.1.0.GA
> Reporter: Daniel Lechner
> Assignee: Vaclav Dedik
> Labels: conversation, destroy
> Fix For: 2.3.0.CR1
> Attachments: JBSEAM-4863.zip
> Original Estimate: 3 days
> Remaining Estimate: 3 days
> In an example-project, we have 2 Seam components, one POJO and one SFSB. The POJO-component uses the SFSB-component via Seam-DI (@In). The POJO-component has a method annotated with @Destroy.
> We are using the POJO-component in a (long-running-)conversation. So the POJO-component as well as the SFSB-component will be created within the conversation.
> When the conversation ends and all components will be removed, the @Destroy-methods of all seam-components are called one after each other. The order, the @Destroy-methods are called, depend on the hashCode of the seam-name of the components (the component-names are put into an java.util.HashSet in the method org.jboss.seam.contexts.ServerConversationContext.getNamesFromSession() - the for-loop of the method org.jboss.seam.contexts.Contexts.destroy iterates through this HashSet afterwards).
> If the component-names are chosen this way, that the SFSB-component will be removed before the POJO-component is removed, a memory leak occurs:
> 1. the SFSB-component is destroyed by seam - the container removes the SFSB (the @Remove-method of the SFSB is called)
> 2. the @Destroy-method of the POJO-component is called. But before, Seam-DI creates a new SFSB-component TestEJB because of the @In-annotation
> 3. the POJO-component is removed from the conversation (and later by the GC)
> 4. the SFSB-component's @Remove-method is not called again - the container keeps the SFSB-instance
> An example-code can be found in the forum reference
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the seam-issues