[Glass] " Waiting for vote to complete..." and the famous dev gem alive

[Dale Henrichs via Glass]

On 11/15/17 5:23 AM, Mariano Martinez Peck via Glass wrote:
> Hi,
>
> Remember that famous problem of letting a dev gem (from GemTools, 
> topaz, etc) connected to the stone and making all kind of problems?
> Well, I was making a backup with tODE like this:
>
> bu backup --wait --commit betaTesting1_333_backup_20171115_033542.dbf.gz
>
> BTW, note the --wait.
>
> My question is ... I thought tODE fixed this issue (by hocking in 
> TransactionBacklog defaultHandler??) but it seems it's still happening 
> to me.
Hmmmm, the tODE code itself doesn't have any references to the 
TransactionBacklog class and I don't see any references 
TransactionBacklog in the tODE issues (opened or closed), so I'm not 
sure where you got that idea?

TransactionBacklog is involved but on the other end. The `--wait` flag 
was added for those cases where you have done an MFC right before doing 
a backup and you want the backup to wait for the vote following the mfc 
to complete instead of failing the backup (which was the old behavior).

If w look at the implementation of 
TDGemStoneTool>>buBackup:waitForVotingToComplete:safely:uncompressed:validate: 
and the block that is invoked when the `--wait` flag is used

   waitForVotingToComplete
     ifTrue: [
       Transcript
         cr;
         show: 'Waiting for vote to complete...'.
       self waitForVoteStateIdle.
       self
         checkGcLock: [ :sessionHoldingGcLock |
           self
             error:
               'System has completed voting, but the gc lock is still 
being held by session with id '
                 , sessionHoldingGcLock printString , '.' ].
       Transcript show: 'Vote complete.' ]

we see that #waitForVoteStateIdle is what `--wait` is waiting for... and 
if you follow the chain to System class>>voteState this is the list of 
vote states involved:

   0 IDLE, 1 HIDING_SYMBOLS, 2 VOTING, 3 DONE_VOTING, 4 IN_PDWSU_SWEEP, 
5 PDWSU_DONE

and I think that vote states 4 and 5 prevent a backup from starting (and 
were causing errors previous to the introduction of `--wait`) ... I also 
think that immediately following an MFC the system goes into state 2 
.... and this is the point where TransactionBacklog comes into play ...

The `--wait` code waits for voting to be completed ... as I've already 
said the original purpose of the --wait flag was to allow MFC to finish 
NORMALLY before attempting to run the backup, however idle (or active) 
sessions will not vote until they have crossed a transaction boundary.

The TransactionBacklog notification is something that gems can implement 
a handler for to avoid running into commit record backlog issues --- the 
TransactionBacklog notification is signalled when a certain commit 
record backlog threshold is crossed --- we do not signal the 
TransactionBacklog to force a vote ... and now that I think about it, 
you have likely installed TransactionBacklog in your application so that 
idle gems won't cause commit record backlogs ...

This of course raises the question about whether or not the 
TransactionBacklog notivication can/should be used to inform idle 
sessions that they should vote --- so that the combo MFC then BACKUP can 
proceed without "waiting for the cr backlog to climb" ...

Does this make sense?

I will submit an internal bug, if you think this is worth doing...

Dale