bakaid commented on issue #607: MINIFICPP-733 - Redirect librdkafka log to proper Logger URL: https://github.com/apache/nifi-minifi-cpp/pull/607#issuecomment-509536261 @arpadboda Loggers are members of KafkaConnections and exist unchanged during the entire lifetime of the KafkaConnections. rd_kafka_t handles - to which loggers are associated in the static map - have lifetimes lower than or equal to KafkaConnections (the rd_kafka_t handle can be changed in the KafkaConnection with setConnection). This means that there is an external (external from smart pointers) guarantee that the same logger will exist during the entire lifetime of the rd_kafka_t handle, and a shared_ptr held by the static map is not necessary to extend the logger lifetime to the lifetime of the rd_kafka_t handle. While it is not necessary to have a shared_ptr, why would it be harmful to have one? If everything worked as intended, it would make no difference. However, if there is a bug now or in later iterations of the code, whereby we fail to remove the entry from the static map when the rd_kafka_t handle is freed, then when the KafkaConnection is finally destroyed, its logger will still be held until the static map is freed (i.e. the entire lifetime of the application). In the case of a logger this would not cause a great issue except for the small amount of leaked memory, but in more complicated shared_ptr configurations it might cause more serious errors. To summarize, I have arrived to this design decision because of two factors: - the logger lifetime is guaranteed in other ways than holding a shared_ptr - I am dislike storing shared_ptrs in static variables, and I like to fail safe in these situations, even though an error in the current case does not pose a great threat
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
