[wpkg-users] [Bug 234] Additional command line parameters /noquiet /notify etc

[Rainer Meier]

Hi Heiko,

On 29.08.2011 08:26, heiko.helmle at horiba.com wrote:
>  > MOD: Updated log file handling. Now there is no intermediate local log file
>  > created any more. Instead a log is kept in memory as long as the log file
>  > is not initialized. If anything goes wrong WPKG still tries to flush the
>  > logs at least to a log file in %TEMP%.
>  > This potentially increases efficiency and execution speed slightly.
>
> Does that mean there will be no log during WPKG-Processing - only at the end?
>
> Because if yes, this would make debugging a package a lot harder - I routinely
> look at the last log-line when a package is hanging or taking very long.

I guess you did not try it yet.
No. This does at no means say that the log file is kept in memory until WPKG 
finishes.

Let me explain a bit further.
WPKG first needs to do some initialization process (reading config.xml, reading 
XML files, parsing command line parameters etc.). The location and name of the 
log file is not known until a certain level of initialization has finished. Even 
worse in some cases when "[PROFILE]" is used within the log file name then WPKG 
even needs to know the profile(s) assigned to the host before it knows how the 
log file shall be named.

Until WPKG finishes all this initialization it does not know where to write the log.

Up to now WPKG was immediately creating a local log file in %TEMP%. As soon as 
all information was available it initialized the "real" log file and copied over 
all data from the local one. Usually it would contain log lines written during 
initialization.

If WPKG would have failed early in the initialization phase you would probably 
not see that on the server-side log but instead only within the log file in the 
local %TEMP% folder.

Writing a local log file and then (when all data is available) write a remote 
log file, re-open the old log file in read-only mode and copying over all log 
entries will take some time. To avoid this I've introduced a memory-buffer. WPKG 
will keep logs written during init process (when it does not yet know the target 
file location and name) into memory. As soon as this data is available it writes 
it to the real log file and starts to log exactly the same way as all earlier 
versions (immediate write to log file).

In case there is a failure during initialization WPKG will still try to write 
the log buffer to %TEMP% for traceability.

So for the user the change should be entirely transparent. But in most cases it 
will be more efficient as it will not create any temporary local log file in 
case everything goes well (normal execution case). So in 99.xx% of the cases 
where all goes fine it's more efficient.


br,
Rainer