Part of the solution for MSC-46 was to come up with a general service timing mechanism. Since MSC-42 means that such a mechanism cannot be used to time container shutdown, this issue was created to track that specific feature.

Some discussion around this:

(earlier discussion)
(14:37:11) dmlloyd: I think we should add a volatile nanoTime field on service instance. When the controller mode is set such that it would drive a state change, the field is tagged with the time of the change; then it should be readable from LifecycleContext.
(14:37:23) dmlloyd: that way you can time any service start/stop

(later)
[17:50] <dmlloyd> well, thinking about it a moment, setMode() isn't the only thing that could cause a service stop or start
(...)
[18:00] <dmlloyd> maybe we can simply record a timestamp on transition from UP->STOP_REQUESTED and DOWN->START_REQUESTED
(...)
[18:02] <frainone> if you finish the calculation of the elapsed time from inside listeners, listeners will get different numbers... I'm not sure if this is important or not, though
[18:02] <dmlloyd> yeah, I figure it's not that important
[18:02] <dmlloyd> you could even get different answers depending on when you check in your start()/stop() method
[18:02] <dmlloyd> or depending on how long System.nanoTime() takes to execute even

Additional requirements:

The service start nanoTime should be available via a method on LifecycleContext: long getInitialNanoTime(); This means that timing information is available at start()/stop() but not in listeners (unless the service explicitly makes it available via its value so that the listener can access it via controller.getValue()).