Saturday, July 20, 2013

Help ColdFusion not working in the sky!!!

Well this is a little troubleshooting at 10k in the air. Apparently today when I went to debug an app I am working on, while on my flight home, ColdFusion would continue to give me a 500 error. My first instinct was to open up my coldfusion-out.log file and see if I could find the culprit. As I began to look thru the entries I noticed the License service would fail to start. The line that told me this was the following:

Unable to initialise License service: coldfusion.server.ServiceException: host9772188245.direcpc.com: host9772188245.direcpc.com: nodename nor servname provided, or not known.

So I decided to do a quick Google search and found the following post.

http://blogs.coldfusion.com/post.cfm/coldfusion-server-starting-with-unable-to-initialise-service-exception

Now I am on a Mac and that post was for Red Hat but what I did notice is that they talk about the hostname, then it clicked, I've read this somewhere before, where ColdFusion would fail if the service could not access the License server by hostname.

So I opened up my terminal and typed hostname and was returned with  host9772188245.direcpc.com which was weird because I know my hostname is suppose to be Giancarlos-MacBook-Pro.local. Now I've flown in other flights with WiFi an never had this issue so I decided to do a quick test. I disconnected from my WiFi connection on my SouthWest flight and typed hostname and like magic back to normal. Apparently, this service overwrites your hostname when you connect, in turn causing ColdFusion to fail startup if done after WiFi connection.

The quick fix was to open up my hosts file and type the following:

127.0.0.12 host9772188245.direcpc.com

After that I restarted ColdFusion and I was back on track!!! So if your ColdFusion Server fails to start while you are up in the sky, remember, check your hostname and make sure you can ping it. If not then ColdFusion will fail to start.

Hopefully this helps someone who runs into this issue as well. Hair pulling incident averted!

Wednesday, July 03, 2013

ColdFusion 10 WebSockets Gotcha's and Hair Pulling Fixes

Well I finally can say I am a bit more comfortable using the WebSockets technology offered by ColdFusion 10 but below is a checklist of things to make sure you have completed in order to allow for them to work properly.
  1. Firewall Requirements
    If you have a firewall you have to open up the following default ports or which ever you change to:
    • 8575 Default for WebSocket Server - you can edit this in the CF Admin
    • 1243 Default for Flash fall back - flashPolicyPort (if you care about IE 9 and before) - you can edit this in  <cf_home>/ColdFusion10/cfusion/lib/neo-websocket.xml
       
  2. Directory to SWF for Flash Fall Back
    A little gotcha on the Flash fall back. If you allow this and IE tries to access this and you have changed the default path to your scripts directory which is recommended, it fails because the SWF is always requested from /CFIDE/ ... so you need to still map this directory. If you do, I say create the CFIDE inside your site and then map the scripts directory directly inside rather than opening the entire directory  Good thing about 10 is you can just map the directory and block access to the admin by IP. Also on IIS 7 you can restrict access to /CFIDE/administrator and any other directory you want my using Request Filtering.

    This is referenced in the /CFIDE/scripts/ajax/package/cfWebSocketMain.swf file lines 1069 and 1070.

    The fix is as stated above (map CFIDE) or edit the file and change the path to reflect your new path you set in the admin but that requires you to remember that in case there is an update to these files and it gets overwritten.
     
  3. IE and SSL connections
    So IE10 will not connect to your web socket if being requested from an HTTPS site. Currently it is not supported but in the works as specified here:

    http://stackoverflow.com/questions/10957468/does-cf10-support-secure-websocket-wss/17454026#17454026

    You can see in post above the hack I tired but no luck connecting to wss:// even if I forced it. So for now if you need to support IE, you must make the page initiating the call a regular non-secure page.