OrionSTHSink

[fgalan]

Implement another sink for MongoDB and test it along with the Cosmos sink, e.g. run the program with 2 sinks activated and check that when a notifyContextRequest arrives it is persisted in both places, check if Flume can implement "all or nothing" semantics (i.e. if one of the sinks is offline, for instance the connection to MongoDB is broken, then the notifyContextRequest is not persisted in Cosmos), etc.

[frbattid]

An already developed MongoDB sink for Flume: https://github.com/leonlee/flume-ng-mongodb-sink

Referenced from Flume official wiki (https://cwiki.apache.org/confluence/display/FLUME/Flume+NG+Plugins)

[frbattid]

I've changed the name of this issue to "OrionSTHSink" since it is clear that a sink for the Short-Term Historic of Orion CB has to be created; independently of the underlying technology used for that (Mongo, LevelDB, InfluxDB, Open TSDB, flat files... who knows :)).

[fgalan]

However, if the technology to implement STH is not MongoDB, an issue about "OrionMongoSink" will still making sense (not sure if this one remaned back or a different new one). Have been the STH technology chosen?

[frbattid]

It has not been chosen, really. But the idea behind the original "orion2mongo sink" was to suppert the STH,thus I though it was better to rename it... Nevertheless, I agree maybe in the future a OrionMongoSink issue is necessary if we want to mimic the behaviour of OrionHDFSSink in a Mongo-based fashion... well, I do not know what to do now :)

[gtorodelvalle]

Implemented in #377 ;)