Conversation
|
New Issues (59 out of 59)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 take action directly from this PR:
Try it: |
…d object doProgressLog ended with a Thread.sleep(1) placed outside the log level check, which is done inside doProgressLogWithoutInterruption. The wait was therefore executed on every call, including when the message was filtered out and displayed nowhere. Yet this doProgressLog is called at OBJECTS level in the hot loops of the import, while ImportThread sets the level to OBJECTS_GROUP in normal mode: one wait per file extracted from the zip, per DataObjectGroup, per BinaryDataObject, per PhysicalDataObject and per ArchiveUnit. On a SIP of 50,000 AUs and 50,000 binaries that is about 200,000 waits, i.e. 4 min on Linux and up to 50 min on Windows where a 1ms sleep actually lasts 15.6ms. During all that time the Treat and Export menus stay greyed out, since setContextLoaded is only called from ImportThread.done(), hence the inability to check SEDA compliance, check compliance to a profile and export the SIP within the half hour following the opening. - SEDALibProgressLogger: the three Thread.sleep(1) are replaced by checkInterruption(), which throws InterruptedException if the interrupt flag is set. The cancellation semantics are identical, Thread.sleep doing nothing else on interruption, but the cost is zero. - SEDALibProgressLoggerTest: non-regression on the duration of filtered calls (20,000 calls under 2s, versus 23s before the fix) and on the propagation of cancellation by doProgressLog and doProgressLogIfStep. This fix covers the three tickets opened on the same symptom: #16842 for the SEDA 2.1 compliance check, #16843 for the compliance check against the AN RNG profile and #16845 for the SIP export.
Regzox
force-pushed
the
bug_16844
branch
2 times, most recently
from
September 18, 2026 14:55
7dd03c4 to
9201667
Compare
Regzox
changed the title
mkhediri
reviewed
Sep 21, 2026
| .append(" autre(s) anomalie(s)"); | ||
| break; | ||
| } | ||
| message.append("\n\n-> ").append(getContextualErrorMessage(manifest, error)); |
There was a problem hiding this comment.
On scanne le manifeste à chaque nouvelle anomalie (jusqu'à 50 fois), pas moyen d'optimiser ça avec une seule lecture ?
Contributor
Author
There was a problem hiding this comment.
C'est bon le Scanner est créer une unique fois maintenant.
mkhediri
approved these changes
Sep 21, 2026
Salimdev
approved these changes
Sep 21, 2026
checkWithXSDSchema and checkWithRNGSchema did not install an ErrorHandler on the Validator, which therefore throws on the first anomaly encountered. A non-compliant manifest thus reported only one anomaly per check, and the check had to be replayed as many times as there were problems, each pass giving a different picture from the previous one. This is the "one check reported anomalies, the following checks did not" of the user report: the check never describes the complete state of the package, only the first remaining deviation. - SEDAXMLValidator: an ErrorHandler collects all recoverable anomalies instead of letting the validator stop on the first one. A fatal error still stops the check since the document can no longer be parsed, but it is collected first. Anomalies are reported together, each with its context (ArchiveUnit, line, column, raw message), at most fifty detailed. - Warnings are not counted as compliance anomalies. - Tests: two invalid ArchiveUnits do report two anomalies and not one, and the same check replayed on the same package gives exactly the same result, for the SEDA schema as for an RNG profile. The check otherwise still mutates the package it verifies: it renumbers identifiers when the renumber-before-export option is active, rewrites the management metadata from the export context and regenerates all Uris at serialization. This is the other way two successive checks can differ; it requires the text of the original anomalies to be settled.
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
4 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 and checkWithRNGSchema did not install an ErrorHandler on
the Validator, which therefore throws on the first anomaly encountered. A
non-compliant manifest thus reported only one anomaly per check, and the
check had to be replayed as many times as there were problems, each pass
giving a different picture from the previous one. This is the "one check
reported anomalies, the following checks did not" of the user report: the
check never describes the complete state of the package, only the first
remaining deviation.
instead of letting the validator stop on the first one. A fatal error
still stops the check since the document can no longer be parsed, but it
is collected first. Anomalies are reported together, each with its
context (ArchiveUnit, line, column, raw message), at most fifty detailed.
the same check replayed on the same package gives exactly the same
result, for the SEDA schema as for an RNG profile.
The check otherwise still mutates the package it verifies: it renumbers
identifiers when the renumber-before-export option is active, rewrites the
management metadata from the export context and regenerates all Uris at
serialization. This is the other way two successive checks can differ; it
requires the text of the original anomalies to be settled.