Maarten Bosteels wrote:
I think that will be a nice improvement: simpler and more thread-safe,
don't see any downsides.
Here is a proposal :
/**
* Associate a decoder and encoder instances to the newly created session.
*
* @param nextFilter The next filter to invoke when having processed
the current
* method
* @param session The newly created session
* @throws Exception if we can't create instances of the decoder or encoder
*/
@Override
public void sessionCreated(NextFilter nextFilter, IoSession session)
throws Exception {
// Creates the decoder and stores it into the newly created session
ProtocolDecoder decoder = factory.getDecoder(session);
session.setAttribute(DECODER, decoder);
// Creates the encoder and stores it into the newly created session
ProtocolEncoder encoder = factory.getEncoder(session);
session.setAttribute(ENCODER, encoder);
// Call the next filter
nextFilter.sessionCreated(session);
}
Don't know whether it's documented somewhere, but looking at
ExecutorFilter code, I think it's safe to say that sessionCreated will
always be called BEFORE messageReceived. (That's another promise to
add to the list of framework guarantees, I guess.)
I'm not so sure...
So your proposal looks OK to me.
I had a problem with the ChatClient example, as the ProtocolFilter
wasn't added into the chain immediately, so its sessionCreated() handler
was not called...
Also I don't really know why we are storing a decoder/encoder per
session, when usually all the sessions will use the very same
encoder/decoder instances? If the codec is stateless, we just have to
instanciate it once for the whole server, and resue it.
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
