From: Jim Starkey
Date: March 10 2009 8:24pm
Subject: Re: Proposal: extension to Log interface to get error message written
 independently of falcon-debug-mask
List-Archive: http://lists.mysql.com/falcon/610
Message-Id: <49B6CC8D.1000008@nimbusdb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Looks fine to me.

Olav Sandstaa wrote:
> Hi,
>
> I have now implement this functionality. The main added functionality 
> to the Log class is:
>
> 1. A new debug mask called LogFatalError:
>
> This debug mask will be on by default for the Falcon log. It will not
> be disabled if the user provides a debug mask at startup or changes 
> the debug mask for a running server.
>
> 2. A new log method Log::fatal():
>
> Log messages written using this method will always be written to
> Falcon/MySQL's log file.
>
> Note that compare to my original proposal this debug mask will only be 
> on for the  original Falcon logger (StorageInterface::logger), not for 
> the "MySQL logger" (StorageInterface::mysqlLogger). Due to this the 
> default log mask is not completely maintained inside the Log class but 
> has to be set in when the Falcon logger is added to listen to the log 
> (in ha_falcon.cpp).
>
> The patch is available here:
>
>   http://lists.mysql.com/commits/68742
>
> It would be great if someone could have a look at the patch and either 
> give feedback or an OK to push it.
>
> Thanks,
> Olav
>
>
> Jim Starkey wrote:
>> Olav Sandstaa wrote:
>>>
>>> Based on the discussion we have had by email about writing to 
>>> MySQL's error log file and my need for always getting the error 
>>> message about problems to the serial log written independently of 
>>> what the status of the --falcon-debug-mask is, I propose following 
>>> extention to the Log:: interface:
>>>
>>> Alterantive 1 (based on Ann's suggestions in an earlier email):
>>> ===========
>>>
>>> * Introduce a new log category called "Fatal" (or something similar) 
>>> that always get written to the error log independently of what the 
>>> user has specified in the --falcon-debug-mask.
>>> * Example:
>>>
>>>       Log::log(Fatal, "This text will always go to the error log 
>>> file\n");
>>>
>>>    Note: This log category will possibly be documented in the MySQL 
>>> documentation along with the others, but the user not be allowed to 
>>> turn it off if she sets a debug-mask that does not enable it.
>>>
>>> Alternative 2:
>>> ==========
>>>
>>>  * Extend the Log:: interface with a new method called fatal() (or 
>>> error()) that will always write the message to the error log file
>>>  * Example:
>>>
>>>      Log::fatal("This text will always go to the error log file, and 
>>> by the way Falcon has just crashed\n");
>>>
>>>      or
>>>
>>>      Log::error("This text will always go to the error log file, and 
>>> by the way Falcon has just crashed\n");
>>>
>>>  * "Advantage" of this is that it does not interfere with the 
>>> falcon-debug-mask and the user visibility of this.
>>>
>>> Any strong preference for any of these? Any feedback or other 
>>> suggestions?
>>>
>>> PS: This is not about printf and clashes with the server's log 
>>> writing, it is just to define an interface that can be used for 
>>> messages that we want to get out with having the user needing to 
>>> specify an appropriate debug flag .
>>>
>>> Regards,
>>> Olav
>>>
>>> PS A bonus proposal: I consider removing the implementation of 
>>> Log::print() as it uses printf directly if there is no particular 
>>> use for it (I do not think it is used anywhere)
>>>
>>>
>>>
>>>
>> The two alternative are not mutually exclusive.  The primary 
>> mechanism is a new message class "Fatal".  There is also a secondary 
>> convenience method Log::fatal(const char*, ...) that logs the message 
>> with that bit in a manner analogous to Log::debug(const char*, ...).
>>
>
>


-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376