You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2006/03/26 16:16:05 UTC
Removing synchronization on a ProtocolEncoder and a ProtocolDecoder
Hi,
Peter and I once talked about removing synchronization on a ProtocolEncoder
and a ProtocolDecoder. This synchronization block is a cause of performance
degradation when a user wants to share one encoder/decoder instance between
multiple sessions. I think some decoders and almost all encoders can be
shared safely.
Any idea?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Removing synchronization on a ProtocolEncoder and a ProtocolDecoder
Posted by Trustin Lee <tr...@gmail.com>.
On 3/27/06, peter royal <pr...@apache.org> wrote:
>
> On Mar 26, 2006, at 12:44 PM, Michael Link wrote:
> > I also think that most Encoders/Decoders will be thread-safe so
> > that it should be possible to remove the synchronized-Blocks at the
> > calling places. Perhaps it would be helpful to have something
> > similar like the Collections.synchronizedXXX(...) methods for
> > Encoders/Decoders.
>
> I'm in favor of removing the synchronization, and I think a helper
> like this would also be a good addition..
Done. I added SynchronizedProtocolEncoder and SynchronizedProtocolDecoder
which are more dependency-injection friendly than static decorator methods.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: Removing synchronization on a ProtocolEncoder and a ProtocolDecoder
Posted by peter royal <pr...@apache.org>.
On Mar 26, 2006, at 12:44 PM, Michael Link wrote:
> I also think that most Encoders/Decoders will be thread-safe so
> that it should be possible to remove the synchronized-Blocks at the
> calling places. Perhaps it would be helpful to have something
> similar like the Collections.synchronizedXXX(...) methods for
> Encoders/Decoders.
I'm in favor of removing the synchronization, and I think a helper
like this would also be a good addition..
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Removing synchronization on a ProtocolEncoder and a ProtocolDecoder
Posted by Michael Link <mi...@onlinehome.de>.
Hi,
I also think that most Encoders/Decoders will be thread-safe so that it
should be possible to remove the synchronized-Blocks at the calling
places. Perhaps it would be helpful to have something similar like the
Collections.synchronizedXXX(...) methods for Encoders/Decoders.
public class NotThreadSafeCodecFactory implements ProtocolCodecFactory
{
private final ProtocolEncoder encoder;
private final ProtocolEncoder decoder;
public NotThreadSafeCodecFactory()
{
encoder = ProtocolCodec.synchronizedEncoder(new
NotThreadSafeEncoder());
decoder = ProtocolCodec.synchronizedDecoder(new
NotThreadSafeDecoder());
}
...
Using this pattern the explicit synchronization at the Codec-Calls can
be removed. One can even mix thread-safe encoders with non-thread-safe
decoders or vice versa.
Mike
Trustin Lee wrote:
> Hi,
>
> Peter and I once talked about removing synchronization on a ProtocolEncoder
> and a ProtocolDecoder. This synchronization block is a cause of performance
> degradation when a user wants to share one encoder/decoder instance between
> multiple sessions. I think some decoders and almost all encoders can be
> shared safely.
>
> Any idea?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: 24.03.2006
>
Re: Removing synchronization on a ProtocolEncoder and a ProtocolDecoder
Posted by Niklas Therning <ni...@trillian.se>.
In protocols like SMTP when there are simple line-based commands
intermixed with raw data (mail data) there are also great opportunities
for optimization if you write your own codec filter. I've implemented my
own DecoderFilter which can operate in "data mode". When not in data
mode the filter will act more or less like an ordinary ProtocolDecoder,
copying the received buffer to an autoexpanding buffer, decode SMTP
commands and pass them on to the next filter. When in data mode however
the filter will simply forward the buffers as they are received without
any copying (in most cases).
I guess this could be achieved with the MINA codec package but not
without some tweaking and not as efficiently. Please let me know if I'm
wrong.
I wouldn't mind adding this filter to MINA if anyone is interested.
/Niklas
Trustin Lee wrote:
> On 3/27/06, robert.j.greig@jpmorgan.com <ro...@jpmorgan.com> wrote:
>
>>
>>Yes, this is a good idea - we have done this and found it gave a small
>>performance increase.
>>
>>We also found that while the DemuxingProtocolCodecFactory is useful since
>>it is easy to use, it is worthwhile writing your own custom codec if you are
>>wanting to maximise performance. This is because you can often take
>>advantage of state information so that you "know" which types of frame you
>>are going to receive (or are more likely to receive) rather than going
>>through a list of codecs in a particular order every time.
>>
>
>
> A nice advice, indeed!
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
>
Re: Removing synchronization on a ProtocolEncoder and a ProtocolDecoder
Posted by Trustin Lee <tr...@gmail.com>.
On 3/27/06, robert.j.greig@jpmorgan.com <ro...@jpmorgan.com> wrote:
>
>
> Yes, this is a good idea - we have done this and found it gave a small
> performance increase.
>
> We also found that while the DemuxingProtocolCodecFactory is useful since
> it is easy to use, it is worthwhile writing your own custom codec if you are
> wanting to maximise performance. This is because you can often take
> advantage of state information so that you "know" which types of frame you
> are going to receive (or are more likely to receive) rather than going
> through a list of codecs in a particular order every time.
>
A nice advice, indeed!
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6