Batch load fails on large loads of 45K classes

[NCIEVS]

Files associated with this ticket in private data repo:

• the last editable export prior to the issue (probably not necessary to test, just as a backup for a blank slate)
  • UAB_i2b2_Concept_4_11_2022.zip
• export of baseline that displayed the issue
  • UAB_i2b2_Concept_4_19_2022_gilberto.zip
• batch load file, 57 K
  • patient_details_v1.txt
• server configuration file, the project is "UAB i2b2 Ontology v4"
  • server-configuration-mbh.json
• thread dump while searches are not working
  • thread-dump-while-lucene-nonfunctional.txt
• protege logs for 4/26 and 4/28
  • logs.zip

Some notes:

• first error report re batch load issues on 4/26, at 12:11 pm eastern (11:11 am central, for logs...).
  • Large batch loads had been successful in the past.
• Protege is 3.9.0, plugin versions correct, client memory -Xmx set to 12 GB. windows 10, 32 GB memory
• observations on 4/28:
  • concepts could be created manually
  • batch load of 1 concept failed, the progress bar didn't progress and no output to the batch log panel
  • searches were not working. Indices rebuilt via lucene->index menu progressed maybe halfway and then the progress bar disappeared. Indices deleted via the file->preferences->lucene->remove indices and then the project reloaded failed to index completely (the progress bar disappeared halfway).
  • which would explain the failure of the batch loads since a search for dup names is part of the job processing
  • I could swear I saw an out of memory error related to the search, but it looks like it was only output to the console and not to the protege log file.
  • there is a reference to lucene locking a file in the thread dump, and ERROR references related to lucene/indexing/searching in the log

[fragosog]

This was tested in 4.0 subsequently (indexing approach on batches & others was modified). The batch load had 250K terms, and into a DB with ~300K concepts. It ran uninterrupted for 31 hrs and completed. This size stretches the owlbinary-based backend as well as the full-vocab-in-memory approach. Closing with "wontfix" but keep in the project so it remains accessible.