[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- I'm checking the server with Cacti and the script I wrote does not use cookies to re-use existing sessions. So every minute Cacti creates a session that expires after 30 minutes. Seeing that the push system creates enormous amounts of MessageData objects it looks like the expired sessions are still sent a push event that then is never destroyed. I'll see if I can create a test-case for this hypothesis. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- I created a testcase in which I push an event every two seconds. I see that a org.richfaces.application.push.MessageData object is created every two seconds for every logged on session. The objects are never killed and stay there forever. Somehow the production environment reaches a state that a couple a hundred objects are created for each push request. And because I'm using the push system in a couple of places the result is that about 2000 objects are created every minute. Also in the test environment the number of objects never declines. The count only increases. In my current situation in production I disabled a couple of push generators and with only one left I see 363 new MessageData objects every push moment. There are 34 session from which there are 27 active. So on average instead of one object per session I see about 11 objects per session for each push event. Conclusions: - cleanup system fails completely - listener registration faulty And it could still be that I'm using push the wrong way... Do I need to consume events? MAG, Milo van der Zee -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- /** * Send push events to configured topics. */ public class PushTriggerJob implements BatchJobInterface { private static final Logger LOGGER = Logger.getLogger(PushTriggerJob.class); @Override public void executeBatch(BatchJobContext context) { String[] pushKeys = context.getParameters().trim().split(","); TopicsContext topicsContext = TopicsContext.lookup(); boolean first = true; for (String pushKey : pushKeys) { if (!first) { // delay 1 second for all except the first one Utils.sleep(1000); } first = false; try { LOGGER.debug("triggerPush: pushing '" + pushKey + "' topicsContext: " + topicsContext); topicsContext.publish(new TopicKey(pushKey), null); } catch (MessageException e) { LOGGER.error("executeBatch, topicsContext: " + topicsContext, e); } } } } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee edited comment on RF-12219 at 5/14/12 7:30 AM: ---------------------------------------------------------------- {{monospaced}} /** * Send push events to configured topics. */ public class PushTriggerJob implements BatchJobInterface { private static final Logger LOGGER = Logger.getLogger(PushTriggerJob.class); @Override public void executeBatch(BatchJobContext context) { String[] pushKeys = context.getParameters().trim().split(","); TopicsContext topicsContext = TopicsContext.lookup(); boolean first = true; for (String pushKey : pushKeys) { if (!first) { // delay 1 second for all except the first one Utils.sleep(1000); } first = false; try { LOGGER.debug("triggerPush: pushing '" + pushKey + "' topicsContext: " + topicsContext); topicsContext.publish(new TopicKey(pushKey), null); } catch (MessageException e) { LOGGER.error("executeBatch, topicsContext: " + topicsContext, e); } } } } {{monospaced}} was (Author: MilovdZee): /** * Send push events to configured topics. */ public class PushTriggerJob implements BatchJobInterface { private static final Logger LOGGER = Logger.getLogger(PushTriggerJob.class); @Override public void executeBatch(BatchJobContext context) { String[] pushKeys = context.getParameters().trim().split(","); TopicsContext topicsContext = TopicsContext.lookup(); boolean first = true; for (String pushKey : pushKeys) { if (!first) { // delay 1 second for all except the first one Utils.sleep(1000); } first = false; try { LOGGER.debug("triggerPush: pushing '" + pushKey + "' topicsContext: " + topicsContext); topicsContext.publish(new TopicKey(pushKey), null); } catch (MessageException e) { LOGGER.error("executeBatch, topicsContext: " + topicsContext, e); } } } } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee edited comment on RF-12219 at 5/14/12 7:40 AM: ---------------------------------------------------------------- The PushTriggerJob is called by my scheduling system. This job just sends some push events with the configured names. One name is set to 'notificationIconsPush' and updates some notification icons on the client side. I could use a poller for that but a poller generates more view exceptions. In production the PushTriggerJob is triggered every minute. Mind the sleep(1000) because pushing too rapidly results in other problems. You need to give the client time to handle the previous event before sending the next one... But that is not this issue this case is about. In my testcase I changed the interval to every seconds and I configured just one topic address. After logging into the system I start jvisualvm to monitor the memory. There I see that the MessageData objects are never killed during the lifetime of the session. I noticed that after I came back from lunch and all sessions were gone there also was no MessageData object left. {code:title=PushTriggerJob.java} /** * Send push events to configured topics. */ public class PushTriggerJob implements BatchJobInterface { private static final Logger LOGGER = Logger.getLogger(PushTriggerJob.class); @Override public void executeBatch(BatchJobContext context) { String[] pushKeys = context.getParameters().trim().split(","); TopicsContext topicsContext = TopicsContext.lookup(); boolean first = true; for (String pushKey : pushKeys) { if (!first) { // delay 1 second for all except the first one Utils.sleep(1000); } first = false; try { LOGGER.debug("triggerPush: pushing '" + pushKey + "' topicsContext: " + topicsContext); topicsContext.publish(new TopicKey(pushKey), null); } catch (MessageException e) { LOGGER.error("executeBatch, topicsContext: " + topicsContext, e); } } } } {code} {code} <h:form id="notificationIconsUpdateForm"> <a4j:push id="notificationIconsPush" address="notificationIconsPush" ondataavailable="renderNotificationIcons();"/> <a4j:jsFunction id="renderNotificationIcons" name="renderNotificationIcons" render="notificationIcons" limitRender="true"/> </h:form> {code} was (Author: MilovdZee): {code:title=PushTriggerJob.java} /** * Send push events to configured topics. */ public class PushTriggerJob implements BatchJobInterface { private static final Logger LOGGER = Logger.getLogger(PushTriggerJob.class); @Override public void executeBatch(BatchJobContext context) { String[] pushKeys = context.getParameters().trim().split(","); TopicsContext topicsContext = TopicsContext.lookup(); boolean first = true; for (String pushKey : pushKeys) { if (!first) { // delay 1 second for all except the first one Utils.sleep(1000); } first = false; try { LOGGER.debug("triggerPush: pushing '" + pushKey + "' topicsContext: " + topicsContext); topicsContext.publish(new TopicKey(pushKey), null); } catch (MessageException e) { LOGGER.error("executeBatch, topicsContext: " + topicsContext, e); } } } } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- I found that after every click of the user to another view in my application the number of calls to org.richfaces.application.push.impl.SessionImpl.push() is increased by one. So after a day of work the number of calls to push is very large. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- Yes, every page uses a master template with the push in it. The xhtml snippit is from the master template. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee edited comment on RF-12219 at 5/16/12 7:31 AM: ---------------------------------------------------------------- I found that after every click of the user to another view in my application the number of calls to org.richfaces.application.push.impl.SessionImpl.push() is increased by one. So after a day of work the number of calls to push is very large. clearBroadcastedMessages() is called correctly and the messagesQueue is cleared every couple of pushes. In a heapDump I see that MessageData nearest GC root is "ConcurrentLinkedQueue (head JNI global)". This reaches the MessageData through a line of 'next' references. was (Author: MilovdZee): I found that after every click of the user to another view in my application the number of calls to org.richfaces.application.push.impl.SessionImpl.push() is increased by one. So after a day of work the number of calls to push is very large. clearBroadcastedMessages() is called correctly and the messagesQueue is cleared every couple of pushes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- Might be that this is relevant: [ConcurrentLinkedQueue$Node remains in heap after remove()|http://stackoverflow.com/questions/2547161/concurrentlinkedqueue...] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- I debugged some more and I think that there is no check for if the same session is already listening to a channel. I see in PushHandlerFilter that after every tab-switch (other view/page) in my application the pushSessionId changes but the old sessions are still being handled by some other part of the push framework. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- I don't think this is an enhancement request. This is almost a blocking issue for me because I have to restart my server every night... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-12219: --------------------------------- Yeah, /wrt your comments, I consider this critical too, thanks for investigations! Let's look into conceiving patch or we will look at it in 4.3.0.M1 cycle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-12219: --------------------------------- Milo, I can't see the fix right now, I need first reproduce it. I have assigned to Juraj to try reproduce it using the steps you have provided. Once we will know how to reproduce, we will know it has been fixed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee edited comment on RF-12219 at 5/24/12 9:10 AM: ---------------------------------------------------------------- I changed PushResource.java a little and at first glance it seems to do the trick. I realize that my fix/workaround limits the functionality in that all push clients must have different topic names on one page. Don't know if that was the case before my changes. As far as I can see you could use multiple push components listening to the same topic on one page. Not anymore... {code:title="PushResource.java"} public void encode(FacesContext facesContext) throws IOException { ExternalContext externalContext = facesContext.getExternalContext(); PushContextFactory pushContextFactory = ServiceTracker.getService(PushContextFactory.class); // resource plugin stub if (pushContextFactory == null) { return; } PushContext pushContext = pushContextFactory.getPushContext(); String forgetPushSessionId = externalContext.getRequestParameterMap().get(FORGET_PUSH_SESSION_ID_PARAM); if (forgetPushSessionId != null) { Session oldSession = pushContext.getSessionManager().getPushSession(forgetPushSessionId); if (oldSession != null) { oldSession.invalidate(); } } // Session session = pushContext.getSessionFactory().createSession(UUID.randomUUID().toString()); HttpSession httpSession = (HttpSession)externalContext.getSession(false); String sessionId = httpSession.getId(); Session session = pushContext.getSessionManager().getPushSession(sessionId); if (session == null) { session = pushContext.getSessionFactory().createSession(sessionId); } String[] topicNames = externalContext.getRequestParameterValuesMap().get(PUSH_TOPIC_PARAM); if (topicNames == null) { throw new IllegalArgumentException(); } Collection<TopicKey> successfulSubscriptions = session.getSuccessfulSubscriptions(); List<String> newTopicNames = new ArrayList<String>(); for (String topicName : topicNames) { boolean found = false; for (TopicKey topicKey : successfulSubscriptions) { if (topicKey.getTopicName().equals(topicName)) { found = true; break; } } if (!found) { newTopicNames.add(topicName); } } session.subscribe(newTopicNames.toArray(new String[0])); Map<String, Object> subscriptionData = new HashMap<String, Object>(4); subscriptionData.put("sessionId", session.getId()); Map<TopicKey, String> failedSubscriptions = session.getFailedSubscriptions(); subscriptionData.put("failures", getFailuresMap(failedSubscriptions)); Writer outWriter = facesContext.getExternalContext().getResponseOutputWriter(); ScriptUtils.appendScript(outWriter, subscriptionData); } {code} was (Author: MilovdZee): I changed PushResource.java a little and at first glance it seems to do the trick. I realize that my fix/workaround limits the functionality in that all push clients must have different topic names on one page. Don't know if that was the case before my changes. As far as I can see you could use multiple push components listening to the same topic on one page. Not anymore... {code title="PushResource.java"} public void encode(FacesContext facesContext) throws IOException { ExternalContext externalContext = facesContext.getExternalContext(); PushContextFactory pushContextFactory = ServiceTracker.getService(PushContextFactory.class); // resource plugin stub if (pushContextFactory == null) { return; } PushContext pushContext = pushContextFactory.getPushContext(); String forgetPushSessionId = externalContext.getRequestParameterMap().get(FORGET_PUSH_SESSION_ID_PARAM); if (forgetPushSessionId != null) { Session oldSession = pushContext.getSessionManager().getPushSession(forgetPushSessionId); if (oldSession != null) { oldSession.invalidate(); } } // Session session = pushContext.getSessionFactory().createSession(UUID.randomUUID().toString()); HttpSession httpSession = (HttpSession)externalContext.getSession(false); String sessionId = httpSession.getId(); Session session = pushContext.getSessionManager().getPushSession(sessionId); if (session == null) { session = pushContext.getSessionFactory().createSession(sessionId); } String[] topicNames = externalContext.getRequestParameterValuesMap().get(PUSH_TOPIC_PARAM); if (topicNames == null) { throw new IllegalArgumentException(); } Collection<TopicKey> successfulSubscriptions = session.getSuccessfulSubscriptions(); List<String> newTopicNames = new ArrayList<String>(); for (String topicName : topicNames) { boolean found = false; for (TopicKey topicKey : successfulSubscriptions) { if (topicKey.getTopicName().equals(topicName)) { found = true; break; } } if (!found) { newTopicNames.add(topicName); } } session.subscribe(newTopicNames.toArray(new String[0])); Map<String, Object> subscriptionData = new HashMap<String, Object>(4); subscriptionData.put("sessionId", session.getId()); Map<TopicKey, String> failedSubscriptions = session.getFailedSubscriptions(); subscriptionData.put("failures", getFailuresMap(failedSubscriptions)); Writer outWriter = facesContext.getExternalContext().getResponseOutputWriter(); ScriptUtils.appendScript(outWriter, subscriptionData); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Juraj Huska edited comment on RF-12219 at 5/25/12 11:22 AM: ------------------------------------------------------------ So far I have done these steps: 1. altered richfaces showcase example, to have three pushes bound on one topic - can be cloned from branch RF-12219 of this project [here|https://github.com/jhuska/showcase/tree/RF-12219] 2. altered showcase functional tests for push, to open the three push examples in an infinite loop. The whole altered showcase tests repository can be found on branch RF-12219 of [this|https://github.com/jhuska/qa/tree/RF-12219] project The particular test which does this functionality [here|https://github.com/jhuska/qa/blob/RF-12219/showcase-ftest/src/test/j...] To execute that particular test, please follow instructions from [readme|https://github.com/jhuska/qa/tree/master/showcase-ftest]. Just pass {{-Dtest=TestPushTopicsContext}} as a name of the test. 3. via jvisualvm during the test executing verified: - The number of MessageData objects is correctly handled by GC when there is only one push on the topic. - When there are more, and the test is executed, the number of MessageData objects rises up to 53,000. - This amount is not increased any more, the same applies for heap space. - This amount depends on the number of push clients bound on the same topic very slightly, when there were 2 pushes, then the peak of objects was 52,000, when I increased number of pushes to three, the total amount of MessageData increased by 1000 - When just receiving push data to these three examples, the number of MessageData is around 0. It is increased when I am clicking between the samples (this is what the test is trying to do). was (Author: jhuska): So far I have done these steps: 1. altered richfaces showcase example, to have three pushes bound on one topic - can be cloned from branch RF-12219 of this project [here|https://github.com/jhuska/showcase/tree/RF-12219] 2. altered showcase functional tests for push, to open the three push examples in an infinite loop. The whole altered showcase tests repository can be found on branch RF-12219 of [this|https://github.com/jhuska/qa/tree/RF-12219] project The particular test which does this functionality [here|https://github.com/jhuska/qa/blob/RF-12219/showcase-ftest/src/test/j...] To execute that particular test, please follow instructions from [readme|https://github.com/jhuska/qa/tree/master/showcase-ftest]. Just pass {{-Dtest=TestPushTopicsContext}} as a name of the test. 3. via jvisualvm during the test executing verified: - The number of MessageData objects is correctly handled by GC when there is only one push on the topic. - When there are more, and the test is executed, the number of MessageData objects rises up to 53,000. - This amount is not increased any more. - This amount depends on the number of push clients bound on the same topic very slightly, when there were 2 pushes, then the peak of objects was 52,000, when I increased number of pushes to three, the total amount of MessageData increased by 1000 - When just receiving push data to these three examples, the number of MessageData is around 0. It is increased when I am clicking between the samples (this is what the test is trying to do). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Juraj Huska commented on RF-12219: ---------------------------------- I would like to verify further: - why the total is 53,000 for 3 pushes, whether it is because of session closing - run the example for a longer time, like one day and see the problems with memory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- Hello Juraj, thank you very much for the efforts! Besides the real solution, being cleaning up the stale MessageData, I would suggest to limit the number of events in the queue. Why would anybody like to keep very much events in the queue? A couple of hundred should be enough. Or maybe based on age just remove messages older that a couple of seconds or maybe a minute. If a client has not read the event after some time the client is probably gone anyway. Does that testcase mean that you keep on creating clients forever? Like a user connecting and going away immediately without proper logout? In my real-life situation I noticed that if the client does a page-reload from the browser the cleanup seems to function but when I use my ajax page switching I end up with lots of old push sessions that only receive pushes and for which the cleanup code is never called. Just some thoughts: - Why use some random id for the push sessions? Why not just use the http session combined with something like the JSF id of the component? That at least is a lot more static during a use session. For this to be helpful I assume the programmer would configure a static id and doesn't let JSF generate one because those could easily change as well. - I assume there is one global push thread handling the distribution and cleaning up. Somehow this thread decides (based on a timeout) that a push session should be removed from the queue. Somewhere in that code the cleanup of the queue is missed. MAG, Milo -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Juraj Huska commented on RF-12219: ---------------------------------- I have run the test whole night with MAX_INACTIVE_INTERVAL of [SessionImpl|https://github.com/richfaces/core/blob/develop/impl/src/main/...] set to 2 minutes. My results: - the peak number of MessageData objects was about 8000 objects after the whole night run. - it means that the number does not rise anymore because of some of the sessions expire due to timeout. Lukas, could you please bring you insight into this results and previous comments ? Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Juraj Huska edited comment on RF-12219 at 5/30/12 11:17 AM: ------------------------------------------------------------ I have run the test whole night with MAX_INACTIVE_INTERVAL of [SessionImpl|https://github.com/richfaces/core/blob/develop/impl/src/main/...] set to 2 minutes. My results: - the peak number of MessageData objects was about 8000 objects after the whole night run. - it means that the number does not rise anymore because of some of the sessions expire due to timeout. Lukas, could you please bring you insight into these results and previous comments ? Thanks. was (Author: jhuska): I have run the test whole night with MAX_INACTIVE_INTERVAL of [SessionImpl|https://github.com/richfaces/core/blob/develop/impl/src/main/...] set to 2 minutes. My results: - the peak number of MessageData objects was about 8000 objects after the whole night run. - it means that the number does not rise anymore because of some of the sessions expire due to timeout. Lukas, could you please bring you insight into this results and previous comments ? Thanks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated RF-12219: ---------------------------- Fix Version/s: 4.3.0.Milestone2 (was: 4.3.0.Milestone1) Forum Reference: https://community.jboss.org/message/731978#731978 (was: https://community.jboss.org/message/731978#731978) Further investigations and tests are needed in order to resolve this issue. Shifting to M2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč edited comment on RF-12219 at 7/26/12 4:05 AM: ---------------------------------------------------------- It seems the disconnection of client doesn't destroy the session. Atmosphere calls {{$_atmosphere.unsubscribe()}} on a client on {{window.unload}} event. However the listeners on server-side aren't notified that the client is unsubscribed (might be bug in Atmosphere). I assume {{onDisconnect}} event listener of {{RequestImpl}} should be invoked in this case. However {{onResume}} event listener is invoked instead. That's why when intensively changing pages, new sessions are created and destroyed after 5 minutes. For now, I will incorporate experimental option {{org.richfaces.push.session.maxInactiveInterval}} to allow configure this interval (see RF-12370). was (Author: lfryc): It seems the disconnection of client doesn't destroy the session. Atmosphere calls {{$_atmosphere.unsubscribe()}} on a client on {{window.unload}} event. However the listeners on server-side aren't notified that the client is unsubscribed (might be bug in Atmosphere). I assume {{onDisconnect}} event listener of {{RequestImpl}} should be invoked in this case. However {{onResume}} event listener is invoked instead. That's why when intensively changing pages, new sessions are created and destroyed after 5 minutes. For now, I will incorporate {{org.richfaces.push.session.maxInactiveInterval}} option to allow configure this interval (see RF-12370). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč reassigned RF-12219: ------------------------------- Assignee: Juraj Húska (was: Lukáš Fryč) Juraj, could you please re-test in scope of M2, what's the behavior when, * org.atmosphere.cpr.CometSupport.maxInactiveActivity is configured (say 35000) * org.richfaces.push.session.maxInactiveInterval is configured (say 40000) in those situations: * each option separately * both option in combination -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Milo van der Zee commented on RF-12219: --------------------------------------- Hello Lukáš, thank you very much and nicely found in the Comet software. Looking good :) In my situation my workaround still functions like a charm. An enhancement could be to use the id of the push component combined with the session id (See PushResource.java near "UUID.randomUUID()"). That would naturally limit the number of queues. MAG, Milo van der Zee -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč edited comment on RF-12219 at 7/27/12 5:15 AM: ---------------------------------------------------------- Hi Milo, looked once again to your fix, it seems okay in case of single window per single client. However each client and each browser window needs to establish own connection to the server. Why? Each client (browser tab/window) is subscribed to particular set of topics, and each PushSession own queue of messages to be delivered to those topics. If you would connect more requests to the same session, then you are getting Message Queueing concept instead of Topic Subscription. Basically first client comes, first serves. ---- In detail, each client request which [finds out there are messages in Session's queue|https://github.com/richfaces/core/blob/4cef088fcee550d2d7f0fd4a1b71...], it initiates broadcasting and once broadcasting ends, it [clears sent messages|https://github.com/richfaces/core/blob/4cef088fcee550d2d7f0fd4a1...], making them unavailable to further requests. Additionally there can be only [one request per session|https://github.com/richfaces/core/blob/4cef088fcee550d2d7f0fd4a1b...]. ---- You should be able to simulate this problem by opening two tabs in one browser - messages will be delivered just to one of them. was (Author: lfryc): Hi Milo, looked once again to your fix, it seems okay in case of single window per single client. However each client and each browser window needs to establish own connection to the server. Why? Each client (browser tab/window) is subscribed to particular set of topics, and each PushSession own queue of messages to be delivered to those topics. If you would connect more requests to the same session, then you are getting Message Queueing concept instead of Topic Subscription. Basically first client comes, first serves. ---- In detail, each client request which [finds out there are messages in Session's queue|https://github.com/richfaces/core/blob/4cef088fcee550d2d7f0fd4a1b71...], it initiates broadcasting and once broadcasting ends, it [clears sent messages|https://github.com/richfaces/core/blob/4cef088fcee550d2d7f0fd4a1...]. ---- You should be able to simulate this problem by opening two tabs in one browser - messages will be delivered just to one of them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-12219: --------------------------------- This issue seems related: https://groups.google.com/forum/?fromgroups#!topic/atmosphere-framework/f... User reports problems with Glassfish, but Jean-Francois reports it doesn't work with Tomcat too. Might be actually the problem of XDR: https://github.com/Atmosphere/atmosphere/issues/535 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Juraj Húska commented on RF-12219: ---------------------------------- I ran my testing method as Lukas had proposed with these results. For each of the options I ran test for 7 minutes, and I was checking again number of MessageData instances. * org.richfaces.push.session.maxInactiveInterval configured to 40000 ** number of instances: 1,536 * org.atmosphere.cpr.CometSupport.maxInactiveActivity configured to 35000 ** number of instances: 93,853 ** I have put this init-param to Facet Servlet, however the results are similar to the testing without using any workaround. Like it is not working as expected. * both workarounds used ** number of instances 1,585 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s... ] Juraj Húska reassigned RF-12219: -------------------------------- Assignee: Lukáš Fryč (was: Juraj Húska) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira