[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Shane Bryzak commented on JBSEAM-2082:
--------------------------------------
Just an update - the workaround looks acceptable, although as mentioned it would be nice
to avoid using MockHttpServletRequest - I'm sure we can lookup the
SubscriptionRegistry directly from the session (by wrapping it in a Context).
This still needs to be tested with a real example, although I'm bogged down with TCK
work right now. Norman if you have a chance could you please try this patch out with the
chatroom example. If it all looks ok, then the patch can be directly applied to
SeamListener. We will also need to apply it to the Seam 3.x remoting module.
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