Open cyplas opened 7 years ago
This seems to be fixed, it no longer shows up on healthchecks.
This seems to be fixed, it no longer shows up on healthchecks.
Hmm, spoke to soon, it's back. Odd.
Looking in the logs, it's clear that "every now and then" this error is logged in dspace.ufal.metashare-missing.log.* for almost all items (the recent cases list 98). And this is the only thing that is ever logged in these files, so these log files are typically size 0, but sometimes size 14112 (the recent ones). I'm not sure what triggers these errors, but it's not a regular cron job.
After looking into the java code, I was able to reproduce this (though only once), via the oai application, by changing the URL metadataPrefix URL parameter value to oai_metasharev2.
After looking into the java code, I was able to reproduce this (though only once), via the oai application, by changing the URL metadataPrefix URL parameter value to oai_metasharev2.
More precisely, these errors are triggered (and logged) when visiting http://beta.clarin.si/repository/oai/request?verb=ListRecords&metadataPrefix=oai_metasharev2 for the first time after make restart.
One more trigger could actually be https://github.com/clarinsi/clarin-dspace/blob/d475cc1921a78d515ef863b5a593b352e778d2e3/dspace/config/crosswalks/oai/metadataFormats/lindat_cmdi.xsl#L135, I guess it also depends on how the caching for oai is configured. But you have the gist of it - when it generates the metashare metadata it logs this error. It's there for the sake of compatibility with some old implementation of the oai-metashare crosswalk. In this particular case it always uses the default (and logs the error - somewhere aroud https://github.com/clarinsi/clarin-dspace/blob/d475cc1921a78d515ef863b5a593b352e778d2e3/dspace-oai/src/main/java/cz/cuni/mff/ufal/utils/XslLogUtil.java#L22). Maybe a different log level would be appropriate here, to remind us that a default was used but not to clutter the health checks. In the other cases, where it at least tries to access a metadata value before logging, I'd still consider it an error.
From our healthchecks: