automatically set machine state to error upon disconnect of writer#1054
automatically set machine state to error upon disconnect of writer#1054tschulte wants to merge 2 commits intoopensteno:mainfrom
Conversation
|
I now created a (plugin https://github.com/tschulte/plover_auto_reconnect_machine) that does the reconnect. But that plugin relies on this pull request to be applied. |
plover/machine/base.py
Outdated
| self.machine.run() | ||
| except Exception: | ||
| if not self.machine.finished.isSet(): | ||
| log.error(self.machine.name + ' got disconnected.') |
There was a problem hiding this comment.
Can we simplify the message to just "GeminiPr disconnected"?
| log.error(self.machine.name + ' got disconnected.') | |
| log.error('%s disconnected', self.machine.name) |
Too bad there's no easy way to get the plugin name from what I can see.
plover/machine/base.py
Outdated
| def __init__(self): | ||
| threading.Thread.__init__(self) | ||
| self.name += '-machine' | ||
| self.name = self.__class__.__name__ + '-machine' |
There was a problem hiding this comment.
| self.name = self.__class__.__name__ + '-machine' | |
| self.name = self.__class__.__name__ |
Most of the implementations of the run method of the ThreadedStenotypeBase do not catch exceptions. This causes the thread to silently die (the exception is only logged to the console). Now an exception in the run method is reported as an error to the system and additionally the SerialStenotypeBase class does close the com port on error. Otherwise the com port resource might still be taken by plover upon reconnect of the writer, and a different com port might be taken by the OS and plover might not be able to reconnect to that machine. This is a first part to solving issue opensteno#596. In addition there must be some mechanism to retry connecting when the state is error.
|
@tschulte Are you still interested in getting this in? Would really like this functionality. Have pushed a branch with the suggested edits: https://github.com/pianohacker/plover/tree/issue-596-auto-reconnect-writer |
2661006 to
c4b8956
Compare
|
@pianohacker yes, in principle I am interested in getting this in, although I currently don't have this issue any more, since my setup is different at the moment. Sorry that this pull request dropped of my mind. As I recall, a problem might be, that these classes seem to be part of the API, or at least there are plugins that extend these classes. Therefore changing these might cause them to break. At least for example the treal machine is implemented as a plugin, and it does also implement the reconnect logic. But I think that would have only been an issue with my first attempt where I copied that reconnect logic from treal to ThreadedStenotypeBase. In the current sollution that should not be a problem. Even the treal machine automatically handling the reconnect itself should not be a problem. I reset --hard my branch to your rebased branch and pushed it. Therefore this pull request now contains your changes. |
|
Edit: it appears to be a kernel module/pyserial error. Open a new issue #1273. Remark: with a recent operating system update, this has a weird behavior that I haven't seen before (tl;dr: it stopped working after sleep/wake up): If I do this
=> The machine stopped responding; however the "Machine disconnected" message is not shown until the USB is unplugged. If I additionally do this
Then the (linked) plugin will repeatedly try (and fail) to connect to the old port; while the machine is moved to a new port. If I unplug the USB in the process, this message will be printed and the plugin stopped working completely. |
Most of the implementations of the run method of the ThreadedStenotypeBase
do not catch exceptions. This causes the thread to silently die (the
exception is only logged to the console).
Now an exception in the run method is reported as an error to the system
and additionally the SerialStenotypeBase class does close the com port on
error.
Otherwise the com port resource might still be taken by plover upon
reconnect of the writer, and a different com port might be taken by the OS
and plover might not be able to reconnect to that machine.
This is a first part to solving issue #596. In addition there must be some
mechanism to retry connecting when the state is error.