[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2082) JMS Topic subscriptions never released

Tue Aug 4 14:41:29 EDT 2009

    [ https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12478909#action_12478909 ] 

Norman Richards commented on JBSEAM-2082:
-----------------------------------------

I think adding this to SessionListener is wrong.  I've added a session-scoped UserTokens component which handles cleanup in the @Destroy method.  It works well or the chatroom example, though I would note that there is application-level cleanup of the users list that doesn't happen on session timeout.  However, that is an issue with the example and not with the underlying Seam code, which I have verified gets cleaned up ok.

> JMS Topic subscriptions never released
> --------------------------------------
>
>                 Key: JBSEAM-2082
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-2082
>             Project: Seam
>          Issue Type: Bug
>          Components: Remoting
>    Affects Versions: 1.2.0.GA, 1.2.1.GA, 2.0.0.CR1, 2.0.0.CR2, 2.0.0.CR3, 2.0.2.SP1
>         Environment: JBossAS 4.2.3.GA, All platforms. 
>            Reporter: Scott McNab
>            Assignee: Norman Richards
>             Fix For: 2.2.1.CR1
>
>
> In the current Seam remoting implementation, there is no mechanism to clean up and release JMS topic subscriptions for clients that may have subscribed to a JMS topic, but who do not explicitly unsubscribe()  (e.g. due to a coding error or if the client simply disappears)
> Unless a web-client specifically calls Seam.Remoting.unsubscribe(), the RemoteSubscriber object is never released, and the corresponding TopicSession and TopicSubscriber resources will be held open indefinitely. This will cause the JMS provider to store an ever-growing list of undelivered topic messages, which will eventually result in an out of memory crash.
> Seam Remoting needs to be able to correctly identify situations whereby a RemoteSubscriber is no longer in use, and release resources accordingly.
> One possible solution might be to periodically check all subscriptions in the SubscriptionRegistry and release any which have not had a recent poll request beyond a certain time limit.

-- 
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