[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4cxx-user
Subject:    Re: A few problems to report
From:       "Dale King" <dalewking () gmail ! com>
Date:       2008-05-10 12:22:26
Message-ID: c80a0b890805100522o718737dck2ae40d7e4ed14359 () mail ! gmail ! com
[Download RAW message or body]

I've also figured out why the Watchdog threads do not have the same
problem. The pointers to the watchdog objects which contain the
threads are not retained. The objects are created and no reference is
maintained so the watchdog objects are never destroyed and thus the
threads are never destroyed and thread.join is never called on them
(either in the filewatchdog destructor or the thread destructor).

So I had hoped there was something about the Watchdog thread that
could be copied to the SocketAppender case, but no the Watchdog thread
gets around it by following a bad practice that should be cleaned up.

On Fri, May 9, 2008 at 11:26 PM, Dale King <dalewking@gmail.com> wrote:
> OK, I've figured out why the exception on control-C. The problem is
> Thread::join will throw a ThreadException if the apr_thread_join does
> not return a 0 status. But in the case of control-C the
> apr_thread_join returns a non-zero value and it throws an exception
> that no one catches.
>
> On Fri, May 9, 2008 at 9:56 PM, Dale King <dalewking@gmail.com> wrote:
>> Ok, I have tried the latest in subversion and yes it works when the
>> program exits normally including the annoying wait for the sleep to
>> end.
>>
>> However it does not work when you end the program when you hit
>> control-C. I get an exception in that case only when I include my
>> XMLSocketAppender. If I remove the XMLSocketAppender ctrl-C exits the
>> program normally.
>>
>> So I would not call it resolved.
>>
>> What I still find very curious is the fact that none of these problems
>> occur with the FileWatchdog thread. What makes these threads so much
>> different?
>>
>> On Fri, May 9, 2008 at 5:50 PM, Curt Arnold <carnold@apache.org> wrote:
>>>
>>> On May 7, 2008, at 1:28 PM, Dale King wrote:
>>>
>>>> Any feedback on these issues? I submitted Jira issues on all 3.
>>>>
>>>> The threads not ending cleanly is a major problem with me trying to
>>>> move one component of our system to Log4Cxx. I would at least like to
>>>> get a patch for it (preferrably a released version). I've tried
>>>> several things but have not found a complete solution and the fact
>>>> that it behaves differently than the FileWatchdog thread is confusing.
>>>> I'm willing to help out on it, but am interested in your thoughts on
>>>> the threading issues since you wrote it.
>>>>
>>>
>>>
>>> I've committed several changes against these issues and closed them as
>>> resolved.  Obviously it would be good if you could confirm that they address
>>> the issues that you encountered.
>>>
>>> I spun off LOGCXX-282 as a separate issue to allow Thread::sleep() to be
>>> woken up by a call to Thread::interrupt().  However, the required added
>>> additional member variables to the Thread class which would make the
>>> resulting library not binary compatible with log4cxx 0.10.0.  I've held off
>>> committing it until I get some other non-breaking changes fixed, but I would
>>> appreciate your checking it using the patch file attached to the bug report.
>>>  After we get come feedback, we can decide if you want to have a 0.10.1 or a
>>> 0.11.0 or both.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Dale King
>>
>
>
>
> --
> Dale King
>



-- 
Dale King
[prev in list] [next in list] [prev in thread] [next in thread]