2 instances of websocket

1,760 views
Skip to first unread message

Paul Reed

unread,
Oct 11, 2014, 3:30:57 PM10/11/14
to node...@googlegroups.com
Lawrence has recently updated his excellent mobiui flow to initialise on lost connections, so I deleted the old flow, and imported the latest version, only to find that it would not work.
When I checked the log, I could see the error;
Error: two instances of WebSocketServer cannot listen on the same http server path

Lawrence however quickly noticed that my flows_raspberry.json file contained 2 websocket listeners with the same path;
{"id":"c66445d5.585f48","type":"websocket-listener","path":"/ws/mobiui","wholemsg":"false"},{"id":"11bb4d37.ee44b3","type":"websocket-listener","path":"/ws/mobiui","wholemsg":"false"},

It appears that after deleting the first flow, the websocket got left behind, and a fresh instance created when I imported the revised flow.

All good now, but is this a bug?

Paul

Nicholas O'Leary

unread,
Oct 11, 2014, 4:54:52 PM10/11/14
to node...@googlegroups.com
Hi Paul,

it isn't a bug in the sense of some code going wrong. But that doesn't necessarily mean we're doing the best job we could for the user.

When you imported the original flow, it included a websocket-listener node which is classed as a Configuration Node. This type of node is not draw in the flow itself and contains some configuration shared by nodes in the flow.

When you deleted the flow, I assume you selected the nodes on the workspace and deleted them. As config nodes don't appear on the workspace, this would not have deleted the websocket-listener node. When you reimported the flow, you then got the duplicate config node.

To delete config nodes, you either access them via a node that uses it (edit a websocket node, select the config node in the Path select box, hit the pencil to edit it, hit the delete button), or you need to open the config node sidebar panel (from the drop-down menu, select 'Configuration Nodes...'). You can then double click on any of them to edit/delete.


We need to find a way to make the config nodes more obvious. You may have a completely blank workspace as far as you're concerned, but there could be a number of 'orphaned' config nodes hiding in the background.

More specifically for the websocket-listener node, it shouldn't be creating the actual ws listener on the server if there are no websocket-in/-out nodes configured to use it. This is how, for example, the MQTT config node works - it only connects to the broker if there is a MQTT-in/-out node using it. This is a general pattern that config nodes should follow.

Nick






--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Paul Reed

unread,
Oct 11, 2014, 5:17:18 PM10/11/14
to node...@googlegroups.com
Thanks Nick.
I wasn't aware of that, but all clear now.
It's not such a big issue if you are aware of it, and easy enough to rectify via the ways you describe, especially the 'configuration nodes' menu, which erm... I have not used before.

A positive is the error reporting, 'two instances of WebSocketServer cannot listen on the same http server path' could not be much clearer, although I couldn't work out where the second instance was!

Paul

--
http://nodered.org
---
You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/Aek6xPFpFqI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.

Dave C-J

unread,
Oct 12, 2014, 10:23:46 AM10/12/14
to node...@googlegroups.com
Nick

is there a way we can detect someone deleting all  - eg flow has no nodes in it. - and prompt the user if they want to delete (hidden) configs also - they may not want to of course so can't be automatic. Or maybe auto open the config menu list if we get an error in a config node ? or...

Paul Reed

unread,
Oct 12, 2014, 12:57:08 PM10/12/14
to node...@googlegroups.com
Dave, wouldn't it be better if there was a link between the actual node (where the config is called) and the hidden configs, instead of relying on the flow being deleted?
Then if the respective node was deleted, a prompt asking if the user wants to delete the config or not, maybe even advising if the config is used by other nodes.

Paul

Dave C-J

unread,
Oct 12, 2014, 1:05:08 PM10/12/14
to node...@googlegroups.com
Indeed - probably :-)
Reply all
Reply to author
Forward
0 new messages