Uploaded image for project: 'Log4cxx'
  1. Log4cxx
  2. LOGCXX-246

Config refresh hangs a client application that uses TelnetAppender

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 0.10.0
    • 0.10.0
    • Appender
    • None
    • Windows Server 2003

    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.

      Attachments

        1. telnet.patch
          0.4 kB
          Ufuk Kayserilioglu
        2. telnetappender.patch
          0.8 kB
          Ufuk Kayserilioglu

        Activity

          People

            carnold@apache.org Curt Arnold
            paracycle Ufuk Kayserilioglu
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - 10m
                10m
                Remaining:
                Remaining Estimate - 10m
                10m
                Logged:
                Time Spent - Not Specified
                Not Specified