[jbossseam-issues] [JBoss JIRA] Assigned: (JBSEAM-3622) SFSB not removed from session when temporary conversation ends

Norman Richards (JIRA) jira-events at lists.jboss.org
Tue Oct 28 14:34:21 EDT 2008


     [ https://jira.jboss.org/jira/browse/JBSEAM-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Norman Richards reassigned JBSEAM-3622:
---------------------------------------

    Assignee: Norman Richards


> SFSB not removed from session when temporary conversation ends
> --------------------------------------------------------------
>
>                 Key: JBSEAM-3622
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-3622
>             Project: Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.3.CR1, 2.1.0.GA
>         Environment: JBoss 4.2.2, Seam 2.0.3.CR1
>            Reporter: Nikolay Elenkov
>            Assignee: Norman Richards
>            Priority: Critical
>             Fix For: 2.1.1.CR1
>
>
> I came across this while checking my app for session leaks. I used a simple listener that dumps session attributes on every add/remove/replace.
> When I end a conversation, all entities are removed from the session, as expected. However, manager components (SFSB's) are left over. Repeatedly starting and ending a conversation results in something like (17, 18, 19 have ended, all other attributes for those conversations have been removed from session; 20 is active): 
> 20:11:12,440 INFO  [STDOUT] org.jboss.seam.CONVERSATION#17$userManager
> 20:11:12,440 INFO  [STDOUT] org.jboss.seam.CONVERSATION#18$userManager
> 20:11:12,440 INFO  [STDOUT] org.jboss.seam.CONVERSATION#19$userManager
> 20:11:12,440 INFO  [STDOUT] org.jboss.seam.CONVERSATION#20$userManager
> 20:11:12,440 INFO  [STDOUT] org.jboss.seam.CONVERSATION#20$user
> I stepped through this with the debugger, and it seems that SFSB's are not removed if the conversation is a temporary one.
> Here's what (I think) happens:
>    1. Conversation ended by @End or pages.xml
>    2. SFSB's @Remove @Destroy destroy() method is called
>    3. RemoveInterceptor calls ServerConversationContext#remove(). That results in the component's name being added to ServerConversationContext#removals.
>     4. When ServerConversationContext#flush() is called, names in the removals list are not actually removed from the session, because the conversation is temporary (see *** below)
> from ServerConversationContext.java:
>  public void flush()
>    {      
>       boolean longRunning = !isCurrent() || Manager.instance().isLongRunningConversation();  
>           
>       if ( longRunning )
>       {
>         // ....
>       }
>       else
>       {
>          //TODO: for a pure temporary conversation, this is unnecessary, optimize it
>          // *** Here: getNamesFromSession does not include removals, so they are left over
>          // Should probably be like this:
>          
>          // START
>          for (String name: removals) {
>               session.remove(getKey(name));
>          }
>          removals.clear();
>          // END
>          for ( String name: getNamesFromSession() )
>          {
>             session.remove( getKey(name) );
>          }
>       }
>    }
>  private Set<String> getNamesFromSession()
>  {
>      HashSet<String> results = new HashSet<String>();
>      String prefix = getPrefix(getId());
>      for (String name: session.keySet()) {
>          if (name.startsWith(prefix)) {
>              name = name.substring(prefix.length());
>              if (!removals.contains(name)) { // *** Here: name not added to results if in the removals list
>                  results.add(name);
>              }
>          }
>      }
>      return results;
>  }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the seam-issues mailing list