Julien Vermillard wrote:
Hi,
On Thu, 24 Apr 2008 12:06:57 +0200
Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
Hi,
I have created DIRMINA-575, set to blocker. We need better
documentation, otherwise we won't be able to get new committers to
get into the code base.
It's not just committers, it's for users too, there is some part of the
project we need to fully document, specially new ones.
Very true...
Would be nice if we can work an precise list of things to document, so
we can concentrate our efforts and follow progress easly.
We can do that. A progress page on the wiki could help us :)
I will -1 any new release until this is done, or at least, in a good
progress state, FYI.
Well is it reasonable to block milestone for doc issues ? blocking dot
zero release or RC I understand, but M it's sounding a bit extreme.
For 2.0, I don't see any problem as soon as we are moving from one
milestone to another. But I'm also thinking about 1.1.8 and 2.0-RC1. It
may be hard to get 1.1.8 documented, so let's say I will -1 2.0-GA :)
I have also some concerns about some classes which should have been
removed or deprecated. There where a convo two years ao about pooled
ByteBuffer, where we stated that it was dubious, and can be removed.
I see no reason to keep those pooled BB into the 2.0 code base, if we
have a chance to remove it before the first RC.
I also question the need for a complete rewrite of the IoBuffer,
where an simple extension of nio.ByteBuffer could have been ok. I
will try to experiment around this.
Go ahead :) The biggest issue will probably be auto expand.
Q: do we really need an auto-expand feature? I see this as dangerous, as
we have no way to stop the auto-expension of the buffer. Of course, we
can check that programmatically, but when dealing with buffers on the
network layer, I would say that fixed size buffer is pretty much a
common use.
Last, not least, before getting to GA, I would like to see perf tests
to be done ( Mina / Grizzly ). We don't need to do that right now,
but some threads have expressed some interesting questions about perf
difference between Direct and Heap buffer, which need to be addressed
seriously (microbenchmarkings are just ok to get a first impression,
not to get the real numbers), and some controversy about compared
perfs of those two projects need to be clarified.
For my personal use, MINA is value is more in the codec/filter stack
that in the raw perfs. Even if it was 30% slower than another framework
I'm not really sure to switch.
It's not about raw speed, it's also about contention, and scalability.
And as each of us know, "size matter" ;) People are really interested to
get the fastest possible code, even if they will use it to send 100
messages per day.
The hardest point to settle is which benchmark ? On which protocol ?
A raw benchmark, the simplest the best.
I think we could use the dummy echo protocol, here the gizzly example :
http://weblogs.java.net/blog/jfarcand/archive/2008/02/writing_a_tcpud_1.html
yeah, sounds good.
The biggest difficulty is to fond someone with 2 machines,
motivated enought for doing the test :)
What about a 8 way CPUs, 16 Gb of memory, 1 Gb ethernet connexion plus 9
injectors ?
Will it be enough ?
We can get this conf if needed, we just need to define the best way to
gather results in a comprehensible way.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
