-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can I create a custom handler to handle websocket handshake? #35
Comments
you should be able to use a custom config ( @Override
void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint("/stomp").setHandshakeHandler(myCustomHandshakeHandler);
} |
I'm using Grails 2.4.3 and command (create-web-socket-config) not works for me. How can I do this on my Grails version? Also I found, that in your plugin exists class WebSocketConfig.groovy. As I understand, I need to override this class. But when I override it, it ignores during application start. Is it required additional configuration? Thanks. |
then make sure to stick to the 1.2.x branch: https://github.com/zyro23/grails-spring-websocket/tree/1.2.x
that means:
@Configuration
@EnableWebSocketMessageBroker
class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer {
@Override
void configureMessageBroker(MessageBrokerRegistry mbr) {
mbr.enableSimpleBroker "/queue", "/topic"
mbr.setApplicationDestinationPrefixes "/app"
mbr.setUserDestinationPrefix "/user/"
}
@Override
void registerStompEndpoints(StompEndpointRegistry ser) {
ser.addEndpoint("/stomp").setHandshakeHandler(myCustomHandshakeHandler).withSockJS()
}
}
beans = {
webSocketConfig my.package.WebSocketConfig
grailsSimpAnnotationMethodMessageHandler(
GrailsSimpAnnotationMethodMessageHandler,
ref("clientInboundChannel"),
ref("clientOutboundChannel"),
ref("brokerMessagingTemplate")
) {
destinationPrefixes = ["/app"]
}
} and of course, upgrade to grails-3.1.x as soon as possible :) |
Thank you!!! It really works for me. I have the last question. The root of my problem is next:
|
hmm.. im not really into aws/elb. however, looks like it should be possible to enable sticky sessions with elb so that all requests from a certain user session hit the same instance, thus preventing the issue you described (http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html). |
Yes, thanks for help! |
@strateg29 ELB sticky sessions should solve the instance routing part as zyro23 said. I think making the ELB route TCP rather than HTTP will avoid the sockjs fallback completely. Problem there is you have to do your own SSL termination at the instance instead of at the load balancer. |
No description provided.
The text was updated successfully, but these errors were encountered: