arrow_back veraPDF krasjer og lukker seg - memory problem og løsning?

Question

veraPDF fungerer stabilt og greit i validering av PDF/A-filer for de fleste uttrekk vi har, men i noen tilfeller så krasjer programmet ukontrollert og lukker seg uten spor av hva som var problemet

Sannsynlig betingelse for krasj?
- Stort antall filer, f. eks. rundt 1 million og mer
- Forekomst av store PDF-filer, f. eks. tegning byggesak på 100 MB og større

Mulige årsaker til krasj?
- Memory problem bygger seg opp i java kjøringen?
- Memory probem knyttet til enkeltfil som er stor (100 MB og større)?

Mulige løsninger på problemet?
- Hvordan kan man kjøre veraPDF med mer minne? F. eks. fra Windows GUI-varianten fra bat-filen der?
- Annet?

Erfart krasj med veraPDF v1.20.3 og tidligere versjoner, tester no siste versjon v1.22.3.
Benytter "Greenfeld" kompileringen av veraPDF.

Lenker:
- veraPDF
- veraPDF dev varianter
- veraPDF dokumentasjon

Comments

Flere detaljer og suksess erfart med veraPDF v1.22.3 på et 662 GB stort Noark 5 v5.0-uttrekk:

Test under utført på et Noark 5 v5.0 uttrekk fra Documaster DOTS, migrert fra ephorte Noark 4-system
 - 842 647 filer, der 439 filer > 100 MB og største fil = 1,4 GB en PDF av marint grunnkart i farger på 54 sider

veraPDF v1.19.99: java.lang.IllegalArgumentException: Destination offset is greater than stream length
veraPDF v1.20.0-RC1: java.lang.OutOfMemory: Java heap space

veraPDF v1.22.3: Fullførte valideringen til
 - Item Processed: 726 019
 - Valid: 550 135
 - Invalid: 175 468
 - Error: 416

Answer 1

Vi opplevde også feilmeldingen:

java.lang.IllegalArgumentException: Destination offset is greater than stream length

Årsaken var en feil i "innholdsfortegnelsen" i PDF/A-1 der den henviser til et punkt i filen som ligger etter EOF. De fleste PDF-lesere ignorerer denne feilen og håndterer det bra, mens VeraPDF krasjet. Validatoren ble endret for å håndtere dette, og kommer nå med en generisk feilmelding istedenfor.
For å fjerne feilen er løsningen å konvertere filen til PDF/A-2. PDF/A-2 benytter ikke denne innholdsfortegnelsen.

Answer 2

Jeg skal ikke tilskrive meg mye kunnskap på Java, men ut ifra feilmeldingen du får, så tyder det på at maskinen du kjører dette på ikke har nok minne å gi til JVM, siden den klager over at den ikke klarer å plassere nok minne basert på størrelsen på det den jobber med.

Comments

Som jeg kommentert nettopp til mitt eget hovespørsmål:
Feilen forsvant / det fungerte fint med siste versjon veraPDF v1.22.3 på samme PCer som har 16 eller 32 GB minne.

Angående mere java-minne så er det mulig å kalle opp java med mer start- og maxminne, men siden veraPDF GUI allerede startes med en bat-fil, så må man jo vite hva man gjør. Når jeg sjekket loggen så krasjet v1.19.99 av og til med annen java exception og v1.20.-0-RC1 med out of memory.

Et kjapt søk og hva jeg har notert før:

Notert at vi bruker Xmx for å sikre nok minne på lokale java apper vi kjører, som parameter før kallet
Søk står om Xms også som initial memory allocation pool
Java-minne

Ved store uttrekk må man vurdere å øke java-minnet i maskinen du kjører SIARD på:
–Xmx2000m for å kjøre SIARD java-program med 2 GB minne
–Xmx4000m for å kjøre SIARD java-program med 4 GB minne

Kjapt søk

The flag Xmx specifies the maximum memory allocation pool for a Java Virtual Machine (JVM), while Xms specifies the initial memory allocation pool.

This means that your JVM will be started with Xms amount of memory and will be able to use a maximum of Xmx amount of memory. For example, starting a JVM like below will start it with 256 MB of memory and will allow the process to use up to 2048 MB of memory:

java -Xms256m -Xmx2048m

Answer 3

Utfordringen ved testing av store dokumentsamlinger har vært at VeraPDF ikke genererer rapport dersom den krasjer før siste fil er testet. Vi har omgått dette ved å teste enkeltfiler. Deretter har vi samlet samtlige testrapporter i en XML-database (BaseX) for å hente ut oversikt over hva som feiler og hvilke filer som er godkjent.

Comments

Har dere delbar kode på hvordan dere har brukt kall til enkeltfiler, laget xml og brukt det i BaseX?

Legger til at det interessant hvis noen har kode som analyserer Noark 5-uttrekk dokumentfiler
 - Forhold mellom dokumentbeskrivelse og dokumentobjekt
 - Inklusiv dokumentnummer, variantformat, versjonsnummer m..

Forklart mer folkelig
 - Hver dokumentbeskrivelse representerer et logisk dokument som er hoveddokument eller vedlegg
 - Som kan ha mange dokumentobjekter (dokumentfiler)
 - Der det kan være flere versjoner av dette dokumentet som igjen kan ha Arkivformat og Produksjonsformat
 
Hvis der i uttrekket finnes flere dokumentobjekter til samme dokumentbeskrivelse vil validering ønske å ha godkjent arkivformat av arkivversjonen av siste versjon.

Så hvis der finnes flere dokumentobjekter for hver dokumentbeskrivelse, så må jo validering av antall godkjente arkivversjoner gjøres mot siste versjon og arkivformat av dokumentet. Og se vekk fra ev. produksjonsformater og andre versjoner.

I praksis kan vi vel forvente at noen migrerte uttrekk har både Arkivformat og Produksjonsformat, fordi man vil sikre at originalen produksjonsformat blir bevart i tilfelle migreringens transformasjon til Arkivformat feilet (f. eks. ble en PDF/A med størrelse = 0 eller størrelse men blank).

---

Påstand, dere får korrigere hvis noe blir feil her:

*) Antall dokumentbeskrivelser kan være større eller mindre enn antall dokumentfiler.

a) En dokumentfil kan være referert til fra flere dokumentobjekt, flere dokumentbeskrivelser fordi de er tilknyttet flere registreringer/journalposter og/eller mapper/saker.

b) En dokumentbeskrivelse kan ha et antall underliggende dokumentobjekter (arkivformat, produksjonsformat og versjoner), der det i migrerte system kan være et større antall.