MINA
  1. MINA
  2. DIRMINA-815

CumulativeProtocolDecoder.decode(...) does not find previous buffer

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.2
    • Fix Version/s: 2.0.3
    • Component/s: None
    • Labels:
      None
    • Environment:
      any

      Description

      CumulativeProtocolDecoder does not find previous input buffer stored in 'session.attributes' (see 'CumulativeProtocolDecoder.java', line 136), probably because 'attributes' uses a ConcurrentHashMap, and class AttributeKey does NOT implement hashCode(), rendering CumulativeProtocolDecoder useless.

      1. AttributeKey.patch
        1 kB
        Sergey Ishchenko

        Activity

        Show
        Emmanuel Lecharny added a comment - Fixed with : http://svn.apache.org/viewvc?rev=1090594&view=rev
        Hide
        Emmanuel Lecharny added a comment -

        We can keep the hashcode in the name this way :
        this.name = source.getName() + '.' + name + '@' + Integer.toHexString(super.hashCode());

        Also the hashcode method could be simpler :

        @Override
        public int hashCode()

        { return name.hashCode()); }
        Show
        Emmanuel Lecharny added a comment - We can keep the hashcode in the name this way : this.name = source.getName() + '.' + name + '@' + Integer.toHexString(super.hashCode()); Also the hashcode method could be simpler : @Override public int hashCode() { return name.hashCode()); }
        Hide
        Sergey Ishchenko added a comment -

        I've added equals and hashCode methods to AttributeKey. But I had to remove object address addition to private name field. Wouldn't that be a problem in other use cases of AttributeKey?
        Anyway, please take a look at patch and give some feedback.

        Show
        Sergey Ishchenko added a comment - I've added equals and hashCode methods to AttributeKey. But I had to remove object address addition to private name field. Wouldn't that be a problem in other use cases of AttributeKey? Anyway, please take a look at patch and give some feedback.
        Hide
        Emmanuel Lecharny added a comment -

        In any case, if a new encoder and decoder are not created for every single request, as Serguey is pointing out, then the CummulativeProtocolDecoder should work, no matter if we have a hashCode() method or not.

        However, it's a bad thing not to have such a method. It will be added (ad the equals method that comes along)

        Show
        Emmanuel Lecharny added a comment - In any case, if a new encoder and decoder are not created for every single request, as Serguey is pointing out, then the CummulativeProtocolDecoder should work, no matter if we have a hashCode() method or not. However, it's a bad thing not to have such a method. It will be added (ad the equals method that comes along)
        Hide
        Sergey Ishchenko added a comment -

        I've also encountered this issue. It occures if an implementation of ProtocolCodecFactory returns new instances of encoder/decoder on each call to getDecoder/getEncoder:
        public class PhysicalLayerProtocolCodecFactory implements ProtocolCodecFactory {

        @Override
        public ProtocolDecoder getDecoder(IoSession session) throws Exception

        { return new PhysicalLayerDecoder(); }

        @Override
        public ProtocolEncoder getEncoder(IoSession session) throws Exception

        { return new PhysicalLayerEncoder(); }

        }

        I had to use this workaround:
        public class PhysicalLayerProtocolCodecFactory implements ProtocolCodecFactory {
        private final PhysicalLayerDecoder decoder;
        private final PhysicalLayerEncoder encoder;

        public PhysicalLayerProtocolCodecFactory()

        { this.decoder = new PhysicalLayerDecoder(); this.encoder = new PhysicalLayerEncoder(); }

        @Override
        public ProtocolDecoder getDecoder(IoSession session) throws Exception

        { return this.decoder; }

        @Override
        public ProtocolEncoder getEncoder(IoSession session) throws Exception

        { return this.encoder; }

        }

        Show
        Sergey Ishchenko added a comment - I've also encountered this issue. It occures if an implementation of ProtocolCodecFactory returns new instances of encoder/decoder on each call to getDecoder/getEncoder: public class PhysicalLayerProtocolCodecFactory implements ProtocolCodecFactory { @Override public ProtocolDecoder getDecoder(IoSession session) throws Exception { return new PhysicalLayerDecoder(); } @Override public ProtocolEncoder getEncoder(IoSession session) throws Exception { return new PhysicalLayerEncoder(); } } I had to use this workaround: public class PhysicalLayerProtocolCodecFactory implements ProtocolCodecFactory { private final PhysicalLayerDecoder decoder; private final PhysicalLayerEncoder encoder; public PhysicalLayerProtocolCodecFactory() { this.decoder = new PhysicalLayerDecoder(); this.encoder = new PhysicalLayerEncoder(); } @Override public ProtocolDecoder getDecoder(IoSession session) throws Exception { return this.decoder; } @Override public ProtocolEncoder getEncoder(IoSession session) throws Exception { return this.encoder; } }
        Hide
        Siro Mateos added a comment -

        I'm testing version 2.0.1. Eclipse's automatic implementation of equals() and hashCode() for class AttributeKey seems to work fine.

        Show
        Siro Mateos added a comment - I'm testing version 2.0.1. Eclipse's automatic implementation of equals() and hashCode() for class AttributeKey seems to work fine.
        Hide
        Emmanuel Lecharny added a comment -

        I would not be as vocal as you are, because every java class inherit from Object, which has a hashCode() method implemented, but basically, you are right : this is a smell, and the AttributeKey class must have a hashcode() and an equals() method.

        Which version are you testing ?

        Show
        Emmanuel Lecharny added a comment - I would not be as vocal as you are, because every java class inherit from Object, which has a hashCode() method implemented, but basically, you are right : this is a smell, and the AttributeKey class must have a hashcode() and an equals() method. Which version are you testing ?

          People

          • Assignee:
            Emmanuel Lecharny
            Reporter:
            Siro Mateos
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 0.25h
              0.25h
              Remaining:
              Remaining Estimate - 0.25h
              0.25h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development