|
| 1 | +/* |
| 2 | + * Copyright 2002-2014 the original author or authors. |
| 3 | + * |
| 4 | + * Licensed under the Apache License, Version 2.0 (the "License"); |
| 5 | + * you may not use this file except in compliance with the License. |
| 6 | + * You may obtain a copy of the License at |
| 7 | + * |
| 8 | + * http://www.apache.org/licenses/LICENSE-2.0 |
| 9 | + * |
| 10 | + * Unless required by applicable law or agreed to in writing, software |
| 11 | + * distributed under the License is distributed on an "AS IS" BASIS, |
| 12 | + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 13 | + * See the License for the specific language governing permissions and |
| 14 | + * limitations under the License. |
| 15 | + */ |
| 16 | +package org.springframework.web.socket.config.annotation; |
| 17 | + |
| 18 | + |
| 19 | +/** |
| 20 | + * Configure the processing of messages received from and sent to WebSocket clients. |
| 21 | + * |
| 22 | + * @author Rossen Stoyanchev |
| 23 | + * @since 4.0.3 |
| 24 | + */ |
| 25 | +public class WebSocketTransportRegistration { |
| 26 | + |
| 27 | + private Integer messageBufferSizeLimit; |
| 28 | + |
| 29 | + private Integer sendTimeLimit; |
| 30 | + |
| 31 | + private Integer sendBufferSizeLimit; |
| 32 | + |
| 33 | + |
| 34 | + /** |
| 35 | + * Configure the maximum size of the buffer to use when an incoming message |
| 36 | + * for a sub-protocol (e.g. STOMP) has been split into multiple WebSocket |
| 37 | + * messages or multiple HTTP POSTs when SockJS fallback options are in use. |
| 38 | + * |
| 39 | + * <p>In theory a WebSocket message can be almost unlimited in size. |
| 40 | + * In practice WebSocket servers impose limits on incoming message size. |
| 41 | + * STOMP clients for example tend to split large messages around 16K |
| 42 | + * boundaries. Therefore a server must be able to buffer partial content |
| 43 | + * and decode when enough data is received. Use this property to configure |
| 44 | + * the max size of the buffer to use. |
| 45 | + * |
| 46 | + * <p>The default value is 64K (i.e. 64 * 1024). |
| 47 | + * |
| 48 | + * <p><strong>NOTE</strong> that the current version 1.2 of the STOMP spec |
| 49 | + * does not specifically discuss how to send STOMP messages over WebSocket. |
| 50 | + * Version 2 of the spec will but in the mean time existing client libraries |
| 51 | + * have already established a practice that servers must handle. |
| 52 | + */ |
| 53 | + public WebSocketTransportRegistration setMessageBufferSizeLimit(int bufferSizeLimit) { |
| 54 | + this.messageBufferSizeLimit = bufferSizeLimit; |
| 55 | + return this; |
| 56 | + } |
| 57 | + |
| 58 | + /** |
| 59 | + * Protected accessor for internal use. |
| 60 | + */ |
| 61 | + protected Integer getMessageBufferSizeLimit() { |
| 62 | + return this.messageBufferSizeLimit; |
| 63 | + } |
| 64 | + |
| 65 | + /** |
| 66 | + * Configure a time limit (in milliseconds) for the maximum amount of a time |
| 67 | + * allowed when sending messages to a WebSocket session or writing to an |
| 68 | + * HTTP response when SockJS fallback option are in use. |
| 69 | + * |
| 70 | + * <p>In general WebSocket servers expect that messages to a single WebSocket |
| 71 | + * session are sent from a single thread at a time. This is automatically |
| 72 | + * guaranteed when using {@code @EnableWebSocketMessageBroker} configuration. |
| 73 | + * If message sending is slow, or at least slower than rate of messages sending, |
| 74 | + * subsequent messages are buffered until either the {@code sendTimeLimit} |
| 75 | + * or the {@code sendBufferSizeLimit} are reached at which point the session |
| 76 | + * state is cleared and an attempt is made to close the session. |
| 77 | + * |
| 78 | + * <p><strong>NOTE</strong> that the session time limit is checked only |
| 79 | + * on attempts to send additional messages. So if only a single message is |
| 80 | + * sent and it hangs, the session will not time out until another message is |
| 81 | + * sent or the underlying physical socket times out. So this is not a |
| 82 | + * replacement for WebSocket server or HTTP connection timeout but is rather |
| 83 | + * intended to control the extent of buffering of unsent messages. |
| 84 | + * |
| 85 | + * <p><strong>NOTE</strong> that closing the session may not succeed in |
| 86 | + * actually closing the physical socket and may also hang. This is true |
| 87 | + * especially when using blocking IO such as the BIO connector in Tomcat |
| 88 | + * that is used by default on Tomcat 7. Therefore it is recommended to ensure |
| 89 | + * the server is using non-blocking IO such as Tomcat's NIO connector that |
| 90 | + * is used by default on Tomcat 8. If you must use blocking IO consider |
| 91 | + * customizing OS-level TCP settings, for example |
| 92 | + * {@code /proc/sys/net/ipv4/tcp_retries2} on Linux. |
| 93 | + * |
| 94 | + * <p>The default value is 10 seconds (i.e. 10 * 10000). |
| 95 | + * |
| 96 | + * @param timeLimit the timeout value in milliseconds; the value must be |
| 97 | + * greater than 0, otherwise it is ignored. |
| 98 | + */ |
| 99 | + public WebSocketTransportRegistration setSendTimeLimit(int timeLimit) { |
| 100 | + this.sendTimeLimit = timeLimit; |
| 101 | + return this; |
| 102 | + } |
| 103 | + |
| 104 | + /** |
| 105 | + * Protected accessor for internal use. |
| 106 | + */ |
| 107 | + protected Integer getSendTimeLimit() { |
| 108 | + return this.sendTimeLimit; |
| 109 | + } |
| 110 | + |
| 111 | + /** |
| 112 | + * Configure the maximum amount of data to buffer when sending messages |
| 113 | + * to a WebSocket session, or an HTTP response when SockJS fallback |
| 114 | + * option are in use. |
| 115 | + * |
| 116 | + * <p>In general WebSocket servers expect that messages to a single WebSocket |
| 117 | + * session are sent from a single thread at a time. This is automatically |
| 118 | + * guaranteed when using {@code @EnableWebSocketMessageBroker} configuration. |
| 119 | + * If message sending is slow, or at least slower than rate of messages sending, |
| 120 | + * subsequent messages are buffered until either the {@code sendTimeLimit} |
| 121 | + * or the {@code sendBufferSizeLimit} are reached at which point the session |
| 122 | + * state is cleared and an attempt is made to close the session. |
| 123 | + * |
| 124 | + * <p><strong>NOTE</strong> that closing the session may not succeed in |
| 125 | + * actually closing the physical socket and may also hang. This is true |
| 126 | + * especially when using blocking IO such as the BIO connector in Tomcat |
| 127 | + * configured by default on Tomcat 7. Therefore it is recommended to ensure |
| 128 | + * the server is using non-blocking IO such as Tomcat's NIO connector used |
| 129 | + * by default on Tomcat 8. If you must use blocking IO consider customizing |
| 130 | + * OS-level TCP settings, for example {@code /proc/sys/net/ipv4/tcp_retries2} |
| 131 | + * on Linux. |
| 132 | + * |
| 133 | + * <p>The default value is 512K (i.e. 512 * 1024). |
| 134 | + * |
| 135 | + * @param sendBufferSizeLimit the maximum number of bytes to buffer when |
| 136 | + * sending messages; if the value is less than or equal to 0 then buffering |
| 137 | + * is effectively disabled. |
| 138 | + */ |
| 139 | + public WebSocketTransportRegistration setSendBufferSizeLimit(int sendBufferSizeLimit) { |
| 140 | + this.sendBufferSizeLimit = sendBufferSizeLimit; |
| 141 | + return this; |
| 142 | + } |
| 143 | + |
| 144 | + /** |
| 145 | + * Protected accessor for internal use. |
| 146 | + */ |
| 147 | + protected Integer getSendBufferSizeLimit() { |
| 148 | + return this.sendBufferSizeLimit; |
| 149 | + } |
| 150 | +} |
0 commit comments