Closed lkrocek closed 5 years ago
ok, reading of interface data it delay by 16 ms per each, so function try_force_close
and try_send_ping
when used m.top
every time it delayed by 16 ms which are used 4 times in conditions at all is equal to delayed by 64ms at least.
The error is a stack overflow caused by an infinite recursion bug. A send fails and the close process beings. Upon sending the close frame, the send fails, causing the close process to begin again.
The ping response check was likely what caused the initial close frame to be sent if the incoming/outgoing frames were not able to be handled within one second.
TODO:
I rapidly reduced delay by removing m.top.
into m.
where it was possible (Const as STATE_OPEN, etc., headers, protocols which I am not using), but still have on_message
and send
which are main communication way so if I simulate that 50x each 10ms it might not crash but still can because on_message
field is fired and cause that 16ms delay.
Is there any another way how to communicate? Maybe put messagePort into interface and share data over it, I am still newbie in BrightScript so not sure if it is possible or how it could be done.
So now my application is based on your library, I completely removed all m.top
usage within observes and setField
s so I call directly on_message()
function instead of m.top.setField("on_message" ,...
which is defined in the same component and application works perfectly without delays. So maybe it could be somehow refactored.
And by the way I figured out on same delay issue happens in my other components extended by Group, I had to change extends field from Group to Poster, even it is so weird it works well, I reported this issue but unfortunately without reaction yet.
See #2. The dev branch has a commit that removes Scenegraph dependencies for the main web socket logic.
It's mostly perfect, just put configurable wait loop I mentioned in https://github.com/rolandoislas/BrightWebSocket/issues/2#issuecomment-401727090
Hi, even the infinite recursion bug has been solved When I am sending lot requests with 25ms delay device in a while reset connection (guess some overload). I have 2 models of roku devices:
still no update of this?
Hi there,
I made some app and when I send to the roku client with this library more messages at once like 50 messages in 10-20 ms interval app will crash with stack trace below:
I was trying to investigate what actually happen but didn't find it.
I think this stack trace is actually another fail and feel like system break the app due to long term operation, the loop on roPortMessage is receiving message every 66 ms, so system queue incoming messages which are looking like big one.
PS: I am using the WebSocketClient lib in my ComponentLibrary, I tried put it into app ahead but it worked same, I have model 4200X - Roku 3, older but Software is 8.1.0