[
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
_______________________________________________
richfaces-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/richfaces-issues
