Cygnus must die if it is not able lo log

[frbattid]

If suddenly logging facilities are not available, Cygnus must detect it and die. Previously, Cygnus must warn about this behavior in the standard output/error.

When Cygnus enters this "shutting down state", no more notifications will be accepted at the source(s) and the pending events within the channels will be served; then Cygnus will die.

[frbattid]

Thinking about this issue, these two options arise:

• To add a thread in charge of checking, periodically, if the logging system is alive or not. The check could be as simple as trying to add a testing trace.
  • Pros: easy to implement with low impact in the rest of the code.
  • Cons: a fail in the logging system is not detected until the checking period is reached; a useless trace is left in the logs.
• To modify the current CygnusLogger class in order to perform the check each time any part of the code tries to log something.
  • Pros: a fail in the logging system is detected almost in real time.
  • Cons: high impact in the code since the CygnusLogger is not widely used by Cygnus (it is only used by OrionHDFSSink, OrionMySQLSink and OrionCKANSink).

[fgalan]

The second one seems to be the best, as the "cons" in that case is actually something that we think Cygnus should do (to use the same logger for all cases... or is there some reason so use different ones as it is now?)

[frbattid]

Yes, that's the path I'm following. Basically:

1. CygnusLogger now tries centralizes all the logging methods (info, error, debug...). There is a try...catch for each one of them, and if something fails then an error is printed in the standard error (as @mrutid suggested). Then Cygnus exists.
2. When the Cygnus application is launched, a shutdown hook is created. This hook, when Cygnus exists or the user press crtl+c, starts an ordered shutdown of all the components. This hook did already exist, but now it is more complex... see below.
3. It is a requirement that Cygnus' sinks are stopped only once all the events within the channels are persisted. In the meantime, no more notifications must be accepted (i.e. no more events will be put within the channels) at the sources. This can only be done if we extend the current Cygnus channels (MemoryChannel, FileChannel, JDBCChannel) in order to a getSize() method is available (currently it is not, thus there is no way of controlling if the channels are empty or not). In addition to this, the Cygnus application must be modified in order to get references to the created objects (channels, sources, sinks...) if we want to inspect their status.

I'm currently implementing the point number 3.

[frbattid]

Implemented in PR https://github.com/telefonicaid/fiware-connectors/pull/337