Context oddity

[kpfaulkner]

Hi

I'm trying to figure out how some recent changes I did to a websocket based tool I've got is now breaking. Basically I'm listening on a websocket for traffic, then copying the traffic to a bunch of destination websockets. I'm wondering if I'm doing something silly with either contexts or the websocket connections.

What I have boils down to one goroutine has code similar to:

ctx, _ = context.WithTimeout(context.Background(), 300*time.Millisecond)
_, data, err := conn.Read(ctx)
if err != nil {
// read too long. This doesn't trigger, all good.
}

while in another go-routine I have

ctx2, cancel := context.WithTimeout(context.Background(), 5*time.Minute)
err = conn2.Write(ctx2, websocket.MessageBinary, dataToUse)
if err != nil {
// write too long
<<<<<<<<<------------------ getting error: "failed to write msg: WebSocket closed: read timed out: context deadline exceeded"
}

in this case, conn and conn2 are pointers to the same websocket.Conn. So the read happens without fail, no problems at all. But then during the write (separate go-routine), I end up getting an error back (from the Write method) which says the read timed out due to context deadline.... even though we're performing the Write operation.

If I extend the read context timeout (above at 300ms... to be something larger) then the write will work fine... for a while, until that context is hit. So it appears to be that the write is somehow being impacted by the reads context.

I'm assuming I'm doing something wrong here... but honestly can't figure out what. Can I read/write the same websocket at the same time, or do I need to mutex it? Do I need to cancel the read context as soon as I'm finished reading that message?

If needed I can try and sort out a runnable example, but am hoping that I'm doing something obviously wrong that doesn't need that.

Anyone have any ideas?

Thanks

Ken

[nhooyr]

Hi Ken!

I couldn't say, definitely would need a standalone example.