Stuck server?

[rdica]

There seems to be a stuck server in Genre Rock called Thomakaju at 85.214.171.92. It's been in this state for about a week. Is this something that can be removed from the Directory Servers?

[gilgongo]

That server is currently full (14/14) so you won't be able to join. The Jamulus client doesn't have a clear notification of this - is that what you mean? (see https://explorer.jamulus.io/)

[pljones]

There's definitely something weird with it. I kicked it from the directory (with a little help from iptables) but it re-registered - it's definitely not totally dead. Why it's still reporting all those clients, though, I don't know. The network thread runs separately from the audio processing thread, and I think it's the latter that keeps the list updated. So if that dies, I guess this could happen?

Ideally we'd get some diagnostics on it. At a minimum, whoever runs the server needs to restart it.

[ghost]

There is also the possibility that the server administrator wants the server to operate this way. There are likely many loopholes in Jamulus protocol that programmers and server administrators can use for extra configuration options.

[rdica]

Interesting, thanks for the followup. I have nothing more to contribute to this, as far as I'm concerned this is anwswered.

[softins]

It would be very significant to know whether that server was using multi-threading (-T) or not. But without knowing whose server it is, it's hard to either find that out or to ask for the server to be restarted. Since the server is full, it's not even possible to fetch its welcome message, if any.

Looking at the code, if the clients are not timing out, that indicates CServer::DecodeReceiveData() is no longer being called. Without multi-threading enabled, that is called directly from CServer::OnTimer(). But with multi-threading enabled, it is called from the multiple threads in parallel.

The server in question is running 3.7.0. The multi-threading code was changed significantly between 3.7.0 and 3.8.0, so it may well be that 3.8.0 would not suffer from the same problem.

[pljones]

that is called directly from CServer::OnTimer().

Could the Qt timer die? Or become disconnected? I'd have expected to see problems with other servers, though, given how many there are.

Whilst the server seems to be running vanilla Jamulus 3.7.0 code, there's no telling whether it was installed from the supplied binaries or locally compiled, which would open up even further possibilities.