AttributeError: 'WebSocketProtocol13' object has no attribute 'is_closing'

[mjbogusz]

Running on Ubuntu 20.04, ROS2 Galactic (configured as a ROS2 package in a workspace).

At first I thought it was because of the tornado installed from apt (python3-tornado), but the same error appeared after installing fresh tornado in a virtualenv.

Logs:

Error sending message: 'WebSocketProtocol13' object has no attribute 'is_closing'
Traceback (most recent call last):
  File "/home/mjbogusz/apcar_ws/install/rosboard/lib/python3.8/site-packages/rosboard/handlers.py", line 83, in broadcast
    if socket.ws_connection and not socket.ws_connection.is_closing():
AttributeError: 'WebSocketProtocol13' object has no attribute 'is_closing'

[mjbogusz]

Hmm, it seems it IS about the tornado version (https://github.com/jupyter/notebook/issues/5920). However it also seems that colcon really doesn't like working with virtualenvs...

My workaround was to add the venv to the $PYTHONPATH, resulting in the following scripts: Installation:

cd ~/ws
virtualenv .venv
source .venv/bin/activate
pip install --upgrade tornado
source /opt/ros/DISTRO/setup.bash
colcon build

Running:

source ~/ws/install/setup.bash
export PYTHONPATH=$(realpath ~/ws/.venv/lib/python3.8/site-packages):$PYTHONPATH
ros2 run rosboard rosboard_node

Note: adjust paths (in particular the ~/ws part) accordingly.

Edit: typo in one of the paths

[mjbogusz]

After some testing I've added a following method to the ROSBoardSocketHandler class and used it instead of is_closing() - now the whole thing works with the Ubuntu-provided Tornado 5.1.1.

    @staticmethod
    def is_ws_closing(ws_connection):
        return (not ws_connection) or ws_connection.stream.closed() or ws_connection.client_terminated or ws_connection.server_terminated

[dheera]

@mjbogusz Thank you! I'll set up a virtual machine later and test this.

[dheera]

@mjbogusz Hi there, I used a solution based off yours but slightly different -- I just patched in the is_closing method if the tornado version doesn't have it. Thanks for bringing this up! If you have time please test the dev branch which contains the fix. I'll merge to main at some point soon otherwise. Thanks!

[Timple]

Fwiw: I solved the same issue by pip3 install --user tornado --upgrade (not using virtualenvs)

[mjbogusz]

I used a solution based off yours but slightly different -- I just patched in the is_closing method if the tornado version doesn't have it. Thanks for bringing this up! If you have time please test the dev branch which contains the fix. I'll merge to main at some point soon otherwise. Thanks!

I've rebased my work on top of dev, dropping my quick-n-dirty fix and it works like a charm! :1st_place_medal:

Fwiw: I solved the same issue by pip3 install --user tornado --upgrade (not using virtualenvs)

I don't like installing pip packages user-wise - you don't remember it a year down the line but your program picks up unrecognized packages (e.g. dependencies) in weird (obsolete) versions you can't track down. Been there done that ;) Installing via sudo pip install --global is even worse, because it can easily break the regular package manager updates. So unless impossible I strongly prefer using distro's package manager or virtualenvs.

[dheera]

@mjbogusz Good points. Thanks for checking! I'd also like to see if there is a way for a catkin or colcon package to create its own virtualenv with the correct versions of everything. I did something of the sort here which is kind of a joke but really only a half-joke in the sense that I wish it were possible to say import tornado==6.1 in Python and have it import that exact version directly.

[artivis]

Just ran into this issue myself. A fix supporting Tornado 5.x would be highly appreciated since that's the version Ubuntu 20.04 ships hence the version that e.g. rosdep installs. In the meantime @mjbogusz patch seems to do the job :+1: .

[mjbogusz]

This issue has just been fixed on main by #82.

I'm leaving closing the issue to the maintainers in case anyone wants to add something here (: