Conversation
… par objet importé doProgressLog terminait par un Thread.sleep(1) placé hors du test de niveau de log, ce dernier étant fait à l'intérieur de doProgressLogWithoutInterruption. L'attente s'exécutait donc à chaque appel, y compris quand le message était filtré et n'était affiché nulle part. Or ce doProgressLog est appelé au niveau OBJECTS dans les boucles chaudes de l'import, alors que ImportThread règle le niveau à OBJECTS_GROUP en mode normal: une attente par fichier extrait du zip, par DataObjectGroup, par BinaryDataObject, par PhysicalDataObject et par ArchiveUnit. Sur un SIP de 50 000 AU et 50 000 binaires cela fait environ 200 000 attentes, soit 4 mn sous Linux et jusqu'à 50 mn sous Windows où un sleep d'1ms dure réellement 15,6ms. Pendant tout ce temps les menus Traiter et Export restent grisés, puisque setContextLoaded n'est appelé que depuis ImportThread.done(), d'où l'impossibilité de vérifier la conformité SEDA, de vérifier la conformité à un profil et d'exporter le SIP dans la demi-heure suivant l'ouverture. - SEDALibProgressLogger: les trois Thread.sleep(1) sont remplacés par checkInterruption(), qui lève InterruptedException si le drapeau d'interruption est posé. La sémantique d'annulation est identique, Thread.sleep ne faisant rien d'autre sur interruption, mais le coût est nul. - SEDALibProgressLoggerTest: non-régression sur la durée des appels filtrés (20 000 appels sous 2s, contre 23s avant correctif) et sur la propagation de l'annulation par doProgressLog et doProgressLogIfStep. Ce correctif couvre les trois tickets ouverts sur le même symptôme: #16842 pour la vérification de conformité au SEDA 2.1, #16843 pour la vérification de conformité au profil RNG des AN et #16845 pour l'export du SIP.
…es sont là Un BinaryDataObject porte d'un côté ses métadonnées et de l'autre le chemin du fichier qui contient son contenu, et rien ne garantissait que les deux soient d'accord. Le désaccord n'était constaté qu'à l'export, sur le premier fichier introuvable, avec un message ne nommant que le SIP en cours d'écriture. Cause identifiée, et reproduite par les tests sur le SIP d'exemple: le chemin sur disque était construit à partir de l'Uri brute du manifest, alors que les importeurs SIP et DIP extraient tout dans un répertoire "content" en minuscules. Un manifest déclarant "Content/ID13.txt" produisait donc un BinaryDataObject pointant sur un répertoire inexistant, et tous ses binaires devenaient inatteignables tandis que leurs métadonnées étaient bien présentes. Le défaut reste invisible sous Windows, dont le système de fichiers est insensible à la casse, et se manifeste partout ailleurs. - BinaryDataObject.normalizePackageUri: la normalisation du répertoire de paquet est mise en commun, et appliquée là où le chemin sur disque est construit (DataObjectPackage, DataObjectGroup) comme à la décompression (importeurs SIP et DIP), pour que les deux ne puissent plus diverger. - DataObjectPackage.getUnreadableBinaryDataObjectDescriptions et verifyBinaryDataObjectFilesAreReadable: recensement des BinaryDataObjects sans fichier associé, ou dont le fichier est absent ou illisible. - ArchiveTransferToSIPExporter, DataObjectPackageToDiskExporter: contrôle avant d'écrire quoi que ce soit. Tous les fichiers manquants sont nommés en une seule passe, au lieu d'un export à refaire autant de fois qu'il en manque, et rien n'est écrit plutôt que de laisser un SIP tronqué. - SIPToArchiveTransferImporter: l'import signale les binaires déclarés au manifest et absents du paquet, dans le journal et dans le récapitulatif, pour que l'écart soit rattaché au paquet source et non découvert à l'export. - DiskToDataObjectPackageImporter, DiskToArchiveTransferImporter: un fichier écarté par un motif d'exclusion était ignoré sans une ligne de journal; il est désormais tracé et compté dans le récapitulatif. - Tests: SIP complet sans anomalie, binaire supprimé détecté et nommé, export refusé sans rien écrire, Uri à casse variable, et comptage des fichiers exclus.
|
New Issues (55)Checkmarx found the following issues in this Pull Request
Fixed Issues (2)Great job! The following issues were fixed in this Pull Request
Use @Checkmarx to interact with Checkmarx PR Assistant. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Un BinaryDataObject porte d'un côté ses métadonnées et de l'autre le chemin du
fichier qui contient son contenu, et rien ne garantissait que les deux soient
d'accord. Le désaccord n'était constaté qu'à l'export, sur le premier fichier
introuvable, avec un message ne nommant que le SIP en cours d'écriture.
Cause identifiée, et reproduite par les tests sur le SIP d'exemple: le chemin sur
disque était construit à partir de l'Uri brute du manifest, alors que les
importeurs SIP et DIP extraient tout dans un répertoire "content" en minuscules.
Un manifest déclarant "Content/ID13.txt" produisait donc un BinaryDataObject
pointant sur un répertoire inexistant, et tous ses binaires devenaient
inatteignables tandis que leurs métadonnées étaient bien présentes. Le défaut
reste invisible sous Windows, dont le système de fichiers est insensible à la
casse, et se manifeste partout ailleurs.
est mise en commun, et appliquée là où le chemin sur disque est construit
(DataObjectPackage, DataObjectGroup) comme à la décompression (importeurs SIP
et DIP), pour que les deux ne puissent plus diverger.
verifyBinaryDataObjectFilesAreReadable: recensement des BinaryDataObjects sans
fichier associé, ou dont le fichier est absent ou illisible.
d'écrire quoi que ce soit. Tous les fichiers manquants sont nommés en une seule
passe, au lieu d'un export à refaire autant de fois qu'il en manque, et rien
n'est écrit plutôt que de laisser un SIP tronqué.
manifest et absents du paquet, dans le journal et dans le récapitulatif, pour
que l'écart soit rattaché au paquet source et non découvert à l'export.
écarté par un motif d'exclusion était ignoré sans une ligne de journal; il est
désormais tracé et compté dans le récapitulatif.
refusé sans rien écrire, Uri à casse variable, et comptage des fichiers exclus.