beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julie Zhuo (JIRA)" <...@beehive.apache.org>
Subject [jira] Closed: (BEEHIVE-814) Provide ability to track lifetime of PageFlow instances
Date Fri, 02 Sep 2005 05:03:12 GMT
     [ 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


Mime
View raw message