1

For example I have a RequestService that is responsible for making requests and LogHandler that is loaded with /home/nao/naoqi/preferences/autoload.ini. The idea of the LogHandler is to handle all logs (with help of the LogManager service) and to make a request with this logs to a remote Server. Furthermore the LogHandler handles the events when the system is started and when the system is shutting down. To handle the shutting down I'm using a logic that is triggered after app.run() method (I used this idea).

The question is: If the LogHandler depends on RequestService, is there any guarantee that the OS will kill first LogHandler and then RequestService or there is risk to kill the RequestService - in this case the LogHandler will fail to send a request to the remote server. In this scenario may be a better idea to implement the LogHandler in such a way as to be independent from the RequestService?

# init of the LogHandler
app = qi.Application(url=ROBOT_URL)
app.start()
session = app.session

request_service = session.service("request_service")

on_os_start(request_service)
...
app.run()
...
on_os_shutdown(request_service)
app.stop()

Can I depend on the request_service in case of system shutting down?

dim
  • 992
  • 11
  • 26

1 Answers1

3

No, there is no "official" service shutdown sequence, so even if your services get shut down in a certain order, there's no guarantee that they will continue doing so in different contexts or system versions.

The best is to reduce the need for dependencies between your services, especially at critical moments like startup and shutdown. So to answer your question ...

In this scenario may be a better idea to implement the LogHandler in such a way as to be independent from the RequestService?

... yes, it's a better idea.

I'm not even sure why you want the requests_service in a different service (or is this just an example?). What I sometimes do is have helper python libraries that provide useful functionality, and import the same library from several different services; that way I have shared functionality without code duplication (you might have other reasons than code duplication for wanting to centralize your request handling though).

Emile
  • 2,946
  • 2
  • 19
  • 22
  • This is an example code but I had a similar case with two `QiMessaging` services. Thank you for the advice. I will organize the common logic in helpers. What do you mean by "different services": different services packed in one application or different services as different application? If the applications are different - how do you manage to import the common libraries? – dim Aug 13 '18 at 19:18
  • 2
    Usually packed in one application package; having python from one package import a module provided in another package is technically possible, but I wouldn't recommend it. What I usually do instead - when I don't have several services in one package - is just have some standard library that is duplicated in several packages. For example these: https://github.com/pepperhacking/studiotoolkit/tree/master/doc – Emile Aug 14 '18 at 02:46
  • Very useful link and explanations - thank you! I'm curious about how to use a common library and why this is not recommended? I wonder and in which case is recommend to use `/home/nao/naoqi/preferences/autoload.ini` for run modules on startup (instead to create a `QiMessaging` service application with `autorun="true"`)? – dim Aug 14 '18 at 13:16
  • 1
    I mean you could have package A include library foo, and package B dynamically add /home/nao/.local/share/PackageManager/apps/A/libs/ to it's pythonpath (with sys.path), but that would create an ugly, brittle dependency between the two packages. – Emile Aug 15 '18 at 14:33
  • 1
    As for autoload.ini, I'd recommend always using the declaration in the manifest instead, like that you never have to edit anything on the robot, just install the package and it's ready. Much more convenient when swapping robots etc. – Emile Aug 15 '18 at 14:34