-
Notifications
You must be signed in to change notification settings - Fork 439
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Edit Page Hangs on Version History #3252
Comments
Atmire would like to claim this issue |
I'm closing this issue because I implemented this fix here #3253 and it works with no problems detected thus far (after a week or so). |
Reopening as tickets should not be closed until the fix is merged. This is because this bug will still exist in the codebase until the fix PR is merged. That said, I'm hoping the reopening will be very temporary, as I'll try out the fix myself and try to merge it quickly. |
@tdonohue Apologies, thank you for looking into it. |
…(see also DSpace/dspace-angular#3252 and DSpace/dspace-angular#3253); the solution originally implemented was intended for version 9 and @alexandrevryghem backported it to 8 here DSpace/dspace-angular#3412
In direct reference to Version History causes Item page to hang.
Hello.
I am right now developing two different DSpace instances and I struggled with this issue for hours thinking it had something to do with my malformed Entities configuration in one of my instances (let's call it Instance A, see: DSpace/DSpace#9729), but I found that I could reproduce this error in my other DSpace instance that doesn't even have Entities enabled (Instance B), leading me to suspect that this may have something to do with the DSpace code itself, and my suspicions were validated once I found this closed issue (I also found that it didn't matter if
dspace.entity.type
was set to Item). Of course, I am using DSpace 8.0.Describe the Bug:
When an Item has multiple versions, going to the Version History on the Edit page for that Item causes CPU usage to skyrocket to 100% and the memory usage to slowly spiral out of control. This was originally discovered in Instance A.
As you can see in the Slack post, I originally believed it had something to do with my Postgres tables. Modifying them did nothing, and
./bin/dspace database info
/test
returned no issues or errors. I had also initially believed that this had something to do with the fact that./bin/dspace healthcheck
would crash and give me Java/SQL error (I have attached that error loghere). That, along with the aforementioned Entities hunch, were both dispelled when I tried to reproduce the issue on Instance B and found that the exact same thing would occur.
The SSL log for Instance A does contain a lot of errors whose relevance I can't really determine to this particular issue, so for the sake of brevity, I will set them aside. Suffice it to say that the REST API backend is accessible at
url.com/server
.The
dspace.log
does not have anything that would obviously stand out to me as being an obvious source of the issue, but I can include that later if needed.To Reproduce
Expected Behavior
Like before, not hanging.
The text was updated successfully, but these errors were encountered: