You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Trustin Lee <tr...@gmail.com> on 2006/03/13 00:07:47 UTC
Re: svn commit: r385254 - in /directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec: ProtocolCodecFactory.java ProtocolCodecFilter.java demux/DemuxingProtocolCodecFactory.java demux/MessageDecoderFactory.java demux/MessageEncoderFacto
On 3/13/06, peter royal <pr...@apache.org> wrote:
>
> On Mar 12, 2006, at 1:08 AM, trustin@apache.org wrote:
> > * Returns a new (or reusable) instance of {@link
> > ProtocolEncoder} which
> > * encodes message objects into binary or protocol-specific data.
> > */
> > - ProtocolEncoder getEncoder();
> > + ProtocolEncoder getEncoder() throws Exception;
> >
> > /**
> > * Returns a new (or reusable) instance of {@link
> > ProtocolDecoder} which
> > * decodes binary or protocol-specific data into message objects.
> > */
> > - ProtocolDecoder getDecoder();
> > + ProtocolDecoder getDecoder() throws Exception;
>
> Performance will suck if shared instances are returned due to
> synchronization on the returned instances in the
> ProtocolCodecFilter... Unless the synchronization is removed, it
> would be unadvisable to return shared instances.
It depends on the implementation of codec. Some codec might be stateless so
they don't need any synchronization. Of course, a codec factory usually
returns a new instance. It's a user's choice.
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: svn commit: r385254 - in /directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec: ProtocolCodecFactory.java ProtocolCodecFilter.java demux/DemuxingProtocolCodecFactory.java demux/MessageDecoderFactory.java demux/MessageEncoderFacto
Posted by peter royal <pr...@apache.org>.
On Mar 12, 2006, at 10:13 PM, Trustin Lee wrote:
> Yep I think so because decoder only works inside the thread pool
> threads. Could you dig into the code a little bit? I might be
> wrong. ;)
I'll take a peek.. That's something I discovered the hard way.. I was
using shared encoders/decoders, and performance was horrible. I'll
look and see if we can safely remove that.
> Oh, did you retain the event order? That sounds very interesting.
> I'll take a look at the code.
Yup, I separated the event ordering code from the logic for how
threads are pooled (since it logically is two different functions)..
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: svn commit: r385254 - in /directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec: ProtocolCodecFactory.java ProtocolCodecFilter.java demux/DemuxingProtocolCodecFactory.java demux/MessageDecoderFactory.java demux/MessageEncoderFacto
Posted by Trustin Lee <tr...@gmail.com>.
On 3/13/06, peter royal <pr...@apache.org> wrote:
>
> On Mar 12, 2006, at 9:25 PM, Trustin Lee wrote:
>
> Because of datagram transport and pluggable thread pool, we have to retain
> the synchronization. Datagram doesn't become a problem if DIRMINA-162 (http://issues.apache.org/jira/browse/DIRMINA-162
> ) is resolved. WRT non-leader-followers thread pool, it apparently is a
> problem.
>
> The question would be 'do we really need pluggable thread pool?' or 'does
> an ordinary thread pool outperform a leader-followers thread pool
> seriously?' Robert told us an ordinary TP performs 25% better than a LFTP,
> but it might be just because encoding is not pooled.
>
>
> Is it really specific to the type of thread pool? I attached a pluggable
> implementation to http://issues.apache.org/jira/browse/DIRMINA-184 , and
> retained the ordering of events while using a ThreadPoolExecutor..
>
Yep I think so because decoder only works inside the thread pool threads.
Could you dig into the code a little bit? I might be wrong. ;)
Oh, did you retain the event order? That sounds very interesting. I'll
take a look at the code.
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: svn commit: r385254 - in /directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec: ProtocolCodecFactory.java ProtocolCodecFilter.java demux/DemuxingProtocolCodecFactory.java demux/MessageDecoderFactory.java demux/MessageEncoderFacto
Posted by peter royal <pr...@apache.org>.
On Mar 12, 2006, at 9:25 PM, Trustin Lee wrote:
> Because of datagram transport and pluggable thread pool, we have to
> retain the synchronization. Datagram doesn't become a problem if
> DIRMINA-162 (http://issues.apache.org/jira/browse/DIRMINA-162 ) is
> resolved. WRT non-leader-followers thread pool, it apparently is a
> problem.
>
> The question would be 'do we really need pluggable thread pool?' or
> 'does an ordinary thread pool outperform a leader-followers thread
> pool seriously?' Robert told us an ordinary TP performs 25% better
> than a LFTP, but it might be just because encoding is not pooled.
Is it really specific to the type of thread pool? I attached a
pluggable implementation to http://issues.apache.org/jira/browse/
DIRMINA-184 , and retained the ordering of events while using a
ThreadPoolExecutor..
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: svn commit: r385254 - in /directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec: ProtocolCodecFactory.java ProtocolCodecFilter.java demux/DemuxingProtocolCodecFactory.java demux/MessageDecoderFactory.java demux/MessageEncoderFacto
Posted by Trustin Lee <tr...@gmail.com>.
On 3/13/06, peter royal <pr...@apache.org> wrote:
>
> t depends on the implementation of codec. Some codec might be stateless
> so they don't need any synchronization. Of course, a codec factory usually
> returns a new instance. It's a user's choice.
>
>
> No, regardless of codec implementation...
>
>
> http://svn.apache.org/viewcvs.cgi/directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java?rev=385254&view=markup
>
> look in messageReceived.. it synchronizes on decoder, prior to doing
> decoder.decode. So if you have a ProtocolDecoder that is stateless that
> could be shared, you will not be able to decode multiple messages in
> parallel.
>
Ah... now I remember! :D
Because of datagram transport and pluggable thread pool, we have to retain
the synchronization. Datagram doesn't become a problem if DIRMINA-162 (
http://issues.apache.org/jira/browse/DIRMINA-162) is resolved. WRT
non-leader-followers thread pool, it apparently is a problem.
The question would be 'do we really need pluggable thread pool?' or 'does an
ordinary thread pool outperform a leader-followers thread pool seriously?'
Robert told us an ordinary TP performs 25% better than a LFTP, but it might
be just because encoding is not pooled.
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: svn commit: r385254 - in /directory/trunks/mina/core/src/main/java/org/apache/mina/filter/codec: ProtocolCodecFactory.java ProtocolCodecFilter.java demux/DemuxingProtocolCodecFactory.java demux/MessageDecoderFactory.java demux/MessageEncoderFacto
Posted by peter royal <pr...@apache.org>.
On Mar 12, 2006, at 6:07 PM, Trustin Lee wrote:
> On 3/13/06, peter royal <pr...@apache.org> wrote:
> On Mar 12, 2006, at 1:08 AM, trustin@apache.org wrote:
> > * Returns a new (or reusable) instance of {@link
> > ProtocolEncoder} which
> > * encodes message objects into binary or protocol-specific
> data.
> > */
> > - ProtocolEncoder getEncoder();
> > + ProtocolEncoder getEncoder() throws Exception;
> >
> > /**
> > * Returns a new (or reusable) instance of {@link
> > ProtocolDecoder} which
> > * decodes binary or protocol-specific data into message
> objects.
> > */
> > - ProtocolDecoder getDecoder();
> > + ProtocolDecoder getDecoder() throws Exception;
>
> Performance will suck if shared instances are returned due to
> synchronization on the returned instances in the
> ProtocolCodecFilter... Unless the synchronization is removed, it
> would be unadvisable to return shared instances.
>
> It depends on the implementation of codec. Some codec might be
> stateless so they don't need any synchronization. Of course, a
> codec factory usually returns a new instance. It's a user's choice.
No, regardless of codec implementation...
http://svn.apache.org/viewcvs.cgi/directory/trunks/mina/core/src/main/
java/org/apache/mina/filter/codec/ProtocolCodecFilter.java?
rev=385254&view=markup
look in messageReceived.. it synchronizes on decoder, prior to doing
decoder.decode. So if you have a ProtocolDecoder that is stateless
that could be shared, you will not be able to decode multiple
messages in parallel.
-pete
--
proyal@apache.org - http://fotap.org/~osi