Closed sadeghim closed 4 years ago
I haven't successfully reproduced locally, but I think this is happening because the image in question is referenced by 3 records in succession, so the request to store the same image comes in 3 times.
The actual image is persisted and stored, and its the subsequent (multi-threaded) requests to store the same image are failing. So i think more synchronisation is needed for this particular scenario.
So its not a widespread issue, but its an issue nonetheless.
Fixed in 1.0.9
Test fails on biocahe-dev with version:
gitCommitSummary = 6344e7c
gitCommitID = 6344e7ccd0993401622763d13d19739a75cc78a2
gitCommitterEmail = noreply@github.com
Manifest-Version = 1.0
Implementation-Title = Biocache
Comment = Manages the loading, processing, sampling and indexing of occurrence records.
Implementation-Vendor = Atlas of Living Australia
Implementation-Vendor-Id = au.org.ala
gitCommitter = GitHub
Created-By = Apache Maven 3.6.0
gitCommitAuthor = Doug Palmer
Implementation-Version = 6344e7ccd0993401622763d13d19739a75cc78a2
sha1 = 6344e7ccd0993401622763d13d19739a75cc78a2
Built-By = travis
buildTimestamp = 2019-11-05T22:17:54Z
Build-Jdk = 1.8.0_222
And image-service of:
Git commit date/time | 2019-10-29T04:41:57+1100 |
---|---|
d1104cbb199637468a85564cc85f081a9887350d | d1104cbb199637468a85564cc85f081a9887350d |
Git commit short ID | d1104cb |
HEAD | HEAD |
Grails Environment | production |
---|---|
App version | 1.0.13-SNAPSHOT |
Grails version | 3.3.9 |
JVM Version | 1.8.0_222 |
Just to clarify, Mahmoud and I have been testing biocache-store on nci-sandbox-dev
with it linked to nci-image-service
(images-dev). nci-sandbox-dev
is the current defacto biocache-dev
server at this point because the sandbox tool allows us to pull in all of the components for a full stack easily
Its deployed on images-dev for testing. Ive tested from biocache-dev. Issue was cause by the introduction of updating licencing here:
As before, the issue is only happening when the image in question is referenced by 2 or more records in succession, so the request to store the same image comes in 2 times.
I believe this is fixed.
@djtfmartin What is the exact test sequence and file data that you used?
thanks @ansell. Tested using image-dev
and nci-sandbox-dev
for running biocache-cli.
Deployed image-service SNAPSHOT from develop branch using ansible.
Clean images-dev first (DB & indexes)
psql> truncate image cascade;
Loaded data using a snapshot @sadeghim had on nci-sandbox-dev
using the following command.
sudo -u tomcat7 biocache load-dwca --local /home/sad036/dr1411-20191105-030138.dwca.zip -b true dr1411
Monitored logs and killed the job before completion to due to space constraints on image-dev
.
Also tested locally using a DWCA with the same multimedia item referenced by 100s of records.
Tried to re-run on nci-sandbox-dev
but getting a NPE possibly due to some of the commits referenced here:
https://github.com/AtlasOfLivingAustralia/biocache-store/issues/350
Ignore previous comment. The NPE was misleading - the argument should be an expanded archive directory.
To test run on nci-sandbox-dev
sudo -u tomcat7 biocache load-dwca --local /data/biocache-load/dr1411-20191105-030138 -b true dr1411 -t 8
Thanks, I was having the same issue with the unexpanded archives and resorted to copying the entire prod collectory database to test to get them into nectar-collections-test. After that I still had to touch
the archive on nci-upload
to bump its timestamp to get it to work for each successive test. I will work through that sequence today to verify this and the fix for AtlasOfLivingAustralia/biocache-store#350
In the biocache-store case I was generating my archives using the rowType
from the Darwin Core Text Guide, http://rs.tdwg.org/dwc/xsd/simpledarwincore/SimpleDarwinRecord
. That rowType has worked for me for the past 3 years for non-media archives, but it appears that it is the cause of my issues (as Doug identified last week) so I will switch to using the one that biocache-store explicitly supports for media archives.
Here is the log for biocache-store:
and the image-service threw these lines at the same time: