It appears what is happening is this: Sometimes the 67 bytes for the
handshake come in on their own (this is when it works), other times
the 67 for the handshake and the 6 for the bitfield are being combined
when processed (this is when it fails). When the ByteBuffer contains
73, the PeerWireHandshakeHandler processed the 67 for the handshake
and returns true, saying it has finished decoding. Since there are
bytes left in the buffer the when control returns to the underlying
CumulativeProtocolDecoder this code is invoked
CumulativeProtocolDecoder
if( !buf.hasRemaining() )
{
break;
}
resulting in the PeerWireHandshakeDecode attempting to process the
bytes, before the change to PeerWireMessageDecode occurs. Even
changing the filter during the doDecode would fail, because the
CumulativeProtocolDecoder code above will still call the same Decoder.
Doesn't look like a bug if either setup, just need to change my
architecture a little.
Using a SwithingProtocolHandler would work, since the resulting call
would switch how it is handled within the same Decoder, avoiding this
problem. I'll go ahead and move to that kind of design. I didn't think
trying to switch Decoders would be a good idea, but it felt like it
would be the most intuitive to someone working with my code in the
future.
Thanks for all of the help,
Tyler
On 5/14/06, Trustin Lee <[EMAIL PROTECTED]> wrote:
Please try to create a new ProtocolDecoder which wraps two decoders you
implemented, and switches them with a method call:
public SwitchingProtocolDecoder implements ProtocolDecoder {
private boolean useDecoderB;
private final ProtocolDecoder decoderA = ...;
private final ProtocolDecoder decoderB = ...;
public void decode(...) {
if (useDecoderB) {
decoderB.decode(...);
} else {
decoderA.decode(...);
}
}
}
Actually we're going to provide this kind of switch soon...
Thanks,
Trustin
On 5/15/06, Tyler Pitchford <[EMAIL PROTECTED]> wrote:
>
> RECEIVED: DirectBuffer[pos=0 lim=6 cap=8192: 00 00 00 02 05 FE]
It seems like you inserted a LoggingFilter. Am I correct? Were there any
logged exceptions then?
Which is the message I'm expecting. However, if I do the addFirst,
> then I get no log printout. I've run Ethereal to check if the packets
> I'm looking for are being sent and it's definitely sending the packet
> to me, but it's not always being picked up by MINA, that's for sure.
> It's very spotty if the message is received (changing of filters or
> not).
Do you mean that you didn't get any messages or exceptions even when you
didn't remove nor add a codec? What happens if you don't change the codec
and encounter a unknown data?
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
