- 14 4月, 2014 2 次提交
-
-
由 Rossen Stoyanchev 提交于
The BufferingStompDecoder now decorates rather than extend StompDecoder. This allows a single StompDecoder instance to be configured and extended independantly while buffering remains a separate concern.
-
由 Rossen Stoyanchev 提交于
Mutate rather than re-create headers when decoding STOMP messages before a message is sent on a message channel. Use MessageBuilder.createMessage to ensure the fully prepared MessageHeaders is used directly MessageHeaderAccessor instance. Issue: SPR-11468
-
- 05 4月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
The UserDestinationMessageHandler adds a header providing a hint for what the original destination a user may have used when subscribing. That is then used when writing messages back to WebSocket clients to ensure they dont see the internally used, transformed user destination. This change moves the header name constatn to make it more broadly applicable. For example SPR-11645.
-
- 04 4月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11655
-
- 26 3月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 25 3月, 2014 8 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11578
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11575
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11578
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11527
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11527
-
由 Sebastien Deleuze 提交于
BufferingStompDecoder message buffer size limit can now be configured with JavaConfig MessageBrokerRegistry.setMessageBufferSizeLimit() or with XML <websocket:message-brocker message-buffer-size="">. Issue: SPR-11527
-
由 Rossen Stoyanchev 提交于
Before this change the StompDecoder decoded and returned only the first Message in the ByteBuffer passed to it. So to obtain all messages from the buffer, one had to loop passing the same buffer in until no more complete STOMP frames could be decoded. This chage modifies StompDecoder to return List<Message> after exhaustively decoding all available STOMP frames from the input buffer. Also an overloaded decode method allows passing in Map that will be populated with any headers successfully parsed, which is useful for "peeking" at the "content-length" header. This change also adds a BufferingStompDecoder sub-class which buffers any content left in the input buffer after parsing one or more STOMP frames. This sub-class can also deal with fragmented messages, re-assembling them and parsing as a whole message. Issue: SPR-11527
-
- 23 3月, 2014 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
Before this change the decorator ensured that for a specific WebSocket session only one thread at a time can send a message. Other threads attempting to send would have their messages buffered and each time that occurs, a check is also made to see if the buffer limit has been reached or the send time limit has been exceeded and if so the session is closed. This change adds further protection to ensure only one thread at a time can perform the session limit checks and attempt to close the session. Furthermore if the session has timed out and become unresponsive, attempts to close it may block yet another thread. Taking this into consideration this change also ensures that state associated with the session is cleaned first before an attempt is made to close the session. Issue: SPR-11450
-
- 21 3月, 2014 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Since we now wrap the WebSocketSession with a concurrent decorator, the synchronized keyword around message sending needed to be removed. Issue: SPR-11586
-
由 Rossen Stoyanchev 提交于
-
- 20 3月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
This change exposes the WebSocketSession attributes through a message header. The StompSubProtocolHandler adds this to incoming messages. For now messaging handling methods can access the map via @Header, e.g.: @Header(StompHeaderAccessor.SESSION_ATTRIBUTES) Map<String, Object> attrs) { Issue: SPR-11566
-
- 14 2月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Before this change, when a client subscribed to a "user" destination (e.g. /user/foo), actual messages received in response to that subscription contained the server-translated, unique user destination (e.g. /foo-user123). This is not an issue for clients such as stomp.js since the subscription is unique and sufficient to match subscription responses. However, other STOMP clients do additional checks on the destination of the subscription and the response. This change ensures that messages sent to clients on user destionations always contain a destination that matches the one on the original subscription. Issue: SPR-11423
-
- 22 1月, 2014 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11327
-
由 Rossen Stoyanchev 提交于
The interface is to be implemented in addition to java.security.Principal when Principal.getName() is not globally unique enough for use in user destinations. Issue: SPR-11327
-
- 03 1月, 2014 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-11277
-
- 08 12月, 2013 1 次提交
-
-
由 Juergen Hoeller 提交于
Introduced SockJsSession interface and moved SockJsSessionFactory and SockJsServiceConfig to sockjs.transport; added initialize(SockJsServiceConfig) method to TransportHandler interface; extracted TransportHandlingSockJsService from DefaultSockJsService; moved sockjs.support.frame to sockjs.frame and extracted (Default)SockJsFrameFormat from SockJsFrame; moved SockJsHttpRequestHandler to sockjs.support; removed Jackson 1.x support
-
- 07 12月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 27 11月, 2013 2 次提交
-
-
由 Rossen Stoyanchev 提交于
Two concurrent threads should not send a message on a single WebSocket session at the same time, for example see: http://docs.oracle.com/javaee/7/api/javax/websocket/RemoteEndpoint.Basic.html In StompSubProtocolHandler it is quite possible that multiple messages may be broadcast to a single WebSocket client concurrently. This change adds synchronization around the sending of a message to a specific cilent session. Issue: SPR-11023
-
由 Phillip Webb 提交于
-
- 26 11月, 2013 1 次提交
-
-
由 Phillip Webb 提交于
Fix remaining Java compiler warnings, mainly around missing generics or deprecated code. Also add the `-Werror` compiler option to ensure that any future warnings will fail the build. Issue: SPR-11064
-
- 24 11月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Before this change spring-messaging contained a few WebSocket-related classes including WebSocket sub-protocol support for STOMP as well as @EnableWebSocketMessageBroker and related configuration classes. After this change those classes are located in the spring-websocket module under org.springframework.web.socket.messaging. This means the following classes in application configuration must have their packages updated: org.springframework.web.socket.messaging.config.EnableWebSocketMessageBroker org.springframework.web.socket.messaging.config.StompEndpointRegistry org.springframework.web.socket.messaging.config.WebSocketMessageBrokerConfigurer MessageBrokerConfigurer has been renamed to MessageBrokerRegistry and is also located in the above package.
-
- 13 11月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Before this change the amount of logging was too little or too much with TRACE turned on. This change separates useful debugging information and logs it under DEBUG and leaves more detailed information to be logged under TRACE.
-
- 08 11月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Before this change subscribing to a user-specific destination in STOMP required manually appending a unique queue suffix provided in a header with the CONNECTED frame. This change removes the need to do that. Instead STOMP clients can subscribe to "/user/queue/error" and can then begin to receive messages sent to "/user/{username}/queue/error" without colliding with any other user doing the same. Issue: SPR-11077
-
- 07 10月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 01 10月, 2013 4 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10930
-
由 Rossen Stoyanchev 提交于
Fix error in te code that handles the result of sending a heartbeat Fix error in processing DISCONNECTED frames that closed the TCP connection before the message was sent.
-
由 Andy Wilkinson 提交于
- Polish javadoc for CONNECTED_USER_HEADER - Improve method ordering
-
由 Andy Wilkinson 提交于
Previously, handling of a STOMP CONNECT message and sending of a CONNECTED response was performed by StompProtocolHandler if it was backed by SimpleBrokerMessageHandler, or left up to the real message broker if it was backed by StompBrokerRelayMessageHandler. This wasn't ideal as it should be StompProtocolHandler's job to simply map messages to and from the STOMP protocol, not to do part of the broker's job and respond directly to CONNECT. This commit introduces a new message type, CONNECT_ACK. When it receives a CONNECT message, SimpleBrokerMessageHandler will now respond with a CONNECT_ACK message that StompProtocolHandler can map into a STOMP CONNECTED message. The CONNECT_ACK message contains the CONNECT message as a header so that StompProtocolHandler has access to its accept-version header. StompProtocolHandler has been simplified so that a CONNECT message is always passed to the output channel, irrespective of whether it's backed by a simple broker or a real broker. The handleConnect flag, and the code that would set it correctly depending on the app's configuration, has been removed.
-
- 27 9月, 2013 3 次提交
-
-
由 Andy Wilkinson 提交于
Previously, the STOMP broker relay did not support heart-beats. It sent 0,0 in the heart-beats header for its own CONNECTED message, and set the heart-beats header to 0,0 when it was forwarding a CONNECTED from from a client to the broker. The broker relay now supports heart-beats for the system relay session. It will send heart-beats at the send interval that's been negotiated with the broker and will also expect to receive heart-beats at the receive interval that's been negotiated with the broker. The receive interval is multiplied by a factor of three to satisfy the STOMP spec's suggestion of lenience and ActiveMQ 5.8.0's heart-beat behaviour (see AMQ-4710). The broker relay also supports heart-beats between clients and the broker. For any given client's relay session, any heart-beats received from the client are forwarded on to the broker and any heart-beats received from the broker are sent back to the client. Internally, a heart-beat is represented as a Message with a byte array payload containing the single byte of new line ('\n') character and 'empty' headers. SubscriptionMethodReturnValueHandler has been updated to default the message type to SimpMessageType.MESSAGE. This eases the distinction between a heartbeat and a message that's been created from a return value from application code.
-
由 Andy Wilkinson 提交于
Before this change, the StompProtocolHandler always responded to clients with a CONNECTED frame, while the STOMP broker relay independantly forwarded the client CONNECT to the broker and waited for the CONNECTED frame back. That meant the relay had to buffer client messages until it received the CONNECTED response from the message broker. This change ensures that clients wait for a CONNECTED frame from the message broker. The broker relay forwards the CONNECT frame to the broker. The broker responds with a CONNECTED frame, which the relay then forwards to the client. As a result, a (well-written) client will not send any messages to the relay until the connection to the broker is fully established. The StompProtcolHandler can now be configured whether to send CONNECTED frame back. By default that is off. So when using the simple broker, the StompProtocolHandler can still respond with CONNECTED frames. The relay's handling of a connection being dropped has also been improved. When a connection for a client relay session is dropped an ERROR frame will be sent back to the client. If a connection is closed as part of a DISCONNECT frame being sent, no ERROR frame is sent back to the client. When the connection for the system relay session is dropped, an event is published indicating that the broker is unavailable. Reactor's TcpClient will then attempt to re-restablish the connection.
-
由 Andy Wilkinson 提交于
Previously, the broker relay's TCP client used Reactor's built in delimited codec as part of its parsing of STOMP frames. \0 was used as the delimiter. This worked for most STOMP frames but, crucially, not for frames with a body that contained \0: when such a frame was received it would be truncated. This commit adds a custom codec that parses STOMP frames more intelligently. It honours the content-length header allowing it to correctly parse frames with a body that contains \0. The codec largely delegates to two new classes: StompEncoder and StompDecoder. For consistency, code that previously used StompMessageConverter has been reworked to use these new encoder and decoder classes. Issue: SPR-10818
-
- 06 9月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
-
- 04 9月, 2013 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issue: SPR-10703
-