[Glass] Backup procedure

[Dale Henrichs via Glass]

On 07/24/2015 06:52 AM, Mariano Martinez Peck via Glass wrote:
>
>
> On Fri, Jul 24, 2015 at 10:51 AM, Mariano Martinez Peck 
> <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>
>
>
>     On Fri, Jul 24, 2015 at 10:18 AM, Trussardi Dario Romano via Glass
>     <glass at lists.gemtalksystems.com
>     <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>         Ciao Mariano,
>
>>
>>
>>         On Tue, Jun 9, 2015 at 1:50 PM, Dale Henrichs
>>         <dale.henrichs at gemtalksystems.com
>>         <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>
>>
>>
>>             On 06/09/2015 07:13 AM, Mariano Martinez Peck wrote:
>>
>>
>>
>>                 Ok, it makes sense your analysis. Thanks.
>>                 BTW....if I set 100% and I do not stop/start seaside
>>                 gems, I am still fine not restarting seaside
>>                 maintenance vm AND i am also find with the backup
>>                 code (besides MFC)? I mean, won't the running seaside
>>                 gems affect at all to the backup? I guess not, but
>>                 just want to confirm.
>>
>>
>>
>>             Keep in mind that even with 100% setting, references from
>>             temp objects to persistent objects will still count as
>>             references to the object and will vote down the gc ...
>>             clearing POM means that the cached values (in POM) won't
>>             count as references...
>>
>>             When the backup runs, it backs up the state of the system
>>             from a given checkpoint (point in time), any changes by
>>             running gems that may have been made while the backups
>>             were being written are saved in the tranlogs so it is
>>             definitely safe to run backups while other gems are running.
>>
>>
>>         Thanks Dale.
>>
>
>>
>>         BTW... I have just changed the MFC part of the script I
>>         pasted at the beginning of the thread. I used to do myself
>>         the #markForCollection as you can see. However, I think the
>>         code implemented by WAGemStoneMaintenanceTask class >>
>>         #maintenanceTaskMarkForCollect is much better, because it
>>         prints some results into the ObjectLog. So instead of doing
>>         "SystemRepository markForCollection."
>
>
>
>>         I am now doing: "WAGemStoneMaintenanceTask
>>         maintenanceTaskMarkForCollect performTask: 0.".
>
>         But this does not conflict with what you wrote:
>
>>>         BTW...be careful with "    I think to run markForCollection
>>>         ". If you are using the glass scripts "runSeasideGems30"
>>>         that will be running a maintenance vm which will be running
>>>         MFC every hour. To disable that, what I am doing is as part
>>>         of my load code I do:
>>>
>>>         (Smalltalk at: #WAGemStoneMaintenanceTask) removeTaskNamed:
>>>         'Mark For Collect'.
>>>         Note that you must do that as part of your post-load code or
>>>         similar because if you happen to load a new version of
>>>         seaside packages at some point, it might fire again the
>>>         class side #initialize and hence rebuild the tasks.
>>>
>
>         How i can understand if Mark For Collectis running
>         automatically every hour?
>
>
>     This will be the case if you start the Seaside maintenance VM as
>     part of your seaside gems. How do you start your seaside gems?
>
>     Also...do a .. "ps -fea | grep mainten"  if you see an entry like
>     this:
>
>     betates+ 30176     1  0 Jul10 ?        00:00:31
>     /opt/gemstone/product/bin/topaz -l -q -e
>     /opt/gemstone/product/seaside/etc/maintenance30.conf -I
>     /xxx/sites/betaTesting1/gemstone/.topazini
>
>     It means it IS indeed running.
>
>     Or check the ObjectLog (the maintenance gem writes some output in
>     the object log) (I use WAObjectLog tool).
>
>     Or.. see if you have a maintenance_gem.log in the folder where
>     your gemstone logs are.
>
>     Or.... are sessions being expired? I mean...if you have defined a
>     seaside timeout of say...45 minutes. And you do nothing in a
>     session and come back after 2 hours. Has the session been expired?
>     If true, the maintenance vm have been running. If so... then it
>     should also be doing a MFC every hour.
>
>     There was also a method that answered the last time the MFC was
>     run I think..but I cannot remember which one...
>

This is a good list from Mariano. I would add, that you should inspect 
the result of:

   WAGemStoneMaintenanceTask tasks

and if it looks like the following:

.            -> anOrderedCollection( Mark For Collect, Seaside Session 
Expiration)
(class)@     -> OrderedCollection
(oop)@       -> 257463553
(committed)@ -> true
(size)@      -> 2
1@           -> Mark For Collect
2@           -> Seaside Session Expiration


(Specifically including the `Mark for Collect` task) AND you are running 
the maintenance VM, then you are running an MFC ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150805/7bd6a7ec/attachment.html>