Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.6DR#1, 1.6DR#2, 1.6DR#3
-
Component/s: Sample Apps
-
Labels:None
-
Environment:Browser and OS independent.
-
Affects:Sample App./Tutorial
Description
This issue has been around for a while, but since it was server side related it wasn't really noticeable.
Basically, the ClockBean (which controls the IntervalRenderer for each user) would be created for a new session. The problem is when the user closed their browser, the ClockBean relied on renderingExceptions to clean itself up, which was unreliable and prone to leaving dead threads hanging around, which would cause a gradual memory leak.
Basically, the ClockBean (which controls the IntervalRenderer for each user) would be created for a new session. The problem is when the user closed their browser, the ClockBean relied on renderingExceptions to clean itself up, which was unreliable and prone to leaving dead threads hanging around, which would cause a gradual memory leak.
Activity
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #13774 | Thu May 03 15:54:12 MDT 2007 | carlo.guglielmin | |
Files Changed | ||||
![]() |
Field | Original Value | New Value |
---|---|---|
Assignee | Carlo Guglielmin [ carlo.guglielmin ] |
Status | Open [ 1 ] | Resolved [ 5 ] |
Fix Version/s | 1.6DR#4 [ 10060 ] | |
Affects | [Sample App./Tutorial] | |
Resolution | Fixed [ 1 ] |
Fix Version/s | 1.6 [ 10031 ] |
Status | Resolved [ 5 ] | Closed [ 6 ] |
Assignee | Carlo Guglielmin [ carlo.guglielmin ] |
With the addition of a ViewListener class and a tie in to the PersistentFacesState, it was possible to reliably clean up the ClockBean for each user.
The ClockBean now implements ViewListener and the associated viewCreated and viewDisposed methods. In viewDisposed the IntervalRenderer for the session will be stopped, the renderable bean removed, and then disposed. This proper cleanup when a user closes their browser will stop the gradual server side memory leak.