Log4cxx
  1. Log4cxx
  2. LOGCXX-256

SocketHubAppender fails after accepting connection

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.10.0
    • Component/s: Appender
    • Labels:
      None

      Description

      On Mar 6, 2008, at 8:57 PM, Dale King wrote:

      What is the status of using Log4Cxx 0.10.0 RC2 with the current
      version of chainsaw? Here is my experience:

      • Reading an XMLLayout log file created by log4cxx, works perfectly
        including location information and MDC properties (when turned on in
        the layout).
      • Using an XMLSocketAppender wroks but I get no location information
        or MDC properties on the chainsaw side and I get annoying trace
        messages from chainsaw in the log for looking up the entities because
        it shows up in the chainsaw log
      • SocketAppender works, but once again no location information or MDC properties
      • SocketHubAppender connects, but then does nothing. I get no loging pane.

      Is this the expected behavior? I found the properties on
      XMLSocketAppender to turn on location information, but it did not seem
      to matter. My configuration file looks like this:

      log4j.rootLogger=TRACE, A1, socketLogger

      log4j.appender.A1=org.apache.log4j.FileAppender

      log4j.appender.A1.filename=log.xml
      log4j.appender.A1.layout=org.apache.log4j.XmlLayout
      log4j.appender.A1.layout.properties=true
      log4j.appender.A1.layout.locationinfo=true

      log4j.appender.socketLogger=org.apache.log4j.net.XMLSocketAppender
      log4j.appender.socketLogger.RemoteHost=localhost
      log4j.appender.socketLogger.Port=4448
      log4j.appender.socketLogger.locationinfo=true


      Dale King

        Activity

        Hide
        Curt Arnold added a comment -

        Committed fixes in rev 640703.

        The next call to accept after connecting with chainsaw would fail with an EWOULDBLOCK which would result in a SocketException that would shut things down. Instead, the EWOULDBLOCK should throw an InterruptedIOException which would correspond to an timeout expiration in Java.

        accept appears to ignore the timeout, so a 1 second sleep is added in the catch block of InterruptedIOException.

        The connection loop did not check an updated value of close, so the loop would not end unless there was an exception.

        The ObjectOutputStream was not flushed.

        With those fixes, a simple test case on Mac OS/X did appear to work properly.

        Show
        Curt Arnold added a comment - Committed fixes in rev 640703. The next call to accept after connecting with chainsaw would fail with an EWOULDBLOCK which would result in a SocketException that would shut things down. Instead, the EWOULDBLOCK should throw an InterruptedIOException which would correspond to an timeout expiration in Java. accept appears to ignore the timeout, so a 1 second sleep is added in the catch block of InterruptedIOException. The connection loop did not check an updated value of close, so the loop would not end unless there was an exception. The ObjectOutputStream was not flushed. With those fixes, a simple test case on Mac OS/X did appear to work properly.

          People

          • Assignee:
            Curt Arnold
            Reporter:
            Curt Arnold
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development