The logging functionalities of OpenViBE

As many software, OpenViBE has the ability to log several things that happened during a session… As many software users, OpenViBE users seem not to notice the log messages… Or maybe they notice it but simply ignore it… Printing colorful logs in the console is not just cool. It gives some information… Sometimes this information can not be understood by the user, sometimes it is actually targeted to the user ! The aim of this post is to explain the importance of the log in OpenViBE and how that can save your time when you try to use it.

The OpenViBE kernel is composed of several managers, each of them being dedicated to a specialized task. One of those manager is the log manager. It aims at receiving any message that the application or its components should make available. In OpenViBE, each message has a log level which roughly indicates the importance of the message and its audience. These levels are :

  • Messages targeted to the application user :
    • Fatal : basically means that something that should never happen actually happened causing a crash that could not be avoided
    • Error : means that something that should never happen actually happened. Some recovery strategies have been tried but the application may remain unstable
    • Important Warning : something did not happen the way the user probably expected. This may cause later unexpected behaviors. There is no risk of crash
    • Warning : something did not happen the way the user probably expected. However, the risk that this affects other processes is limited. There is no risk of crash
    • Info : something expected just happened and it is interesting / important / mandatory to notice the user
  • Messages targeted to the developers :
    • Trace : something expected just happened it may help the developer to know this if something unexpected happens somewhere else, however, the application user does not care
    • Debug : something happened and it happens so often that even the developer is not interested in this information during the session.

Now, given that the kernel is able to receive lots of messages flagged sorted by log levels, what should it do with those messages ? It sends them to the registered log listener. The kernel natively registers two log listeners : one that prints the messages to the console and one that prints the messages to a text file… So as soon as something unexpected happens (be it in the designer or the acquisition server), please look at your console. You probably have the answer to your question there…

As I said, the Debug and Trace will most of the time not be of interest to the user. Therefore, there is a filtering process at the manager level, and a second filtering process at the listener level…

The following figure shows an example of successive filters and how messages meet their target media or not.

The log process - The messages are filtered at the log manager level and at each log listerner level

The main log level can be changed in the designer during a session. Additionally, the configuration manager (which we discussed a few times in the past) allows you to configure the log levels of the log manager, the console log listener and the file log listener separately. The following tokens can be used :

Kernel_MainLogLevel = Information
Kernel_ConsoleLogLevel = Debug
Kernel_FileLogLevel = Debug

This default configuration allows the listeners to receive all the messages but limits the propagation at the log manager level…

I personally prefer the following configuration :

Kernel_MainLogLevel = Trace
Kernel_ConsoleLogLevel = Trace
Kernel_FileLogLevel = Debug

Indeed, I am almost always interested by Trace messages… But in case I’d move to Debug, I wouldn’t want my console to be messed up by those messages. There are too many messages to read them in the console. It is useful to have them in the log file however…

Again, the log messages usually have useful information. Anyway, if a message is unclear, feel free to ask for explanations / enhancements to developers on the forum

Comments are closed.