1 Reply Latest reply on Apr 12, 2008 7:49 AM by timfox

    Inefficiencies in JBM 2 remoting layer

    timfox

      I've been looking through our current JBM 2.0 remoting layer - which uses MINA to get a good picture of how things hang together, and it strikes me there are some serious inefficiencies / redundancy in the current implementation.

      We are using DemuxingProtocolEncoder/Decoder - and MessageEncoder/Decoder instances - this is redundant - we should just be using ProtocolEncoder and CumulutaveProtocolDecoder directly.

      The DemuxingProtocolDecoder will cause decodable to be invoked on *gulp* every codec for every packet. The current decodable() implementation is very slow since it parses the packet, including parsing strings which involves allocation of new strings too, just to find out if the packet is decodable.

      I suspect this is why we were seeing very low performance although we know MINA can give great performance.

      All this is unnecessary if we just use one codec and a switch statement to identify the packet type, and just use CumulativeProtocolDecoder directly. It will also simplify the code quite a bit.

        • 1. Re: Inefficiencies in JBM 2 remoting layer
          timfox

          The work required here actually overlaps with work I'm currently doing on splitting up messages into chunks, so I'd like to complete it as part of that work.

          Unfortunately I'm going on holiday next week, so probably won't be able to get it finished until after then.