[Glass] Cannot backup anymore while Seaside gems are running

Mariano Martinez Peck via Glass glass at lists.gemtalksystems.com
Mon Feb 6 10:28:59 PST 2017


On Mon, Feb 6, 2017 at 2:34 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> 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 ...
>

Ohh yes, another of the changes I did is to enable symbol GC as previously
I was not able to set it because it was broken for that GemStone version.


> 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:)
>
>
Yes, I was aware of the gc lock part.
And yes, I think your logic is good for the moment with --wait.


> 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> 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
>>
>>
>> _______________________________________________
>> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>> _______________________________________________ Glass mailing list
>> Glass at lists.gemtalksystems.com http://lists.gemtalksystems.co
>> m/mailman/listinfo/glass
>
> --
> Mariano http://marianopeck.wordpress.com
>
>


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


More information about the Glass mailing list