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

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

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