Bug 45335 - NDC.remove NullPointerException
Summary: NDC.remove NullPointerException
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.2
Hardware: PC Linux
: P2 major
Target Milestone: ---
Assignee: log4j-dev
Depends on:
Reported: 2008-07-03 12:50 UTC by Derek Scherger
Modified: 2008-08-07 20:24 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Derek Scherger 2008-07-03 12:50:07 UTC
calling NDC.remove during tomcat shutdown results in a NullPointerException

Jul 3, 2008 1:09:51 PM org.apache.coyote.http11.Http11BaseProtocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
Jul 3, 2008 1:09:51 PM org.apache.catalina.core.AprLifecycleListener lifecycleEvent
INFO: Failed shutdown of Apache Portable Runtime
Exception in thread "error" java.lang.NullPointerException
	at org.apache.log4j.NDC.remove(NDC.java:377)
	at ProcessMonitor$1.run(ProcessMonitor.java:44)
	at java.lang.Thread.run(Thread.java:619)
Exception in thread "exit" java.lang.NullPointerException
Exception in thread "response" 	at org.apache.log4j.NDC.remove(NDC.java:377)
	at ProcessMonitor$2.run(ProcessMonitor.java:83)
	at java.lang.Thread.run(Thread.java:619)
	at org.apache.log4j.NDC.remove(NDC.java:377)
	at ProcessMonitor$3.run(ProcessMonitor.java:114)
	at java.lang.Thread.run(Thread.java:619)

Glancing at the source for NDC.java it appears the the ht hashtable variable is null at this point in the tomcat shutdown sequence. I notice that some of the other places in NDC that refer to ht check that it is not null.

Two other minor things I notice in NDC:

1. bogus comment
  // The synchronized keyword is not used in this class. This may seem
  // dangerous, especially since the class will be used by
  // multiple-threads. In particular, all threads share the same
  // hashtable (the "ht" variable). This is OK since java hashtables
  // are thread safe. Same goes for Stacks.

However the lazyRemove method synchronizes on ht while checking the pushCounter.

2. another bogus comment

  // The number of times we allow push to be called before we call lazyRemove
  // 5 is a relatively small number. As such, lazyRemove is not called too
  // frequently. We thus avoid the cost of creating an Enumeration too often.
  // The higher this number, the longer is the avarage period for which all
  // logging calls in all threads are blocked.
  static final int REAP_THRESHOLD = 5;

The lazyRemove method is NOT called by push, it is only called by remove.

Comment 1 Curt Arnold 2008-08-07 20:24:11 UTC
Committed rev 683824.  See bug 40212 and 43867 about issues with Tomcat unloading.