I have been working on a new application in FW\1. This application has a messaging aspect to it that sends alerts to users. The alerts can be either on screen, email, or a websocket message. When I went to start adding the websocket parts I started running into strange errors.

First, I was getting the following error after sending a websocket message and trying to do a redirect in FW\1.

The code looks like this (just a couple relevant parts)

view plain print about
1getmessengerService().sendMessage(message: "Message goes here", type: "error", delivery: 2);
2variables.fw.redirect('home:main.default', "displayMessage");

Original exception in onRequest
Cannot lock session scope.
Cannot use cflock to lock the application or session shared scopes without these scopes using the cfapplication tag. To use the session scope, you must enable session management. Application and/or Session variables must also be enabled in the ColdFusion Administrator. (Lock)

This struck me as odd because on refresh, I still had a session and was still logged in. I checked the redirect code and removed the preserve item (2nd argument) and tried again. This time I received a different error:

File not found: /Users/dferguson/Documents/Development/nfmtools/common/config/handler.cfc/Users/dferguson/Documents/Development/nfmtools/common/config/handler.cfc

Now I was totally lost. The redirect was going to a very odd place. However, the odd place it was going to was to not as odd as it seems. It was the defined handler for the websocket channel. So, I then decided to take out the handler and see how that would affect it. I now received this error:

File not found: /Applications/ColdFusion10/cfusion/wwwroot/CFIDE/websocket/ChannelListener.cfc/Applications/ColdFusion10/cfusion/wwwroot/CFIDE/websocket/ChannelListener.cfc

This is the default system handler for websockets. So, now I am totally confused and resting my head on my desk... over and over. I can't seem to get around these errors. Also, if I take out the wspublish() code everything works just fine. I even went as far as to put an application.cfc file in the directory with the handler to see if that did anything. Well... it didn't.

At this point I went in and started using the line debugger. If you have never used this tool then you are missing out. Instead of putting dumps and traces in your code you can actually watch the path that CF it taking through the code and what vars are being set. You can also see what is being passed to functions. So, I added a few breakpoints and ran the debugger.

I noticed that I had a full session scope right before the redirect call. However, once inside the redirect function the scope was gone. I also noticed that the RC, request, and just about every other scope was gone as well. I tried just about everything, ran the code hundreds of times stepping through it trying to find the cause. I even bugged someone on some under the hood things with websockets. Nothing I did seemed to change the fact that the var scopes were vanishing.

I then tweaked a few settings in the debugger so I could see other scopes, like cgi, form, and cookie. With some tweaking I was able to coheres the code past a couple failure points. I was trying to get deeper into the redirect function to see why I was redirecting to a cfc.

After a few more runs I noticed something. I was stepping though the redirect code on how it generated the redirect url. I saw that it was tapping the cgi scope for the path info. It was then that I noticed the cgi scope was, for the most part, blank. All the vars were empty except for just a few and they all had pathing info to the handler cfc file.

Original CGI dump:

Post websocket call CGI dump:

It was at this point I realized what was happening. The websocket call and it then calling it's hander, was resetting the cgi scope mid request. This was causing session loss, and the redirect failure. I have made a few attempts to get around the issue but all have failed this far.

I am not sure where to go from here. I don't think that this is an issue I can correct myself without some elaborate workaround. It was suggested to use cfthread to get around the issue. I am going to try that and see what happens.

If anyone has any ideas on how to solve it please let me know.

Till next time...

--Dave