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 (JIRA)" <ji...@apache.org> on 2007/03/28 03:58:32 UTC
[jira] Created: (DIRMINA-363) Visibility problem in
ProtocolCodecFilter
Visibility problem in ProtocolCodecFilter
-----------------------------------------
Key: DIRMINA-363
URL: https://issues.apache.org/jira/browse/DIRMINA-363
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 1.0.2, 1.0.1, 1.0.0
Reporter: Trustin Lee
Assigned To: Trustin Lee
Fix For: 1.0.3
ProtocolCodecFilter doesn't wrap the decoder calls with synchronized block at all, which often causes 'visibility problem' in multi-threaded programming. The bug had not been revealed because ProtocolCodecFilter had explicit synchronized block that prevents the problem, but it has been removed for performance by mistake.
We need to wrap the call to ProtocolDecoder.decoder() with an appropriate synchronized block so it doesn't hurt performance much.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (DIRMINA-363) Visibility problem in ProtocolCodecFilter
Posted by Maarten Bosteels <mb...@gmail.com>.
Hyung,
check the previous thread on this mailing-list, it's exactly about that.
http://www.nabble.com/CumulativeProtocolDecoder-BUG---tf3466819.html
Maarten
On 3/29/07, HyungSok Kwon <hy...@yahoo.com> wrote:
> Hi,
>
>
> I have a question regarding the fix below:
>
> + private Object getDecoderLock( IoSession session )
> + {
> + Object lock = session.getAttribute( DECODER_LOCK );
> + if( lock == null )
> + {
> + lock = new Object();
> + session.setAttribute( DECODER_LOCK, lock );
> + }
> +
> + return lock;
> + }
>
> Shouldn't the getDecoderLock method need to be synchronized?
> Is there any chance that multiple threads call this method concurrently when lock is null?
> Please correct me if I am wrong.
>
> Thanks,
> Hyung
>
>
>
>
> "Trustin Lee (JIRA)" <ji...@apache.org> wrote:
> [ https://issues.apache.org/jira/browse/DIRMINA-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Trustin Lee closed DIRMINA-363.
> -------------------------------
>
> Resolution: Fixed
>
> Done.
>
> > Visibility problem in ProtocolCodecFilter
> > -----------------------------------------
> >
> > Key: DIRMINA-363
> > URL: https://issues.apache.org/jira/browse/DIRMINA-363
> > Project: MINA
> > Issue Type: Bug
> > Components: Core
> > Affects Versions: 1.0.0, 1.0.1, 1.0.2
> > Reporter: Trustin Lee
> > Assigned To: Trustin Lee
> > Fix For: 1.0.3
> >
> >
> > ProtocolCodecFilter doesn't wrap the decoder calls with synchronized block at all, which often causes 'visibility problem' in multi-threaded programming. The bug had not been revealed because ProtocolCodecFilter had explicit synchronized block that prevents the problem, but it has been removed for performance by mistake.
> > We need to wrap the call to ProtocolDecoder.decoder() with an appropriate synchronized block so it doesn't hurt performance much.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
>
Re: [jira] Closed: (DIRMINA-363) Visibility problem in ProtocolCodecFilter
Posted by HyungSok Kwon <hy...@yahoo.com>.
Hi,
I have a question regarding the fix below:
+ private Object getDecoderLock( IoSession session )
+ {
+ Object lock = session.getAttribute( DECODER_LOCK );
+ if( lock == null )
+ {
+ lock = new Object();
+ session.setAttribute( DECODER_LOCK, lock );
+ }
+
+ return lock;
+ }
Shouldn't the getDecoderLock method need to be synchronized?
Is there any chance that multiple threads call this method concurrently when lock is null?
Please correct me if I am wrong.
Thanks,
Hyung
"Trustin Lee (JIRA)" <ji...@apache.org> wrote:
[ https://issues.apache.org/jira/browse/DIRMINA-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trustin Lee closed DIRMINA-363.
-------------------------------
Resolution: Fixed
Done.
> Visibility problem in ProtocolCodecFilter
> -----------------------------------------
>
> Key: DIRMINA-363
> URL: https://issues.apache.org/jira/browse/DIRMINA-363
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0, 1.0.1, 1.0.2
> Reporter: Trustin Lee
> Assigned To: Trustin Lee
> Fix For: 1.0.3
>
>
> ProtocolCodecFilter doesn't wrap the decoder calls with synchronized block at all, which often causes 'visibility problem' in multi-threaded programming. The bug had not been revealed because ProtocolCodecFilter had explicit synchronized block that prevents the problem, but it has been removed for performance by mistake.
> We need to wrap the call to ProtocolDecoder.decoder() with an appropriate synchronized block so it doesn't hurt performance much.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-363) Visibility problem in
ProtocolCodecFilter
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRMINA-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Trustin Lee closed DIRMINA-363.
-------------------------------
Resolution: Fixed
Done.
> Visibility problem in ProtocolCodecFilter
> -----------------------------------------
>
> Key: DIRMINA-363
> URL: https://issues.apache.org/jira/browse/DIRMINA-363
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0, 1.0.1, 1.0.2
> Reporter: Trustin Lee
> Assigned To: Trustin Lee
> Fix For: 1.0.3
>
>
> ProtocolCodecFilter doesn't wrap the decoder calls with synchronized block at all, which often causes 'visibility problem' in multi-threaded programming. The bug had not been revealed because ProtocolCodecFilter had explicit synchronized block that prevents the problem, but it has been removed for performance by mistake.
> We need to wrap the call to ProtocolDecoder.decoder() with an appropriate synchronized block so it doesn't hurt performance much.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.