You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/09/13 17:13:32 UTC
[VOTE] MINA 2.0.0
Hi,
The last version of MINA (2.0.0) has been released !
Here are the complete release notes from JIRA:
Bug
* [DIRMINA-539 <https://issues.apache.org/jira/browse/DIRMINA-539>]
- NioDatagramConnector doesn't takes the TrafficClass value set to
his DatagramSessionConfig
* [DIRMINA-650 <https://issues.apache.org/jira/browse/DIRMINA-650>]
- Mina server does not recieve all data sent by client using
SSLSocketFactory
* [DIRMINA-678 <https://issues.apache.org/jira/browse/DIRMINA-678>]
- NioProcessor 100% CPU usage on Linux (epoll selector bug)
* [DIRMINA-679 <https://issues.apache.org/jira/browse/DIRMINA-679>]
- NullPointerException in ProtocolCodecFilter.filterWrite
* [DIRMINA-684 <https://issues.apache.org/jira/browse/DIRMINA-684>]
- NullPointerException when opening socket to localhost
* [DIRMINA-711 <https://issues.apache.org/jira/browse/DIRMINA-711>]
- Adding some logs in the chain make the MDCFilter tests to fail
* [DIRMINA-720 <https://issues.apache.org/jira/browse/DIRMINA-720>]
- Hardware Flow Control Disables Serial Port on Windows Platform
* [DIRMINA-732 <https://issues.apache.org/jira/browse/DIRMINA-732>]
- Session Idle events never comes in sessions managed by
NioDatagramAcceptor
* [DIRMINA-733 <https://issues.apache.org/jira/browse/DIRMINA-733>]
- The profile method in the ProfilerTimerFilter can caused more
methods to be profiled than intended.
* [DIRMINA-742 <https://issues.apache.org/jira/browse/DIRMINA-742>]
- When session is closed, DefaultIoFilterChain is in deadlock.
* [DIRMINA-746 <https://issues.apache.org/jira/browse/DIRMINA-746>]
- DefaultSocketSessionConfig.setReceiveBufferSize(...) throws
NullPointerException
* [DIRMINA-748 <https://issues.apache.org/jira/browse/DIRMINA-748>]
- CachedBufferAllocator does not free buffers when
maxCachedBufferSize=0
* [DIRMINA-749 <https://issues.apache.org/jira/browse/DIRMINA-749>]
- Cannot have more than one CODEC in the chain
* [DIRMINA-753 <https://issues.apache.org/jira/browse/DIRMINA-753>]
- Some writes observed to stall until select times out
* [DIRMINA-755 <https://issues.apache.org/jira/browse/DIRMINA-755>]
- IoConnectot.dispose blocks forever
* [DIRMINA-760 <https://issues.apache.org/jira/browse/DIRMINA-760>]
- Client fails to detect disconnection
* [DIRMINA-762 <https://issues.apache.org/jira/browse/DIRMINA-762>]
- WARN org.apache.mina.core.service.IoProcessor - Create a new
selector. Selected is 0, delta = 0
* [DIRMINA-763 <https://issues.apache.org/jira/browse/DIRMINA-763>]
- Errors with Datagram when running tests on linux
* [DIRMINA-764 <https://issues.apache.org/jira/browse/DIRMINA-764>]
- DDOS possible in only a few seconds...
* [DIRMINA-770 <https://issues.apache.org/jira/browse/DIRMINA-770>]
- Remove all the new NullPointerException()
* [DIRMINA-771 <https://issues.apache.org/jira/browse/DIRMINA-771>]
- Calling NioSocketSession.toString() causes java.lang.Error
* [DIRMINA-777 <https://issues.apache.org/jira/browse/DIRMINA-777>]
- IoSessionConfig.setUseReadOperation(true) doesn't seem to work
* [DIRMINA-778 <https://issues.apache.org/jira/browse/DIRMINA-778>]
- TextLineDecoder not thread safe?
* [DIRMINA-779 <https://issues.apache.org/jira/browse/DIRMINA-779>]
- SSLHandler can re-order data that it reads
* [DIRMINA-782 <https://issues.apache.org/jira/browse/DIRMINA-782>]
- Combination of SslFilter & FileRegionWriteFilter causes
messageSent events to be lost
* [DIRMINA-784 <https://issues.apache.org/jira/browse/DIRMINA-784>]
- Error with MDCInjectionFilter on Windows
Improvement
* [DIRMINA-593 <https://issues.apache.org/jira/browse/DIRMINA-593>]
- Javadoc & documentation for org/apache/mina/filter/reqres
* [DIRMINA-682 <https://issues.apache.org/jira/browse/DIRMINA-682>]
- We need a better documentation for the ExecutorFilter [was
:Writing more than one message will block until the
MessageReceived as been fully proceced]
* [DIRMINA-707 <https://issues.apache.org/jira/browse/DIRMINA-707>]
- Add sendfile support to APR transport
* [DIRMINA-751 <https://issues.apache.org/jira/browse/DIRMINA-751>]
- IoBuffer.normalizeCapacity improvement
* [DIRMINA-754 <https://issues.apache.org/jira/browse/DIRMINA-754>]
- Javadoc omission in IoFilterChain#fireMessageSent()
* [DIRMINA-761 <https://issues.apache.org/jira/browse/DIRMINA-761>]
- how to shutdown a mina application
* [DIRMINA-780 <https://issues.apache.org/jira/browse/DIRMINA-780>]
- Writing null objects to the Session should raise an Exception
Task
* [DIRMINA-477 <https://issues.apache.org/jira/browse/DIRMINA-477>]
- Update page about differences between 1.x and 2.x
* [DIRMINA-575 <https://issues.apache.org/jira/browse/DIRMINA-575>]
- Add the missing Javadoc, add some comments
* [DIRMINA-681 <https://issues.apache.org/jira/browse/DIRMINA-681>]
- Strange CPU peak occuring at fixed interval when several
thousand connections active
* [DIRMINA-708 <https://issues.apache.org/jira/browse/DIRMINA-708>]
- Unbound thread growth on discovery attempts : Improve documentation
* [DIRMINA-756 <https://issues.apache.org/jira/browse/DIRMINA-756>]
- Bump up the used jars
* [DIRMINA-757 <https://issues.apache.org/jira/browse/DIRMINA-757>]
- Add an entry in FAQ explaining how to correctly close a session
and dispose the connector
* [DIRMINA-759 <https://issues.apache.org/jira/browse/DIRMINA-759>]
- Replace JUnit 3.8 constructions with JUnit 4.7 annotations
* [DIRMINA-795 <https://issues.apache.org/jira/browse/DIRMINA-795>]
- Rework the release process
Here's the Jira link for this version if you'd like to review issues in more details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670&styleName=Html&version=12313701
A temporary tag has been created (it can be removed if the vote is not approved):
https://svn.apache.org/repos/asf/mina/tags/2.0.0/
The svn revision is : http://svn.apache.org/viewvc?view=revision&revision=996542
The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository:
https://repository.apache.org/content/repositories/orgapachemina-016/
The distributions are available for download on :
https://repository.apache.org/content/repositories/orgapachemina-016/org/apache/mina/distribution/2.0.0/
The revision number for this release is :
Let's vote now:
[ ] +1 | Release MINA 2.0.0
[ ] ±0 | Abstain
[ ] -1 | Do*NOT* release MINA 2.0.0
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by Alex Karasulu <ak...@apache.org>.
Yeap sorry about that did not know how this happened.
Re: [VOTE] MINA 2.0.0
Posted by Stefan Seelmann <se...@apache.org>.
Wrong mailing list?
On Tue, Sep 14, 2010 at 2:11 PM, Emmanuel Lécharny <el...@apache.org> wrote:
> On 9/14/10 1:49 PM, Niklas Gustavsson wrote:
>>
>> On Tue, Sep 14, 2010 at 1:35 PM, Emmanuel Lécharny<el...@apache.org>
>> wrote:
>>>
>>> Shouldn't we consider the download of the rxtx.jar as an active choice
>>> already ? (just wondering)
>>
>> But, with how I proposed earlier (which I now think is wrong) rxtx.jar
>> would be downloaded by running "mvn -Pdistribute install". Don't think
>> that would be clear to users.
>>
>> So, instead I think it's best not to include the serial stuff among
>> our binaries. Those wanting to use it should instead having to make an
>> informed choice by building it themselves.
>
> So to be clear :
> - the bin won't contain anything related to serial (no rxtx jar, no serial
> code)
> - the src package will contain the code of the serial project
>
> I'm fine with that if nobody object.
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Re: [VOTE] MINA 2.0.0
Posted by Alex Karasulu <ak...@apache.org>.
On Tue, Sep 14, 2010 at 3:11 PM, Emmanuel Lécharny <el...@apache.org>wrote:
> On 9/14/10 1:49 PM, Niklas Gustavsson wrote:
>
>> On Tue, Sep 14, 2010 at 1:35 PM, Emmanuel Lécharny<el...@apache.org>
>> wrote:
>>
>>> Shouldn't we consider the download of the rxtx.jar as an active choice
>>> already ? (just wondering)
>>>
>> But, with how I proposed earlier (which I now think is wrong) rxtx.jar
>> would be downloaded by running "mvn -Pdistribute install". Don't think
>> that would be clear to users.
>>
>> So, instead I think it's best not to include the serial stuff among
>> our binaries. Those wanting to use it should instead having to make an
>> informed choice by building it themselves.
>>
> So to be clear :
> - the bin won't contain anything related to serial (no rxtx jar, no serial
> code)
> - the src package will contain the code of the serial project
>
> I'm fine with that if nobody object.
>
>
FWIW there was some feature in Maven that conditionally downloads an
artifact after having the user approve the license. Perhaps we can take the
same steps for the rxtx.jar artifact?
Regards,
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [VOTE] MINA 2.0.0
Posted by Emmanuel Lécharny <el...@apache.org>.
On 9/14/10 1:49 PM, Niklas Gustavsson wrote:
> On Tue, Sep 14, 2010 at 1:35 PM, Emmanuel Lécharny<el...@apache.org> wrote:
>> Shouldn't we consider the download of the rxtx.jar as an active choice
>> already ? (just wondering)
> But, with how I proposed earlier (which I now think is wrong) rxtx.jar
> would be downloaded by running "mvn -Pdistribute install". Don't think
> that would be clear to users.
>
> So, instead I think it's best not to include the serial stuff among
> our binaries. Those wanting to use it should instead having to make an
> informed choice by building it themselves.
So to be clear :
- the bin won't contain anything related to serial (no rxtx jar, no
serial code)
- the src package will contain the code of the serial project
I'm fine with that if nobody object.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Sep 14, 2010 at 1:35 PM, Emmanuel Lécharny <el...@apache.org> wrote:
> Shouldn't we consider the download of the rxtx.jar as an active choice
> already ? (just wondering)
But, with how I proposed earlier (which I now think is wrong) rxtx.jar
would be downloaded by running "mvn -Pdistribute install". Don't think
that would be clear to users.
So, instead I think it's best not to include the serial stuff among
our binaries. Those wanting to use it should instead having to make an
informed choice by building it themselves.
/niklas
Re: [VOTE] MINA 2.0.0
Posted by Emmanuel Lécharny <el...@apache.org>.
On 9/14/10 1:20 PM, Niklas Gustavsson wrote:
> On Tue, Sep 14, 2010 at 12:18 PM, Emmanuel Lécharny
> <el...@apache.org> wrote:
>> The serial profile has been added as we don't want users to get a bin
>> including the rxtx parts, as it's LGPL. Right now, I'm questionning this
>> choice, at least for the Java part of it, as soon as we don't deliver the
>> rxtx lib with the whole dist.
>>
>> Do you think we should get rid of the serial profile completely, assuming we
>> don't include the rxtx lib?
> As you say, including the serial transport in our dist is probably not
> very useful for our users. How about keeping it as a module (and
> profile) but include it in the dist? Users that want the serial
> support will have to build from source, using the profile, which is
> probably what we want (i.e. the user gets to make an active choice).
>
> /niklas
>
Shouldn't we consider the download of the rxtx.jar as an active choice
already ? (just wondering)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Sep 14, 2010 at 12:18 PM, Emmanuel Lécharny
<el...@apache.org> wrote:
> The serial profile has been added as we don't want users to get a bin
> including the rxtx parts, as it's LGPL. Right now, I'm questionning this
> choice, at least for the Java part of it, as soon as we don't deliver the
> rxtx lib with the whole dist.
>
> Do you think we should get rid of the serial profile completely, assuming we
> don't include the rxtx lib?
As you say, including the serial transport in our dist is probably not
very useful for our users. How about keeping it as a module (and
profile) but include it in the dist? Users that want the serial
support will have to build from source, using the profile, which is
probably what we want (i.e. the user gets to make an active choice).
/niklas
Re: [VOTE] MINA 2.0.0
Posted by Emmanuel Lécharny <el...@apache.org>.
On 9/14/10 11:08 AM, Niklas Gustavsson wrote:
> On Tue, Sep 14, 2010 at 11:00 AM, Emmanuel Lecharny<el...@gmail.com> wrote:
>> I think we just have to remove the<activation> part for this distribution
>> module to get the build working as it was.
> +1, this probably also requires adding the "mina-transport-serial"
> module to the list of modules in the distribution profile.
Let's discuss that a bit.
The serial profile has been added as we don't want users to get a bin
including the rxtx parts, as it's LGPL. Right now, I'm questionning this
choice, at least for the Java part of it, as soon as we don't deliver
the rxtx lib with the whole dist.
Do you think we should get rid of the serial profile completely,
assuming we don't include the rxtx lib?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Sep 14, 2010 at 11:00 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> I think we just have to remove the <activation> part for this distribution
> module to get the build working as it was.
+1, this probably also requires adding the "mina-transport-serial"
module to the list of modules in the distribution profile.
/niklas
Re: [VOTE] MINA 2.0.0
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 9/14/10 9:22 AM, Niklas Gustavsson wrote:
> On Tue, Sep 14, 2010 at 3:54 AM, Alan D. Cabrera<li...@toolazydogs.com> wrote:
>> The default mvn install does not build w/out the artifacts created from the serial profile. Is that by design?
> I had the same problem, but forgot to add a JIRA issue for it. Now fixed:
> https://issues.apache.org/jira/browse/DIRMINA-798
>
> /niklas
>
The problem is that the distribution module is executed no matter what,
and if the -Pserial profile has not be activated, then there will be a
missing part.
Even if the distribution module is removed from the list of modules (in
fact, there is no reason for it to be put at the end of the modules
list, as it must be activated with a -Pdistribution, but as the
condition for this profile to be executed is for the pom.xml file to
exist, it will be executed in any case).
I think we just have to remove the <activation> part for this
distribution module to get the build working as it was.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Sep 14, 2010 at 3:54 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> The default mvn install does not build w/out the artifacts created from the serial profile. Is that by design?
I had the same problem, but forgot to add a JIRA issue for it. Now fixed:
https://issues.apache.org/jira/browse/DIRMINA-798
/niklas
Re: [VOTE] MINA 2.0.0
Posted by Julien Vermillard <jv...@archean.fr>.
I have the same trouble building here.
Julien
Le Tue, 14 Sep 2010 10:29:51 +0200,
Emmanuel Lecharny <el...@gmail.com> a écrit :
> On 9/14/10 3:54 AM, Alan D. Cabrera wrote:
> >> Here's the Jira link for this version if you'd like to review
> >> issues in more details:
> >>
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670&styleName=Html&version=12313701
> >>
> >> A temporary tag has been created (it can be removed if the vote is
> >> not approved): https://svn.apache.org/repos/asf/mina/tags/2.0.0/
> >> The svn revision is :
> >> http://svn.apache.org/viewvc?view=revision&revision=996542
> >>
> >> The newly approved Nexus has been used for the preparation of this
> >> release and all final artifacts are stored in a staging
> >> repository:
> >> https://repository.apache.org/content/repositories/orgapachemina-016/
> >>
> >>
> >> The distributions are available for download on :
> >> https://repository.apache.org/content/repositories/orgapachemina-016/org/apache/mina/distribution/2.0.0/
> >>
> >> The revision number for this release is :
> >>
> >> Let's vote now:
> >> [ ] +1 | Release MINA 2.0.0
> >> [ ] ±0 | Abstain
> >> [ ] -1 | Do*NOT* release MINA 2.0.0
> > The default mvn install does not build w/out the artifacts created
> > from the serial profile. Is that by design?
>
> I guess you get :
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to resolve dependencies for one or more projects in the
> reactor. Reason: Missing:
> ----------
> 1) org.apache.mina:mina-transport-serial:jar:2.0.0
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
> mvn install:install-file -DgroupId=org.apache.mina
> -DartifactId=mina-transport-serial -Dversion=2.0.0 -Dpackaging=jar
> -Dfile=/path/to/file
>
> Alternatively, if you host your own repository you can deploy the
> file there:
> mvn deploy:deploy-file -DgroupId=org.apache.mina
> -DartifactId=mina-transport-serial -Dversion=2.0.0 -Dpackaging=jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>
> Path to dependency:
> 1) org.apache.mina:distribution:pom:2.0.0
> 2) org.apache.mina:mina-transport-serial:jar:2.0.0
>
> ----------
> 1 required artifact is missing.
>
> for artifact:
> org.apache.mina:distribution:pom:2.0.0
>
> from the specified remote repositories:
> apache.snapshots (http://repository.apache.org/snapshots),
> central (http://repo1.maven.org/maven2)
>
>
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 9 minutes 2 seconds
> [INFO] Finished at: Tue Sep 14 10:28:15 CEST 2010
> [INFO] Final Memory: 66M/129M
> [INFO]
> ------------------------------------------------------------------------
>
>
> No, it's not by design. Let me check what is the problem.
>
--
Julien Vermillard
Archean Technologies
http://www.archean.fr
Re: [VOTE] MINA 2.0.0
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 9/14/10 3:54 AM, Alan D. Cabrera wrote:
>> Here's the Jira link for this version if you'd like to review issues in more details:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670&styleName=Html&version=12313701
>>
>> A temporary tag has been created (it can be removed if the vote is not approved):
>> https://svn.apache.org/repos/asf/mina/tags/2.0.0/
>> The svn revision is : http://svn.apache.org/viewvc?view=revision&revision=996542
>>
>> The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository:
>> https://repository.apache.org/content/repositories/orgapachemina-016/
>>
>>
>> The distributions are available for download on :
>> https://repository.apache.org/content/repositories/orgapachemina-016/org/apache/mina/distribution/2.0.0/
>>
>> The revision number for this release is :
>>
>> Let's vote now:
>> [ ] +1 | Release MINA 2.0.0
>> [ ] ±0 | Abstain
>> [ ] -1 | Do*NOT* release MINA 2.0.0
> The default mvn install does not build w/out the artifacts created from the serial profile. Is that by design?
I guess you get :
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve dependencies for one or more projects in the
reactor. Reason: Missing:
----------
1) org.apache.mina:mina-transport-serial:jar:2.0.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.mina
-DartifactId=mina-transport-serial -Dversion=2.0.0 -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the
file there:
mvn deploy:deploy-file -DgroupId=org.apache.mina
-DartifactId=mina-transport-serial -Dversion=2.0.0 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.mina:distribution:pom:2.0.0
2) org.apache.mina:mina-transport-serial:jar:2.0.0
----------
1 required artifact is missing.
for artifact:
org.apache.mina:distribution:pom:2.0.0
from the specified remote repositories:
apache.snapshots (http://repository.apache.org/snapshots),
central (http://repo1.maven.org/maven2)
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 9 minutes 2 seconds
[INFO] Finished at: Tue Sep 14 10:28:15 CEST 2010
[INFO] Final Memory: 66M/129M
[INFO]
------------------------------------------------------------------------
No, it's not by design. Let me check what is the problem.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
>
> Here's the Jira link for this version if you'd like to review issues in more details:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670&styleName=Html&version=12313701
>
> A temporary tag has been created (it can be removed if the vote is not approved):
> https://svn.apache.org/repos/asf/mina/tags/2.0.0/
> The svn revision is : http://svn.apache.org/viewvc?view=revision&revision=996542
>
> The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-016/
>
>
> The distributions are available for download on :
> https://repository.apache.org/content/repositories/orgapachemina-016/org/apache/mina/distribution/2.0.0/
>
> The revision number for this release is :
>
> Let's vote now:
> [ ] +1 | Release MINA 2.0.0
> [ ] ±0 | Abstain
> [ ] -1 | Do*NOT* release MINA 2.0.0
The default mvn install does not build w/out the artifacts created from the serial profile. Is that by design?
Regards,
Alan
[VOTE] MINA 2.0.0 : Cancelled until we fix the few issues in the
distribution
Posted by Emmanuel Lécharny <el...@apache.org>.
Hi guys,
I think it's better to cancel this vote and fix the issues we have in
the distribution. It's not the first time we cancelled the vote anyway,
so we don't have any pride anymore anyway ;)
Here is what is going to be fixed this afternoon, before I reinitiate a
vote :
- we will create two distribution packages : one for binaries, one for
sources (already working on my laptop)
- we will make the build work even if -Pserial is not added in the
command line (already fixed locally)
But, first, lunch !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by Emmanuel Lécharny <el...@apache.org>.
On 9/14/10 9:16 AM, Niklas Gustavsson wrote:
> On Tue, Sep 14, 2010 at 1:23 AM, Emmanuel Lécharny<el...@apache.org> wrote:
>> On 9/13/10 11:43 PM, Maarten Bosteels wrote:
>> Then 30 minutes later, it passes. I have no idea why it behaves this
>> way, but this is systematic, and not only for MINA, but also for Vysper,
>> FtpServer and so on.
> This is not true, at least not for Vysper and FtpServer. There are two
> types of issues we've seen in Hudson in these two projects:
> * Failed builds due to Hudson stability problems. These are easily
> recognized since the build will fail with a Hudson error rather then a
> build error. Typical example is a borked connection to a Hudson slave.
> For Vysper and FtpServer I try to clean these from Hudson history when
> they happen.
> * Failed builds due to build problems, recognized problems coming from
> the build, typically test failures. This seems to be the case with
> MINA on Windows at the moment.
My bad. I wasn't able to characterize the problem last night, Hudson was
down.
I was confused by the message Hudson send us when you commit some
change, as we get a mail saying that "Hudson became unstable". (IMO? a
*very* bad message...).
We have some random failure on Windows, it seems, like for build #39 :
java.lang.AssertionError: expected:<4194304> but was:<0>
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:126)
at org.junit.Assert.assertEquals(Assert.java:470)
at org.junit.Assert.assertEquals(Assert.java:454)
at org.apache.mina.filter.stream.AbstractStreamWriteFilterTest.testWriteUsingSocketTransport(AbstractStreamWriteFilterTest.java:364)
or for build 37 :
java.lang.AssertionError:
Unexpected method call messageReceived((0x00000028: mina dummy, server, ? => ?), response: { requestId=1, type=WHOLE, message=org.apache.mina.filter.reqres.RequestResponseFilterTest$Message@33238785 }):
exceptionCaught((0x00000028: mina dummy, server, ? => ?), org.apache.mina.filter.reqres.RequestTimeoutException): expected: 1, actual: 0
and
java.lang.AssertionError:
Unexpected method call messageReceived((0x00000029: mina dummy, server, ? => ?), response: { requestId=1, type=PARTIAL_LAST, message=org.apache.mina.filter.reqres.RequestResponseFilterTest$Message@43ce663c }):
exceptionCaught((0x00000029: mina dummy, server, ? => ?), org.apache.mina.filter.reqres.RequestTimeoutException): expected: 1, actual: 0
Has someone got those kind of errors on Windows ?
>> Well, I think we should release a 2.0.0, and then fix issues as fast as we
>> can, releasing a 2.0.1 if needed. IMO, we have waited way too much for this
>> 2.0.0
> Agreed. I think we could aim for a 2.0.1 within a month. But, of
> course I don't do much work on MINA itself so view this as some random
> user's opinion :-)
>
> /niklas
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Sep 14, 2010 at 1:23 AM, Emmanuel Lécharny <el...@apache.org> wrote:
> On 9/13/10 11:43 PM, Maarten Bosteels wrote:
> Then 30 minutes later, it passes. I have no idea why it behaves this
> way, but this is systematic, and not only for MINA, but also for Vysper,
> FtpServer and so on.
This is not true, at least not for Vysper and FtpServer. There are two
types of issues we've seen in Hudson in these two projects:
* Failed builds due to Hudson stability problems. These are easily
recognized since the build will fail with a Hudson error rather then a
build error. Typical example is a borked connection to a Hudson slave.
For Vysper and FtpServer I try to clean these from Hudson history when
they happen.
* Failed builds due to build problems, recognized problems coming from
the build, typically test failures. This seems to be the case with
MINA on Windows at the moment.
> Well, I think we should release a 2.0.0, and then fix issues as fast as we
> can, releasing a 2.0.1 if needed. IMO, we have waited way too much for this
> 2.0.0
Agreed. I think we could aim for a 2.0.1 within a month. But, of
course I don't do much work on MINA itself so view this as some random
user's opinion :-)
/niklas
Re: [VOTE] MINA 2.0.0
Posted by Emmanuel Lécharny <el...@apache.org>.
On 9/13/10 11:43 PM, Maarten Bosteels wrote:
> I think we should also try to make the tests stable. Hudson builds on
> windows seem to be failing more than they pass.
> It took us a very long time to reach 2.0.0. That's why I wonder if we
> shouldn't spend just a little more time to get these things right ?
I don't think that we have an issue on Hudson build on Windows. When we
modify the code, the build always breaks the first time, as far as I can
see. Then 30 minutes later, it passes. I have no idea why it behaves
this way, but this is systematic, and not only for MINA, but also for
Vysper, FtpServer and so on.
I'd like to understand why this is the case, but Hudson is barely
available those days (it's currently down :/ )
> Hmm, on the other hand, we could start applying the "release early, release
> often" philosophy from now on ;-)
Well, I think we should release a 2.0.0, and then fix issues as fast as
we can, releasing a 2.0.1 if needed. IMO, we have waited way too much
for this 2.0.0
> I am well aware of the fact that I have contributed near to nothing for far
> too long, and I hope my comments are not offending anyone.
Don't worry, your concern is very valid. The question is how do we
address it...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by Maarten Bosteels <mb...@gmail.com>.
I think we should also try to make the tests stable. Hudson builds on
windows seem to be failing more than they pass.
It took us a very long time to reach 2.0.0. That's why I wonder if we
shouldn't spend just a little more time to get these things right ?
Hmm, on the other hand, we could start applying the "release early, release
often" philosophy from now on ;-)
I am well aware of the fact that I have contributed near to nothing for far
too long, and I hope my comments are not offending anyone.
regards,
Maarten
On Mon, Sep 13, 2010 at 11:08 PM, Emmanuel Lécharny <el...@apache.org>wrote:
> On 9/13/10 10:54 PM, Niklas Gustavsson wrote:
>
>> On Mon, Sep 13, 2010 at 5:13 PM, Emmanuel Lecharny<el...@gmail.com>
>> wrote:
>>
>>> [X] +1 | Release MINA 2.0.0
>>>
>> I got some minor issues with the distribution packages, but nothing
>> stopping this release. Otherwise, I think it's looking good.
>>
> yes, we could do better. Like Niklas suggested, releasing a source packaged
> separated from the bin package would be way better.
>
> I think we can go on with the current release, and fix things in a 2.0.1
> asap.
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
Re: [VOTE] MINA 2.0.0
Posted by Alex Karasulu <ak...@apache.org>.
On Tue, Sep 14, 2010 at 12:08 AM, Emmanuel Lécharny <el...@apache.org>wrote:
> On 9/13/10 10:54 PM, Niklas Gustavsson wrote:
>
>> On Mon, Sep 13, 2010 at 5:13 PM, Emmanuel Lecharny<el...@gmail.com>
>> wrote:
>>
>>> [X] +1 | Release MINA 2.0.0
>>>
>> I got some minor issues with the distribution packages, but nothing
>> stopping this release. Otherwise, I think it's looking good.
>>
> yes, we could do better. Like Niklas suggested, releasing a source packaged
> separated from the bin package would be way better.
>
> I think we can go on with the current release, and fix things in a 2.0.1
> asap.
>
>
+1 I'm in agreement we can fine tune things as long as we're not violating
any ASF release criteria.
Great job guys,
Alex
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [VOTE] MINA 2.0.0
Posted by Emmanuel Lécharny <el...@apache.org>.
On 9/13/10 10:54 PM, Niklas Gustavsson wrote:
> On Mon, Sep 13, 2010 at 5:13 PM, Emmanuel Lecharny<el...@gmail.com> wrote:
>> [X] +1 | Release MINA 2.0.0
> I got some minor issues with the distribution packages, but nothing
> stopping this release. Otherwise, I think it's looking good.
yes, we could do better. Like Niklas suggested, releasing a source
packaged separated from the bin package would be way better.
I think we can go on with the current release, and fix things in a 2.0.1
asap.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] MINA 2.0.0
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Sep 13, 2010 at 5:13 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> [X] +1 | Release MINA 2.0.0
I got some minor issues with the distribution packages, but nothing
stopping this release. Otherwise, I think it's looking good.
/niklas