Closed ronaldtse closed 1 year ago
@ronaldtse we don't have SP 800-160-1
and SP 800-160-2
in our sources. May be the references should be SP 800-160v1
and SP 800-160v2
?
There aren't NIST SP 800-60-1
, NIST SP 800-154
, and NIST SP 800-188
but there are NIST SP 800-60v1
, NIST SP 800-154 (PD)
, and NIST SP 800-188 (PD)
in the https://csrc.nist.gov/CSRC/media/feeds/metanorma/pubs-export.zip source.
Other references work for me. Do you use async fetching when you get the issue? If so, we seems having a bug with concurrent getting pub-export.zip
How can I reproduce the issue on my local comp?
@andrew2net wow you are correct here on all counts!
We will update those particular references (ping @manuelfuenmayor )
I am using Metanorma to fetch from Relaton. I don't know if the problem is using async fetching, but I know for sure we are fetching A LOT of references at once because there are a lot of refs in this doc. (see the document PR)
I think once we fetch pubs-export.zip once, we should respect the ETag and cache it properly.
@andrew2net these are the remaining issues in this ticket:
[relaton] ERROR: NIST SP 800-50 -- zlib error while inflating
[relaton] ERROR: NIST FIPS 180-4 -- Zip end of central directory signature not found
[relaton] ERROR: NIST FIPS 201-2 -- 859: unexpected token at ''
[relaton] ERROR: NIST SP 800-61 -- undefined method `bytesize' for nil:NilClass
return if buf.bytesize == ::Zip::CDIR_ENTRY_STATIC_HEADER_LENGTH
^^^^^^^^^
I think once we fetch pubs-export.zip once, we should respect the ETag and cache it properly.
@ronaldtse this is correct but in the case of async fetch one thread may start downloading the pub-export.zip and another may start doing same task because the first one doesn't finish it. I can try to model the situation, but if you tell me how to reproduce the issue using Metanorma then it will be useful.
The way to reproduce, assume there is no relaton cache:
$ cd mn-samples-nist
$ bundle
$ cd sources/800-53r5
$ bundle exec metanorma document.adoc
# ...
I think we should use a queue for the fetches to pubs-export.zip.
@ronaldtse I don't get any error with the mn-smples-nist
. Try to remove the Gemfile.lock file and rub bundle
again.
I think we should use a queue for the fetches to pubs-export.zip.
I didn't get the idea. We use queue for threads but it doesn't prevent the threads form causing to load the archive. I think we need to create a singleton class in the relaton-nist, that fetches pubs-export.zip
file, and wrap the fetching method in a Mutex block. So the first thread that calls the fetching will blocks the fetching, and other threads that need to fetch the pubs-export.zip
will have to wait until it loaded. Does it make sense?
Thread safe fetching pubs-export implemented in v 1.14.2
@ronaldtse can we close this issue?
This issue is indeed fixed but I'm still seeing issues in that particular document. Will open new ticket.
From SP 800-53r5:
And
This is blocking https://github.com/metanorma/mn-samples-nist/pull/79