new check: make sure remote zone connection information is good

[trel]

remote zones each have a hostname and port

• need to reach out, heartbeat?... to make sure they're awake at that location.
  • warning if not

[trel]

https://docs.irods.org/4.3.0/system_overview/tips_and_tricks/#monitoring-status-of-irods-servers

[ganning127]

Genquery columns have ZONE_CONNECTION, ZONE_TYPE. If ZONE_TYPE is remote, need to do something with ZONE_CONNECTION, which is in format of example.org:1234

[ganning127]

Just leaving this here for reference: If we had a backend, we could do something like this (written in AWS Lambda)

const NetcatClient = require('netcat/client')
const client = new NetcatClient()
const bytes = "\x00\x00\x00\x33<MsgHeader_PI><type>HEARTBEAT</type></MsgHeader_PI>";

module.exports.handler = async (event) => {
  console.log(event);
  const hostname = event.queryStringParameters.hostname;
  const port = parseInt(event.queryStringParameters.port);

  const res = await runFunc(hostname, port);
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        result: res,
        input: event,
      },
      null,
      2
    ),
  };
};

function runFunc(hostname, port) {
  return new Promise((resolve, reject) => {
    client.addr(hostname).port(port).connect().send(bytes);

    const timeout = setTimeout(() => {
      client.close();
      resolve('failure');
    }, 2000);

    
    client.on('data', (data) => {
      clearTimeout(timeout);
      if (data.toString() === "HEARTBEAT") {
        client.close();
        resolve("HEARTBEAT");
      }
    });
  });
}

[korydraughn]

Very cool!

[trel]

Yes, instead - let's poke the iRODS port directly, and treat the 'invalid' HTTP response as the 'alive' check.

This will pollute the iRODS server's log with "readWorkerTask - readStartupPack failed", but we can't do better for now since the browser is not allowed to talk to raw TCP sockets.

[ganning127]

I don't think that this is possible right now for ZMT. I made two GET requests, one to http://localhost:1247 and one to https://easjdlfkajklljkjklasdjklfjklasjkldf.org:1247/ (non-server URL). In the JavaScript console, we see:

GET http://localhost:1247/ net::ERR_INVALID_HTTP_RESPONSE
GET https://easjdlfkajklljkjklasdjklfjklasjkldf.org:1247/ net::ERR_NAME_NOT_RESOLVED

However, we don't have a way of extracting the ERR_INVALID_HTTP_RESPONSE and ERR_NAME_NOT_RESOLVED using axios, so we can't differentiate between the two types of responses.

From here, we could either:

1. create a ZMT backend, and deploy the server code to do HEARTBEAT there
2. add the HEARTBEAT code to the CPP API (seems like the better option to me, since that's where everything else the ZMT is interacting with is)

[trel]

not excited about a ZMT backend. we'd just build this into the server itself...

yes, something like a HEARTBEAT that is available via REST/HTTP is probably the better answer.

[ganning127]

Hmm, just thought about this. Would adding a socket connection in the HTTP/REST API be better or would adding a websocket / HTTP API to the main iRODS server code be better?

[trel]

we won't open up new things on the iRODS server until well understood and 'contact with the enemy' is proven

i think REST/HTTP is first in line for that.

[trel]

removing from milestone for now - awaiting new API endpoint(s).