run_forever() terminates too early #152
Comments
|
Good catch. Thanks for the report. I will try to fix this this week. |
|
Any update on this? |
|
Any updates on this? |
|
@alumae can you verify that the problem persists (since the pull request was accepted)? |
|
When using Kaldi as backend to a speech recognition Android app using SpeechKit we get the strange effect that the first time we set up an session, it works fine. But after stopping this session and resuming within approx. 4 seconds, we run into the problem that this second session does not work. (If the session was setup after more than 4-5 seconds after the first, the second session is setup well and working fine.) But, always after such an uncuccesful session, a retry (third session) works again great. If I compare it with Konele, I can see that Konele does not have this problem with our Kaldi server. Also a java client on a PC has not got this problem. I was looking into the app as the cause, but this websocket server side problem as described here seems to fit the problem in our app. I include some loggings but first I will descipe some events. Whilst the speech is recognized, frames flow. Though "err: -1" seems bad, it works fine. The loggings in the app shows still some creating frames (Creating frame for: [B@221087c op: 2 err: -1) flowing and a partial result AFTER STOP is pressed and the message (Speechkit status: STOPPING) . In another log (debug) EOF shows up together with Looking at the log, it seems to me that one process seems still busy while the data gets interrupted unexpectedly, maybe the socket gets killed by the server. Anyone has a suggestion? So I am very interested if this issue (also [https://github.com/alumae/kaldi-gstreamer-server/issues/7] ) is already solved, and could the behavior of our app be explained by this issue? Could this problem be caused by the bug signalled by @alumae in ws4py 3.5.0, where the problem is that ws4py finishes the websocket handling thread before the websocket has actually done its cleanup? And is the current workaround is to use an earlier version of ws4py (3.0.0 ... 3.2.0 should be fine)? Please excuse me for maybe not following normal guidelines, I am still a bit noob on Github. ------------ Android Studio Debug Log:----------------------- First the app is installed in the emulator. 02-06 13:38:15.633 1706-1719/system_process I/UsageStatsService: User[0] Flushing usage stats to disk At releasing the STOP buttom we get: |
I expect the
run_forever()inthreadedclient.pyto return when the websocket has completely finished. However, it can return before the websocket'sclosed()method has returned.The
run_forver()method checks whether theterminated()method return true. However,ws4py/websocket.pyterminate(), theclient_terminatedandserver_terminatedproperties thatterminate()checks are set to true in the beginning, before callingclosed(). This means that if theclosed()method takes some time (e.g., to do some cleanup),run_forver()returns beforeclosed()has finished.The solution would be to move the line
in ws4py/websocket.py to the
finallyblock.The text was updated successfully, but these errors were encountered: