Websocket No matching function [WEBSOCKETSERVER] found


#1

Hi

I have installed Lucee 5.2 on an IIS box with tomcat 8

I can run the websocket extension on tomcat directly from an external address by stopping IIS

I have configured IIS with Websockets, AAR and rewrite rule

^ws/([0-9a-zA-Z-_/]+)$
target: http://{HTTP_HOST}:8888/ws/{R:1}

If I try on IIS, I get this error.

Lucee 5.2.4.37 Error (expression)
Message
No matching function [WEBSOCKETSERVER] found
Stacktrace
The Error Occurred in
C:\inetpub\wwwroot\wstest\Application.cfc: line 9 
7: 
8: Application.objects.connMgrBroadcast =
9: Websocketserver("/ws/broadcast", new BroadcastListener());
10: }
11: }

Any help will be greatly appreciated
Thanks
Nils


#2

This is very strange because the error that you are citing seems to come from Lucee and has nothing to do with IIS.

Please tell us more about your setup. I understand that you installed the latest version of the Lucee WebSocket Extension?

The only logical explanation I can think of is that you have two separate instances of Lucee, and the one that IIS is hooked into does not have the extension installed.

If you are calling Tomcat directly then you have to do it on its listening port, e.g. 8080. There is no need to stop IIS for that.


#3

Yes, I figured that as well, just can’t find the reason.
I just checked, and I do have 2 websites, one on port 80 is hooked up to IIS, and the default one from tomcat on port 8888.
I did only have the extension on the Tomcat webapp, but I just installed it on the IIS app, and the error is the same?

For some reason I can’t call into tomcat:8888 when IIS runs, but since the box is just for test that’s okay

Would it make sense to delete the tomcat root app ?

Thanks
Nils


#4

BTW: I installed version 2.0.3 in both webapps, and followed the instructions for the servlet-filter-utils-1.1.1.jar and updating the web.xml with the filter


#5

The way it works is that IIS is simply a proxy to Tomcat, so you only install the extension on Tomcat – never on IIS. The IIS connector needs to know how to handle the WebSocket connection but that’s a different story.

IIS listens by default on port 80. Tomcat by default listens on 8080 or on some Lucee set ups on 8888. If you have Tomcat listening on port 80 then you’d have a problem because it will “fight” with IIS on the port, and the first one that takes the port “wins” while the other will fail to start, so there’s defeinitely something weird with your setup.

It makes sense to delete anything you don’t need and don’t use, but as always – be careful to only delete stuff that you don’t need. It’s always a good idea to make a backup before you delete anything in case you do delete something that you need by accident.


#6

Tomcat listens on port 8888, and I can use it and access the websocket test just fine, as long as IIS is not running, and I understand that all Lucee apps runs on Tomcat, which it’s also why I cant figure out whats wrong since the Websocketserver function is not found?

Let me try and delete the Tomcat webapp

When you add the filter in web.xml for the port 80 app in C:\inetpub\wwwroot, I should make a web.xml file in c:\inetpub\wwwroot\WEB-INF\ aas I read the tomcat docs?


#7

Not completely accurate. Lucee can run on any Servlet container. Tomcat is probably the most popular of those though.

You could, but not necessarily should. Settings in /WEB-INF/web.xml will override settings in {Tomcat}/conf/web.xml


#8

Yes, I see your point, I have just only used tomcat

When I tried to add the filter settings for websockets in the {Tomcat}/conf/web.xml, Tomcat was not working properly, so I just added the filter options in an empty web-inf,/web.xml

Trying a reinstall of Lucee / Tomcat, will get back


#9

WEB-INF/web.xml is CaSe-sensitive so be sure to have it exactly in that case.

It probably didn’t work because you don’t have the jar file in the classpath.


#10

Thanks, good point, think I copied the Jar file, but will check again

But just to be sure, I should be able to define this

component {
    this.name = "websocket_broadcast";
    function onApplicationStart(){
        Application.objects.connMgrBroadcast =
            WebsocketServer("/ws/broadcast", new BroadcastListener());
    }

in the application.cfc without any IIS url rewrites etc?


#11

Yes, this has nothing to do with IIS.

If you get an error that WebsocketServer is not a known function then the extension is not installed properly.

Also keep in mind that the name of the function WebsocketServer applies to the most recent version of the extension only. Before that it was WebsocketRegister which is deprecated now. The reason for the name change is that I hope to add WebsocketClient at some point.


#12

Ok, thanks for clarification, just wanted to be 100% sure

I read the docs from you on the name change, we started on v. 2.0.3 but the developer still used the old version :slight_smile:

For some reason in Lucee extension admin, if you install v. 1.1.0.3 then it says downgrade for v. 2.0.3 not upgrade as I would expect?


#13

That’s a bug in the sort order (care to open a ticket for it in JIRA?). 2.0.3 is the most recent version and is the one that you should use as it fixes some issues in prior versions.


#14

Yeah, I eventually figured it out :slight_smile:

I will open a ticket.

thanks for responding so late, it helps, looking forward to getting websockets working


#15

It’s still rather early here :wink:

You’re welcome.


#16

Yes, of course :slight_smile:

Now I got it to work in Edge and IE, but not FF and Chrome

I then tried setting this java parameter

-Dorg.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS=true 

And now the error is back, and the strange thing is that removing the java parameter and restarting Tomcat does not fix it.

Any ideas?


#17

Here is an update
I finally got it working, but using v. 1.1.0.3 and a IIS URL rewrite

-Dorg.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS=true

this works fine now, it is needed to get FF and Chrome to work

I am fairly sure the issue with v. 2.0.3 is this part of the configuration

Save the jar file servlet-filter-utils-1.1.1.jar to the classpath, e.g. if you’re using Tomcat it can go into {tomcat}/lib, or if you’re using Jetty then it can go into {jetty}/lib/ext

Add the following snippet to your web deployment descriptor (web.xml), be sure to modify the url-pattern to match your URLs that will used with WebSockets:

    <!-- Required for the Lucee WebSocket Extension !-->    
    <filter>
      <filter-name>HttpSessionInitializerFilter</filter-name>
      <filter-class>net.twentyonesolutions.servlet.filter.HttpSessionInitializerFilter</filter-class>
    </filter>

    <filter-mapping>
      <filter-name>HttpSessionInitializerFilter</filter-name>
      <!-- modify url-pattern to match your websocket endpoints !-->
      <url-pattern>/ws/*</url-pattern>
    </filter-mapping>

Where should servlet-filter-utils-1.1.1.jar be copied to, I realize the java classpath, so my guess is
c:\lucee\tomcat\lib\ with a default Lucee setup

And where should the snippet to your web deployment descriptor (web.xml), be located?
can you make an empty web.xml here? c:\inetpub\wwwroot\WEB-INF\

Or am I wrong?

Will test some more, but welcome any input


#18

What error are you seeing now?

This applies only to the Session resolution, so I’m not sure you’re “there” yet, unless that’s the problem that you’re seeing now.

It can not be an “empty” web.xml. It must have the XML header and footer that conforms to web deployment descriptors.


#19

Hi,

I haven’t tested anymore for now, will post as soon as I am there, right now v. 1.1.0.3 works

Re this:
Save the jar file servlet-filter-utils-1.1.1.jar to the classpath
I am not using it now, stuck on. v. 1.1.0.3, I was just unsure where it should go? c:\lucee\tomcat\lib\ ?

Re web.xml I know it have to be proper xml with the footer etc, but will Tomcat just append / owerwrite any settings in the file top the default one? And is that the proper location to place it?


#20

Yes, that should work IMO.

Settings in /WEB-INF/web.xml override Tomcat/conf/web.xml so yes, that’s a proper place to put it if you want to keep your configurations with the application code instead of having them in the Tomcat conf directory.