Details
Major Description
Some time ago, we spent some time migrating to the new 0.10 pre-release code-base. Upon checkout and build of Revision 582102, we found that there is a problem with the TelnetAppender.
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, then the platform tries to reload the config file and the process stops responding before it can reinit the TelnetAppender. It just hangs.
However, 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.
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.
