Noctam/DWP/ACS Test Harness/Diary/Week 4: Difference between revisions
Blank week 4 |
m →Day 16: 27/09/2021: Fix equals in code |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
<noinclude>{{Nav/ACS Test Harness}}</noinclude> | <noinclude>{{Nav/ACS Test Harness}}</noinclude> | ||
=== Day 16: 27/09/2021 === | === Day 16: 27/09/2021 === | ||
''Not officially working'' | |||
News, though: my Macbook is ready to pick up at the tech bar, | |||
on Friday 1st October at 11am. | |||
So I should be properly up and running at that point. | |||
I might put a few hours in before that to give me a head start. | |||
If I do, I'll update here with details. | |||
---- | |||
So I did do, so here's some details. | |||
The server is up and running and handling DCI calls. It's all a | |||
bit clunky at the moment; the start/stop scripts aren't tied in - | |||
indeed "kill -9"-ing the process is still the only way to get rid | |||
of it. | |||
I've moved config around quite a bit; there's the concept of a | |||
'config directory' now, under which all other config lives. The | |||
config directory is provided as an argument to the server, or | |||
defaults to {{c|${JCIS_HOME}/config}} (IIRC). The response files | |||
all sit in the {{c|responses.d}} directory underneath that. They | |||
are not currently date/time-sensitive, and there are no triggered | |||
reloads or anything like that. All very vanilla. | |||
I'm not really happy with the config yet, but it's taking shape; | |||
better than it was? Well, maybe more structured anyway. There's a | |||
few classes going in to help with config directories and such like. | |||
One thing to note; the HttpsServer that I'm using doesn't handle | |||
curl very well - it will hang with 100% CPU after handling the first | |||
request that curl sends. This is apparently a problem with socket | |||
management in TLS1.3 vs TLS1.2. I don't really understand it, but | |||
apparently [https://bugs.openjdk.java.net/browse/JDK-8208526 JDK-8208526] | |||
explains it some.<br/> | |||
The workaround is to set the JVM variable: | |||
{{c|-Djdk.tls.acknowledgeCloseNotify{{=}}true}}. | |||
I wish I understood it better - I'd need to dive deeper into the | |||
{{c|HttpServer}} class and the SSH handling to do so, and odds | |||
are that we ''won't'' be using that going forward, so I probably | |||
won't... something to be aware of, though. | |||
Next steps are: | |||
* Get the scripts starting and stopping the server | |||
** Indeed, implement a mechanism for stopping the server | |||
* Clean up the code and organise it better | |||
=== Day 17: 28/09/2021 === | === Day 17: 28/09/2021 === | ||
Latest revision as of 15:31, 27 September 2021
ACS Test Harness
|
|---|
|
Meetings Existing System Specifications Diary |
Day 16: 27/09/2021
Not officially working
News, though: my Macbook is ready to pick up at the tech bar, on Friday 1st October at 11am.
So I should be properly up and running at that point.
I might put a few hours in before that to give me a head start. If I do, I'll update here with details.
So I did do, so here's some details.
The server is up and running and handling DCI calls. It's all a bit clunky at the moment; the start/stop scripts aren't tied in - indeed "kill -9"-ing the process is still the only way to get rid of it.
I've moved config around quite a bit; there's the concept of a
'config directory' now, under which all other config lives. The
config directory is provided as an argument to the server, or
defaults to ${JCIS_HOME}/config (IIRC). The response files
all sit in the responses.d directory underneath that. They
are not currently date/time-sensitive, and there are no triggered
reloads or anything like that. All very vanilla.
I'm not really happy with the config yet, but it's taking shape; better than it was? Well, maybe more structured anyway. There's a few classes going in to help with config directories and such like.
One thing to note; the HttpsServer that I'm using doesn't handle
curl very well - it will hang with 100% CPU after handling the first
request that curl sends. This is apparently a problem with socket
management in TLS1.3 vs TLS1.2. I don't really understand it, but
apparently JDK-8208526
explains it some.
The workaround is to set the JVM variable:
-Djdk.tls.acknowledgeCloseNotify=true.
I wish I understood it better - I'd need to dive deeper into the
HttpServer class and the SSH handling to do so, and odds
are that we won't be using that going forward, so I probably
won't... something to be aware of, though.
Next steps are:
- Get the scripts starting and stopping the server
- Indeed, implement a mechanism for stopping the server
- Clean up the code and organise it better