Our log4j usage should contain more diagnostic information.

For example the user name, asessionid, request id could all be placed in log lines so that we have yet more evidence to use when debugging problems.

With the new HTTP access log in JIRA, there becomes a nice symmetry between requestId/asessionId and the general JIRA log file.

This is a revival of what Anton did for shipit in the past. Use log4j MDC to hold per request information and have this defined in the log4j.properties.

One can imagine something like this

2009-02-10 17:00:33,854 http-8090-Processor6  {1234155568686-12-1}  9354B2BB99EC8DA8F84839BA05620C86 admin INFO [jira.issue.index.DefaultIndexManager] Optimising the index because 4000 issues have been re-indexed since last optimise. Threshold is 4000.

This marries well with the new HTTP access log format of

127.0.0.1 o{1234155568686-12-1} admin [09/Feb/2009:15:59:28 +1100] "GET http://localhost:8090/jira/secure/admin/jira/ViewLogging.jspa HTTP/1.1" 200 13492 0.0640 "http://localhost:8090/jira/secure/admin/jira/ViewLogging.jspa" "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121623 Ubuntu/8.10 (intrepid) Firefox/3.0.5" "9354B2BB99EC8DA8F84839BA05620C86"

NOTE : the session if shown here is a hash of the JSESSIONID and hence its ok to leak it. The JESSESSIONID should never be logged.