ghost
commented
3 years ago /etc/systemd/system/tomcat.service
Environment='CATALINA_OPTS=-Xms2g -Xmx4g -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Xms2g -Xmx4g'DSpace with Solr indexing requires 2-4GB of memory.
Here's a transcript of an exchange between James and Kim Shepherd on the DSpace tech channel: We're having a funny issue with item permissions lately. Listing items with discovery for anonymous users requires that the Solr document for the displayed items have a field of the form read:"g[uuid]" where the uuid is the uuid of the anonymous group. See here: https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-api/src/main/java/org/dspace/discovery/SolrServiceResourceRestrictionPlugin.java#L92 . But our items being submitted with the single item submission don't get this key set. It's working for other routes like SAF import. It also works if we reindex the items in question. Has anyone else seen this? I'd like to know before I dig further. 3 replies Also sent to the channel
James Creel 26 days ago Update on this question - the problem is also manifesting with a creation of an item over the 6.3. REST API. Also sent to the channel
Kim Shepherd 26 days ago i haven't seen this before, but i wonder if there's something going on with an event consumer not working consistently (or an event not firing in some cases) ? or a race condition where the group read policy isn't yet set/committed on the item when the SolrServiceResourceRestrictionPlugin.additionalIndex()method goes to check and set policy fields? Also sent to the channel
Kim Shepherd 26 days ago you could debug that additionalIndex() method and see what the resource policies look like at the time of ingest and then later at the reindex. perhaps the item is only inheriting policies from the owning collection after that index has already run, in the case of traditional submission (but not in other import methods like SAF or REST)