[
https://issues.jboss.org/browse/RF-12219?page=com.atlassian.jira.plugin.s...
]
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