content_image/798151.jpg content_image/798157.jpg content_image/798160.jpg
<img src='content_image/798151.jpg'>

This parameter sets an upper limit in seconds for trying to write a given redo log to disk before timing out. The number of times the data node tries to flush this redo log, but takes longer than RedoOverCommitLimit , is kept and compared with RedoOverCommitCounter , and when flushing takes too long more times than the value of that parameter, any transactions that were not committed as a result of the flush timeout are aborted. When this occurs, the API node where any of these transactions originated handles the operations making up those transactions according to its DefaultOperationRedoProblemAction  setting (it either queues the operations to be re-tried, or aborts them). 

Controlling restart attempts.  It is possible to exercise finely-grained control over restart attempts by data nodes when they fail to start using the MaxStartFailRetries  and StartFailRetryDelay  data node configuration parameters. 

MaxStartFailRetries  limits the total number of retries made before giving up on starting the data node, StartFailRetryDelay  sets the number of seconds between retry attempts. These parameters are listed here: 

• StartFailRetryDelay 

<img src='content_image/798157.jpg'>

Use this parameter to set the number of seconds between restart attempts by the data node in the event on failure on startup. The default is 0 (no delay). 

Both this parameter and MaxStartFailRetries  are ignored unless StopOnError  is equal to 0. 

• MaxStartFailRetries 

<img src='content_image/798160.jpg'>

Use this parameter to limit the number restart attempts made by the data node in the event that it fails on startup. The default is 3 attempts. 

