opamp.Connection needs a Mutex to avoid concurrent write panic about opamp-go HOT 4 CLOSED

FYI, we protect the connection with a mutex in our example. So it seems reasonable to just move this mutex inside the connection struct and have proper encapsulation.

One argument against having the mutex in the connection is that in the server implementation one may have a mutex per agent anyway (e.g. to protect agent's data fields) and that same mutex can be used to protect the connection. However, we don't do it in our example (we have a separate mutex for data fields) so perhaps the combined mutex is not such a good option (otherwise why don't we use it?).

from opamp-go.

This is working as intended per the Connection interface:

I will do some benchmarking with a large number of connections to determine the overhead of adding a mutex per connection.

from opamp-go.

I missed this issue while working on #200. In my opinion having separate mutexes for the WS connection and the agent data fields makes sense because the cost of the mutexes is low and it would cause contention between updating the agent and sending it messages if we had a shared mutex.

@andykellr @tigrannajaryan Are we satisfied that this is resolved?

from opamp-go.

Yes, I think we can close this.

from opamp-go.