[Glass] ObjectLogEntry considerations

[Dale Henrichs via Glass]

Both Mariano and Johan are giving you good advice ... I add my 2 cents 
below ...

On 11/18/2015 02:13 AM, Trussardi Dario Romano via Glass wrote:
> Ciao folk,
>
> 	I open a new chapter, although aware that it is linked to the previous email.
>
> 	Into my deployment system the SystemRepository freeSpace decrease about 50 MB any day.
>
> 	But when investigate about it i found that this space is largely relative to the ObjectLogEntry.
>
> 	When i do:  		 ObjectLogEntry _objectLog size  	 the system answer:		0
>
> 	and i think it's all ok,   without error.
>
> 	When i do the fullBackup 	the relative file size is about 	4156MB
>
> 	After   i do the command:		ObjectLogEntry emptyLog
>
> 		the size of fullBackup file is about   759MB ( and MFC and relative cleanup running in background ).
>
> 	Now my questions are:
>
> 		A) how i can view all the data into ObjectLogEntry ?
I recommend that you use tODE and use the `ol view` command. Look at 
`man ol` to see the various operations supported. There is a pretty rich 
set of operations that can be performed:

NAME
   ol - View and manipulate object log entries

SYNOPSIS
   ol [--help] <command> [<options>] [ <priority>... ]

DESCRIPTION
   A <priority> is one of the following:

     debug
     error
     fatal
     interaction
     info
     trace
     transcript
     warn

   An empty <priority> implies the entire object log.

   Commands:
     clear Remove object log entries
     view  View object log entries

OPTIONS
   --help [<command>]
     Bring up this man page or a man page for a subCommand.

EXAMPLES
   ol --help

   ol view error
   ol view --inverse transcript
   ol view --age=`1 day` -r transcript
   ol view --continuation
   ol view --continuation --age=`1 month` error

   ol clear debug error trace
   ol clear --inverse transcript
   ol clear --age=`1 month`
   ol clear --continuation
   ol clear --continuation --age=`1 month` error

   NOTE - use the `tode it` menu item to run the examples directly from 
this window.

SEE ALSO

edit /tools/gs/bin/ol
   browse method --spec `TDGemStoneTool class>>ol`

   NOTE - use the `tode it` menu item to run the commands directly from 
this window.


>
> 		B) The Transcript show: ',,,,,,,,, '  call by the methods,	 are added to the ObjectLogEntry ?
Yes they are, but in recent versions of GLASS/GsDevKit, you can control 
whether or not the Transcript messages are logged to the gem log or the 
object log on a session by session basis.
>
> 		C) What else is added to the ObjectLogEntry ?
The Transcript entries are the only thing that are added in a standard 
GLASS/GsDevKit system. If you are using seaside, then continuations are 
added to the object log in the event of errors while handling requests. 
Also there are entries added when seaside gems are started and stopped ....

Use tODE and `ol view` to see more.
>
> 		D) into deployment system when and who reset-clear the ObjectLogEntry
In a deployed system, you should probably be looking for errors on a 
daily basis ... how long you keep error continuations is up to you ... 
if you use the object log to record import system events, then you may 
not want to completely clear the object log and simply clear out the 
continuations (which are likely to be consuming the majority of space) 
.... if you don't use the object log at all, then clear it as part of 
your weekly cleanup ...
>
> 		E) The background process to manage and recover  the freeSpace is very slow ( 5 hours )
> 			
> 			It's correct ?
There are ways to speed up these operations, but the cost is in 
increased SPC, faster disks, more extens .... the real question is "is 
it acceptable to have the free space reclaimed in 5 hours?" if it is not 
acceptable (adverse impact on other parts of the system), then you may 
want to invest the time in reading the manual, studying statmon output 
and learning ... if there is enough demand it is possible that we could 
put on tuning courses of some sort, but usually there is a cost 
associated with putting on such class ....

Dale