From: <log...@li...> - 2015-01-08 10:13:11
|
Hello, I would like to be able to initialise log4cpp from a properties file, to shut it down, to reinitialise it from another properties file etc. In my opinion, there are two problems with this approach: 1. Leaking Appenders: The Appenders are not owned by the Categories when the log system is initialised from a properties file. Therefore Category::shutdown does neither close nor destroy the Appenders. I could close them with Appender::closeAll but not destroy them. I could work around this problem by calling Category::getCurrentCategories() and then for each Category getAllAppenders() and then I destroy every Appender that is not owned by the Category. This works if the system is initialised exclusively from properties file as no Appender is owned by any Category. If, however, one Appender was owned by one Category, but not by another, then I would run the risk to destroy an Appender twice, once by my code and once by the destructor of the Category that owns it. 2. Leaking Categories: I could destroy all Categories by calling HierarchyMaintainer::deleteAllCategories(). One problem is that HierarchyMaintainer is an internal class, as the comments say, so I should not use it. Another problem is that deleteAllCategories() destroys the Categories in _categoryMap but does not clear the map. Thus, when the HierarchyMaintainer is destroyed automatically upon program exit the HierarchyMaintainer destructor attempts to destroy the already destroyed Categories and I get a segfault. I could work around this problem by implementing a log4cpp::Log4cppCleanup class (exploiting the "friend class Log4cppCleanup" feature in HierarchyMaintainer) and setting a shutdown handler (HierarchyMaintainer::register_shutdown_handler) that executes HierarchyMaintainer::_categoryMap.clear(). So all in all I get the behaviour I want, but I have the feeling of forcing the lib. I would have preferred a) that deleteAllCategories cleared the _categoryMap. I think this is a bug. b) that deleteAllCategories was exported via a call to Category. c) that there was a straightforward way to destroy all Appenders that are not owned by the Categories. Best regards, Sorin |
From: <log...@li...> - 2015-01-09 19:01:49
|
Hello Sorin, Thank you for your deep considerations. I agree that the graceful shutdown is missing in the library, though as weak excuse it is really rarely applied. Your a) seems pretty reasonable, I just have to check if it may cause any unexpected consequences. DeleteAllCategories call could be made public, it is just that categories and appenders are interconnected via pointers and therefore it probably will be better to have cleanup method that will take care of them both. Appenders might be shared. And not only at the instantiation time after reading properties file, but programmatically later too. The log4cpp lib does not make use of smart pointers, and it is not easy to determine whether particular appender is shared. I will dedicate some time to investigate it further, but if you have something already, please share your findings too. Regards, Alexander On Jan 8, 2015 2:13 PM, <log...@li...> wrote: > Hello, > > I would like to be able to initialise log4cpp from a properties file, to > shut it down, to reinitialise it from another properties file etc. > > In my opinion, there are two problems with this approach: > > 1. Leaking Appenders: The Appenders are not owned by the Categories when > the log system is initialised from a properties file. Therefore > Category::shutdown does neither close nor destroy the Appenders. I could > close them with Appender::closeAll but not destroy them. > > I could work around this problem by calling > Category::getCurrentCategories() and then for each Category > getAllAppenders() and then I destroy every Appender that is not owned by > the Category. This works if the system is initialised exclusively from > properties file as no Appender is owned by any Category. If, however, > one Appender was owned by one Category, but not by another, then I would > run the risk to destroy an Appender twice, once by my code and once by > the destructor of the Category that owns it. > > 2. Leaking Categories: I could destroy all Categories by calling > HierarchyMaintainer::deleteAllCategories(). One problem is that > HierarchyMaintainer is an internal class, as the comments say, so I > should not use it. Another problem is that deleteAllCategories() > destroys the Categories in _categoryMap but does not clear the map. > Thus, when the HierarchyMaintainer is destroyed automatically upon > program exit the HierarchyMaintainer destructor attempts to destroy the > already destroyed Categories and I get a segfault. > > I could work around this problem by implementing a > log4cpp::Log4cppCleanup class (exploiting the "friend class > Log4cppCleanup" feature in HierarchyMaintainer) and setting a shutdown > handler (HierarchyMaintainer::register_shutdown_handler) that executes > HierarchyMaintainer::_categoryMap.clear(). > > So all in all I get the behaviour I want, but I have the feeling of > forcing the lib. > > I would have preferred > > a) that deleteAllCategories cleared the _categoryMap. I think this is a > bug. > > b) that deleteAllCategories was exported via a call to Category. > > c) that there was a straightforward way to destroy all Appenders that > are not owned by the Categories. > > Best regards, > Sorin > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Log4cpp-devel mailing list > Log...@li... > https://lists.sourceforge.net/lists/listinfo/log4cpp-devel > |
From: <log...@li...> - 2015-01-09 20:42:23
|
On 01/09/2015 09:01 PM, log...@li... wrote: > Hello Sorin, > > Thank you for your deep considerations. > I agree that the graceful shutdown is missing in the library, though as > weak excuse it is really rarely applied. > Your a) seems pretty reasonable, I just have to check if it may cause > any unexpected consequences. Long time ago I have implemented graceful shutdown but didn't committed anything for reasons I don't remember now. I will take a look on code tomorrow and comment Sorin's message too. |