OSM Scout Server often freezes, when used with different clients

[Olf0]

When using various clients consecutively, OSM Scout Server often freezes, i.e. no new log entries etc.
This occurred to me quite reproducible when testing the address lookup and routing speed of Pure Maps, Modrana and Poor Maps. Hence the client apps did not receive a response to their requests and timed out, but were staying up and running.
I have not tried to run multiple clients in parallel, yet (expecting worse results).

I also have not checked yet, if the clients somehow lost the connection to OSM Scout Server and subsequently failed to reconnect. How do I check for this, as the client apps do not emit a specific error message (they just time out)?

Note that this happens easily when automatic activation is on and the idle timeout is set high (e.g., 15 minutes in my case), without the user being properly notified (preferably be the client app, but also not by OSM Scout Server) that something went wrong.

While this currently is rather a niche use case (I can barely imagine a user wanting to use Pure Maps and Laufhelden in parallel, but not two map applications), it may become more important in the future to handle requests from multiple client apps well, if OSM Scout Server aims to become a central provider for address lookup, routing and displaying maps on mobile and desktop devices.

P.S.: I suspect OSM Scout Server to behave slightly different when testing this, if either started by "automatic activation" (hence running in the background) or manually (hence running in the foreground), but am not sure about this observation.

[rinigus]

Sorry for delay, let me try to reply.

I would expect systemd and gui activated performance to be the same. In this respect, its better to benchmark using gui and enable INFO level messages in log (end of Settings). If the performance is remarkably different, I'd have to look into why.

The server should be able to establish rather large list of connections. Each connection provides a job which is pushed through one of the working threads. Number of threads is the same as number of CPUs on device. Depending on job type, a single job can lock all threads for that type of a job to avoid access for the same data if its not supported. For example, all Valhalla's jobs are actually exclusive and are running one after another. So, no new calculation can start until a prev one has finished. Same goes for geocoder-nlp. (not sure if I can run them in parallel, but memory could become an issue in that case).

So, I do wonder if your freezing was induced by non-finished calculations. As for figuring out if it was a timeout, no idea how to help with that...

[Olf0]

I would expect systemd and gui activated performance to be the same.

Oh, that is a misunderstanding: I did not observe any differences WRT performance when starting OSM Scout Server either per GUI icon or systemd's "socket activation" by a client (also because I did not really look for that).
I think I observed a different behaviour WRT this issue: "OSM Scout Server does not respond to a client after using multiple clients consecutively."

Back to the original issue: May I easily observe these open connections / pending jobs with some UNIX CLI tool?

[rinigus]

Hi! I'll try to reply tomorrow, got swamped with side projects.

[Olf0]

Take your time. :-)

[rinigus]

No, there are no simple connection tracking tools to my knowledge. But you could start OSM Scout Server as a console application (just add --console on command line) after setting it to log info messages as well. It should print every attempt to contact and start new task by each client. Then we can see a log and maybe it will become clear why it happens.