Et raskt svar på det. RabbitMQ er til en viss grad eksperimentell, men kom i master fordi det må eksplisitt slås på. Det er også kilden til en advarsel/feilmelding ved oppstart om du ikke har slått på køhåndtering som profil. Feilmeldingen kommer fordi rabbitmq er en del av avhengighetene til prosjektet oj jeg mener at spring ser det og tenker at det da skal brukes.
Den måten jeg har brukt det er at når en sak er ferdig og du ønsker å ekspedere et utgående brev, så sendes en melding til utgående-brev kø. Da satt nikita-integration-mail-out og lyttet til denne og ville lage en epost for deg. Jeg har egentlig aldri fått den delen til å fungere riktig, men det hadde vært gøy å ogs"få det på plass til undervisningen.
For privat bruk er det nok ikke så viktig med dette, men folk som setter systemer sammen i en arkitektur har ofte behov for en meldingsutveksling. Derfor har det blittliggende der, men kun noe som slås på ved behov.
Hva som er riktig, er jeg usikker på. I en større arkitektur bilde vil det kanskje være viktig med bestandighet, men da måtte køen være koblet til en relasjonsdatabase og ikke et internminne som blir borte ved omstart. For min bruk er 10 min OK, fordi om ikke integrasjonen svelger bort den meldingen, så er det ikke så farlig. Utfordringen her at vi ikke har hatt en god case rundt bruken av det. Jeg har også brukt det til å teste integrasjon til blokkjede, der alle CRUD hendelser blir registrert i blokkjeden og kunne vært brukt lignende for tidsstempling av dokumenter.
Thomas
________________________________ Fra: Petter Reinholdtsen pere@hungry.com Sendt: søndag 13. september 2026 01:32 Til: nikita-noark@nuug.no nikita-noark@nuug.no Emne: Er 10 minutters levetid nok for rabbitmq-behandling?
I forbindelse med at jeg fikk sludderbot-en til å skrive kode for å teste epostintegrasjonen i app.integration.mail oppdaget jeg at støtten som annonserer via RabbitMQ at det skal sendes ut en epost, ikke har mekanisme for å rydde opp vedleggende som skal sendes ut. Slik jeg og sludderboten forstår koden vil filene bli liggende til evig tid, eller en ekstern jobb rydder dem bort.
Det virker uheldig, og jeg foreslår at dette endres til en fast levetid. Mitt forslag i <URL: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com...https://gitlab.com/OsloMet-ABI/nikita-noark5-core/-/merge_requests/622/ > er 10 minutter.
Alternativet er vel at det er opp til RabbitMQ-købehandlere å fjerne filen når de er ferdig med den og at det ikke er noe levetid på filene ut over omstart av nikita, men i og med at det kan være flere købehandlere som ikke vet om hverandre (det er i grunnen egenskapet med en utgiver/abonnent-mekanisme som RabbitMQ), så er kanskje det en tvilsom antagelse.
Uansett, tenkte det var best å lufte forslaget litt videre før endringen går inn i master, i tilfelle det er gode argumenter for den ene eller andre tilnærmingen.
Innspill? -- Vennlig hilsen Petter Reinholdtsen _______________________________________________ nikita-noark mailing list -- nikita-noark@nuug.no To unsubscribe send an email to nikita-noark-leave@nuug.no