Bug submitted DIRMINA-672
On Fri, Mar 13, 2009 at 1:54 PM, James Talmage <
[email protected]> wrote:
> I'm using 2.0.0-M4. Upon inspection of the source code, I can tell it's
> going to be a JDK / OS independent issue. Also upon inspection, I've
> discovered the bug is actually in the CumulativeProtocolDecoder (starting @
> line 125):
>
> if (!session.getTransportMetadata().hasFragmentation()) {
> doDecode(session, in, out);
> return;
> }
>
> This breaks the contract with the doDecode method as it is only called once
> (the documentation says it should be called repeatedly until it returns
> false). The following changes makes my previous test case pass, but it's
> probably a little simplistic.
>
> if (!session.getTransportMetadata().hasFragmentation()) {
> while(in.hasRemaining() && doDecode(session, in, out)){
> //Do nothing
> }
> return;
> }
>
> The code should probably make sure that if doDecode returns true, some of
> the buffer was actually consumed (as the code for fragmented transports
> does). Also, it may make sense to provide another method (i.e.
> finishNonFragmentedDecode(...)), for handling the remainder of the buffer
> after doDecode returns false.
>
> I see where the author was headed with this code. Transports (such as UDP)
> that don't support fragmentation probably don't jive with the concept of an
> accumulating buffer (what do we do with the accumulation buffer if we drop a
> UDP packet?). It does however make perfect sense to use such transports
> with the concept of a DemuxingProtocolDecoder. Perhaps it would be better
> to refactor the DemuxingProtocolDecoder so that it's not a subclass of
> CumulativeProtocolDecoder. Create a helper class that handles the fragment
> accumulation aspect. CumulativeProtocolDecoder would always use said helper
> class (throwing an error if the protocol doesn't support fragmentation), but
> DemuxingProtocolDecoder could opt to use it depending on the protocol it
> encounters.
>
> As for JIRA: I tried to submit there first, but it had been a long time
> since I'd used it to submit a bug, and couldn't figure out how to create a
> new issue. I see it now, so I'll do that as well.
>
>
>
> On Fri, Mar 13, 2009 at 7:18 AM, Emmanuel Lecharny
> <[email protected]>wrote:
>
>> Maarten Bosteels wrote:
>>
>>> and please create a JIRA ticket and attach your test-case.
>>>
>>>
>> Also give some info about the version of MINA you are using, the OS you
>> are running on and the JVM you are using.
>>
>> Reading
>> http://mina.apache.org/contact.html#Contact-BeforePostingYourMessagecould
>> help, too.
>>
>> http://www.catb.org/~esr/faqs/smart-questions.html<http://www.catb.org/%7Eesr/faqs/smart-questions.html>is
>> also a nice article.
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
>
>
> --
> James Talmage
> Owner
> JR Technical
> cell: 248-259-3137
> fax: 248-498-6071
>
--
James Talmage
Owner
JR Technical
cell: 248-259-3137
fax: 248-498-6071
