[Glass] Cannot backup anymore while Seaside gems are running

[Dale Henrichs via Glass]

Mariano,

A call to #fullCompressedBackup: would have failed with a "failed to 
acquire gc lock error message" so what appears to be happening now is 
that you hit a gc operation that was taking a long time to complete ... 
we know that if you have symbol gc enabled it can take a noticeable 
amount of time to gc symbols if you have a lot of dead symbols to deal 
with ... there are other operations (getting the voteState and the 
session id holding the lock (plus stats and log files) would allow us to 
determine just what was going on ...

Voting is not the only operation that could prevent a backup from 
running. Both an object audit or list instances acquires the gc lock and 
would prevent a backup from running with a voteState of 0, I will 
probably check for the gc lock as part of the `--wait` option, but I'm 
not sure that I will wait for the lock to be freed in those cases .... 
we'll cross that bridge when we come to it:)

Dale


On 02/06/2017 09:12 AM, Mariano Martinez Peck wrote:
>
>
> On Mon, Feb 6, 2017 at 1:52 PM, Dale Henrichs via Glass 
> <glass at lists.gemtalksystems.com 
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>     oh, and I think I will make some changes to the `bu backup`
>     command ... first instead of just printing the the `Please wait
>     ...` message, I will include the voteState and or session holding
>     gc lock in the message ... I will also add a `--wait` so that the
>     backup will wait until the voting is completed before making the
>     backup ... at least then the `bu backup` command can be used in a
>     cron job and ensure that the backup gets executed as soon as
>     voting is complete ...
>
> OK. I think the --wait is exactly what I need. Because on my cron job, 
> I fire the cleaning (MFC included) and then the `bu backup`. So...my 
> next question was going to be ... "how can I then wait until vote is 
> done so that my backup script work".
>
> Great. I will wait for your changes then.
>
> BTW, do you know why it worked for me before? I was doing the 
> fullCompressedBackup: myself... (rather than `bu backup`) so I was not 
> validating any voteState explicitly. Could that be the difference?
>
> Thanks in advance,
>
>
>     Dale
>
>
>     On 02/06/2017 08:47 AM, Dale Henrichs wrote:
>>
>>     Mariano,
>>
>>     The `Please wait...` message is displayed, because voting is
>>     ongoing, or another process is holding onto the gc lock (see
>>     TDGemStoneTool>>systemIsVoting):
>>
>>       systemIsVoting
>>         | vs sessId |
>>         vs := System voteState.
>>         sessId := System sessionIdHoldingGcLock.
>>         ^ sessId ~= 0 or: [ vs > 0 and: [ vs < 4 ] ]
>>
>>     It would probably help the see what the voteState is and which
>>     session is holding the GcLock. You could pass those results along
>>     as soon as you get them.
>>
>>     The next step will be to supply us with some statmon files and
>>     your log files that cover a failed backup.
>>
>>     Dale
>>
>>     PS: if you look at the man page for the backup command (`man bu
>>     backup`), you'll see a line near the bottom that looks like this:
>>
>>       browse method --spec `TDGemStoneTool>>bubackup`
>>
>>     All man pages should have a line like this (not all have this
>>     yet:) that will take you directly to the method that implements
>>     the command .. then you can set a breakpoint in the that method
>>     for debugging/understanding what's going on in a command ... I
>>     know that in this case it wouldn't necessarily solve the problem,
>>     but I did figure it was worth pointing out for future reference ...
>>
>>     On 02/06/2017 07:27 AM, Mariano Martinez Peck via Glass wrote:
>>>     Hi,
>>>
>>>     Previously I was able to make backups while my Seaside gems were
>>>     running. Now, whenever I try to make a backup while they are
>>>     running, I get this error:
>>>
>>>     * 'Please wait until system is no longer voting and try again'*
>>>
>>>     Of course I get that error even after shutting down the stone
>>>     and starting again. And even waiting for a long time.
>>>
>>>     The way I make the backups are:
>>>
>>>     $GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile
>>>
>>>     Both `system.conf` and `gem.conf` have this setting:
>>>
>>>     $GS_HOME/bin/todeIt $stoneName bu backup --commit $backupfile
>>>
>>>
>>>     Now...if I shut down the seaside gems, the backup does work.
>>>
>>>     Any idea what I am doing wrong? I am on GemStone 3.3.3.
>>>
>>>     Thanks,
>>>
>>>
>>>     -- 
>>>     Mariano
>>>     http://marianopeck.wordpress.com <http://marianopeck.wordpress.com>
>>>
>>>
>>>     _______________________________________________
>>>     Glass mailing list
>>>     Glass at lists.gemtalksystems.com
>>>     <mailto:Glass at lists.gemtalksystems.com>
>>>     http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>     <http://lists.gemtalksystems.com/mailman/listinfo/glass>
>     _______________________________________________ Glass mailing list
>     Glass at lists.gemtalksystems.com
>     <mailto:Glass at lists.gemtalksystems.com>
>     http://lists.gemtalksystems.com/mailman/listinfo/glass
>     <http://lists.gemtalksystems.com/mailman/listinfo/glass> 
>
> -- 
> Mariano http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170206/6230746f/attachment-0001.html>