Hi,
org.apache.tomcat.websocket.STREAMS_DROP_EMPTY_MESSAGES
The above system property was added to address an issue with Tomcat's
WebSocket implementation not passing the TCK. Tomcat was sending empty
messages when the TCK wasn't expecting a message to be sent.
Now that we have access to the TCK I have been able to track down the
root cause of these failures.
The root cause is this code in WsRemoteEndpointImplBase:
...
} else if (encoder instanceof Encoder.TextStream) {
try (Writer w = getSendWriter()) {
((Encoder.TextStream) encoder).encode(obj, w);
}
}
The call to getSendWriter() triggers the state change that a write has
started. Then the exception is thrown and because of the
try-with-resources close() is called. That triggers the end of message
state change hence a zero length message is written.
The STREAMS_DROP_EMPTY_MESSAGES causes all empty messages (not just in
this error case) to be dropped.
I'm currently thinking that handling of this error case and
STREAMS_DROP_EMPTY_MESSAGES should be decoupled. The idea is that, in
the above case, obtaining the Writer is delayed until the encoder tries
to write bytes.
If the above change is implemented then what should be happen to
STREAMS_DROP_EMPTY_MESSAGES?
a) keep it as is
b) deprecate it and remove it in 10.x
c) remove it now
I'm leaning towards b)
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
