You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Edouard De Oliveira <do...@yahoo.fr> on 2010/03/02 12:27:32 UTC
Re : ConnectFuture confusion
There are months i'm thinking the same without daring to say so ...
The problem is that 1.x branches have been abandonned long time ago and much people are indeed waiting for the release of this 2.0
how bad would it be to release it for the early adopters with a 'use it at your own risk' warning and invite new comers to wait for a 3.0 preview ?
would it be acceptable for the community to say that we won't support it extensively as our efforts will be concentrated on 3.0 ?
Maybe it's the right time to shake the anthill or maybe not ...
my 2 cents
Cordialement, Regards,
-Edouard De Oliveira-
----- Message d'origine ----
De : Emmanuel Lecharny <el...@gmail.com>
À : dev@mina.apache.org
Envoyé le : Lun 1 Mars 2010, 18 h 45 min 02 s
Objet : Re: ConnectFuture confusion
On 3/1/10 6:30 PM, Alan D. Cabrera wrote:
>
> On Mar 1, 2010, at 9:20 AM, Emmanuel Lecharny wrote:
>
>> On 3/1/10 6:10 PM, Alan D. Cabrera wrote:
>>>
>>> On Mar 1, 2010, at 8:04 AM, Emmanuel Lecharny wrote:
>>>
>>>> On 3/1/10 4:38 PM, Alan D. Cabrera wrote:
>>>>>
>>>>> On Feb 26, 2010, at 9:03 AM, Ashish wrote:
>>>>>
>>>>>>
>>>>>>> Thoughts ?
>>>>>>
>>>>>> Unless it breaks the system, i would say lets not loose our sleep over this.
>>>>>
>>>>> While I share the same opinion about the IoFuture hierarchy as you I have the same sentiments as Ashish.
>>>> I'm afraid that we might have to fix the issue in 2.0.... Trust me, i'm not pleased with this !
>>>
>>> Fixing a bug is one thing. Reorganizing a code base a few days after an attempted vote on its initial release is another.
>>
>> I know :/ This is why I created a branch, in a desesperate attempt to get rid of all those futures, instead of doing that in trunk. Now, it was the end of a long and painful week, chasing many bugs in many places, and I was turning in circle.
>>
>> I *wish* we can fix the bug, without having to rewrite this part.
>
> Another alternative is to totally abandon 2.x. It was never officially released. Just leave it as it is and work on the new 2.x
I'm also considering this option...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
AW: Calling NioSocketSession.toString() causes java.lang.Error
Posted by "Michelberger, Joerg" <JO...@NDSatcom.com>.
Hi Emmanuel,
created https://issues.apache.org/jira/browse/DIRMINA-771 what happens next?
Regards Jörg
-----Ursprüngliche Nachricht-----
Von: Emmanuel Lecharny [mailto:elecharny@gmail.com]
Gesendet: Mittwoch, 3. März 2010 12:22
An: dev@mina.apache.org
Betreff: Re: Calling NioSocketSession.toString() causes java.lang.Error
On 3/3/10 11:28 AM, Michelberger, Joerg wrote:
> Hi there,
>
> using MINA 2.0.0 RC1 and have a log statement in my IOHandler.exceptionCaught() method plugged on top of a NioSocketSession.
> The log statement calls toString() on the IoSession passed in. In some cases I get the appended Exception.
> Thats not good.
>
Yeah, sure. Can you create a JIRA for this bug ?
Should be easy to fix, as it's probably trying to print a closed socket.
> Regards Jörg
>
> 2010-03-03 09:51:46,818 WARN [NioProcessor-2] filterchain.DefaultIoFilterChain::callNextExceptionCaught() (DefaultIoFilterChain.java:483) - Unexpected exception from exceptionCaught handler. java.lang.Error: java.net.SocketException: Socket operation on nonsocket: getsockname
> at sun.nio.ch.Net.localAddress(Net.java:125)
> at sun.nio.ch.SocketChannelImpl.localAddress(SocketChannelImpl.java:430)
> at sun.nio.ch.SocketAdaptor.getLocalAddress(SocketAdaptor.java:147)
> at java.net.Socket.getLocalSocketAddress(Socket.java:703)
> at org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:158)
> at org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:47)
> at org.apache.mina.core.session.AbstractIoSession.toString(AbstractIoSession.java:1139)
> at com.ndsatcom.cecsdatamodel.cecsclient.newmulti.mina.MinaCecsIoHandler.exceptionCaught(MinaCecsIoHandler.java:33)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.exceptionCaught(DefaultIoFilterChain.java:694)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:788)
> at org.apache.mina.core.filterchain.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:111)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireExceptionCaught(DefaultIoFilterChain.java:468)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:397)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778)
> at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778)
> at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed(ProtocolCodecFilter.java:345)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778)
> at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireSessionClosed(DefaultIoFilterChain.java:388)
> at org.apache.mina.core.service.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:210)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:535)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeSessions(AbstractPollingIoProcessor.java:497)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:61)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:974)
> at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.net.SocketException: Socket operation on nonsocket: getsockname
> at sun.nio.ch.Net.localInetAddress(Native Method)
> at sun.nio.ch.Net.localAddress(Net.java:122) ... 37 more
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: Calling NioSocketSession.toString() causes java.lang.Error
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 3/3/10 11:28 AM, Michelberger, Joerg wrote:
> Hi there,
>
> using MINA 2.0.0 RC1 and have a log statement in my IOHandler.exceptionCaught() method plugged on top of a NioSocketSession.
> The log statement calls toString() on the IoSession passed in. In some cases I get the appended Exception.
> Thats not good.
>
Yeah, sure. Can you create a JIRA for this bug ?
Should be easy to fix, as it's probably trying to print a closed socket.
> Regards Jörg
>
> 2010-03-03 09:51:46,818 WARN [NioProcessor-2] filterchain.DefaultIoFilterChain::callNextExceptionCaught() (DefaultIoFilterChain.java:483) - Unexpected exception from exceptionCaught handler. java.lang.Error: java.net.SocketException: Socket operation on nonsocket: getsockname
> at sun.nio.ch.Net.localAddress(Net.java:125)
> at sun.nio.ch.SocketChannelImpl.localAddress(SocketChannelImpl.java:430)
> at sun.nio.ch.SocketAdaptor.getLocalAddress(SocketAdaptor.java:147)
> at java.net.Socket.getLocalSocketAddress(Socket.java:703)
> at org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:158)
> at org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:47)
> at org.apache.mina.core.session.AbstractIoSession.toString(AbstractIoSession.java:1139)
> at com.ndsatcom.cecsdatamodel.cecsclient.newmulti.mina.MinaCecsIoHandler.exceptionCaught(MinaCecsIoHandler.java:33)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.exceptionCaught(DefaultIoFilterChain.java:694)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:788)
> at org.apache.mina.core.filterchain.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:111)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireExceptionCaught(DefaultIoFilterChain.java:468)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:397)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778)
> at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778)
> at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed(ProtocolCodecFilter.java:345)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778)
> at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395)
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireSessionClosed(DefaultIoFilterChain.java:388)
> at org.apache.mina.core.service.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:210)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:535)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeSessions(AbstractPollingIoProcessor.java:497)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:61)
> at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:974)
> at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.net.SocketException: Socket operation on nonsocket: getsockname
> at sun.nio.ch.Net.localInetAddress(Native Method)
> at sun.nio.ch.Net.localAddress(Net.java:122) ... 37 more
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Calling NioSocketSession.toString() causes java.lang.Error
Posted by "Michelberger, Joerg" <JO...@NDSatcom.com>.
Hi there,
using MINA 2.0.0 RC1 and have a log statement in my IOHandler.exceptionCaught() method plugged on top of a NioSocketSession.
The log statement calls toString() on the IoSession passed in. In some cases I get the appended Exception.
Thats not good.
Regards Jörg
2010-03-03 09:51:46,818 WARN [NioProcessor-2] filterchain.DefaultIoFilterChain::callNextExceptionCaught() (DefaultIoFilterChain.java:483) - Unexpected exception from exceptionCaught handler. java.lang.Error: java.net.SocketException: Socket operation on nonsocket: getsockname
at sun.nio.ch.Net.localAddress(Net.java:125)
at sun.nio.ch.SocketChannelImpl.localAddress(SocketChannelImpl.java:430)
at sun.nio.ch.SocketAdaptor.getLocalAddress(SocketAdaptor.java:147)
at java.net.Socket.getLocalSocketAddress(Socket.java:703)
at org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:158)
at org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:47)
at org.apache.mina.core.session.AbstractIoSession.toString(AbstractIoSession.java:1139)
at com.ndsatcom.cecsdatamodel.cecsclient.newmulti.mina.MinaCecsIoHandler.exceptionCaught(MinaCecsIoHandler.java:33)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.exceptionCaught(DefaultIoFilterChain.java:694)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:46)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:788)
at org.apache.mina.core.filterchain.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:111)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireExceptionCaught(DefaultIoFilterChain.java:468)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:397)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778)
at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778)
at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed(ProtocolCodecFilter.java:345)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778)
at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireSessionClosed(DefaultIoFilterChain.java:388)
at org.apache.mina.core.service.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:210)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:535)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeSessions(AbstractPollingIoProcessor.java:497)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:61)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:974)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.SocketException: Socket operation on nonsocket: getsockname
at sun.nio.ch.Net.localInetAddress(Native Method)
at sun.nio.ch.Net.localAddress(Net.java:122) ... 37 more
Re: Re : ConnectFuture confusion
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, Mar 2, 2010 at 14:00, Maarten Bosteels <mb...@gmail.com> wrote:
> I totally agree with Niklas.
+1 from the downstream gallery.
Bernd
> Maarten
>
> On Tue, Mar 2, 2010 at 1:50 PM, Niklas Gustavsson <ni...@protocol7.com>wrote:
>
>> On Tue, Mar 2, 2010 at 1:30 PM, Emmanuel Lecharny <el...@gmail.com>
>> wrote:
>> > Ok, MINA 2.0 is far from being perfect, there are some issues, but so
>> far,
>> > it's usable.
>>
>> Agreed. I think not getting 2.0 out would be bikeshedding. I think we
>> should release and support a 2.0 release, then put our main focus on
>> 3.0 (rather than a 2.1) were we can break stuff. Not releasing 2.0
>> would be a disservice to our users who's been waiting for a final
>> release. I think most users rather take a good-but-not-perfect 2.0
>> over waiting for 3.0 even further.
>>
>> My 2 öre as a developer mostly working on the subprojects :-)
>>
>> /niklas
>>
>
Re: Re : ConnectFuture confusion
Posted by Maarten Bosteels <mb...@gmail.com>.
I totally agree with Niklas.
Maarten
On Tue, Mar 2, 2010 at 1:50 PM, Niklas Gustavsson <ni...@protocol7.com>wrote:
> On Tue, Mar 2, 2010 at 1:30 PM, Emmanuel Lecharny <el...@gmail.com>
> wrote:
> > Ok, MINA 2.0 is far from being perfect, there are some issues, but so
> far,
> > it's usable.
>
> Agreed. I think not getting 2.0 out would be bikeshedding. I think we
> should release and support a 2.0 release, then put our main focus on
> 3.0 (rather than a 2.1) were we can break stuff. Not releasing 2.0
> would be a disservice to our users who's been waiting for a final
> release. I think most users rather take a good-but-not-perfect 2.0
> over waiting for 3.0 even further.
>
> My 2 öre as a developer mostly working on the subprojects :-)
>
> /niklas
>
Re: Re : ConnectFuture confusion
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, Mar 2, 2010 at 1:30 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Ok, MINA 2.0 is far from being perfect, there are some issues, but so far,
> it's usable.
Agreed. I think not getting 2.0 out would be bikeshedding. I think we
should release and support a 2.0 release, then put our main focus on
3.0 (rather than a 2.1) were we can break stuff. Not releasing 2.0
would be a disservice to our users who's been waiting for a final
release. I think most users rather take a good-but-not-perfect 2.0
over waiting for 3.0 even further.
My 2 öre as a developer mostly working on the subprojects :-)
/niklas
Re: Re : ConnectFuture confusion
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 3/2/10 1:13 PM, Victor wrote:
> I agree with Edouard, much people not even waited but used (!) mina
> 2.0 in production. Our servers are working on mina 2.0 during ~1.5
> years - we use both connectors and acceptors.
> In fact, 2.0 is not so bad as it seems to be ;) We just have some bugs
> which should be fixed in 2.0. Otherwise people may think that mina
> will never be released ;-(
I'm using MINA 2.0 since 2.0-M1, I think. I have had hard time getting
it working, but at the end of the day, 2.0.0-RC1 is pretty useable, if
you don't dare using it in fancy ways. Most of the fixed bugs since then
are for obscure features, but the most important fix is dealing with the
selector freeze (a workaround for a JVM bug).
We still have a couple of annoying issues with some tests on some OS,
the problem is to undrstand if the tests are fragile or if MINA is the
cause.
Last friday, I was able to workaround a blockage I have with trunk
simply by not waiting on a WriteFuture. You would say, "wait, but this
is a MAJOR issue, a future.wait() should never block forever !", but in
fact, I get this problem _only_ because I call the write operation and
the server will immediately close the connection before the writeFuture
can be informed of this fact, so the client is waiting forever for an
answer that never comes.
I just let it be, assuming that the write will be sucessful, and moved on.
Ok, MINA 2.0 is far from being perfect, there are some issues, but so
far, it's usable.
As soon as you know the limits, you can play within those limits with no
fears...
But as one of the developer, it's embarrassing ...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: Re : ConnectFuture confusion
Posted by Victor <dr...@mail333.com>.
I agree with Edouard, much people not even waited but used (!) mina 2.0
in production. Our servers are working on mina 2.0 during ~1.5 years -
we use both connectors and acceptors.
In fact, 2.0 is not so bad as it seems to be ;) We just have some bugs
which should be fixed in 2.0. Otherwise people may think that mina will
never be released ;-(
Victor N
Edouard De Oliveira wrote:
> There are months i'm thinking the same without daring to say so ...
> The problem is that 1.x branches have been abandonned long time ago and much people are indeed waiting for the release of this 2.0
> how bad would it be to release it for the early adopters with a 'use it at your own risk' warning and invite new comers to wait for a 3.0 preview ?
> would it be acceptable for the community to say that we won't support it extensively as our efforts will be concentrated on 3.0 ?
>
> Maybe it's the right time to shake the anthill or maybe not ...
> my 2 cents
>
> Cordialement, Regards,
> -Edouard De Oliveira-
>
>
>
>
> ----- Message d'origine ----
> De : Emmanuel Lecharny <el...@gmail.com>
> À : dev@mina.apache.org
> Envoyé le : Lun 1 Mars 2010, 18 h 45 min 02 s
> Objet : Re: ConnectFuture confusion
>
> On 3/1/10 6:30 PM, Alan D. Cabrera wrote:
>> On Mar 1, 2010, at 9:20 AM, Emmanuel Lecharny wrote:
>>
>>> On 3/1/10 6:10 PM, Alan D. Cabrera wrote:
>>>> On Mar 1, 2010, at 8:04 AM, Emmanuel Lecharny wrote:
>>>>
>>>>> On 3/1/10 4:38 PM, Alan D. Cabrera wrote:
>>>>>> On Feb 26, 2010, at 9:03 AM, Ashish wrote:
>>>>>>
>>>>>>>> Thoughts ?
>>>>>>> Unless it breaks the system, i would say lets not loose our sleep over this.
>>>>>> While I share the same opinion about the IoFuture hierarchy as you I have the same sentiments as Ashish.
>>>>> I'm afraid that we might have to fix the issue in 2.0.... Trust me, i'm not pleased with this !
>>>> Fixing a bug is one thing. Reorganizing a code base a few days after an attempted vote on its initial release is another.
>>> I know :/ This is why I created a branch, in a desesperate attempt to get rid of all those futures, instead of doing that in trunk. Now, it was the end of a long and painful week, chasing many bugs in many places, and I was turning in circle.
>>>
>>> I *wish* we can fix the bug, without having to rewrite this part.
>> Another alternative is to totally abandon 2.x. It was never officially released. Just leave it as it is and work on the new 2.x
> I'm also considering this option...
>