[ http://issues.apache.org/jira/browse/BEEHIVE-814?page=all ]
Alejandro Ramirez reassigned BEEHIVE-814:
-----------------------------------------
Assign To: Julie Zhuo (was: Alejandro Ramirez)
verify
> 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
