You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by "David Read (JIRA)" <be...@incubator.apache.org> on 2005/06/14 22:23:48 UTC
[jira] Created: (BEEHIVE-814) Provide ability to track lifetime of PageFlow instances
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
Assigned to: Rich Feit
Priority: Minor
Fix For: TBD
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
[jira] Commented: (BEEHIVE-814) Provide ability to track lifetime of PageFlow instances
Posted by "David Read (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-814?page=comments#action_12313681 ]
David Read commented on BEEHIVE-814:
------------------------------------
Yes. I think System.currentTimeMillis() should be fine. Any user of the API should be prepared to deal with the problem of out-of-sync time(s) in a cluster. It seems reasonable to me to assume that any difference in system clocks would be insignificant relative to the lifetime of a PageFlow instance.
> 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: Rich Feit
> Priority: Minor
> Fix For: TBD
>
> 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
[jira] Commented: (BEEHIVE-814) Provide ability to track lifetime of PageFlow instances
Posted by "Rich Feit (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-814?page=comments#action_12313675 ]
Rich Feit commented on BEEHIVE-814:
-----------------------------------
I'm assuming that System.currentTimeMillis() is sufficient for your option (1)... do you agree?
> 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: Rich Feit
> Priority: Minor
> Fix For: TBD
>
> 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
[jira] Commented: (BEEHIVE-814) Provide ability to track lifetime of PageFlow instances
Posted by "Rich Feit (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-814?page=comments#action_12313645 ]
Rich Feit commented on BEEHIVE-814:
-----------------------------------
Capturing the create time is an interesting idea. But I have two questions:
1) Would there be other situations where tying two begin/end-type events together would be useful? Seems like that might be a possibility.
2) Why would the identity have a larger/more-variable impact on performance? Is this because it should be unique *across* VMs?
> 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: Rich Feit
> Priority: Minor
> Fix For: TBD
>
> 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
[jira] Updated: (BEEHIVE-814) Provide ability to track lifetime of PageFlow instances
Posted by "Rich Feit (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-814?page=all ]
Rich Feit updated BEEHIVE-814:
------------------------------
Fix Version: V1
(was: TBD)
> 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: Alejandro Ramirez
> 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
[jira] Resolved: (BEEHIVE-814) Provide ability to track lifetime of PageFlow instances
Posted by "Rich Feit (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-814?page=all ]
Rich Feit resolved BEEHIVE-814:
-------------------------------
Resolution: Fixed
Assign To: Alejandro Ramirez (was: Rich Feit)
Fixed with revision 190754. You can now get the create time on a page flow by calling getCreateTime().
> 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: Alejandro Ramirez
> Priority: Minor
> Fix For: TBD
>
> 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