On Tue, Feb 5, 2019 at 7:58 PM Mark Thomas <ma...@apache.org> wrote:
> 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)
>
You could probably do c) as the only purpose was to stick to the TCK
behavior. When there is no spec, the TCK is supposed to be the referee (and
I don't really see why empty messages are useful).
Rémy
>
> Thoughts?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
