You are here: Foswiki>Tasks Web>Item12384 (05 Jul 2015, GeorgeClark)Edit Attach

Item12384: Logger issues causes statistics crash.

Priority: Urgent
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Engine
Component: FoswikiLogger, FoswikiUIRegister, FoswikiUIStatistics
Branches: Release01x01 trunk
Reported By: GeorgeClark
Waiting For:
Last Change By: GeorgeClark
There are a couple of issues.

  • The new logger API doesn't set a Web.Topic name if omitted from the log call.
  • Statistics crashes if Web.Topic is undefined.
  • Register logs malformed "Web.Topic(user) - 1" when allowLoginName is permitted.
  • log calls that build the "extra" field should use named fields, and leave it to the logger to concatenate them into $extra if it doesn't have a defined disposition.

Logger should set a default Web.Topic if available, statistics should skip records with missing Web.Topic, and Register should log extra data into the "Extra" field, not into the topic name field.

Also discovered that statistics scans the log record trying to find a field that maps and returns a canonical userid. If for any reason the user misses, it shifts through all fields, and runs out of fields to log. So removing a user will cause statistics to mis-process the log records.

Crawford, can you look over this part of the Statistics process? Everything I've seen in the loggers assumes that the files are in a fixed field layout, I don't understand why the record is scanned trying to find a Canonical ID. I'd rather address the log parsing in the Logger eachEventSince routine and ensure that a username is returned if available, maybe return the UnknownUser if it isn't?

Do you have a corpus of old log records that eachEventSince needs to reliably scan? This would be really helpful.

-        while ( !$logFileUserName && scalar(@$line) ) {
-            $logFileUserName = shift @$line;
-            # Use Func::getCanonicalUserID because it accepts login,
-            # wikiname or web.wikiname
-            $logFileUserName =
-              Foswiki::Func::getCanonicalUserID($logFileUserName);
-        }

+        $logFileUserName = shift @$line;
+        # Use Func::getCanonicalUserID because it accepts login,
+        # wikiname or web.wikiname
+        my $canonicalUID = Foswiki::Func::getCanonicalUserID($logFileUserName);
+        $logFileUserName = $canonicalUID if ($canonicalUID);

I looked through the history of this code (a long way back) and think the scan happens because a very old version of the logger code generated records that had one or more blank fields at the start of some records, and the scan helped to make the code more robust to this circumstance.

My reaction is "bugger old log records" - a failing log file needs to be (manually) rotated out, simple as that.

-- CrawfordCurrie - 15 Mar 2013
Topic revision: r14 - 05 Jul 2015, GeorgeClark - This page was cached on 18 Sep 2021 - 01:52.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy