Hi Agustina, Yes, if you are able to narrow down the issue to code within DSpace, please do submit a bug ticket (and possibly also a PR if you've found a fix). I'm not familiar enough with all the DOI code in DSpace to comment further, but generally, it's best to report bugs back if you can narrow down the issue to DSpace code itself.
Thanks & glad to hear you've started to figure out what is going on. Tim ________________________________ From: dspace-tech@googlegroups.com <dspace-tech@googlegroups.com> on behalf of Agustina Martinez <amgcia...@gmail.com> Sent: Tuesday, March 21, 2023 10:55 AM To: DSpace Technical Support <dspace-tech@googlegroups.com> Subject: [dspace-tech] Re: DSpace 7.5 intermittent errors with patch operations Hi Tim, Many thanks for the hints. Yes, I can confirm now that the issue was completely unrelated to CORS. Unfortunately there were no errors at all in any of the backend logs regarding this other than a request timeout. I have managed to track down the issue and it was quite a worrying one, which I am happy to share in case others experience similar issues and to also gather some advice from you in terms of appropriate fixes: * The root of the issue was a locked DB transaction originating in a time consuming curation task that we were running over a large repository collection. This curation task iterates over collection items and modifies their metadata in certain conditions are matched. The curation task is run via the command-line "curate -t" command * We have observed that until the curation task completes successfully all of the potentially affected items cannot be edited at all via the user interface and the error I reported above is the one that occurs. I.e. patch request from UI but request timeouts as there is the DB transaction locked. There is no useful message being reported at the DSpace level. * The transaction lock took place when the event dispatcher queue kicks off after the curation task has finished iterating over the collection and before committing changes to the DB. * The event consumer that was causing for the DB lock was the DOIConsumer, and I think that the root of the issue is the "ctx.commit" call in https://github.com/DSpace/DSpace/blob/b956bcd3891e372cc0fe5b1595e422e5d059bced/dspace-api/src/main/java/org/dspace/identifier/doi/DOIConsumer.java#L144. Replacing that commit call with a "ctx.uncacheEntity(dso)" call seems to have resolved the DB transaction lock as our curation task now finishes successfully and all the events, including discovery indexing take place as expected, but wanted to check whether this is the appropriate way of doing it. It makes sense to not do a hard commit in the DOIConsumer in case the transaction does not finish successfully to be able to roll back but I would like advice here?? Tim, should I open a ticket and try to replicate this with a DSpace standard curation task running over a large collection? Your advice would be much appreciated. Best, Agustina On Monday, 20 March 2023 at 17:55:12 UTC Tim Donohue wrote: Hi Agustina, If you are sure it's not a CORS policy error, then I'd recommend checking the backend logs. That "500 (Internal Server Error)" might also be logged in dspace.log or tomcat logs. If so, there may be more information there to help out. If it's reproducible semi-easily, you could also turn on "Debug mode for the REST API" per our troubleshooting guide: https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove) (I wouldn't recommend leaving that on for a long time though, as allows full error stacktraces to be seen in every REST API response, which is really useful to debug issues...but also can be useful to hackers trying to find vulnerabilities in your system.) Tim On Friday, March 17, 2023 at 11:46:47 AM UTC-5 Agustina Martinez wrote: Hi all, We are experiencing intermittent errors, mostly affecting PATCH operations (e.g. modifying items metadata, editing a user or group), when there is heavy load in the backend. We do not see any relevant errors in the backend logs at all, but after some timeout takes place I consistently see these two errors in the developer tools: Access to XMLHttpRequest at 'OUR-BACKEND-URL/server/api/core/items/421578b1-a644-4016-b3a0-c0afe904b0e8' from origin 'https://dspace7-f-dev.lib.cam.ac.uk' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. polyfills.1cded4d53dfa4781.js:1 PATCH OUR-BACKEND-URL/server/api/core/items/421578b1-a644-4016-b3a0-c0afe904b0e8 net::ERR_FAILED 500 (Internal Server Error) It is definitely not CORS related and that error is mis-leading. Is anybody experiencing similar issues? So far I have not been able to reproduce in the DEMO DSpace site or in my local environment. Best, Agustina -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to a topic in the Google Groups "DSpace Technical Support" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/dspace-tech/0wI3czNRwP8/unsubscribe. To unsubscribe from this group and all its topics, send an email to dspace-tech+unsubscr...@googlegroups.com<mailto:dspace-tech+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/5879ae73-6286-48ce-9c9b-c5b09f3e238fn%40googlegroups.com<https://groups.google.com/d/msgid/dspace-tech/5879ae73-6286-48ce-9c9b-c5b09f3e238fn%40googlegroups.com?utm_medium=email&utm_source=footer>. -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/PH0PR22MB32749F0F6D521F7DEA313338ED819%40PH0PR22MB3274.namprd22.prod.outlook.com.
