0
votes

I'm having a problem with running an ipython notebook server. I've written a series of custom ROI (Region Of Interest) widgets for the notebook that allow a user to draw shapes like rectangles and ellipses on an image displayed in the notebook, then send information about the shapes back to python running on the server. All information is passed via widget traitlets; the shape info is in a handles traitlet of type object. When I run this locally on port 8888 (the default) and access it with firefox running on the same computer, everything works. (The system in this case is a Mac running OSX Yosemite).

Now I tried to access it remotely by making an ssh connection from another computer (ubuntu linux, in this case) and forwarding local port 8888 to 8888 on the host. This almost works: firefox running on the client is able to access the ipython notebook server, execute code in notebooks, etc. The ROI widgets also display and seem to work properly, except for one thing: no information about the shapes drawn makes it back to the server.

This is not just an issue of remote access (although that's the most important for my intended use). I have exactly the same problem if I run locally, but use a port other than 8888. For instance, if I set the port to 9999 in ipython_notebook_config.py, run the notebook server and access it with a local firefox, I get exactly the same problem. Similarly, if I run ipython notebook twice with all default settings, the second instance binds port 8889, because 8888 was bound by the first. When I access the server running at 8888 with a local firefox, everything works; when I access the simultaneously running server running at 8889, my widgets once more fail to send info back to the server. If I use --debug, I can see all the comm_msgs passed. The server running on 8888 receives messages that contain shape info, as expected. These messages simply don't show up in the log of the server running at 8889.

Any thoughts?

1
That's bizarre. The comm messages should be sent over the same websocket channel as the execute messages. I can't think why one would work and the other wouldn't. - Thomas K

1 Answers

0
votes

I never did figure out the answer to my question -- why the port matters. However, I found that my ROI widgets had a rookie mistake on the JavaScript side (I'm fairly new to JS programming) that, when fixed, made all the problems go away. Ironically, the puzzle now is why it worked when I was using the default port!