Oh yeah, that's a good idea. We have been stepping on the accelerator for a very long time to implement new features and improve performance, so it seems like it's time to take care of stability.
One problem is that most bug reports these days are not easy to
reproduce, which means they are related with high concurrency situation
and unit tests cannot be the way to find many potential bugs, although
CircularQueue issue is probably detectable by a unit test.
The best solution would be to have a kind of regression test lab within
the ASF so we can run some exhaustive tests preiodically and share the
facility with other projects like HTTPD and Directory. I don't think it
will happen soon though.
Anyways, we need to raise the coverage rate on and on.
2008-02-13 (수), 03:23 -0500, Alex Karasulu 쓰시길:
> I've been noticing and hearing many complaints about the amount of tests and
> overall coverage in the MINA code base. If there was more coverage
> contributors and committers would feel much more comfortable making changes
> knowing they're not going to break something.
>
> At some point we need to stop growing the code base like mad and just start
> documenting and thoroughly testing the code. Otherwise as we grow the
> barrier of entry into the heart of MINA especially will increase.
>
> Alex
>
> On Feb 13, 2008 12:00 AM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
>
> > 2008-02-01 (금), 13:57 +0100, Emmanuel Lecharny 쓰시길:
> > > Makoto YUI wrote:
> > > > I have the same problem to you.
> > > > I'm using the latest snapshot (
> > mina-core-2.0.0-M1-20080124.103130-116.jar).
> > > >
> > > > | java.lang.ArrayIndexOutOfBoundsException
> > > > | at
> > > > org.apache.mina.util.CircularQueue.shrinkIfNeeded(CircularQueue.java
> > :233)
> > > >
> > > > This problem caused when newLen is less than the length of
> > > > System.arraycopy().
> > > >
> > > > | Object[] tmp = new Object[newLen];
> > > > | ..
> > > > | if (first < last) {
> > > > | System.arraycopy(items, first, tmp, 0, last - first);
> > > > * bug
> > > > | } else {
> > > > | System.arraycopy(items, first, tmp, 0, oldLen -
> > first); *
> > > > bug
> > > > | System.arraycopy(items, 0, tmp, oldLen - first,
> > last); *
> > > > bug
> > > > | }
> > > >
> > > > It seems to be preferred to use java.util.LinkedList instead of custom
> > > > CircularQueue
> > > > for messageQueue(s) in
> > > > AbstractProtocolEncoderOutput/AbstractProtocolDecoderOutput.
> > > >
> > > > Thanks,
> > > >
> > > > Makoto YUI
> > > >
> > > I don't think that it's a problem to use our own brewed CircularQueue
> > ...
> > >
> > > I looked at the code, and I'm a little bit annoyed that there is
> > > absolutely no comment at all. There is a clear bug somewhere, as you got
> > > a java.lang.ArrayIndexOutOfBoundsException (and many thanks for having
> > > posting this mail, btw !!!), but without a knowledge about what is doing
> > > this class, it's really difficult to find a fix in 2 minutes. This
> > > should not be the case...
> > >
> > > Btw, there is no test cases either...
> >
> > I wrote that evil code hehe. :)
> >
> > There's test case for CircularQueue in 1.x branch, but it was removed
> > from the trunk when I replace it with LinkedList. After then, I
> > realized the CircularQueue implementation performs better than
> > LinkedList, so I resurrected it. However, I forgot to resurrect the
> > test case together. Will take care of this when I get back home.
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> >
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
