From the module config page - /config/nodejs/config. Setting anything other than 'localhost' for Node.js server host effectively crashes the site. Loading any page, including re-loading the module config page, takes minutes and completely times out more often than not. This happens from the moment I click the 'save configuration' button. If 'localhost' was the value, it saves quickly, if not it takes forever or doesn't load at all. It doesn't matter if I enter 'google.com' (e.g. a nonsense site where I presume there is no server.js listening on the port I specified) or 'my.site.org', where I can see server.js is listening on the port I specified (see last value - port 5000).

# nmap -sT -O localhost
Not shown: 993 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
80/tcp   open  http
111/tcp  open  rpcbind
631/tcp  open  ipp
3306/tcp open  mysql
5000/tcp open  upnp

Before trying to host the server elsewhere, I successfully had nodejs integration working on localhost with both the chatroom and drupalchat modules. I now get the same behavior when developing locally (using acquia dev desktop, drupal version 7.19) or remotely on my actual site (drupal 7.19).

Could this be a firewall issue or something else? I'm not sure how to begin debugging this, or better yet solve the problem. Should I be able to leave this as localhost if server.js will be running on the same machine as my site?

Edit: anyone? Even a tip on how I could debug this? This makes it seem like I do need to change the value from localhost.

Comments

mobabo’s picture

Issue summary: View changes

edit to note I have the same effect developing locally or remotely

mobabo’s picture

Issue summary: View changes

does seem like I need to use something besides localhost, still need tips

pabloid’s picture

anyone had the same issue? I am experiencing exactly the same only on one particular webserver, but not on others.
Checking the watchdog table it seems Drupal is checking in a loop the wrong url.

colorado’s picture

Same problem here. Clearing all caches un-crashed the site, at least. Just a temporary workaround...