IInputDataHandler.getFile call for file found in IFileDataSTore.getFileData

Hi,



we’ve implemented a custom InputDataHandler and a custom CacheHandler.



The first custom function called in ViewerImageHandler.getDocumentInfo() is IInputDataHandler.getFileDescription for loading Metadata of the File. The next function is IFIleDataStore.getFileData for loading cached FileDataInfo.

Here’s my debug Output:

csb.dps.JcrDataHandler loadFile File FileABCD MetaData loaded from DMS

csb.dps.JcrDataHandler loadFile File FileABCD LastModifiedDate: 11 Oct 2016 08:14:29 GMT

csb.dps.FileInfoDataHandler getFileData FileABCD Read from FileDataCache

csb.dps.FileInfoDataHandler getFileData FileABCD LastModifiedDate: 11 Oct 2016 08:14:29 GMT



According to the LastModifiedDate, the cached FileData should be up to date and could be used.



No matter if a relevant file is contained in the filedatacache or not, the next function call is always IInputDataHandler.getFile and the whole content is loaded from the dms.



JcrDataHandler.getFile(String) line: 52

a.a(b) line: not available

o.bKa() line: not available

o(g).bKo() line: not available

c.c(FileDataOptions) line: not available

c.b(FileDataOptions) line: not available

ViewerImageHandler(ViewerHandler).d(a) line: not available

ViewerImageHandler(ViewerHandler).a(String, IInputDataHandler, DocumentInfoOptions) line: not available

ViewerImageHandler(ViewerHandler).getDocumentInfo(String, DocumentInfoOptions) line: not available



Why is it necessary to load the whole content in getDocumentInfo, when a cached FileData is available?



We are using Java API 3.7.



Kind regards, Josef

Hi Josef,


Thanks for posting your concerns.
No matter if a relevant file is contained in the filedatacache or not, the next function call is always IInputDataHandler.getFile and the whole content is loaded from the dms.
Can you please elaborate this a bit? If a file is present in filedatacache, does getDocumentInfo load file data again instead of taking it from cache ?
We’d appreciate your cooperation.

Kind regards

Hi,



exactly, the file content is always loaded from the filesystem/dms, although it is present in the filedatacache.



Kind regards,

Josef

Hi Josef,


Thanks for the clarification.
We’re investigating your scenario. We’ll let you know about the outcome shortly.

Best wishes

Hi Josef,


We successfully reproduced this behavior at our end as well. Don’t you think that this behavior is legitimate in order to get file information in real time? For instance, if you want that viewer must always get file data/information from cache then viewer will not show what happens with actual file at actual physical path. If some user updates the file/document and viewer fetches file data/information from cache. How you will see actual last modification date? It will always show cached data.
However, I’ve logged your scenario in our internal issue tracking system as an investigation with ID:VIEWERJAVA-1365. We’ll share more details on it as we get any response from the concerned team.

Kind regards

Hi Atir,



in the first step, metadata for the file is loaded within IInputDataHandler.getFileDescription. If the actual files lastmodifieddate is equals the cached lastmodifieddate, the file should be the same?

If the file was changed, also the metadata should have been updated?



Kind regards, josef

Hi Josef,


If the actual files lastmodifieddate is equals the cached lastmodifieddate, the file should be the same?
Yes, file should be same.
If the file was changed, also the metadata should have been updated?
We investigated this scenario at our end as well. When we change a file/document in file-system, and then compile viewer/application to view same document info, cached file/document information is also updated. Please find the attached output cases and observe the value/behaviorof dateModified tag.

Kind regards

Hi,

if a file was changed, everything works fine - but if there are no file changes, it should be enough to load metadata and the filedata from the cache?



King regards, Josef

Hi Josef,


We are further investigating this scenario and we are in contact with the concerned team. As we get any update from them, we will notify you.
We’ll share DocumentInfoContainer class behavior with you.

Thanks