| Issue Number | 4393 |
|---|---|
| Summary | [Gauss QA Testing] Unable to connect to Gatekeeper on STAGE |
| Created | 2018-01-18 11:45:21 |
| Issue Type | Bug |
| Submitted By | Englisch, Volker (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2018-02-05 14:10:19 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.219941 |
When running a push job on STAGE the CDR is unable to connect to the Gatekeeper server. The server name appears to be picked up from our hostnames file since the log file reports it correctly:
==== Wed Jan 17 19:39:18 2018 SEND REQUEST (host=gatekeeper-stage.cancer.gov) ====
However, the error indicates line 544 of cdr2gk.py to be a problem with the hostname listed as a blank space:
sendRequest('http:// /GateKeeper/GateKeeper.asmx') caught exception HTTPConnectionPool(host='%2520', port=80)
We actually have two problems. The first is that the logging was not correctly reflecting the host name being passed in to override the default. I have corrected that problem. The other is that the database indeed has " " (a single space) as the value of the "GKServer" parameter in the pub_proc_parm table for this job. Is it possible that this job was run from the admin Publishing interface (rather than the scheduler) and that the space bar was inadvertently hit with the cursor in the GKServer field? I suppose we could test this theory by starting another job but making sure to leave that field alone, but we can't do that now because they've started the app scan.
The second problem was caused by a bug in the adodbapi package.
https://sourceforge.net/p/adodbapi/bugs/27/
Workaround has been installed on QA, and commited as https://github.com/NCIOCPL/cdr-lib/commit/c8cae22
Elapsed: 0:00:00.001513