12:07 p.m.
JMS Topic subscriptions never released
--------------------------------------
Key: JBSEAM-2082
URL: http://jira.jboss.com/jira/browse/JBSEAM-2082
Project: JBoss Seam
Issue Type: Bug
Components: Remoting
Affects Versions: 2.0.0.CR2, 2.0.0.CR1, 1.2.1.GA, 1.2.0.GA, 2.0.0.GA
Environment: JBossAS 4.2.0.GA, All platforms.
Reporter: Scott McNab
Assigned To: Shane Bryzak
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:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:55 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Scott McNab updated JBSEAM-2082:
--------------------------------
Environment: JBossAS 4.2.3.GA, All platforms. (was: JBossAS 4.2.0.GA, All
platforms. )
Affects Version/s: 2.0.2.SP1
We have (finally!) developed a workaround to this problem: it involves extending the
SeamListener to unsubscribe any JMS subscribers that are still active whenever a Session
is destroyed. This way we can guarantee that all Seam JMS sessions are eventually closed
when they are no longer in use.
The code for our custom SeamListener class is as follows (we also modify the web.xml to
use our custom listener instead of the standard one):
public class CustomSeamListener extends SeamListener {
@Override
public void sessionDestroyed(HttpSessionEvent event) {
// Fake a HttpServletRequest that unsubscribes all the tokens associated with this
session
HttpServletRequest req = new MockHttpServletRequest(event.getSession());
ServletLifecycle.beginRequest(req);
ServletContexts.instance().setRequest(req);
// Take a copy of the token list so we don't modify the list as we are iterating
SubscriptionRegistry subRegistry = SubscriptionRegistry.instance();
Set<String> tokenSet = new HashSet<String>();
tokenSet.addAll(subRegistry.getUserTokens());
// Unsubscribe all the subscriptions associated with this session
for (String token : tokenSet) {
RemoteSubscriber subscriber = subRegistry.getSubscription(token);
subscriber.unsubscribe();
}
ServletLifecycle.endRequest(req);
// Call the normal SeamListener implementation
super.sessionDestroyed(event);
}
}
Can we please get a comment on the validity of this workaround? (Specifically, is there a
better way to access the SubscriptionRegistry other than using the MockHttpServletRequest
like this?)
Also, if this is indeed a valid fix, could we please get it integrated into the official
SeamListener source code?
Thanks
Scott
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: Shane Bryzak
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
8:17 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Tihomir Surdilovic updated JBSEAM-2082:
---------------------------------------
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: Shane Bryzak
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
5:12 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Shane Bryzak commented on JBSEAM-2082:
--------------------------------------
Patch looks good to me, I'll try to get it into Seam_2_1 branch this week.
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: Shane Bryzak
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
11:29 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Marek Novotny updated JBSEAM-2082:
----------------------------------
Labels: backport_2_0 (was: )
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: Shane Bryzak
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
7:56 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Scott McNab commented on JBSEAM-2082:
-------------------------------------
How are you going with applying this patch? If it helps, we have also implemented this fix
for Seam 1.2.1.GA.
The example custom SeamListener implementation for Seam 1.2.1.GA is as follows:
public class CustomSeamListener extends SeamListener {
@Override
public void sessionDestroyed(HttpSessionEvent event) {
// Fake a HttpServletRequest that unsubscribes all the tokens associated
with this session
HttpServletRequest request = new
MockHttpServletRequest(event.getSession());
HttpSession session = event.getSession();
ServletContext servletContext = session.getServletContext();
Lifecycle.setPhaseId(PhaseId.INVOKE_APPLICATION);
Lifecycle.setServletRequest(request);
Lifecycle.setServletContext(servletContext);
Lifecycle.beginRequest(servletContext, session, request);
SubscriptionRegistry subRegistry = SubscriptionRegistry.instance();
// Take a copy of the token list so we don't modify the list as we are
iterating
Set<String> tokenSet = new HashSet<String>();
tokenSet.addAll(subRegistry.getUserTokens());
for (String token : tokenSet) {
RemoteSubscriber subscriber = subRegistry.getSubscription(token);
subscriber.unsubscribe();
}
Lifecycle.endRequest();
Lifecycle.setServletRequest(null);
Lifecycle.setPhaseId(null);
// Call the normal SeamListener implementation
super.sessionDestroyed(event);
}
}
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: Shane Bryzak
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
10:24 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Assigned: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Pete Muir reassigned JBSEAM-2082:
---------------------------------
Assignee: Norman Richards (was: Shane Bryzak)
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
10:24 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Pete Muir updated JBSEAM-2082:
------------------------------
Fix Version/s: 2.2.1.CR1
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
9:09 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2082) JMS Topic subscriptions never released
[
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
9:14 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Shane Bryzak commented on JBSEAM-2082:
--------------------------------------
Just an afterthought - for the Seam 3.x changes, it might pay to raise a new JIRA issue
for this. JMS/Remoting support is really only experimental, and could probably benefit
from some extra love.
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
8:41 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
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
8:43 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Resolved: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Norman Richards resolved JBSEAM-2082.
-------------------------------------
Resolution: Done
Assignee: Shane Bryzak (was: Norman Richards)
Marking as reolved and assigning back to Shane just in case he wants to veto or tweak
anything here. I've tested and verified that subscriptions are cleaned up now.
It's just a matter of style and future direction of the components.
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: Shane Bryzak
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
3:21 p.m.
New subject: [JBoss JIRA] Closed: (JBSEAM-2082) JMS Topic subscriptions never released
[
https://jira.jboss.org/jira/browse/JBSEAM-2082?page=com.atlassian.jira.pl...
]
Pete Muir closed JBSEAM-2082.
-----------------------------
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: Shane Bryzak
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
5263
days inactive
6097
days old
12 comments
6 participants
participants (6)
-
Marek Novotny (JIRA) -
Norman Richards (JIRA)
-
Pete Muir (JIRA)
-
Scott McNab (JIRA)
-
Shane Bryzak (JIRA)
-
Tihomir Surdilovic (JIRA)