VM Controller 3.12.4
What is in this release
| Count | Summary | |
|---|---|---|
| Change | 1 | When the controller rejects a request it cannot decode, the error… |
| Fix | 8 | The VM controller no longer crashes when several constellation, batch…; Opening a new file transfer or terminal stream on a busy connection…; The VM controller no longer crashes when a connection fails while it…; and 5 more |
Changes
- When the controller rejects a request it cannot decode, the error returned to the client now explains why the payload was invalid instead of only saying it was invalid
Fixes
- The VM controller no longer crashes when several constellation, batch or VPN-orchestration requests reach the same worker VM at the same time
- Opening a new file transfer or terminal stream on a busy connection no longer pauses the processing of incoming data on that connection
- The VM controller no longer crashes when a connection fails while it is still sending queued replies or stream data
- When a connection drops while the controller is still sending to it, pending operations now fail right away instead of hanging. Shutdown no longer waits up to two seconds or gets stuck on streams that were still open
- A worker or batch node VM shutting down while the controller is sending it a request no longer crashes the controller. The request now fails with an error instead
- The VM controller now pings its connections every 30 seconds and drops a peer that stops responding for three minutes, instead of hanging forever. A peer that stops reading no longer blocks every request on that connection, because each message write now times out after two minutes
- The VM controller now signs its connection handshake with FIPS mode on, instead of briefly turning FIPS mode off for the whole VM, and it no longer turns FIPS mode on for images that have it turned off
- SLURM batch jobs can now request up to 100 TiB of memory per node. Previously, jobs requesting more than about 1 TiB were rejected