The JSR-356 Java WebSocket 1.1 implementation is only available when Tomcat
is running on Java 7 or later.
Tomcat provides a number of Tomcat specific configuration options for
WebSocket. It is anticipated that these will be absorbed into the WebSocket
specification over time.
The write timeout used when sending WebSocket messages in blocking mode
defaults to 20000 milliseconds (20 seconds). This may be changed by setting
in the user properties collection attached to the WebSocket session. The
value assigned to this property should be a
Long and represents
the timeout to use in milliseconds. For an infinite timeout, use
If the application does not define a
incoming binary messages, any incoming binary messages must be buffered so
the entire message can be delivered in a single call to the registered
MessageHandler.Whole for binary messages. The default buffer
size for binary messages is 8192 bytes. This may be changed for a web
application by setting the servlet context initialization parameter
org.apache.tomcat.websocket.binaryBufferSize to the desired
value in bytes.
If the application does not define a
incoming text messages, any incoming text messages must be buffered so the
entire message can be delivered in a single call to the registered
MessageHandler.Whole for text messages. The default buffer size
for text messages is 8192 bytes. This may be changed for a web application by
setting the servlet context initialization parameter
org.apache.tomcat.websocket.textBufferSize to the desired value
The Java WebSocket specification 1.0 does not permit programmatic deployment
after the first endpoint has started a WebSocket handshake. By default,
Tomcat continues to permit additional programmatic deployment. This
behavior is controlled by the
org.apache.tomcat.websocket.noAddAfterHandshake servlet context
initialization parameter. The default may be changed by setting the
true but any explicit setting on the servlet context
will always take priority.
The Java WebSocket 1.0 specification requires that callbacks for
asynchronous writes are performed on a different thread to the thread that
initiated the write. Since the container thread pool is not exposed via the
Servlet API, the WebSocket implementation has to provide its own thread pool.
This thread pool is controlled by the following servlet context
org.apache.tomcat.websocket.executorCoreSize: The core
size of the executor thread pool. If not set, the default of 0 (zero)
is used. Note that the maximum permitted size of the executor thread
pool is hard coded to
Integer.MAX_VALUE which effectively
means it is unlimited.
The maximum time an idle thread will remain in the executor thread pool
until it is terminated. If not specified, the default of 60 seconds is
When using the WebSocket client to connect to server endpoints, the timeout
for IO operations while establishing the connection is controlled by the
userProperties of the provided
javax.websocket.ClientEndpointConfig. The property is
org.apache.tomcat.websocket.IO_TIMEOUT_MS and is the
timeout as a
String in milliseconds. The default is 5000 (5
When using the WebSocket client to connect to secure server endpoints, the
client SSL configuration is controlled by the
of the provided
following user properties are supported:
The default truststore password is
org.apache.tomcat.websocket.SSL_CONTEXT property is
set then the
will be ignored.
For secure server end points, host name verification is enabled by default.
To bypass this verification (not recommended), it is necessary to provide a
SSLContext via the
org.apache.tomcat.websocket.SSL_CONTEXT user property. The
SSLContext must be configured with a custom
TrustManager that extends
javax.net.ssl.X509ExtendedTrustManager. The desired verification
(or lack of verification) can then be controlled by appropriate
implementations of the individual abstract methods.