Geolocation queries should be cached

[eudoxos]

Geolocation is queried remotely after every update of VPN status (every few seconds), for each client; this should be cached (with infinite TTL). It also causes the markers to briefly disappear and appear one after another during the refresh.

mupif-monitor/src/stores/vpnStat.js

Lines 44 to 56 in f76b34b

	for (var i of this.peers) {
	const remote = i.remote.host;
	// geo geolocation data
	const response = await fetch(
	"https://get.geojs.io/v1/ip/geo/" + remote + ".json"
	);
	var ans = await response.json();
	//console.log(answer.latitude, answer.longitude);
	i["coords"] = [ans.latitude, ans.longitude];
	i["country"] = ans.country;
	i["city"] = ans.city;
	i["organization_name"] = ans.organization_name;
	}

[bpatzak]

This is done in c20e8ab

I am currently trying to figure out why https://musicode.mupif.org/safe-api/scheduler-status2/ is so slow
The endpoint calls schedulerInfo method defined in monitor.py.

In schedulerInfo method there is

• s.getStatistics() call that returns immediately
• s.getExecutions(status='Running') which returns array of size 140 (in musicode), also including records with other statuses (Finished, etc). this method calls restApiControl.getExecutionRecords(status=status). So this call is the root cause of slow response of this endpoint. Filtering does not work properly.
• Then the endpoint loops over recieved executions and tries to get tail of the log. Not sure if this is needed at all.... (at least the monitor does not seem to need the data on running executions, it shows only the data on "lastExecutions"

export MUPIF_NS="172.22.2.1:10000"

import Pyro5
import mupif
ns=mupif.pyroutil.connectNameserver()
query = ns.yplookup(meta_any={"type:scheduler"})
uri=query['mupif.scheduler'][0]
s = Pyro5.api.Proxy(uri)
executions = s.getExecutions(status='Running')
len(executions)

140

[stanislavsulc]

Filtering of executions by status is done in
mupif/mupifDB@2081d69
mupif/mupifDB@b71762e

[eudoxos]

This commit to mupif@Musicode disables fetching logs mupif/mupif@ff335e4 (@stanislavsulc sorry I have no time to really sync that with the container; apologies for the extra merge into Musicode — can you take care of that?)

[bpatzak]

The jobman logs are shown in monitor (jobman statistics, jobman tree allows to show logs of running models). This need to be tested if not breaking the app. Borek

…

On Mon, 21 Oct 2024, 06:33 eudoxos, ***@***.***> wrote: This commit to ***@***.*** disables fetching logs ***@***.*** <mupif/mupif@ff335e4> ***@***.*** <https://github.com/stanislavsulc> sorry I have no time to really sync that with the container; apologies for the extra merge into Musicode — can you take care of that?) — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEHV23VXW7VERJPIBGUVOA3Z4R7ZVAVCNFSM6AAAAABQH23FTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRVGU3DEMBZGQ> . You are receiving this because you commented.Message ID: ***@***.***>