Changes lost between incremental loader triggering full loader(s)?

We've deployed an incremental loader based on the information found at...
https://spaces.at.internet2.edu/display/Grouper/Grouper+loader+real+time+updates

In our example, 
GROUPER_INCREMENTAL = myincrementaltable
UMICHHR__V = myloadertable

 

We are losing transactions in the case where the incremental is running with a threshold of 100 and a large amount of transactions are processing.  The incremental loader notes that there are transactions over the 100 threshold on the GROUPER_INCREMENTAL table and calls the full loader to take over.  At that time, the full loader grabs the transactions that are there to process at that time.  Meanwhile data is still processing through and queuing on GROUPER_INCREMENTAL table to be processed.  At one minute increments, the incremental loader wakes up and checks the GROUPER_INCREMENTAL table and sees a batch of data to process again over the 100 threshold.  The incremental loader tries to call the full loader.  The full loader is already running.  The incremental loader adds a time_completed to the GROUPER_INCREMENTAL and thinks it is good .  Those new batches of changes do not get picked up because the first full loader is still processing its first 100+ changes from the first call.  Additional full loader runs are NOT scheduled.  This continues as long as there are enough transactions over the threshold for the incremental loader.  

The result is transactions after the incremental first calls the full loader to run are not processed but are marked complete.

Annotated log....

Incremental loader activity from 9:01, removing 805 umichhr values, with annotations:

grouper-daemon;grouper_error.log;${ENV};${USERTOKEN};2022-05-11T09:01:00,179: [DefaultQuartzScheduler_Worker-5] WARN  GrouperLoaderIncrementalJob.runJob(327) - [] - Loader group etc:loader:umichhr__v has too many changes.  Threshold=100.  Changes=163.  Marking incremental updates as complete and triggering full sync.

Full run triggered, 2022-05-11 09:01:00.0 almost immediately issues sql query for all data, picking up ??? of the records

meanwhile, data continues to arrive . . .

 

grouper-daemon;grouper_error.log;${ENV};${USERTOKEN};2022-05-11T09:02:00,404: [DefaultQuartzScheduler_Worker-8] WARN  GrouperLoaderIncrementalJob.runJob(327) - [] - Loader group etc:loader:umichhr__v has too many changes.  Threshold=100.  Changes=164.  Marking incremental updates as complete and triggering full sync.

another full run is NOT successfully triggered; Grouper does not see most of these changes

 

grouper-daemon;grouper_error.log;${ENV};${USERTOKEN};2022-05-11T09:03:00,148: [DefaultQuartzScheduler_Worker-4] WARN  GrouperLoaderIncrementalJob.runJob(327) - [] - Loader group etc:loader:umichhr__v has too many changes.  Threshold=100.  Changes=164.  Marking incremental updates as complete and triggering full sync.

another full run is NOT successfully triggered; Grouper does not see these changes

 

grouper-daemon;grouper_error.log;${ENV};${USERTOKEN};2022-05-11T09:04:00,170: [DefaultQuartzScheduler_Worker-9] WARN  GrouperLoaderIncrementalJob.runJob(327) - [] - Loader group etc:loader:umichhr__v has too many changes.  Threshold=100.  Changes=168.  Marking incremental updates as complete and triggering full sync.

another full run is NOT successfully triggered; Grouper does not see these changes

 

grouper-daemon;grouper_error.log;${ENV};${USERTOKEN};2022-05-11T09:05:00,363: [DefaultQuartzScheduler_Worker-3] WARN  GrouperLoaderIncrementalJob.runJob(327) - [] - Loader group etc:loader:umichhr__v has too many changes.  Threshold=100.  Changes=145.  Marking incremental updates as complete and triggering full sync.

another full run is NOT successfully triggered; Grouper does not see these changes

full run ends 2022-05-11 09:18:50.0, only the first 163 changes were processed