[
https://issues.apache.org/jira/browse/DIRMINA-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582654#comment-14582654
]
Emmanuel Lecharny commented on DIRMINA-934:
-------------------------------------------
I never liked the way the decoder was implemented, from day one. It's over
complicated.
AFAICT, the idea was to decouple the decoding from the processing of incoming
bytes. It was possible to inject a DecoderOut that is using an internal
executor to send the decoded message while the decoding is executed. For
instance, if a bufer is containing more than one message, we could imagine that
each decoded message is pushed to the DecoderOut, which spawn a thread (or get
one free thread) to process this decoded message, while the decoder kep going
with the remaining bytes. It's just killing.
I would rather call the decoder, get the message, push it to the chain,
assuming that the implementers could have added an executor filter later on in
the chain, and then keep going with the decoding. In other words, we don't need
this callback mechanism which requires some synchronization. This is what you
are proposing , somehow.
wdyt ?
> Replace synchronized with a Semaphore for better performance
> ------------------------------------------------------------
>
> Key: DIRMINA-934
> URL: https://issues.apache.org/jira/browse/DIRMINA-934
> Project: MINA
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0.7, 2.0.8
> Environment: Window 8 Pro x64, JDK 7
> Reporter: Paul Gregoire
> Labels: patch
> Fix For: 2.0.8
>
> Attachments: ProtocolCodecFilterWithSemaphoreAndMore.diff
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> Replacing the synchronized block with a Semaphore in the ProtocolCodecFilter
> provides a lot of benefit in terms of locking and also reduces CPU
> utilization. See attached git diff.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
