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.
…à la fois checkWithXSDSchema et checkWithRNGSchema n'installaient pas d'ErrorHandler sur le Validator, qui lève donc sur la première anomalie rencontrée. Un manifest non conforme ne remontait ainsi qu'une anomalie par contrôle, et il fallait rejouer le contrôle autant de fois qu'il y avait de problèmes, chaque passage donnant une image différente de la précédente. C'est le "un contrôle a remonté des anomalies, les contrôles suivants n'en ont pas remonté" de la remontée utilisateur: le contrôle ne décrit jamais l'état complet du paquet, seulement le premier écart encore présent. - SEDAXMLValidator: un ErrorHandler collecte toutes les anomalies récupérables au lieu de laisser le validateur s'arrêter sur la première. Une erreur fatale reste arrêtante puisque le document ne peut plus être analysé, mais elle est collectée avant. Les anomalies sont restituées ensemble, chacune avec son contexte (ArchiveUnit, ligne, colonne, message brut), au plus cinquante détaillées. - Les avertissements ne sont pas comptés comme des anomalies de conformité. - Tests: deux ArchiveUnits invalides remontent bien deux anomalies et non une, et le même contrôle rejoué sur le même paquet donne exactement le même résultat, pour le schéma SEDA comme pour un profil RNG. Le contrôle reste par ailleurs mutateur du paquet qu'il vérifie: il renumérote les identifiants quand l'option de renumérotation avant export est active, réécrit les métadonnées de gestion depuis le contexte d'export et régénère toutes les Uri à la sérialisation. C'est l'autre voie par laquelle deux contrôles successifs peuvent différer; elle demande le texte des anomalies d'origine pour être tranchée.
|
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.
checkWithXSDSchema et checkWithRNGSchema n'installaient pas d'ErrorHandler sur le
Validator, qui lève donc sur la première anomalie rencontrée. Un manifest non
conforme ne remontait ainsi qu'une anomalie par contrôle, et il fallait rejouer le
contrôle autant de fois qu'il y avait de problèmes, chaque passage donnant une
image différente de la précédente. C'est le "un contrôle a remonté des anomalies,
les contrôles suivants n'en ont pas remonté" de la remontée utilisateur: le
contrôle ne décrit jamais l'état complet du paquet, seulement le premier écart
encore présent.
lieu de laisser le validateur s'arrêter sur la première. Une erreur fatale reste
arrêtante puisque le document ne peut plus être analysé, mais elle est collectée
avant. Les anomalies sont restituées ensemble, chacune avec son contexte
(ArchiveUnit, ligne, colonne, message brut), au plus cinquante détaillées.
le même contrôle rejoué sur le même paquet donne exactement le même résultat,
pour le schéma SEDA comme pour un profil RNG.
Le contrôle reste par ailleurs mutateur du paquet qu'il vérifie: il renumérote les
identifiants quand l'option de renumérotation avant export est active, réécrit les
métadonnées de gestion depuis le contexte d'export et régénère toutes les Uri à la
sérialisation. C'est l'autre voie par laquelle deux contrôles successifs peuvent
différer; elle demande le texte des anomalies d'origine pour être tranchée.