Service Life Cycle
Name |
Action
Type |
Description |
|
Runtime.install(service) |
Method |
framework will install if not installed |
|
Runtime.publishStatus |
Event |
installationStart &
installationStop - "general" Status msgs |
|
Service.getMetaData |
Method |
getting "meta" information - dependencies, exclusions, peers |
|
Runtime.create(name, type) |
Method |
construct a new service - do not start inbox or outbox - do not create peers yet |
|
Runtime.register(service) |
Method |
puts service in Runtime's registry |
|
Runtime.registered |
Event |
publish to any subscribers the newly registered service, can use onRegistered(name) |
|
Service.startService() |
Method |
starts inbox, outbox - and can call startPeer for all peers |
|
Service.isReady() |
Method |
|
|
Service.isRunning() |
Method |
is true at this point |
|
Service.publishShutdown |
Event |
notifies subscribed services of impending shutdown, can use onShutdown() |
|
Service.preShutdown() |
Method |
called on each service from Runtime before stopService & releaseService are called |
|
Service.stopService() |
Method |
stops the inbox and outbox threads of the service
if overriden super.stopService should be called
any additional threads created by the service need to be shutdown |
|
Service.releaseService() |
Method |
calls stopService(), detach(), releasePeers(), unregister() |
|
Service.detach() |
Method |
all attached services are detached - possibly should be "before"stop service because with inbox & outbox stopped this service is unreachable, and detach might require action |
|
Service.releasePeers() |
Method |
recursively release all peers a service might have - recently working - Yay! |
|
Service.purgeTasks() |
Method |
Purges all timers for the service added with addTask |
|
Runtime.unregister(name) |
Method |
Final action to remove service from Runtime registry |
|
Runtime.released |
Event |
publishes released service to any subscribers, can use onReleased |
|
Runtime.uninstall |
Method |
doesn't exist yet - TODO |
|
Rough draft of "what exists"
Currently these are method calls, and not "events" ..
register & release are the only official "events" in mrl
OpenCV Filter Life Cycle
I think we need to
I think we need to differentiate what the framework does vs which method is called on the service/which methods a service should override to do custom things at that stage.
e.g. I want to call a custom cleanup method durning stopService(). Do I now need to take care of my inbox and outbox myself as well?
Lifecycle management
This is really a subset of the methods on services. Lifecycle really is having consistent programatic hooks around when certain framework related things happen to services.
https://docs.oracle.com/cd/E19501-01/819-3659/beamc/index.html
Java defines a specific lifecycle for web servers, and if we consider our services to be very similar in nature.. then the following "official" java lifecycles would be as follows:
INIT_EVENT
STARTUP_EVENT
READY_EVENT
SHUTDOWN_EVENT
TERMINATION_EVENT..
This is just one model ... we might find there are other "events" in a service that we want to hook. Off the top of my head I can think of the following
We might want pre/post hooks on each of those events... we might also want to introduce an error event of some sort.