event service - trigger containers after archive "stable"

20 views
Skip to first unread message

akluiber

unread,
Jul 28, 2025, 10:13:38 PMJul 28
to xnat_discussion
I have containers which are triggered by the event service - i.e. Session: Created - but I have to write in code to check whether the dicoms for that session are actually done being written to the archive.

I'm not sure if it could be related to the performance of our storage appliance (NFS mount), but unfortunately that's not something I can control regardless.

So, I'm wondering if there's a way to trigger the event only after a session is fully archived and "stable"?

Moore, Charlie

unread,
Jul 29, 2025, 10:48:16 AMJul 29
to xnat_di...@googlegroups.com
Hi there,

One thing to double check is if there are any "Merged" events in the session history table. The only way I can think of this happening other than a bug in the event service is if:
  1. You're receiving DICOM from a scanner
  2. You hit the wait time to consider a study complete so XNAT archives the partial study
  3. Then the scanner sends additional instances which get merged into the session

Thanks,
Charlie Moore

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of akluiber <al...@kluiber.net>
Sent: Monday, July 28, 2025 9:13 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] event service - trigger containers after archive "stable"
 
I have containers which are triggered by the event service - i.e. Session: Created - but I have to write in code to check whether the dicoms for that session are actually done being written to the archive.

I'm not sure if it could be related to the performance of our storage appliance (NFS mount), but unfortunately that's not something I can control regardless.

So, I'm wondering if there's a way to trigger the event only after a session is fully archived and "stable"?

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/xnat_discussion/36655bfb-233a-47b3-aeb2-35219e50a430n%40googlegroups.com.

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

akluiber

unread,
Jul 29, 2025, 4:36:22 PMJul 29
to xnat_discussion
There are no merged events in these sessions at this point. I am receiving via dicom send, however from a script crawling and sending an organized directory one whole study at a time.

I've attached the relevant portions of a stdout and stderr for an example session, and the code snippet which does the testing.

stderr.log
snippet.txt
stdout.log

Moore, Charlie

unread,
Jul 29, 2025, 5:41:29 PMJul 29
to xnat_di...@googlegroups.com
Hi there,

I see an NFS lock file in your stderr.log, so couldn't the issue be that your "snapshot" in your code is indeterministic from lock files being included in it? Another possible problem is exactly what data is getting mounted in: when snapshots get viewed for the first time on a scan in the UI, XNAT will save them in a SNAPSHOTS directory that sits next to the DICOM directory within the particular scan directory.

Thanks,
Charlie Moore

Sent: Tuesday, July 29, 2025 3:36 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] event service - trigger containers after archive "stable"
 

akluiber

unread,
Jul 30, 2025, 3:05:56 PMJul 30
to xnat_discussion
I did notice the lockfiles. I wasn't totally sure whether that was caused by NFS or something in XNAT. I did find that lockfile prefix here. But I am thinking its probably related to our NFS performance and delayed writes, caching, or something of that sort.

I guess until we correct our performance issues, this little snippet does help for now.

Reply all
Reply to author
Forward
0 new messages