I’m trying to get @21Solutions websocket extension running on WIndows 2012 R2 using Application Request Routing (ARR 3) on IIS. In short, I’ve configured the Websockets Role on the server, and I’ve got a URL Rewrite rule setup to rewrite ^ws/([0-9a-zA-Z-_/]+)$ to ws://{HTTP_HOST}:8888/ws/{R:1} The server is sitting behind an AWS ALB.
Right now, IIS is returning a 502 error code for these requests, so I’m trying to figure out what’s is happening to the request and why I’m getting a 502.
I know the websocket request hits the IIS because the response header includes Server:Microsoft-IIS/8.5
Looking at the failed request logs, I get the error: There was a connection error while trying to route the request.
So, it looks like it never reaches tomcat. Any ideas? How can I figure out why there’s a connection error?
I made some progress on this… instead of the rewriting to ws:// I am rewriting to http:// and now I’m getting the expected 101 returned status code for a successful websocket connection. I’ll post more info as I continue to test/debug.
Configured ARR as a reverse proxy. After ARR is installed, restart IIS and you’ll see “Application Request Routing Cache” in the server home list. Click on that, and in the right pane, click on “Server Proxy Settings”. Check “Enable proxy” leaving all the default settings. Make sure “Reverse rewrite host in response headers” is checked.
All my websocket endpoints go through /ws/{params}, so I setup a URL Rewrite rule to forward those incoming websocket requests directly to Tomcat:
Pattern: ^ws/([0-9a-zA-Z-_/]+)$
Rewrite to: http://{HTTP_HOST}:8888/ws/{R:1}
###Tomcat Settings###
I ran into an issue with compression using Firefox and Chrome, which I solved by disabling compression for websocket frames. I don’t completely understand this issue, and I don’t know what if there will be any overall performance issues with Tomcat/Lucee. All I know is that it worked.
Prior to making this change, websockets were being closed immediately after being opened in Firefox. In Chrome, no frames were being sent/received. So, I opened the Lucee-Tomcat Service Control, went to the Java tab, and added this to the Java Options:
Are you seeing that when you’re trying to open a connection? There is an issue that I am aware of that requires a restart of Lucee, where all websocket requests fail to connect, but I can’t remember the error that I get in the browser. The issue is here:
Not sure how to help without seeing some code. I don’t use wsbroadcast.send(). I have seen that error condition before, but I can’t tell you exactly what causes it.
The best way I’ve found to debug problems with websockets is through logging. Make sure your channel is being opened correctly on the server, and log everything that comes through your websocket handler. Then in the browser, use the Network/Websockets tab in the Chrome dev tools to make sure you have an open connection prior to calling wsbroadcast.send(). Maybe there’s a problem with the way you initialize your javascript.
Tried that in another machine, it was working. So it might be issue at my laptop. Decided to reinstall IIS & it’s modules (ARR, URL rewrite, Websockets role) in Laptop & it worked. @Redtopia Thanks a lot for your support
Thank you for this. After many, many hours of searching the web and trying every possible combination of URL Rewrite, this is the article that helped me get WebSockets working properly with Lucee!
I’m trying to do this and getting the same problem that cfmitrah was doing. I tried reinstalling IIS and their modules. It seemed to make things worse. It doesn’t seem to be hitting the URL Rewrite steps like it was when I was getting a 502.3 error. Now, I’m just getting a 404 error.
There are several parts to getting this to work, and it’s definitely not straightforward or easy to debug. I have it working in production and is configured exactly how I described above. But, as you can see, that’s old tech. Not sure what if anything has changed.
Personally, I would try to find another solution. Igal’s websocket extension has some critical bugs that prevent it from working with the latest Lucee builds, or at least without hard server restarts whenever you need to reset your app, or reload your websocket handlers.
I would check to see what’s out there for 3rd party services and figure out if you can get that to work. Honestly, I don’t think it’s worth the effort to use the Lucee Websocket Extension because it’s doubtful that it will ever receive the support it needs from either Igal or Lucee.
It doesn’t seem to be hitting the URL Rewrite steps like it was when I was getting a 502.3 error. Now, I’m just getting a 404 error.