WebViewer InstanceInfoCache invalidation

I believe we ran into a bug on the Osimis Webviewer InstanceInfoCache. One of our studies showed up with a single instance on each of its series (two series, each with 400+ instances in Orthanc). Restarting Orthanc had no effect.

I suspected the InstanceInfoCache was the source of the issue and disabled it. That got the studies to display correctly in the webviewer.

Is there any way to invalidate the InstanceInfoCache for a specific study? Is this a known issue?

Cheers,

Chico Venancio

Hi Chico,

No, we’re not aware of that issue. If you find a way to reproduce it, feel free to provide us with more info.

The InstanceCacheInfo are actually stored in metadatas at instance and series levels.
To invalidate the cache, you can issue a DELETE request on every instance at instances/{id}/metadata/9998 and, on every series at series/{id}/metadata/9997. Sorry, it’s not very convenient but it’s not supposed to happen …

Best regards,

Alain.

InstanceInfoCacheHi Alain,
Thank you for the quick response. DELETE on the series was enough to invalidate the instance list and allow users to view the full study with InstanceInfoCache enabled. If I can figure out what triggered it I will pass along further information.

One aspect I am going to investigate is we have an auto-retrieval script setup. Maybe the series only had one instance when the InstanceInfoCache calculated the metadata?

Best regards,

Hi Chico,

The instance info are stored in metadata when the instance is stored → it’s indeed always valid.
The series info are stored in metadata the first time we access the series to display it → so we actually assume that the series will be displayed only once it is completed…
https://bitbucket.org/osimis/osimis-webviewer-plugin/src/b80cd32aef2fdf459822dc6cfc33363483373c68/backend/WebViewerLibrary/Series/SeriesRepository.cpp#lines-67

We are running into this again. Only it now affected most of the series stored for the day. The weird finding is that we don’t see requests for the series in the access logs, this leads me to believe that some internal process is driving the initial series caching with a single instance.

I’m not very familiar with the code (or C++) so I could not find the immediate cause for this in the code. For now I am disabling “ShortTermCachePrefetchOnInstanceStored” in the hopes it is the source and I am using a script to look for series with different number of series than their metadata/9997 and invalidating as necessary.

Best regards,

Hi Chico,

I wanted to inform you that we’ve just encountered the same issue on one of our system. I don’t know yet why the cache info is corrupted but I’ll probably implement a check to make sure the cached information is complete when we try to access it (and then invalidate it if this is not the case).

I’ll make a new release before the end of the year.

Best regards,

Alain.