Stream: IG creation
Topic: terminology server down?
Brian Reinhold (Sep 13 2018 at 09:23):
I am getting a new error with the IG publisher this AM
Connect to Terminology Server at http://tx.fhir.org/r4 (40.0074sec)
Error : Error sending Http Request: Connection to http://tx.fhir.org refused
Is the server down or have the parameters changed requiring a new update of the IG publisher? New parameter in the ig.json config file?
Now I am getting this error
Contacting Build Server... (00.0041sec)
... done (00.0972sec)
Error : C:\Users\brian\.fhir\packages\hl7.fhir.core#current\package\package.json (The system cannot find the path specified)
java.io.FileInputStream.open0(Native Method)
which comes even sooner.
I was able to get rid of the second error by deleting the .fhir and fhircache directories on my computer. But the first error remains. I have downloaded the latest IG publisher.
Grahame Grieve (Sep 13 2018 at 11:27):
server is down. bringing it back up now.
Grahame Grieve (Sep 13 2018 at 11:27):
sorry about that
Grahame Grieve (Sep 13 2018 at 11:27):
I lost access while upgrading it
Brian Reinhold (Sep 13 2018 at 11:29):
I lost access while upgrading it
okay. Standing by. Been mostly engaged in various update, create, and conditional versions thereof this AM.
Grahame Grieve (Sep 13 2018 at 11:30):
back
Brian Reinhold (Sep 13 2018 at 11:32):
back
Yep! Its back! Thanks ... But the package (tgz file) conflict still remains after two passes.
Grahame Grieve (Sep 13 2018 at 11:34):
ok well I have time to look at that now.
Grahame Grieve (Sep 13 2018 at 11:35):
in your log, you'll have something like this:
Grahame Grieve (Sep 13 2018 at 11:35):
Package Cache: C:\Users\graha\.fhir\packages
Grahame Grieve (Sep 13 2018 at 11:35):
go to that directory, and tell me what folders are in it
Brian Reinhold (Sep 13 2018 at 11:39):
go to that directory, and tell me what folders are in it
There is one folder 'packages'
in the 'packages' folder there are 2 folders and one file (an ini file)
One of the folders is for the core and the other is for phd
Do you need the specific names for these folders?
Grahame Grieve (Sep 13 2018 at 13:39):
what version is the core one, and what's in /package/package.json of the core one?
Brian Reinhold (Sep 13 2018 at 15:30):
what version is the core one, and what's in /package/package.json of the core one?
I just did this now and I get:
directory name
hl7.fhir.core#current
package.json
{
"name": "hl7.fhir.core",
"version": "3.6.0",
"tools-version": 1,
"type": "fhir.core",
"license": "CC0-1.0",
"canonical": "http://hl7.org/fhir",
"url": "http://build.fhir.org//",
"title": "FHIR Core package",
"description": "FHIR Core package - the NPM package that contains all the definitions for the base FHIR specification",
"dependencies": {
"hl7.fhir.core": "3.6.0"
},
"author": "HL7 Inc",
"homepage": "http://build.fhir.org//"
}
Grahame Grieve (Sep 13 2018 at 21:27):
well, that's what I expected - the package you are getting is the wrong version. I can only think you cache problem - but then it should be fast
Brian Reinhold (Sep 13 2018 at 23:11):
well, that's what I expected - the package you are getting is the wrong version. I can only think you cache problem - but then it should be fast
I can delete the .fhir and fhircache directories again. Will that solve the version 1 vs version 2?
After deleting those two files here is the log
Package Cache: C:\Users\brian\.fhir\packages Load Configuration from E:\Ruby25-x64\IG_Publisher\PHD-IG\ig.json (00.0039sec) Root directory: E:\Ruby25-x64\IG_Publisher\PHD-IG (00.0103sec) Terminology Cache is at C:\Users\brian\fhircache. 0 files in cache (01.0135sec) Contacting Build Server... (01.0135sec) ... done (02.0175sec) Fetch hl7.fhir.core-current package from http://build.fhir.org/package.tgz (02.0176sec) Checking hl7.fhir.core-current currency (43.0978sec) Updating hl7.fhir.core-3.6.0 package from source (too old - is 1, must be 2 (43.0978sec) Fetch hl7.fhir.core-current package from http://build.fhir.org/package.tgz (43.0978sec) Load hl7.fhir.core-current package from C:\Users\brian\.fhir\packages\hl7.fhir.core#current (00:01:28.0711sec) Load Terminology Cache from C:\Users\brian\fhircache (00:01:34.0233sec) Connect to Terminology Server at http://tx.fhir.org/r4 (00:01:34.0233sec) Fetch Template: https://github.com/FHIR/test-template (00:01:35.0013sec)
It appears that the wrong tgz file is located at http://build.fhir.org/package.tgz, so the conflict happens every time.
Grahame Grieve (Sep 17 2018 at 09:14):
it's not wrong. must be a caching issue but I'm not sure what to do about it
Brian Reinhold (Sep 17 2018 at 09:19):
it's not wrong. must be a caching issue but I'm not sure what to do about it
@Grahame Grieve I suppose you mean a caching issue on the server side? I see where the publisher caches the tgz file on my computer and I can delete all those files. But when I run the publisher it recreates the cache downloading tools '1' tgz. So next time I run, it sees tgz 1 in the cache and downloads a new one. However that newly downloaded one is still 1. So every time I publish it downloads the tgz file.
Grahame Grieve (Sep 17 2018 at 09:23):
when I download that file, I get version 2.
Grahame Grieve (Sep 17 2018 at 09:24):
so I assume it's some intermediate http cache
Brian Reinhold (Sep 17 2018 at 09:24):
when I download that file, I get version 2.
so I assume it's some intermediate http cache
That would be on my end?
Grahame Grieve (Sep 17 2018 at 09:26):
well, somewhere.
Grahame Grieve (Sep 17 2018 at 09:26):
I don't know what to do about it
Lloyd McKenzie (Oct 18 2020 at 02:55):
Seems hung. @Grahame Grieve @Rob Hausam @Mark Iantorno
Rob Hausam (Oct 18 2020 at 02:56):
Yes, just saw that. I'll restart it.
Rob Hausam (Oct 18 2020 at 03:21):
Well, I would restart it if I could, but unfortunately, at least at this time I seem to be stuck. :( The server isn't responding to a request for an rdp connection, and without that there's nothing that I can do with it. The tx.fhir.org server is responding to ping, so it's not completely down, but that's not of any help at the moment. I think we'll have to restart the server instance itself from the console (AWS?), but I don't have the credentials for that (possibly only @Grahame Grieve does?). @Lloyd McKenzie
Rob Hausam (Oct 18 2020 at 03:28):
Never mind. I just got a connection (not sure what changed). Should be back up soon.
Lloyd McKenzie (Oct 18 2020 at 03:42):
Thank you
Rob Hausam (Oct 18 2020 at 03:44):
Server's up, but I'm getting an issue with the SNOMED version. I'm checking it out.
Rob Hausam (Oct 18 2020 at 03:57):
The SNOMED issue is that it's using the 20200309 version as the default for the International Edition if no edition/version is specified, even though the later 20200731 version is loaded and available on the server (and works correctly if you specify it in the query string explicitly as &version=http://snomed.info/sct/900000000000207008/version/20200731).
Rob Hausam (Oct 18 2020 at 04:05):
That SNOMED CT issue probably will affect only a relatively small number of queries overall (but by default it will miss the latest COVID-19 concepts that were added in the July release). I assume this is something that we should be able to address in @Grahame Grieve's reworking of the terminology server code?
Grahame Grieve (Oct 18 2020 at 07:00):
the default version is specified in the ini file
Grahame Grieve (Oct 18 2020 at 07:08):
tx.fhir.org stability is presently at the top of my list. Looks like it will be a few more days before what I'm working on lands though
Rob Hausam (Oct 18 2020 at 15:19):
@Grahame Grieve Yes, the default version is specified in the ini file. Previously that was specifying the currently hosted version of the International edition as the default. When we started hosting multiple versions of the International edition, it wasn't entirely clear how that was supposed to be applied. The most obvious way, though, is to choose a specific edition/version combination as the default. I've adjusted it now so that the 20200731 version of the International edition is flagged as the (only) default, and it's working as expected.
Last updated: Apr 12 2022 at 19:14 UTC
