[richfaces-issues] [JBoss JIRA] (RF-12219) Push: Test that messages do not become stale in a queue
Milo van der Zee (JIRA)
jira-events at lists.jboss.org
Fri May 25 17:19:17 EDT 2012
[ https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696150#comment-12696150 ]
Milo van der Zee edited comment on RF-12219 at 5/25/12 5:18 PM:
----------------------------------------------------------------
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.
The code I changed does indeed seem to fix my problems. After a day of running there are almost no MessageData objects in the heap.
MAG,
Milo
was (Author: MilovdZee):
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
> Push: Test that messages do not become stale in a queue
> -------------------------------------------------------
>
> Key: RF-12219
> URL: https://issues.jboss.org/browse/RF-12219
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 4.2.1.Final
> Reporter: Lukáš Fryč
> Assignee: Juraj Huska
> Priority: Critical
> Fix For: 4.3.0.Milestone1
>
>
> According to the [Forum reference],
> we can have problems with stale messages.
> I would suggest to write tests for following scenarios and check that queue is destroyed properly:
> * view expires
> * client leaves the page with {{a4j:push}} without proper clean up
> * ...
> Let's brainstorm other scenarios.
--
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
More information about the richfaces-issues
mailing list