[
https://issues.apache.org/jira/browse/LOGCXX-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13868827#comment-13868827
]
Joseph Southwell commented on LOGCXX-390:
-----------------------------------------
Although, now that I read it, I see that you are allowing multiple watchdogs to
run at the same time. My fix does not do that. It simply replaces the existing
watchdog with the new one.
What is the use case for wanting multiple watch dogs running? If we are going
to allow that do we need to add some locking around doConfigure? I also note
your fix will break our c++ 98 compatibility since shared_ptr was not part of
the standard library at that point. I am not necessarily opposed to that but
think there should be some discussion first.
> xml::DOMConfigurator::configureAndWatch leaks memory and threads like
> LOGCXX-342
> --------------------------------------------------------------------------------
>
> Key: LOGCXX-390
> URL: https://issues.apache.org/jira/browse/LOGCXX-390
> Project: Log4cxx
> Issue Type: Bug
> Components: Configurator
> Affects Versions: 0.10.1
> Environment: windows
> Reporter: Victor
> Assignee: Florian Seydoux
>
> Each call to configureAndWatch causes a new FileWatcher object to be created
> (without deleting the old one) and consequently a new thread to be created
> (even though the old one may still be running).
> It problem may be fixed by creating
> std::vector<std::tr1::shared_ptr<FileWatchdog>> vecWatchDog;
> change
> // XMLWatchdog * xdog = new XMLWatchdog(file);
> // xdog->setDelay(delay);
> // xdog->start();
> std::tr1::shared_ptr<FileWatchdog> xdog((FileWatchdog*)new
> XMLWatchdog(file));
> xdog->setDelay(delay);
> xdog->start();
> vecWatchDog.push_back(xdog);
> and adding
> void xml::DOMConfigurator::stopAllWatch()
> {
> vecWatchDog.clear();
> }
> for correctly stoped FileWatchers on application exit befor destroing Pool
> objects. Or need create vecWatchDog on Pool.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
