Conversation
|
@iainbeeston Tests look much better now, the real cause was https://github.com/machinio/cuprite/pull/36/files#diff-9948fab217d02bb27cd531aa7af30938R40 @jcoglan I see that in faye/websocket-driver-ruby#46 people had similar issues. It looks like when you send message way too faster than |
| @thread.kill | ||
| end | ||
|
|
||
| def send(data) |
There was a problem hiding this comment.
Hey is it a good idea to define the method as send? Won't that override Object#send?
There was a problem hiding this comment.
right, I was just copy-pasting from websocket example, I'll put it back
| end | ||
|
|
||
| def close | ||
| @driver.close |
There was a problem hiding this comment.
Should Socket#close also call @thread.join, just like Client#close above? When I was reading the examples for websocket-driver I noticed that they do that in their socket class but curprite does not
There was a problem hiding this comment.
websocket-driver has two versions of close. One is event-driven https://github.com/faye/websocket-driver-ruby/blob/master/examples/tcp_client.rb#L25 and another one is plain close like the one we use https://github.com/faye/websocket-driver-ruby/blob/master/examples/tcp_client.rb#L42. I think it's pretty much close to what they have in example. Though @thread.join doesn't help as thread can be blocked on IO and they have to use kill as we do.
|
Wow travis looks far better on this branch! 😀 |
| @driver.text(json) | ||
| @logger&.puts("\n\n>>> #{json}") | ||
| def on_open(_event) | ||
| sleep 0.01 # https://github.com/faye/websocket-driver-ruby/issues/46 |
There was a problem hiding this comment.
I've just read that github issue now - would it be possible to loop/sleep here until the state of the socket is not "connecting"? I'm not sure if that is possible, but if it is it might be more reliable, and also it would be easier to understand why the code is sleeping
There was a problem hiding this comment.
I believe that looping in here will hang the only thread we have and make it even worse but I haven't tried it so I can be wrong. All callbacks get executed in @thread and if we don't return from on_open we may never change state. I don't fully understand how to handle it properly so asked @jcoglan for a perfect solution but he didn't have time to answer yet.
|
@iainbeeston oook looks good enough to me to merge it and then deal with refactoring and stuff |
Fix intermittent issues on CI
2 participants
No description provided.