Noctam/DWP/ACS Test Harness/Diary/Week 4: Difference between revisions

From The Dreaming
Jump to navigation Jump to search
Update on the day's work
Line 3: Line 3:
''Not officially working''
''Not officially working''


News, though: my Macbook is ready to pick up at the tech bar, on Friday 1st October at 11am.
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.
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.
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 ===

Revision as of 15:30, 27 September 2021

ACS Test Harness

Meetings

Existing System

Specifications

Diary
2009:

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: {{{1}}}.

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


Day 17: 28/09/2021

Day 18: 29/09/2021

Day 19: 30/09/2021

Day 20: 01/09/2021