mina-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rosenstrauch <dar...@darose.net>
Subject Confusion about CumulativeProtocolDecoder
Date Thu, 26 Feb 2009 04:05:22 GMT
I'm running into a bug in a Mina(2.0M4)-based server I'm developing that 
seems to be due to the implementation of CumulativeProtocolDecoder.

Reading through the code, it appears that CumulativeProtocolDecoder 
executes a different code path when I'm unit testing with a DummySession 
vs. when I'm running on a live server with a real session.  When using a 
DummySession, it looks like it completely ignores all the functionality 
for accumulating messages across decode invocations - i.e., never 
empties out the remaining contents of the in buffer (to be stored in the 
session for next invocation) and also ignores the true or false return 
value that my decoder returns from the doDecode method.  i.e.:

         if (!session.getTransportMetadata().hasFragmentation()) {
             doDecode(session, in, out);
             return;
         }

vs.

             boolean decoded = doDecode(session, buf, out);
             if (decoded) {
...
             } else {
                 break;
             }


This is causing a big problem in my testing code.  I'm trying to test 
that I'm properly handling various situations where the remote user 
makes a call to the server with erroneous and/or missing data.  In these 
cases, I'm returning "false" from the doDecode method, attempting to 
indicate to the CumulativeProtocolDecoder parent class that there's not 
enough data to decode the message.

However, the ProtocolCodeFilter calls the CumulativeProtocolDecoder's 
decode method in a loop as follows:

         while (in.hasRemaining()) {
...
                     decoder.decode(session, in, decoderOut);
         }

And since the CumulativeProtocolDecoder never empties the in buffer when 
using a DummySession, the net result is that my test is going into an 
infinite loop.


Seems to me the workaround I'd need to put in place to get around this 
would be rather ugly.  I'd need to code my CumulativeProtocolDecoder 
subclass in such a way that it's aware of whether it's being called from 
a DummySession or not (i.e., 
!session.getTransportMetadata().hasFragmentation()).  When fragmentation 
is in effect, it'd be OK to return false (need more data).  But when 
it's not in effect, then I'd need to invoke different code to flag the 
insufficient data condition as erroneous data.


So I'm wondering a few things:

* Should this implementation of CumulativeProtocolDecoder be considered 
buggy (in that it causes different behavior when using DummySessions)?

* Is there any reason why the CumulativeProtocolDecoder needs to handle 
the dummy (non-fragmentable) session differently?  Would it not be 
possible to have a single set of code that works identically for both?

* If this isn't considered a bug, then is there any cleaner way for me 
to work around this situation?


TIA,

DR

Mime
View raw message