Details

    • Type: Task Task
    • Status: Resolved Resolved (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 3.3
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      log4j has some heavy synchronization, which can sometimes lead to code blocking up to 30 seconds (see [1]).

      Investigate whether we should switch to log42 [2]. Perhaps we can simply program against the API (30K) and not even ship the implementation ?

      [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51047

      [2] http://logging.apache.org/log4j/2.x/

        Issue Links

          Activity

          Hide
          David Lloyd
          added a comment -

          Programming against an API is a good idea. Log4j does suck pretty badly, hence our replacement of it inside of AS as a backend. I won't rehash any arguments but I do want to point out (again) a few options:

          • JBoss Logging is a nice clean API and easy to use, and works against any backend (auto-detected); only one JAR is needed (plus the selected backend JAR, if any; if none is present then plain JUL is used).
          • SLF4J is simple though not as fully-featured, but requires an impl JAR (this API is also supported in AS)
          • Coding to the log4j API will still work in AS (we have our own implementation which uses our own backend).

          If you use either of the first two approaches, you can bundle jboss-logmanager for your tests (if your tests entail logging) and get some nicely formatted output with pretty easy config, and good performance as well. It works for the third approach as well but it's complex enough that you probably wouldn't want to bother with it.

          Show
          David Lloyd
          added a comment - Programming against an API is a good idea. Log4j does suck pretty badly, hence our replacement of it inside of AS as a backend. I won't rehash any arguments but I do want to point out (again) a few options: JBoss Logging is a nice clean API and easy to use, and works against any backend (auto-detected); only one JAR is needed (plus the selected backend JAR, if any; if none is present then plain JUL is used). SLF4J is simple though not as fully-featured, but requires an impl JAR (this API is also supported in AS) Coding to the log4j API will still work in AS (we have our own implementation which uses our own backend). If you use either of the first two approaches, you can bundle jboss-logmanager for your tests (if your tests entail logging) and get some nicely formatted output with pretty easy config, and good performance as well. It works for the third approach as well but it's complex enough that you probably wouldn't want to bother with it.
          Hide
          Bela Ban
          added a comment - - edited

          Hi David,

          here are my requirements:

          1. Add vararg log methods to Log [1], e.g. trace(String format, Object... params);
          2. Replace log4j, possible candidates so far:
            1. log4j2
            2. jboss-logging
          3. I currently support JUL and log4j as backends, and these need to be supported. If more backends can be supported, even better
          4. Minimize the number of JARs to be used
          5. No pre-processing phase (mvn or ant)
          6. Ability to change the log level at runtime. This is an issue for me with log4j2, which doesn't support this anymore. It's not enough to be able to periodically reparse the config file, as I want to do this across a cluster, via probe.sh op=UDP.setLevel["trace"]
            1. Derived from above: extensibility. I might want to extend a logging impl to provide this feature. Or users might ant to provide their own logging frameworks.

          If you tell me that I need only 1 JAR (plus the backend, but that's up to the deployer), than that sounds appealing. I looked at jboss-logging on GitHub, but am unsure which project I should use there. Do you have documentation on jboss-logging ? I googled, but I think I hit old documentation...

          [1] https://github.com/belaban/JGroups/tree/master/src/org/jgroups/logging
          [2] https://github.com/jboss-logging

          Show
          Bela Ban
          added a comment - - edited Hi David, here are my requirements: Add vararg log methods to Log [1] , e.g. trace(String format, Object... params); Replace log4j, possible candidates so far: log4j2 jboss-logging I currently support JUL and log4j as backends, and these need to be supported. If more backends can be supported, even better Minimize the number of JARs to be used No pre-processing phase (mvn or ant) Ability to change the log level at runtime. This is an issue for me with log4j2, which doesn't support this anymore. It's not enough to be able to periodically reparse the config file, as I want to do this across a cluster, via probe.sh op=UDP.setLevel ["trace"] Derived from above: extensibility. I might want to extend a logging impl to provide this feature. Or users might ant to provide their own logging frameworks. If you tell me that I need only 1 JAR (plus the backend, but that's up to the deployer), than that sounds appealing. I looked at jboss-logging on GitHub, but am unsure which project I should use there. Do you have documentation on jboss-logging ? I googled, but I think I hit old documentation... [1] https://github.com/belaban/JGroups/tree/master/src/org/jgroups/logging [2] https://github.com/jboss-logging
          Hide
          David Lloyd
          added a comment -

          We support all of those, except for #6 (though I am pretty sure we can add that). (Also - log4j2 seriously doesn't support runtime level changes? Yikes...)

          Actually #5 is actually a "so-so" kind of thing. To support the i18n stuff we're supposed to support, you do need one additional compile-time-only JAR, but it uses Javac's built-in and standard annotation processing mechanism, so it works fine even if you just run javac on the command line. If you do not use the i18n mechanism though, that part is completely optional. But beyond that, it's just one JAR at runtime (plus the backend of choice, if it != JUL).

          Show
          David Lloyd
          added a comment - We support all of those, except for #6 (though I am pretty sure we can add that). (Also - log4j2 seriously doesn't support runtime level changes? Yikes...) Actually #5 is actually a "so-so" kind of thing. To support the i18n stuff we're supposed to support, you do need one additional compile-time-only JAR, but it uses Javac's built-in and standard annotation processing mechanism, so it works fine even if you just run javac on the command line. If you do not use the i18n mechanism though, that part is completely optional. But beyond that, it's just one JAR at runtime (plus the backend of choice, if it != JUL).
          Hide
          David Lloyd
          added a comment -

          The project is here: https://github.com/jboss-logging/jboss-logging

          There are no docs other than JavaDoc; just use the Logger class in the obvious way. Methods that end in "f" or "v" are varargs; the "f" variants use printf-style formatting and the "v" variants use MessageFormat-style formatting.

          Example:

              static final Logger log = Logger.getLogger("org.myproject");
          
              // ... later on ...
              log.debugf("Flop the frob (%s)", frob); // or ...
              log.debugv("Flop the frob ({0})", frob);
              // ... etc ...
          
          Show
          David Lloyd
          added a comment - The project is here: https://github.com/jboss-logging/jboss-logging There are no docs other than JavaDoc; just use the Logger class in the obvious way. Methods that end in "f" or "v" are varargs; the "f" variants use printf-style formatting and the "v" variants use MessageFormat-style formatting. Example: static final Logger log = Logger.getLogger( "org.myproject" ); // ... later on ... log.debugf( "Flop the frob (%s)" , frob); // or ... log.debugv( "Flop the frob ({0})" , frob); // ... etc ...
          Hide
          Bela Ban
          added a comment -

          Thanks David,

          I'll take a look

          Show
          Bela Ban
          added a comment - Thanks David, I'll take a look
          Hide
          Bela Ban
          added a comment -

          log4j2:

          • Requires 2 JARs: API and CORE
            • We could copy the required API code (mainly LogManager.getLogger()) into JGroups's LogFactory ...
          • The level cannot be set at runtime, unless we downcast the Logger to its implementation class (setting the level is not exposed in the interface).
          Show
          Bela Ban
          added a comment - log4j2: Requires 2 JARs: API and CORE We could copy the required API code (mainly LogManager.getLogger()) into JGroups's LogFactory ... The level cannot be set at runtime, unless we downcast the Logger to its implementation class (setting the level is not exposed in the interface).
          Hide
          Bela Ban
          added a comment - - edited

          jboss-logging:

          • meta-logging framework, does the same as what JGroups org.jgroups.logging already does
          • Easy to use
          • Provides logging adapters for JBoss, log4j, JUL and slf4j
          • Does not provide adapter for log4j2 or logback

          I think I'm going to go with log4j2 for now, with the following changes:

          • Hack support for setting the level at runtime
          • Use only the CORE JAR and copy the relevant part of the API JAR (creation of loggers) into JGroups's Log4j2LogImpl
          Show
          Bela Ban
          added a comment - - edited jboss-logging: meta-logging framework, does the same as what JGroups org.jgroups.logging already does Easy to use Provides logging adapters for JBoss, log4j, JUL and slf4j Does not provide adapter for log4j2 or logback I think I'm going to go with log4j2 for now, with the following changes: Hack support for setting the level at runtime Use only the CORE JAR and copy the relevant part of the API JAR (creation of loggers) into JGroups's Log4j2LogImpl

            People

            • Assignee:
              Bela Ban
              Reporter:
              Bela Ban
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: