-
Notifications
You must be signed in to change notification settings - Fork 18
Problems errors
DSpace uses solr for searches and for caching some data. If many users add extremely long text data or create items with extremely long descriptions (or other fields), solr might have trouble with memory and might crash.
DSpace appears non-functional, impossible to find communities, collections, items.. when clicking on http://$HOSTNAME/community-list, site is just loading and no results are visible
Solr creates a file each time it crashes due to OOM (Out of Memory). It can be found by entering solr docker docker exec -it dspacesolr /bin/bash
and checking contents of /var/solr/logs
. Those are OOM files with date. (Contents are not important, just check if files are present)
Note that time might be different (wrong timezones and such) so if you know exactly when it happened, hours might be off, but minutes should be fine.
Nothing. Solr will restart itself and work normally in a few tens of seconds or minutes. It might happen that it fails several times in a row for the same entry, but it will resolve the problem eventually.
Check and/or increase memory. To check, enter solr docker docker exec -it dspacesolr bash
and execute solr status
last line shows currently used memory and max memory. If it's low, it can be increased
In our case, docker-compose-rest.yml must be modified.
https://github.com/ufal/dspace-angular/blob/bf743b702de6b09c292911d14f6771b42b37e5c9/docker/docker-compose-rest.yml#L116
Command solr -f -m 4g
(where -m 4g is argument specifying 4GB of memory) can be modified to for example solr -f -m 8g
. Then rerun deploy of dspace, preferably from github action on front-end repository. Similar procedure is to be expected when running outside of docker.
FE Integration tests: http://127.0.0.1:8080/server/api/core/sites timed out on retry 6 of 5
Reason: FE tests use database dump which is not up to date with BE docker test image.
Solution: You must update test BE docker - update branch dtq-dev
Caused by: java.lang.NullPointerException: Cannot invoke "org.dspace.submit.factory.SubmissionServiceFactory.getSubmissionConfigService()" because the return value of "org.dspace.submit.factory.SubmissionServiceFactory.getInstance()" is null
Check if the solr is started
Caused by: org.hibernate.HibernateException: Calling method 'contains' is not valid without an active transaction (Current status: MARKED_ROLLBACK)
Finally we found out what was the problem. The test VersioningWithRelationshipsIT#test_placeRecalculationAfterDelete_complex
has some context.commit()
calls, which set all previously fetched entities as DETACHED (e.g., Collection). And we were trying to update the Item's metadata in the ItemServiceImpl#update
method after setting it's owning_collection
in the finishItem()
. Here is a moment when the error Calling method 'contains' is not valid without an active transaction (Current status: MARKED_ROLLBACK) came. By updating Item's metadata in the ItemServiceImpl#updatethe
Java is trying to persist Item's owning collection (because of CascadeType.persist
), but that Collection object is already committed, therefore DETACHED.
I'm going to fix it by moving the code where is updating Item's metadata from ItemServiceImpl#update to ItemServiceImpl#populateMetadata
- WorkspaceItemRestRepositoryIT.lookupPubmedMetadataTest is still failing in vanilla DSpace also.
- WorkspaceItemRestRepositoryIT.createPubmedWorkspaceItemFromFileTest is failing after some our change. If is run only this test it pass but if are run all tests it pass. The test fail in the
PubmedImportMetadataSourceServiceImpl.splitToRecords
, row 329, code:OMElement element = records.getDocumentElement();
Caused by node trying to go through ipv6, disable by using NODE_OPTIONS=--dns-result-order=ipv4first
env var