[Glass] ObjectLogEntry considerations

[Mariano Martinez Peck via Glass]

On Wed, Nov 18, 2015 at 7:13 AM, Trussardi Dario Romano via Glass <
glass at lists.gemtalksystems.com> 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 ).
>
>

That MIGHT be related to the fact of RC classes holding up data.
Read the thread with subject: "RcIdentityBag holding deleted objects via
instVar "components"
In that thread I shared the cleanup I end up running as part of my daily
cleanup.
It's very important you run that code WITHOUT any other gem running.


>         Now my questions are:
>
>                 A) how i can view all the data into ObjectLogEntry ?
>

ObjectLogEntry objectLog inspect.
>From Seaside there is a WAObjectLog component which is very nice for
browsing it.
With tODE via command "ol view".


>
>                 B) The Transcript show: ',,,,,,,,, '  call by the
> methods,       are added to the ObjectLogEntry ?
>

Yes. Unless you explicitly disable that (very new feature we added with
Dale into Transcript).


>
>                 C) What else is added to the ObjectLogEntry ?
>


Errors, continuations, traces, etc.


>
>                 D) into deployment system when and who reset-clear the
> ObjectLogEntry
>


Depends on your app. With Dale and James we included an example in
ObjectLogEntry class exactly for this reason. So that you can customize and
create your own. I run that one everyday. See:
https://github.com/GsDevKit/GsDevKit/issues/71



>
>                 E) The background process to manage and recover  the
> freeSpace is very slow ( 5 hours )
>
>
Yes, reclaimAll is very very slow (I/O operations mostly). They say it is
faster in 3.2 (I come from 3.1.0.6) but I cannot confirm that.


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151118/f33ad467/attachment.html>