As the gorilla websocket documentation makes clear, it is the callers
responsibility to ensure there is only 1 concurrent reader and writer to
every websocket.
While investigating alternative Broker implementations which are
asynchronous, I was able to trigger go data race warnings while writing
to the socket from subscriptions which were writing from different
goroutines to the same client.
Add a simple mutex on the websocketPeer to gate writers on Send.
Looking at the current implementation there should only be one reader
from the websocket a time which writes to a messages channel.
This should help with issue #105 and is low hanging fruit. It is the most obvious fix until the code is refactored to use a Send message channel where all the writes would be serialized by the channel.
As the gorilla websocket documentation makes clear, it is the callers responsibility to ensure there is only 1 concurrent reader and writer to every websocket.
While investigating alternative Broker implementations which are asynchronous, I was able to trigger go data race warnings while writing to the socket from subscriptions which were writing from different goroutines to the same client.
Add a simple mutex on the websocketPeer to gate writers on Send. Looking at the current implementation there should only be one reader from the websocket a time which writes to a messages channel.
This should help with issue #105 and is low hanging fruit. It is the most obvious fix until the code is refactored to use a Send message channel where all the writes would be serialized by the channel.