[jira] [Comment Edited] (LOGCXX-390) xml::DOMConfigurator::configureAndWatch leaks memory and threads like LOGCXX-342

["Florian Seydoux (JIRA)" <lo...@logging.apache.org>]

    [ https://issues.apache.org/jira/browse/LOGCXX-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13868841#comment-13868841 ] 

Florian Seydoux edited comment on LOGCXX-390 at 1/11/14 6:00 PM:
-----------------------------------------------------------------

Hi Joseph;
Feel free to get the handle on the ticket, especially if you already have a working/tested solution (in this case, you can probably also takes LOGCXX-342).

Btw, the fix on the description was proposed by the reporter (Victor). I agree with you, it would be better to not break conformity to C++98 (cf. thread on the dev. list).

I've attached a patch proposal to LOGCXX-342 - but I let you see if it help or not.


was (Author: fsdidoux):
Hi Joseph;
Feel free to get the handle on the ticket, especially if you already have a working/tested solution (in this case, you can probably also takes LOGCXX-342).

Btw, the fix on the description was proposed by the reporter (Victor). I agree with you, it would be better to not break conformity to C++98 (cf. thread on the dev. list).

I've attached a patch proposal to LOGCXX-342 - but I let to see if it help or not.

> 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)