Algorithm behind the Unified Broker writing to Server log files when multiple log files are defined?

What is the algorithm behind the Unified Broker writing to the server log files when multiple log files are defined?
How does the Unified Broker manage multiple Server log files?
How do the srvrLogAppend and the srvrNumLogFiles parameters work?
What are the possible causes for exceeding the Server log size threshold value srvrLogThreshold?
Can I manually delete server log files in sequence?
Why does the Server log file grow beyond its size threshold?
Why does an AppServer or WebSpeed Broker become unresponsive when the log files are deleted or compressed to reclaim space while the it was running?

In addition to the 'append' feature (srvrLogAppend) being enabled, in which case the log files will always exceed their set size (srvrLogThreshold) once, there are only two possible reasons that a Server logfile could grow to more than threshold value:
             
srvrLogAppend and srvrLogThreshold parameters are never ignored.

The Broker monitors the Server log size when srvrLogThreshold is set. Whether srvrLogAppend is set or not, when the Broker detects that the current file size reached the log threshold, it will create the next file using the next sequence value. 

If a log file already exists with that sequence value, it will get deleted and then created. The srvrLogAppend is only significant when the Broker starts. 

• If srvrLogAppend is set to 0 (disabled), the Broker, during startup, deletes all existing log files and creates a new log file with sequence number 000001. 
• If srvrLogAppend is set to 1 (enabled), the Broker checks the last file based on the sequence number and starts writing to it. 

Bottom line, the Broker controls the Server log file rollover.

The Server always appends to the most current file. But the srvrLogAppend setting is not taken into account by the Servers at all. This setting is read and handled by the Broker at startup.

The Servers check if they need to switch to the next log file from time to time, such as every other request, or while idle. While "BUSY", it will never switch log file - this is for performance considerations. Also, if the srvrlogthreshold is set to a reasonable value (not too low), the server will catch up and move on to the next one. Yet it is possible that the log file grows beyond the srvrlogthreshold value in the situation where the limit is reached while processing a request. The srvrlogthreshold value does not mean the log will never grow beyond that size.

2. The Server log file in sequence gets deleted manually

Once the Broker and all Servers close a given log file, it can be deleted manually but should not.

These log files should never be deleted which leave gaps in the sequencing number while the Server/Broker is running.

For instance, if there are log files with sequence numbers:

• log files with sequence numbers 000002 and 000003 are deleted manually,
• a Server that has file 000001 open will never notice that it should have moved to the next file (since it doesn't exist) and it will not switch log file. The server will continue to write to the current log file sequence as it cannot switch to the next in sequence which doesn't exist

When log files are deleted or compressed when the AppServer is running, it will become unresponsive when the current logfile sequence that Broker was writing to cannot be accessed.