"Currently, there is no way for RA to recognize a "replica" as an entity, and derive profiles from this. I realize that this is not trivial, since it might break some abstractions/rules/design principles you may have in place. For instance, a replica does not have an acyclic state model (whether or not a "cyclic" state model is acceptable is for you to decide).
That being said, it would be very useful to be able to recognize a replica as an entity and derive the time spent by the replica running MD, being idle, or performing exchange. Currently, I am doing this by running a wildcard string search on the session's .json file for task/stage names (rep.0000.md or rep.0000.ex) and using those tasks to filter out the relevant events in the analytics script.
This is cumbersome, and is entirely at the mercy of what the task names are in RepEx (the user will likely not be privy to the internal task names, it just so happens that I am)."
From @SrinivasMushnoori :
"Currently, there is no way for RA to recognize a "replica" as an entity, and derive profiles from this. I realize that this is not trivial, since it might break some abstractions/rules/design principles you may have in place. For instance, a replica does not have an acyclic state model (whether or not a "cyclic" state model is acceptable is for you to decide).
That being said, it would be very useful to be able to recognize a replica as an entity and derive the time spent by the replica running MD, being idle, or performing exchange. Currently, I am doing this by running a wildcard string search on the session's .json file for task/stage names (rep.0000.md or rep.0000.ex) and using those tasks to filter out the relevant events in the analytics script.
This is cumbersome, and is entirely at the mercy of what the task names are in RepEx (the user will likely not be privy to the internal task names, it just so happens that I am)."