Folks,
There appears to be a change of behavior in ProtocolCodeFilter due to the
previously non-static and now-static nature of the attribute keys used to
cache the encoder, encoder output, decoder and decoder output.
Specifically, the pre-2.0.0-RC1 code
private final AttributeKey ENCODER = new
AttributeKey(ProtocolCodecFilter.class, "encoder");
private final AttributeKey DECODER = new
AttributeKey(ProtocolCodecFilter.class, "decoder");
private final AttributeKey DECODER_OUT = new
AttributeKey(ProtocolCodecFilter.class, "decoderOut");
private final AttributeKey ENCODER_OUT = new
AttributeKey(ProtocolCodecFilter.class, "encoderOut");
has been changed to
private static final AttributeKey ENCODER = new
AttributeKey(ProtocolCodecFilter.class, "encoder");
private static final AttributeKey DECODER = new
AttributeKey(ProtocolCodecFilter.class, "decoder");
private static final AttributeKey DECODER_OUT = new
AttributeKey(ProtocolCodecFilter.class, "decoderOut");
private static final AttributeKey ENCODER_OUT = new
AttributeKey(ProtocolCodecFilter.class, "encoderOut");
This change now prevents two different ProtocolCodecFilters from operating
on the same IoSession because of the following:
private ProtocolEncoderOutput getEncoderOut(IoSession session,
NextFilter nextFilter, WriteRequest writeRequest) {
ProtocolEncoderOutput out = (ProtocolEncoderOutput)
session.getAttribute(ENCODER_OUT);
if (out == null) {
// Create a new instance, and stores it into the session
out = new ProtocolEncoderOutputImpl(session, nextFilter,
writeRequest);
session.setAttribute(ENCODER_OUT, out);
}
return out;
}
When a second instance of ProtocolCodecFilter attempts to retrieve its
encoder output for the first time, then it finds the shared instance cached
in the session by the first ProtocolCodecFilter, under the same static
attribute key. When the attribute keys were non-static, then the second
ProtocolCodecFilter's behavior was isolated from the first, as desired.
Typically, filter instances are created in advance, and reused for all
sessions, so there does not seem to be any practical advantage in having
these attribute keys static.
Is there any objection to reverting these 4 attribute key constants to
non-static for 2.0.0 final?
Kind Regards,
John Fallows
--
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.960.8148
888 Villa St, Ste 410 | Mountain View, CA 94041, USA
