Skip to content
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

Closed
aseyedia opened this issue Aug 14, 2024 · 4 comments · Fixed by #3253
Closed

Edit Page Hangs on Version History #3252

aseyedia opened this issue Aug 14, 2024 · 4 comments · Fixed by #3253
Assignees
Labels
bug claimed: Atmire Atmire team is working on this issue & will contribute back component: versioning performance / caching Related to performance, caching or embedded objects
Milestone

Comments

@aseyedia
Copy link
Contributor

aseyedia commented Aug 14, 2024

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.

  • Instance A
    • On research hospital's private intranet with strict security regime.
    • Only permitted exposed ports are 443 and 80.
    • Uses RHEL 9.4.
    • Has a mangled custom Entities configuration that I have yet to resolve.
  • Instance B
    • AWS EC2 VM .
    • Uses Ubuntu 22.
    • Has no Entities enabled.

Describe the Bug:

image

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 log
here). 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

  1. Create an Item.
  2. Create a new version of said Item.
  3. Attempt to view the "Version History" tab of the Edit Item screen.

Expected Behavior

Like before, not hanging.

@aseyedia aseyedia added bug needs triage New issue needs triage and/or scheduling labels Aug 14, 2024
@alexandrevryghem
Copy link
Member

Atmire would like to claim this issue

@alexandrevryghem alexandrevryghem added component: versioning performance / caching Related to performance, caching or embedded objects claimed: Atmire Atmire team is working on this issue & will contribute back and removed needs triage New issue needs triage and/or scheduling labels Aug 14, 2024
@alexandrevryghem alexandrevryghem self-assigned this Aug 14, 2024
@aseyedia
Copy link
Contributor Author

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).

@tdonohue
Copy link
Member

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 tdonohue reopened this Aug 27, 2024
@aseyedia
Copy link
Contributor Author

@tdonohue Apologies, thank you for looking into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug claimed: Atmire Atmire team is working on this issue & will contribute back component: versioning performance / caching Related to performance, caching or embedded objects
Projects
Development

Successfully merging a pull request may close this issue.

3 participants