Win a copy of Cloud Native PatternsE this week in the Cloud forum
or Natural Language Processing in the AI/ML forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Getting 404 on WebSocket when deploying on my Server

 
Ranch Hand
Posts: 40
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey there,

I programmed a WebSocket in Java, which works fine on my local Tomcat 7 server when running inside of Eclipse. But after deploying on my Server it doesn't work anymore. I've just programmed a little test application which without any other code in it. Same result: works on my local Tomcat but not on my Server.

This is what I get when running in my Firefox console:


I have really no Idea what to do now. I read many threads on Stackoverflow, here and other boards but nothing helped.
The Tomcat version on the server is 7.0.56. I couldn't attach the .war nor the .java file, so here you go:



Any ideas? :-)
 
Ranch Hand
Posts: 259
15
Android Angular Framework Spring AngularJS Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First, are you sure that's a 404? 404 is about not finding something on a server, once communication has been established. Your Firefox message is claiming there was no contact at all. You might also try hitting a page known to be on 'myserver:8080' directly from the Firefox URL input, if you have not already. That would eliminate this having to do with the hostname you are using, and port.
 
Christian Wansart
Ranch Hand
Posts: 40
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I am sure. I checked the package using Firefox' analyze tool. The interesting thing was, that it wasn't send to ws:// but to http:// instead. When I try to access http://myServer:8080/wsock/chat I get a 404 error page by Tomcat. So I guess that Java or Tomcat is redirecting those WebSocket messages on my local machine. (But that's only an assumption.)
 
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Wansart wrote:The interesting thing was, that it wasn't send to ws:// but to http:// instead. When I try to access http://myServer:8080/wsock/chat I get a 404 error page by Tomcat. So I guess that Java or Tomcat is redirecting those WebSocket messages on my local machine. (But that's only an assumption.)


Every WS handshake starts off as a normal HTTP request to the same URL, with an additional "Upgrade to websocket header". If the server is capable of doing so, it'll return the same header with HTTP 101. If not, you get 404.
Check in Firefox Dev tools network tab if the response header from remote server sent "Upgrade:websocket". If not, it's probably a Tomcat configuration problem.
 
Christian Wansart
Ranch Hand
Posts: 40
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It seems that you're right. This is the header that was sent to the server:


and this is what it returned:


This is very interesting, but what setting could be missing? If you know please let me know. I'm going to work through some documentation.
 
Sheriff
Posts: 24594
55
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You got 1005 bytes in the response, it says in one of the headers, so it might be interesting to look at them. Perhaps you aren't missing anything.
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A successful WS handshake shouldn't contain a "content-type" response header. So I suppose the response here is the standard 404 resource not found tomcat page, which OP should verify from dev tools response tab.

I don't know exactly what the misconfiguration here, because WS usually works out of the box and version 7.0.56 is fairly recent.
So just a checklist below which you can run through:

1) The URLs changed as this discussion progressed, making it a bit confusing.
Since this is a 404 error, first thing to verify is that all the actual URLs in code and deployment are correct, even if they were typed differently in these posts.
From the Origin header, I believe your page and its javascript code is served from "http://192.168.2.103:8888", which suggests it's the ROOT webapp on server.
From the first post, it looks like WS URL is "ws://myServer:8080/wsock/chat". Assuming "myServer:8080" is actually "http://192.168.2.103:8888", it means you have the WS servlet deployed in a second web app called wsock.war.
Is this the case?

2) Deploying to Tomcat from Eclipse is usually rather misleading because Eclipse makes a temp copy of the selected server's files and deploys in the copy.
What you want to do is make a WAR and deploy that on the standalone Tomcat. I suppose that's exactly what you're doing here, but just something to remember.

3) Check that "tomcat7-websocket.jar" and "websocket-api.jar" are in Tomcat server's lib directory.
That's usually "/usr/share/tomcat7/lib" in GNU/Linux distros, or TOMCAT_DIR/lib in Windows.

4) Ensure that your WAR's WEB-INF/lib does not have any of the standard Tomcat JARs like "servlet-api.jar", "tomcat*.jars", or "websocket-api.jar".

5) Finally, check the logs. Look for successful deployment of the WAR containing the WS servlet.

That's all I can think of for now.
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've moved this to the Tomcat forum, since it seems better suited.
 
Christian Wansart
Ranch Hand
Posts: 40
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Second Edit It's not fixed. I downloaded and unpacked the current tomcat 7 from Apache and run it:


"Firefox kann keine Verbindung zu dem Server unter ws://192.168.2.103:8080/wsock/chat aufbauen" means that it can't connect to the address.

------------------------------------

EDIT I guess we found the answer. Thanks for your help. I assumed that the tomcat7 package from the repos would work -- I'v been proven otherwise!
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787220 <-- this is what I found when I wanted to report this bug.



------------------------------------ old answer

Karthik Shiraly wrote:A successful WS handshake shouldn't contain a "content-type" response header. So I suppose the response here is the standard 404 resource not found tomcat page, which OP should verify from dev tools response tab.


I guess you're right, but the response tab is empty. See the attachment. (Anwort means response and Kopfzeilen means headers.)

Karthik Shiraly wrote:1) The URLs changed as this discussion progressed, making it a bit confusing.
Since this is a 404 error, first thing to verify is that all the actual URLs in code and deployment are correct, even if they were typed differently in these posts.


Oh sorry about that. Those are two almost identical programs doing almost the same thing, except that the new one has a JDBC Connection in it. I've ran the test again with my wsock application. You can see the exact same result in wsock2.jpg attachment. The request was:

and the response was:



Karthik Shiraly wrote: From the Origin header, I believe your page and its javascript code is served from "http://192.168.2.103:8888", which suggests it's the ROOT webapp on server.
From the first post, it looks like WS URL is "ws://myServer:8080/wsock/chat". Assuming "myServer:8080" is actually "http://192.168.2.103:8888", it means you have the WS servlet deployed in a second web app called wsock.war.
Is this the case?


Very interesting, because as you can see in my third attachment, I typed the full address ws://192.168.2.103:8888/wsock/login.
192.168.2.103 and myServer is the same machine, for the exception that the 8888 is not exposed to the Internet whereas 8080 is.


Karthik Shiraly wrote:2) Deploying to Tomcat from Eclipse is usually rather misleading because Eclipse makes a temp copy of the selected server's files and deploys in the copy.
What you want to do is make a WAR and deploy that on the standalone Tomcat. I suppose that's exactly what you're doing here, but just something to remember.


OK, I'll check that on my local machine by putting the war file in my Tomcat.

Karthik Shiraly wrote:3) Check that "tomcat7-websocket.jar" and "websocket-api.jar" are in Tomcat server's lib directory.
That's usually "/usr/share/tomcat7/lib" in GNU/Linux distros, or TOMCAT_DIR/lib in Windows.


Now THAT's interesting:

I installed it from the repos. Interestingly: ../../ only contains folders. There are no jar files. I've checked the tomcat package contents with "dpkg -L tomcat7" and "dpkg -L tomcat7-commen" and those symlinks are the only thing there. in ../../java are the files. I missed the "java" and thought it was pointing to /usr/share/lib. But in /usr/share/java is no websocket jar file. I think I'll contact the maintainer of that package. I ran locate to find all jar files and there are more symlinks but no real files... wtf is going on here? This is by the way raspbian as the operating system.

Karthik Shiraly wrote: 4) Ensure that your WAR's WEB-INF/lib does not have any of the standard Tomcat JARs like "servlet-api.jar", "tomcat*.jars", or "websocket-api.jar".


No, those folders are empty.

Karthik Shiraly wrote:5) Finally, check the logs. Look for successful deployment of the WAR containing the WS servlet.




I guess the Tomcat 7 package is broken. I'll check if that happens on my local machine with Debian too. (edit: no websocket file either.)
wsock1.jpg
[Thumbnail for wsock1.jpg]
response
wsock2.jpg
[Thumbnail for wsock2.jpg]
headers
wsock3.jpg
[Thumbnail for wsock3.jpg]
console
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, if I've understood the sequence right, the summary of what has happened is:

- tomcat7 installed from repos on 192.168.2.103 had missing WS jars.
You've now uninstalled the repo version (to ensure there's no clashes with new version), and replaced it with Tomcat7 downloaded directly from Apache.
I assume you've verified that websocket JARs are actually present in this new version?

- In the new version, wsock.war deployed correctly with no error in logs and listening on both 8080 and 8888 (or are these 2 different Tomcat instances).

- But the WS endpoint "ws://192.168.2.103:8080/wsock/chat"; is still failing.
What is "ws://192.168.2.103:8080/wsock/login"? Is it another endpoint?

- Is the website flow "user opens http://192.168.2.103:8080/wsock/login"; -> then javascript on that page tries to open WS to "ws://192.168.2.103:8080/wsock/chat"; and this fails? (sorry, I'm a bit confused about the URLs here, hence the question)
 
Christian Wansart
Ranch Hand
Posts: 40
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Karthik Shiraly wrote:- tomcat7 installed from repos on 192.168.2.103 had missing WS jars.
You've now uninstalled the repo version (to ensure there's no clashes with new version), and replaced it with Tomcat7 downloaded directly from Apache.
I assume you've verified that websocket JARs are actually present in this new version?


Yes, they are present.

Karthik Shiraly wrote:- In the new version, wsock.war deployed correctly with no error in logs and listening on both 8080 and 8888 (or are these 2 different Tomcat instances).


8888 was my prior instance from the repos. 8080 is the new one from Apache. I didn't change the port.

Karthik Shiraly wrote:- But the WS endpoint "ws://192.168.2.103:8080/wsock/chat"; is still failing.
What is "ws://192.168.2.103:8080/wsock/login"? Is it another endpoint?


They are the same. First it was login later it's chat. I wanted to make sure this issn't some keyword or so, that's why I changed it. Now it's only chat. This is the code I am currently working with. There is no other class.


Karthik Shiraly wrote:- Is the website flow "user opens http://192.168.2.103:8080/wsock/login"; -> then javascript on that page tries to open WS to "ws://192.168.2.103:8080/wsock/chat"; and this fails? (sorry, I'm a bit confused about the URLs here, hence the question)


I do open http://192.168.2.103:8080/wsock, then I open Firefox' console and write "ws = new WebSocket('ws://192.168.2.103:8080/wsock/chat')" to check if the connection works.

Interestingly the WebSocket chat example shipped with Tomcat works! The same host, the same Tomcat instance.
websocket-chat-example.JPG
[Thumbnail for websocket-chat-example.JPG]
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I copied your code into a test WS webapp that I had, and it's working perfectly fine. So problem is not in your java code.
And it's not Tomcat either, as you already have the chat example working.

That leaves only your WAR file.
So another one of those checklists :
- Is there a /webapps/wsock directory in your newly installed tomcat directory?
- Is there a "/webapps/wsock/WEB-INF/web.xml" and "/webapps/wsock/WEB-INF/classes/wsock/ChatServer.class"?
- Is your web.xml <web-app version >= "3.0"> ? Can you put up the web.xml contents here?
 
Christian Wansart
Ranch Hand
Posts: 40
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've just tested it on my Ubuntu Notebook (Java 8): working! Then on my Debian PC (Java 7): not working. My Windows 10 (Java 8) working. Raspberry PI (Java 7): not working. I do see a pattern here.

To my knowledge I build it with Java 8, so that could be the reason? I'll test that now. Also: It does work on your machine!
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the classes were built with Java 8 compiler but deployed on machines with older Java 7 JRE, you should see Unsupported class version error in tomcat logs.
 
Christian Wansart
Ranch Hand
Posts: 40
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Karthik Shiraly wrote:If the classes were built with Java 8 compiler but deployed on machines with older Java 7 JRE, you should see Unsupported class version error in tomcat logs.



I didn't see those messages. I probably didn't pay enough attention to this. However, building it with Java 7 made it work! Thank you so much for you time and effort!
 
Karthik Shiraly
Bartender
Posts: 1210
25
Android Python PHP C++ Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're welcome! Glad to know it's working
I'd never have guessed it was a Java version problem tbh. For some reason, I was under the impression web app deployment would fail if the class version was unsupported. I should test my assumptions.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!