[
https://issues.apache.org/jira/browse/LOGCXX-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13903478#comment-13903478
]
Joseph Southwell commented on LOGCXX-390:
-----------------------------------------
My solution didn't work because there is a already a list tracking these
pointers in the aprinitialize class. Instead I just tracked that pointer
separately and removed it from that list and deleted it. That way if one is
left when apr is terminated it gets deleted as it should be to avoid issues
like LOGCXX-396.
> 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: Joseph Southwell
>
> 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)
