Noctam/DWP/ACS Test Harness/Diary/Week 4

ACS Test Harness

edit this panel Meetings 06/09/2021: Initial Workshop 01/10/2021: Current System Existing System CISSIM Command Line Tools User Docs PDSIM.odt PDSIM demo.odt PVTstub.odt simcertshowto.txt SIMD.odt Specifications JIRA Issues ACS Test Harness General Services CIS NPS Transactions DCI908 DCI913 DCI923 PDD Diary 2009: Week 1: 06/09 - 12/09 Week 2: 13/09 - 19/09 Week 3: 20/09 - 26/09 Week 4: 27/09 - 03/10 Notes

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