You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by 이희승 (Trustin Lee) <t...@gmail.com> on 2008/04/24 10:44:11 UTC
Issues to resolve for 2.0.0 (GA)
Hi,
There are currently 47 unresolved issues in our issue tracking system.
IMO, they can be categorized into the following categories:
1) Bugs that needs fix
https://issues.apache.org/jira/browse/DIRMINA-539
https://issues.apache.org/jira/browse/DIRMINA-574
These are known bugs so they need to be fixed before the GA release.
2) New features or improvement requests that require refactoring or API
change
https://issues.apache.org/jira/browse/DIRMINA-554
3) Others that don't require any API change
All the other issues
This means we have high possibility of reaching the first RC after three
fixes. This is a good news for many those who use 2.0.0 milestones. If
there's no noticeable issues with the RC, we can proceed to the first GA
release of MINA 2.
After then, we can keep adding bells and whistles in 2.1, 2.2 and so on.
The reasoning behind this idea is to give users more chance to use MINA
2, which is a great step-forward comparing to MINA 1, and eventually
will lessen our burden to maintain three branches at the same time.
WDYT?
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Issues to resolve for 2.0.0 (GA)
Posted by Emmanuel Lecharny <el...@apache.org>.
"이희승 (Trustin Lee) <tr...@gmail.com>" wrote:
> Emmanuel Lecharny wrote:
>
>> 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.
>>
>
> ? The pooling already has been removed loooooooooooooooooooong time ago.
>
Sh*t... Was looking at the wrong code base (1.1.x) :) My bad !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Issues to resolve for 2.0.0 (GA)
Posted by 이희승 (Trustin Lee) <t...@gmail.com>.
Emmanuel Lecharny wrote:
> 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.
? The pooling already has been removed loooooooooooooooooooong time ago.
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: Issues to resolve for 2.0.0 (GA)
Posted by Emmanuel Lecharny <el...@apache.org>.
David M. Lloyd wrote:
> On 04/24/2008 05:06 AM, Emmanuel Lecharny 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.
>>
>> I will -1 any new release until this is done, or at least, in a good
>> progress state, FYI.
>
> Who will do it? Making an issue, setting it to blocker, and not
> assigning it to anybody will not make this documentation write itself.
Anyone who want to take care of it. We are all volunteers...
>
>> 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.
>
> You can't extend ByteBuffer, it's impossible.
Yeah, sorry, my comment was a little bit misleaded. I didnt meant
"extends ByteBuffer", but define helper classes to deal with specific
needs. For instance, I'm not sure that providing Unsigned getters is
really something which imply the definition of a new class (IoBuffer).
So is the auto-expand capability. IMHO, the justification for the
existence of this class are weak.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Issues to resolve for 2.0.0 (GA)
Posted by "David M. Lloyd" <da...@redhat.com>.
On 04/24/2008 05:06 AM, Emmanuel Lecharny 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.
>
> I will -1 any new release until this is done, or at least, in a good
> progress state, FYI.
Who will do it? Making an issue, setting it to blocker, and not assigning
it to anybody will not make this documentation write itself.
> 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.
You can't extend ByteBuffer, it's impossible.
- DML
Re: Issues to resolve for 2.0.0 (GA)
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> Hi,
>
> On Thu, 24 Apr 2008 12:06:57 +0200
> Emmanuel Lecharny <el...@apache.org> 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
Re: Issues to resolve for 2.0.0 (GA)
Posted by Emmanuel Lecharny <el...@apache.org>.
Niklas Gustavsson wrote:
> On Thu, Apr 24, 2008 at 12:43 PM, Julien Vermillard
> <jv...@archean.fr> wrote:
>
>> > 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.
>>
>
> -1 votes does not veto a release, it's only a veto on code changes. Of
> course, a negative vote is still a strong indication that something is
> wrong.
>
Exactly. If the community thinks that the release is in good shape, but
me, then I see no reason why it should be blocked because I have had a
bad day...
Thanks for the clarification, Niklas !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Issues to resolve for 2.0.0 (GA)
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Thu, Apr 24, 2008 at 12:43 PM, Julien Vermillard
<jv...@archean.fr> wrote:
> > 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.
-1 votes does not veto a release, it's only a veto on code changes. Of
course, a negative vote is still a strong indication that something is
wrong.
http://apache.org/foundation/voting.html
/niklas
Re: Issues to resolve for 2.0.0 (GA)
Posted by Julien Vermillard <jv...@archean.fr>.
Hi,
On Thu, 24 Apr 2008 12:06:57 +0200
Emmanuel Lecharny <el...@apache.org> 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.
Would be nice if we can work an precise list of things to document, so
we can concentrate our efforts and follow progress easly.
>
> 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.
>
> 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.
>
> 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.
The hardest point to settle is which benchmark ? On which protocol ?
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
The biggest difficulty is to fond someone with 2 machines,
motivated enought for doing the test :)
>
> Julien's question about the serial project also needs to be
> addressed, otherwise, he may be disapointed.
Well I think it's going to be shorted soon I think.
>
> Still lot to do before going to 2.0-GA, IMHO ...
>
> Thanks !
>
> Thanks
>
> "이희승 (Trustin Lee) <tr...@gmail.com>" wrote:
> > Hi,
> >
> > There are currently 47 unresolved issues in our issue tracking
> > system. IMO, they can be categorized into the following categories:
> >
> > 1) Bugs that needs fix
> >
> > https://issues.apache.org/jira/browse/DIRMINA-539
> > https://issues.apache.org/jira/browse/DIRMINA-574
> >
> > These are known bugs so they need to be fixed before the GA release.
> >
> > 2) New features or improvement requests that require refactoring or
> > API change
> >
> > https://issues.apache.org/jira/browse/DIRMINA-554
> >
> > 3) Others that don't require any API change
> >
> > All the other issues
> >
> > This means we have high possibility of reaching the first RC after
> > three fixes. This is a good news for many those who use 2.0.0
> > milestones. If there's no noticeable issues with the RC, we can
> > proceed to the first GA release of MINA 2.
> >
> > After then, we can keep adding bells and whistles in 2.1, 2.2 and
> > so on.
> >
> > The reasoning behind this idea is to give users more chance to use
> > MINA 2, which is a great step-forward comparing to MINA 1, and
> > eventually will lessen our burden to maintain three branches at the
> > same time.
> >
> > WDYT?
> >
>
>
Re: Issues to resolve for 2.0.0 (GA)
Posted by Emmanuel Lecharny <el...@apache.org>.
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.
I will -1 any new release until this is done, or at least, in a good
progress state, FYI.
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.
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.
Julien's question about the serial project also needs to be addressed,
otherwise, he may be disapointed.
Still lot to do before going to 2.0-GA, IMHO ...
Thanks !
Thanks
"이희승 (Trustin Lee) <tr...@gmail.com>" wrote:
> Hi,
>
> There are currently 47 unresolved issues in our issue tracking system.
> IMO, they can be categorized into the following categories:
>
> 1) Bugs that needs fix
>
> https://issues.apache.org/jira/browse/DIRMINA-539
> https://issues.apache.org/jira/browse/DIRMINA-574
>
> These are known bugs so they need to be fixed before the GA release.
>
> 2) New features or improvement requests that require refactoring or API
> change
>
> https://issues.apache.org/jira/browse/DIRMINA-554
>
> 3) Others that don't require any API change
>
> All the other issues
>
> This means we have high possibility of reaching the first RC after three
> fixes. This is a good news for many those who use 2.0.0 milestones. If
> there's no noticeable issues with the RC, we can proceed to the first GA
> release of MINA 2.
>
> After then, we can keep adding bells and whistles in 2.1, 2.2 and so on.
>
> The reasoning behind this idea is to give users more chance to use MINA
> 2, which is a great step-forward comparing to MINA 1, and eventually
> will lessen our burden to maintain three branches at the same time.
>
> WDYT?
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Issues to resolve for 2.0.0 (GA)
Posted by Maarten Bosteels <mb...@gmail.com>.
Hi Trustin,
Sounds great !!!
Maarten
On Thu, Apr 24, 2008 at 10:44 AM, "이희승 (Trustin Lee) <tr...@gmail.com>
wrote:
> Hi,
>
> There are currently 47 unresolved issues in our issue tracking system.
> IMO, they can be categorized into the following categories:
>
> 1) Bugs that needs fix
>
> https://issues.apache.org/jira/browse/DIRMINA-539
> https://issues.apache.org/jira/browse/DIRMINA-574
>
> These are known bugs so they need to be fixed before the GA release.
>
> 2) New features or improvement requests that require refactoring or API
> change
>
> https://issues.apache.org/jira/browse/DIRMINA-554
>
> 3) Others that don't require any API change
>
> All the other issues
>
> This means we have high possibility of reaching the first RC after three
> fixes. This is a good news for many those who use 2.0.0 milestones. If
> there's no noticeable issues with the RC, we can proceed to the first GA
> release of MINA 2.
>
> After then, we can keep adding bells and whistles in 2.1, 2.2 and so on.
>
> The reasoning behind this idea is to give users more chance to use MINA
> 2, which is a great step-forward comparing to MINA 1, and eventually
> will lessen our burden to maintain three branches at the same time.
>
> WDYT?
> --
> Trustin Lee - Principal Software Engineer, JBoss, Red Hat
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
>
>