2

We've deployed our Spring MVC web application on Windows Server 2012. Our web-app uses Spring Websockets for updates with stomp.js and sock.js.

Our websocket configuration:

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer {

    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        config.enableSimpleBroker("/topic");
        config.setApplicationDestinationPrefixes("/calcApp");
    }

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/add").setAllowedOrigins("*").withSockJS();
    }

}

Websocket works on localhost and logs are following:

Opening Web Socket...
Web Socket Opened...
>>> CONNECT
accept-version:1.1,1.0
heart-beat:10000,10000

<<< CONNECTED
version:1.1
heart-beat:0,0
user-name:admin

connected to server undefined

>>> SUBSCRIBE
id:sub-0
destination:/topic/resident

...

Strangely, it doesn't work when I enter external ip, on same machine and browser:

Opening Web Socket...
WebSocket connection to 'ws://192.168.5.50:8080/autopark/add/629/i148hb1c/websocket' failed: WebSocket is closed before the connection is established.
Whoops! Lost connection to undefined

We thought that for external access, there is some firewall and totally disabled it:

enter image description here

But it didn't solve our problem.


How can we solve this issue?

nurgasemetey
  • 752
  • 3
  • 15
  • 39

2 Answers2

0

I'm not really sure and not a spring expert.

but it seems you need to call the server by a domain name over its ip addr which is logical.

Since an ip would be used for more than one domain, so it seems the context need to know which context should be called(even if one) in spring context.

in other word, calling the context by ip would confuse the spring context to select/invoke which context/domain, so it refuses the connection.

have atry, binf the 192.168.5.50 to a domain name, then try to call the path using the domain(not ip). Hope it works this way.

0

The first step in debugging this would be verifying that your application server is actually listening on the external interface.

You can verify what IP your container is bound to by looking for 8080 entries in the output of netstat.

The next step should be verifying an external computer can "see" the port on the external IP. There are various ways to do this, but using the telnet command will suffice.

  • telnet 192.168.5.50 8080
    • If this does not work, then we know there is something blocking communication between the two applications

If we get to this point, then there is likely an issue with the configuration of the application itself.

Community
  • 1
  • 1
jsorah
  • 111
  • 6