[ http://issues.apache.org/jira/browse/BEEHIVE-814?page=all ] Julie Zhuo closed BEEHIVE-814: ------------------------------
Verified at rev265606. The PageFlowManagedObject now has a getCreateTime() API. There is a CreateTime bvt and it has been passing. > Provide ability to track lifetime of PageFlow instances > ------------------------------------------------------- > > Key: BEEHIVE-814 > URL: http://issues.apache.org/jira/browse/BEEHIVE-814 > Project: Beehive > Type: New Feature > Components: NetUI > Versions: TBD > Environment: All > Reporter: David Read > Assignee: Julie Zhuo > Priority: Minor > Fix For: V1 > > We've been looking at how to capture the lifetime of PageFlow instances > through the EventReporter API. The original thinking was to generate create > and destroy events that were correlated with an instance identifier for the > PageFlow. Someone who wanted to analyze PageFlow usage could then "join" the > create/destroy events to understand (1) how many of what type of PageFlow > were created (over what period of time) and (2) how long PageFlows of each > type existed. > We originally looked at using system identity hash code to identify an > instance (session id doesn't work since the same flow can exist more than > once in a given session ... at the same time or over time). The problem with > that approach is when clustering is involved. If the destroy event happened > on a "secondary" server, the (calculated) correlation value would be > different. > Two other approaches come to mind ... but there could be others ... > (1) capture the create time as a non-transient attribute of the flow and > expose that via a public API. That would allow the event reporter to ignore > the create event (WRT lifetime), and just capture the destroy event. While > this does add to memory and serialization cost, the benefit is that it is > fairly small and is fixed. > (2) capture an identity as a non-transient attribute of the flow and expose > that via a public API. This may be a more useful concept, but might have a > larger (or more variable) impact on performance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
