[Glass] Stone startup delayed by reading

[Dale Henrichs via Glass]

Marten,

This situation occurs ("Stone startup delayed by reading 535481 
outstanding commit records.") when you stop a stone that has an 
outstanding commit record backlog.

The most common reason for a commit record backlog is to have a 
development session (topaz, tODE, Jade)  logged in while your system is 
actively committing. When you shut down a stone, the commit records are 
written to disk (most of which are probably already on disk) and the 
stone exits ... when the stone starts up, it has to process all of the 
outstanding commit records before going into normal operation.

Soooo, if you are seeing this over multiple start/stop stone sessions, 
then you are apparently creating a _new_ commit record backlog before 
stopping the stone ...

So I think that you should try to track down the session that is causing 
the commit record backlog ...

Before we get too far into this, I want to rule out the most common 
cause: a development session sitting idle while a production/dev system 
is doing commits.

If you've got this situation, you should stop leaving your development 
session logged in during heavy commits and or do a `SystemRepository 
reclaimAll` in your development evironment before stopping the stone and 
after shutting down all of your headless vms ... be sure to do a commit 
or abort in the your dev environment before running reclaimAll ..

If you are not leaving a dev environment idle, then your headless 
servers need to be responding to SigAbort signals and that is done by 
code that looks something like the following:

System transactionMode: #manualBegin.

Exception
   installStaticException:
     [:ex :cat :num :args |
       "Run the abort in a lowPriority process, since we must acquire the
        transactionMutex."
       [
         GRPlatform current transactionMutex
           critical: [
             GRPlatform current doAbortTransaction ].
         System enableSignaledAbortError.
       ] forkAt: Processor lowestPriority.
     ]
   category: GemStoneError
   number: 6009
   subtype: nil.
System enableSignaledAbortError.
"This thread is needed to handle the SigAbort exception, when the primary
  thread is blocked on an accept. Assuming default 60 second
  STN_GEM_ABORT_TIMEOUT, wake up at 30 second intervals."
[
   [ true ] whileTrue: [ (Delay forSeconds: 30) wait ].
] forkAt: Processor lowestPriority.


If you are not leaving dev environments idle and you have code like the 
above in your headless vms ... then we need to hunt down the session 
that is creating a commit record backlog ...

Dale


On 06/22/2016 01:03 AM, Marten Feldtmann via Glass wrote:
>
> When I started my stone during the last days i noticed a much longer 
> startup time of my stone. looking through my log-files I noticed the 
> following lines. What happened here ?
>
>
> ...
> Totals
>   ------
>   Repository Size = 110320 Mbytes = 7060480 pages
>   Free Space = 55955 Mbytes = 3581166 pages
>   ---------------------------------------------------
>   Started AIO page server, processId 3707
>   Stone startup delayed by reading 535481 outstanding commit records.
>   535000 remaining to be read
>   534500 remaining to be read
>   534000 remaining to be read
> ...
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160622/a5d2ab4a/attachment-0001.html>