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 the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/5879ae73-6286-48ce-9c9b-c5b09f3e238fn%40googlegroups.com.
