Ok here is a list of (very) bad bugs using boygrouping.
-
If a client tcp connection fails, vvvv keeps on trying connecting to it. So the server appears to hang, but by using network monitor we can notice it just desperately tries to send some packets to the client. Should have some timeout and disconnect connection, log message instead, since for the moment any small loss of connection makes the system pretty much unuseable.
-
Memory (or absence of) management needs a huge improvement.If we start a decently big patch, then start the clients, we have a huge memory leak on a per client basis (the more client the higher memory usage). If we start clients one by one we have the same effect since memory is not freed anyway. That makes it impossible to start decent big patch that way (23 clients), since it goes out of memory all the time. Only way for now is to start a minimal patch, start all clients, then open the big patch (which gives the issue if a few clients disconnect for some reason we have to restart the whole system).
-
Any patching has memory leak, which is also higher depending on client count (with or without Undo on/off). Simple way to replicate this, boygroup a patch with a decent amount of nodes, CTRL+A to select all nodes and move with keyboard, you should see memory growing quickly.
-
Startup behaviour is quite unpredictable, when we open all clients, in most cases we’ll have a few clients which fail to connect. If connection failed, client should be able to try to reconnect every N seconds. This makes it very painful to have a solid startup when nobody knowing 4v has to manage the installation.
-
Seems 4v sends a pretty big amount of TCP messages, even when not patching (and no setpatch is on either). I’ll try to have a cut down version showing that.