[
https://issues.apache.org/jira/browse/DIRMINA-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-767:
--------------------------------------
Description:
When we initialize a new session with a ProrocolCodecFilter in the chain, the
filter is storing the encoder and decoder into the session's Attribute :
{code}
private void initCodec(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);
}
{code}
Assuming that the codec is stateless, there is no reason to do that. If we have
thousands of sessions, that would store thousands of references to the encoder
and the decoder in the session hashmap, forever.
The factory used to get those elements can efficiently provide references to
those elements to the codec when needed.
One could think that two sessions could use two different codec for an
application, but this is a non-sense, as the codec is stored in the attributes
at the beginning, and the encoder/decoder selection does not use any context,
so they will always be the same.
was:
When we initialize a new session with a ProrocolCodecFilter in the chain, the
filter is storing the encoder and decoder into the session's Attribute :
private void initCodec(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);
}
Assuming that the codec is stateless, there is no reason to do that. If we have
thousands of sessions, that would store thousands of references to the encoder
and the decoder in the session hashmap, forever.
The factory used to get those elements can efficiently provide references to
those elements to the codec when needed.
One could think that two sessions could use two different codec for an
application, but this is a non-sense, as the codec is stored in the attributes
at the beginning, and the encoder/decoder selection does not use any context,
so they will always be the same.
> Move encoder/decoder out of the session Attributes
> --------------------------------------------------
>
> Key: DIRMINA-767
> URL: https://issues.apache.org/jira/browse/DIRMINA-767
> Project: MINA
> Issue Type: Improvement
> Affects Versions: 2.0.0-RC1
> Reporter: Emmanuel Lecharny
> Priority: Minor
> Fix For: 2.0.8
>
>
> When we initialize a new session with a ProrocolCodecFilter in the chain, the
> filter is storing the encoder and decoder into the session's Attribute :
> {code}
> private void initCodec(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);
> }
> {code}
> Assuming that the codec is stateless, there is no reason to do that. If we
> have thousands of sessions, that would store thousands of references to the
> encoder and the decoder in the session hashmap, forever.
> The factory used to get those elements can efficiently provide references to
> those elements to the codec when needed.
> One could think that two sessions could use two different codec for an
> application, but this is a non-sense, as the codec is stored in the
> attributes at the beginning, and the encoder/decoder selection does not use
> any context, so they will always be the same.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
