TelnetAppender and Configuration Reload

[Ufuk Kayserilioglu <gr...@paralaus.com>]

For a while we have been using Log4CXX (somewhat) successfully in our
project despite all its shortcomings. Since we feel that the release of
0.9.8 is close, we have started to port our codebase to the new version.
Our program is a server application running on the Windows platform. We
are using the Win32 src distribution obtained from
http://littletux.homelinux.org/log4cxx/ on 16/05/2006.

In our application we output some log data to the TelnetAppender and we
were hit by an interesting bug during our testing. It appears that if
you have a DOMConfigurator::configureAndWatch setup and your config file
has a TelnetAppender, the initial configuration runs fine. However, if
you change the file, when the platform tries to reload the config file
the process stops before it can reinit the TelnetAppender. We have been
able to trace the problem to the TelnetAppender::close() method which
does a sh.stop(); on the handle which ultimately leads to the current
running thread to exit because the underlying apr function calls
_endthreadex(0). This stops all subsequent processing and even causes
application instability. Moreover, if we skip over the sh.stop() call,
then as soon as serverSocket->close() is called, we get an access
violation due to an operation on the freed socket.

It appears as if, the accept call should be somehow unblocked by the
close method which should afterwards wait for the thread to join.

Thanks for a great tool,

Ufuk Kayserilioglu

TelnetAppender bug fix [was: TelnetAppender and Configuration Reload]

[Ufuk Kayserilioglu <gr...@paralaus.com>]

A quick follow-up to this issue:

We have recently had some time to look at migration to the new 0.10
pre-release code-base. Upon checkout and build of Revision 582102, we
found that the TelnetAppender problem that we have run into before, was
still there. However, this time we have been able to make it work in,
what we think is, a satisfactory manner.

The relevant patch is attached and has been tested to run fine on
Windows 2003 platform. The patch is simple and basically performs what
has been described below:

   1. It closes all the sockets, first.
   2. The closing of a socket interrupt the blocking accept with an
      exception.
   3. When an exception is caught in "acceptConnections", pThis->closed
      is checked and if set to true, the thread loop is exited.
   4. The main thread, in the meanwhile, is waiting for this thread to join.
   5. Once the join happens, we are done.

I would again like to stress again that the previous code which calls
"Thread.stop()" ultimately stops the thread that makes that call, not
the thread that was spawned (at least on Win32). This has very critical
results for an operation as simple as a config reload. For this reason,
I believe this bug should be a blocker for the 0.10 release. Should I
open a bug on Jira about this?

PS: As far as I can see, there could be a similar problem in
"FileWatchdog::~FileWatchdog()" which calls "thread.stop" to stop the
thread that it has spawned. The right thing might be to set the
"interrupted" flag to  1 and wait for the thread to join again. However,
since the destruction of FileWatchDog happens at application shutdown
for us, it has not been a critical issue. For other applications, it
might be critical.

*Ufuk Kayserilioglu wrote:*
> For a while we have been using Log4CXX (somewhat) successfully in our
> project despite all its shortcomings. Since we feel that the release
> of 0.9.8 is close, we have started to port our codebase to the new
> version. Our program is a server application running on the Windows
> platform. We are using the Win32 src distribution obtained from
> http://littletux.homelinux.org/log4cxx/ on 16/05/2006.
>
> In our application we output some log data to the TelnetAppender and
> we were hit by an interesting bug during our testing. It appears that
> if you have a DOMConfigurator::configureAndWatch setup and your config
> file has a TelnetAppender, the initial configuration runs fine.
> However, if you change the file, when the platform tries to reload the
> config file the process stops before it can reinit the TelnetAppender.
> We have been able to trace the problem to the TelnetAppender::close()
> method which does a sh.stop(); on the handle which ultimately leads to
> the current running thread to exit because the underlying apr function
> calls _endthreadex(0). This stops all subsequent processing and even
> causes application instability. Moreover, if we skip over the
> sh.stop() call, then as soon as serverSocket->close() is called, we
> get an access violation due to an operation on the freed socket.
>
> It appears as if, the accept call should be somehow unblocked by the
> close method which should afterwards wait for the thread to join.
>
> Thanks for a great tool,
>
> Ufuk Kayserilioglu