Skip to content
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

STOMP CONNECT ignored ("No session for...") when using <websocket:decorator-factories> [SPR-13190] #17782

Closed
spring-issuemaster opened this issue Jul 2, 2015 · 6 comments
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Jul 2, 2015

Clark Duplichien opened SPR-13190 and commented

Currently running spring 4.2.0.BUILD-SNAPSHOT

Adding the websocket:decorator-factories element to a websocket:message-broker configuration in XML will prevent the associated SubProtocolWebSocketHandler from starting. Any attempts to make websocket connections will hang on the CONNECT frame.

Connect log with websocket:decorator-factories in place:

2015-07-01 12:57:08,817 DEBUG: org.springframework.web.socket.handler.LoggingWebSocketHandlerDecorator - New WebSocketServerSockJsSession[id=2r1eakba]
2015-07-01 12:57:08,819 TRACE: org.springframework.web.socket.handler.LoggingWebSocketHandlerDecorator - Handling TextMessage payload=[CONNECT
ac..], byteCount=56, last=true] in WebSocketServerSockJsSession[id=2r1eakba]
2015-07-01 12:57:08,820 DEBUG: org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler - Processing CONNECT user=cduplichien session=2r1eakba
2015-07-01 12:57:08,829 DEBUG: org.springframework.web.socket.messaging.SubProtocolWebSocketHandler - No session for GenericMessage [payload=byte[0], headers={simpMessageType=CONNECT_ACK, simpUser=org.springframework.security.authentication.UsernamePasswordAuthenticationToken@fb48ec72: Principal: org.springframework.security.core.userdetails.User@40dd7ab4: Username: cduplichien; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ...omitted..., simpHeartbeat=[J@6b8741, simpSessionId=2r1eakba}], simpSessionId=2r1eakba}]

Connect log without websocket:decorator-factories in place:

2015-07-01 12:54:35,054 DEBUG: org.springframework.web.socket.handler.LoggingWebSocketHandlerDecorator - New WebSocketServerSockJsSession[id=4hbhkzih]
2015-07-01 12:54:35,054 TRACE: org.springframework.web.socket.handler.LoggingWebSocketHandlerDecorator - Handling TextMessage payload=[CONNECT
ac..], byteCount=56, last=true] in WebSocketServerSockJsSession[id=4hbhkzih]
2015-07-01 12:54:35,054 DEBUG: org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler - Processing CONNECT user=cduplichien session=4hbhkzih
2015-07-01 12:54:38,642 INFO : org.springframework.web.socket.config.WebSocketMessageBrokerStats - WebSocketSession[1 current WS(1)-HttpStream(0)-HttpPoll(0), 2 total, 0 closed abnormally (0 connect failure, 0 send limit, 0 transport error)], stompSubProtocol[processed CONNECT(2)-CONNECTED(2)-DISCONNECT(0)], stompBrokerRelay[null], inboundChannel[pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0], outboundChannelpool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0], sockJsScheduler[pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 0]

The "No Session for Generic Message" log is produced when using websocket:decorator-factories because the SubProtocolWebSocketHandler was not started when the CONNECT frame was received, and did not create a new session.

In Debugging, there actually was a SubProtocolWebSocketHandler which was started by the SmartLifecycle, but it was a different instance than the one wrapped by the decorator factory configured through websocket:decorator-factories.

Manually starting the SubProtocolWebSocketHandler from my DecoratorFactory as a workaround makes the connections usable, and the websockets function as expected.

It would seem that a separate instance is provided to the DecoratingFactoryBean by MessageBrokerBeanDefinitionParser, and this instance is never started.


Affects: 4.2 RC2

Referenced from: commits 05f163b, 3eb54cc

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 2, 2015

Rossen Stoyanchev commented

I can see two instances created when websocket:decorator-factory is used in unit tests. What I'm not sure is whether we broke this recently or if it was always an issue? Looking at the code it looks more like this was always in issue. Was it working for you in any version since 4.1.2 (i.e. since 97596f).

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 2, 2015

Clark Duplichien commented

I've only been using websockets since 4.2 (I've need for the new WebSocketStompClient), but I just switched my server project to Spring version 4.1.2.RELEASE to retest. I'm still able to reproduce the issue as described above.

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 2, 2015

Rossen Stoyanchev commented

I've pushed a fix now. Could you give that a try to confirm that it works? There should be a 4.2.0 snapshot shortly and this is the change.

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 2, 2015

Rossen Stoyanchev commented

Okay, I'm adding 4.1.8 to the fix list. If you are able to confirm the fix in 4.2, I'll backport it then. Thanks!

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 2, 2015

Clark Duplichien commented

In spring-websocket-4.2.0.BUILD-20150702.201539-518 everything works as expected. The SubProtocolWebSocketHandler instance that is started by the lifecycle is the same instance that's wrapped by the decorator, and websocket connections are made successfully. Thank you!

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 2, 2015

Rossen Stoyanchev commented

Thanks for quick response!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.