A few problems to report

[Dale King-2]

ReconnectionDelay is not working for XMLSocketAppender. This method is
backwards:

void SocketAppenderSkeleton::fireConnector()
{
        synchronized sync(mutex);
        if (thread.isActive()) {
                thread.run(monitor, this);
        }
}

You need a ! on the if condition,

I was also playing around with using TimeBasedRollingPolicy as a
TriggeringPolicy for rolling a file, but using a
FixedWindowRollingPolicy as the RollingPolicy. This did not work as I
expected. every logging event was triggering rollover so every file
contained only 1 log event. This is because lastFileName is only
updated in the rollover method

I'm not sure this is supposed to be supported, but it would seem like
it should work. This also means that using TimeBasedRollingPolicy to
trigger a SMTPAppender will not work correctly and will flood your
inbox with an email for every message!

Also on Windows when I have other threads running like the one to do
reconnection to a socket then my app does not shut down cleanly. When
it ends I get this message on the console:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

and I get an unknown software exception (0x40000015).

If I add an XMLSocketAppender (with the fix from above so the thread
actually runs) and the thread is sleeping then when main exits there
is a delay (equal to the reconnectionDelay) then the exception occurs.
I think the problem is that the SocketAppender is destroyed but the
monitor thread is continuing to sleep when it wakes up it is not
checking if it was interrupted like FileWatchdog does.

I can get rid of the exception by doing a thread.join in the close
method and changing the monitor code to check for being interrupted
like this:

                        Thread::sleep(socketAppender->reconnectionDelay);
                        if( !socketAppender->thread.interrupted() )
                        {

LogLog::debug(LogString(LOG4CXX_STR("Attempting connection to "))
                                    + socketAppender->address->getHostName());
                            socket = new
Socket(socketAppender->address, socketAppender->port);
                            Pool p;
                            socketAppender->setSocket(socket, p);
                            LogLog::debug(LOG4CXX_STR("Connection
established. Exiting connector thread."));
                        }
                        return NULL;

But that does not get rid of the delay waiting for the sleep to end. I
don't understand why the sleep is not interrupted in this thread, but
FileWatchdog does not have the same problem. The call to sleep from
FileWatchdog does not keep the app from exiting.

I hope you're planning on a 0.10.1 version soon.

--
Dale King

[Dale King-2]

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.

On Thu, May 1, 2008 at 10:59 PM, Dale King <dalewking@...> wrote:

> ReconnectionDelay is not working for XMLSocketAppender. This method is
>  backwards:
>
>  void SocketAppenderSkeleton::fireConnector()
>  {
>         synchronized sync(mutex);
>         if (thread.isActive()) {
>                 thread.run(monitor, this);
>         }
>  }
>
>  You need a ! on the if condition,
>
>  I was also playing around with using TimeBasedRollingPolicy as a
>  TriggeringPolicy for rolling a file, but using a
>  FixedWindowRollingPolicy as the RollingPolicy. This did not work as I
>  expected. every logging event was triggering rollover so every file
>  contained only 1 log event. This is because lastFileName is only
>  updated in the rollover method
>
>  I'm not sure this is supposed to be supported, but it would seem like
>  it should work. This also means that using TimeBasedRollingPolicy to
>  trigger a SMTPAppender will not work correctly and will flood your
>  inbox with an email for every message!
>
>  Also on Windows when I have other threads running like the one to do
>  reconnection to a socket then my app does not shut down cleanly. When
>  it ends I get this message on the console:
>
>  This application has requested the Runtime to terminate it in an unusual way.
>  Please contact the application's support team for more information.
>
>  and I get an unknown software exception (0x40000015).
>
>  If I add an XMLSocketAppender (with the fix from above so the thread
>  actually runs) and the thread is sleeping then when main exits there
>  is a delay (equal to the reconnectionDelay) then the exception occurs.
>  I think the problem is that the SocketAppender is destroyed but the
>  monitor thread is continuing to sleep when it wakes up it is not
>  checking if it was interrupted like FileWatchdog does.
>
>  I can get rid of the exception by doing a thread.join in the close
>  method and changing the monitor code to check for being interrupted
>  like this:
>
>                         Thread::sleep(socketAppender->reconnectionDelay);
>                         if( !socketAppender->thread.interrupted() )
>                         {
>
>  LogLog::debug(LogString(LOG4CXX_STR("Attempting connection to "))
>                                     + socketAppender->address->getHostName());
>                             socket = new
>  Socket(socketAppender->address, socketAppender->port);
>                             Pool p;
>                             socketAppender->setSocket(socket, p);
>                             LogLog::debug(LOG4CXX_STR("Connection
>  established. Exiting connector thread."));
>                         }
>                         return NULL;
>
>  But that does not get rid of the delay waiting for the sleep to end. I
>  don't understand why the sleep is not interrupted in this thread, but
>  FileWatchdog does not have the same problem. The call to sleep from
>  FileWatchdog does not keep the app from exiting.
>
>  I hope you're planning on a 0.10.1 version soon.
>
>  --
>  Dale King
>

--
Dale King

[Curt Arnold-3]

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-2]

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@...> 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-2]

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@...> 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@...> 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-2]

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@...> 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@...> 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@...> 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