DO NOT REPLY [Bug 33855] New: - Log4j should supply concurrent (and deadlock-free) appender classes

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33855>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33855

           Summary: Log4j should supply concurrent (and deadlock-free)
                    appender classes
           Product: Log4j
           Version: 1.3alpha
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Appender
        AssignedTo: log4j-dev@logging.apache.org
        ReportedBy: eross@m-qube.com


Justifaction:

"Why is such a package needed?"

In today's world of hyper-threaded, multi-processor application servers,
inevitably there is a need (like any application server library) for a
scalable logging solution.

"Okay, but it's not like you're logging 100 times a second..."

Not necessarily.  When diagnosing problems in a running server, one
often has to turn on and turn off logging, hopefully without disrupting
processing that is occurring on a live system.

It would also be a good basis for appenders that could greatly benefit
from concurrency, such as SNMP, JDBC, JMS appenders.  There wouldn't be
any need to lock these as each thread.  As each log event is relatively
expensive, concurrency would _greatly_ improve these classes, as one
thread would not need to hold a lock for 10-30 milliseconds, for
example.

Often times, a large amount of logging occurs during outage situations. 
When a database hiccups, or a Servlet class fails (due to bugs), the
server tries to log 1000 times a second, causing unrelated threads to
block as well.  Could log4j bring your server to its knees?

"Why not just use the Async appender?"

This would improve matters, but it does not allow for synchronous
logging of events or take advantage of multi-processors.  A possible fix
for the latter problem would be creating a thread pool, which would have
to be tuned for the installation.

"Why not fix the existing appender classes?"

Unfortunately, there would be a lot of compatibility problems.  Anybody
who extended an existing appender class in their own code expects
locking to behave in a particular way.  (This is the "Inheritance breaks
encapsulation" anti-pattern.)

"Nobody would use it.  Nobody cares.  Why not create it yourself?"

I'm somebody, aren't I?  I care.

I think the log4j project and its users would benefit with an integrated
solution, rather than one that comes from an unknown source such as
myself.  Plus, log4j could itself leverage such a library.

In addition, it'd be another simple reason log4j beats
java.util.logging.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org