[jira] Issue Comment Edited: (DIRMINA-555) FastCGI and SCGI handler.
[ https://issues.apache.org/jira/browse/DIRMINA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591162#action_12591162 ] vcdaniel edited comment on DIRMINA-555 at 11/18/08 10:48 PM: - A first preview of AsyncFCGI is available at http://blog.code-emitter.com/?page_id=8 Feel free to take a look. was (Author: vcdaniel): A first preview of AsyncFCGI is available at http://daniel.users.hostunity.net/asyncfcgi/. Feel free to take a look. > FastCGI and SCGI handler. > - > > Key: DIRMINA-555 > URL: https://issues.apache.org/jira/browse/DIRMINA-555 > Project: MINA > Issue Type: New Feature > Components: Handler >Reporter: Mathieu Lecarme > > fastcgi and scgi are simple inteface between application server and > webserver. It's like a neutral AJP13 protocol. > http://www.fastcgi.com/ > http://www.mems-exchange.org/software/scgi/ > With that handler, mina applications can be put behind web server, like > Nginx, lighttpd or even Apache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-623) Failure of test org.apache.mina.proxy.NTLMTest.testType1Message on windows Vista
[ https://issues.apache.org/jira/browse/DIRMINA-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edouard De Oliveira resolved DIRMINA-623. - Resolution: Fixed Fix Version/s: 2.0.0-M4 Assignee: Edouard De Oliveira Trivial fix : the test supposed that the class was run on XP This is an OS dependant test so i added conditions to only do the test under winXP > Failure of test org.apache.mina.proxy.NTLMTest.testType1Message on windows > Vista > > > Key: DIRMINA-623 > URL: https://issues.apache.org/jira/browse/DIRMINA-623 > Project: MINA > Issue Type: Test > Components: Core >Affects Versions: 2.0.0-M4 > Environment: Test are ran under windows vista business edition using > Hudson and the "mvn clean install" maven command. JDK is 1.6.0.7 >Reporter: simon trudeau >Assignee: Edouard De Oliveira > Fix For: 2.0.0-M4 > > > Failed > org.apache.mina.proxy.NTLMTest.testType1Message > null expected:<0[501280a]000f> but was:<0[600]000f> > Stacktrace > junit.framework.ComparisonFailure: null expected:<0[501280a]000f> but > was:<0[600]000f> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at org.apache.mina.proxy.NTLMTest.testType1Message(NTLMTest.java:114) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at junit.framework.TestSuite.runTest(TestSuite.java:232) > at junit.framework.TestSuite.run(TestSuite.java:227) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) > at org.apache.maven.surefire.Surefire.run(Surefire.java:177) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-23) New transport type: non-NIO sockets
[ https://issues.apache.org/jira/browse/DIRMINA-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648848#action_12648848 ] Edouard De Oliveira commented on DIRMINA-23: very old issue is there any sense on supporting blocking IO ? i basically think this is non sense Should we close this one ? > New transport type: non-NIO sockets > --- > > Key: DIRMINA-23 > URL: https://issues.apache.org/jira/browse/DIRMINA-23 > Project: MINA > Issue Type: New Feature > Components: Core >Affects Versions: 0.7.0, 0.8.0 >Reporter: Trustin Lee > > Current NIO implementation doesn't outperform non-NIO sockets, and doesn't > support multicasting. We could complement this gap by adding transport type > support for non-NIO sockets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-555) FastCGI and SCGI handler.
[ https://issues.apache.org/jira/browse/DIRMINA-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edouard De Oliveira closed DIRMINA-555. --- Resolution: Invalid this sqhould be an asyncweb feature request link does not work closing the issue as invalid > FastCGI and SCGI handler. > - > > Key: DIRMINA-555 > URL: https://issues.apache.org/jira/browse/DIRMINA-555 > Project: MINA > Issue Type: New Feature > Components: Handler >Reporter: Mathieu Lecarme > > fastcgi and scgi are simple inteface between application server and > webserver. It's like a neutral AJP13 protocol. > http://www.fastcgi.com/ > http://www.mems-exchange.org/software/scgi/ > With that handler, mina applications can be put behind web server, like > Nginx, lighttpd or even Apache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-234) Simple HTTP server based on Jakarta HttpComponents Core and MINA
[ https://issues.apache.org/jira/browse/DIRMINA-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edouard De Oliveira closed DIRMINA-234. --- Resolution: Won't Fix No recent work on this one and we now have asyncweb project so lets close this one to continue on cleaning > Simple HTTP server based on Jakarta HttpComponents Core and MINA > > > Key: DIRMINA-234 > URL: https://issues.apache.org/jira/browse/DIRMINA-234 > Project: MINA > Issue Type: New Feature >Affects Versions: 0.9.5 >Reporter: Oleg Kalnichevski > Attachments: mina-httpcore-httpserver.tar.gz, > mina-httpcore-httpserver.tar.gz > > > I am submitting my first cut at a HTTP server based on Jakarta HttpComponents > Core and MINA for your review and feedback. This is a very simple but > nonetheless a full-featured and HTTP/1.1 compliant HTTP file server that > supports connection persistence, chunk coding, correctly handles older > (HTTP/1.0) clients among many things. I believe this sample code makes > evident that it takes fairly little code and effort to put the HttpCore > protocol stack on top of MINA I/O model. > This version is still far from being perfect and am working on a more > advanced version that integrates better with MINA's asynchronous I/O layer. > Feedback, suggestions, critique will be hugely appreciated > Oleg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648825#action_12648825 ] Edouard De Oliveira commented on DIRMINA-539: - indeed, the example was just intended to highlight the unnecesseray redundant tests happening with the use of a isSetTrafficClassAvailable(...) method. http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#getTrafficClass() also states that "the underlying network implementation may ignore the traffic class or type-of-service set using #setTrafficClass()" If any error throws an exception i just wonder why the hell this code got so complicated ? ps : tried to search through mina jira db but found nothing proving that it could fail silently > NioDatagramConnector doesn't takes the TrafficClass value set to his > DatagramSessionConfig > --- > > Key: DIRMINA-539 > URL: https://issues.apache.org/jira/browse/DIRMINA-539 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M1 > Environment: WinXP, RHEL5 (probably not important) >Reporter: martin krivosik >Assignee: Emmanuel Lecharny > Fix For: 2.0.0-M4 > > Original Estimate: 0.33h > Remaining Estimate: 0.33h > > client sending datagrams without taking care to the trafficClas set in the > config, so the ToS byte is not set in the packet sent from client. > client code: > NioDatagramAcceptor acceptor = new NioDatagramAcceptor(); > DatagramSessionConfig dcfg = > ((NioDatagramAcceptor)acceptor).getSessionConfig(); > dcfg.setTrafficClass(tosByte); > InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP, > port); > acceptor.bind(bindAddrPort); > -> connecting to another computer with NioDatagramConnector. > for me it looks like in the newHandle method of NioDatagramConnector is not > cared about TrafficClass (like it is done in NioDatagramAcceptor.open()) > The server part with the accceptor is OK and the correct ToS byte is set in > the packet. > (the same problem may be in the socket, i have to check it) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-388) I try mina with a ftp client, it's sampe codes.
[ https://issues.apache.org/jira/browse/DIRMINA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edouard De Oliveira closed DIRMINA-388. --- Resolution: Incomplete It is lacking javadoc and as there is pretty enough examples and much simpler already included , we won't include it in the code for the moment. Moreover FtpServer subproject already provides a full ftp enabled server Thank you for sharing your code with the community. Keep hanging around here. > I try mina with a ftp client, it's sampe codes. > --- > > Key: DIRMINA-388 > URL: https://issues.apache.org/jira/browse/DIRMINA-388 > Project: MINA > Issue Type: Test > Components: Example >Affects Versions: 1.1.0 >Reporter: xiangqinxian >Priority: Trivial > Attachments: minftpclient.jar > > > Hi, > I try mina with ftp client. > maybe its a simple example for mina using. > noted apache ftpserver project use block socket connection as ftp data > channel. > but I dont think its a good idea. > sorry no comments, If need, please notify me, I would do adding. > just do run: > $ ant run > it will download welcome.msg to current directory. > Test code just reside in Controller.java main. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-576) java.lang.OutOfMemoryError in Direct buffers
[ https://issues.apache.org/jira/browse/DIRMINA-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edouard De Oliveira closed DIRMINA-576. --- Resolution: Invalid As you state, this is a jdk bug we cannot circumvent as long as we know. Maybe NIO2 will fix it. > java.lang.OutOfMemoryError in Direct buffers > - > > Key: DIRMINA-576 > URL: https://issues.apache.org/jira/browse/DIRMINA-576 > Project: MINA > Issue Type: Bug > Components: Core > Environment: SunOS [box] 5.10 Generic_120011-14 sun4v sparc > SUNW,Sun-Fire-T200 > java version "1.5.0_12" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) > Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode) > Discovered using MINA 1.1.2 >Reporter: Jane Prusakova > > The problem showed up after MINA-based server has been running for ~100hours, > including a few hours at the peak load. > OutOfMemoryError has been logged 30 times in a span of few minutes, then > servers crashed.This scenario happened on several dozen boxes at the same > time, with the same load. > java.lang.OutOfMemoryError > at sun.misc.Unsafe.allocateMemory(Native Method) > at java.nio.DirectByteBuffer.(DirectByteBuffer.java:99) > at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288) > at sun.nio.ch.Util.getTemporaryDirectBuffer(Util.java:57) > at sun.nio.ch.IOUtil.read(IOUtil.java:205) > at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207) > at > org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcessor.java:201) > at > org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProcessor.java:181) > at > org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoProcessor.java:44) > -XX:MaxDirectMemorySize has not been set, it was running with the default > value (64MB). > The load peaked 24hours before the errors started to show up, at the time of > the crash the load on the servers has been at ~60% of the peak load. > We contacted Sun regarding this issue, and they pointed out RFE 6296278: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6296278 > There is a workaround suggested to make ByteBuffer release its memory w/o > waiting for GC. > Is this addressed in the latest releases of MINA? > thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648780#action_12648780 ] Emmanuel Lecharny commented on DIRMINA-539: --- Well, itwon't work : - first, you don't pass a new traffic class - second, I don't think that it's necessary anyway. The contract is pretty clear : "As the underlying network implementation may ignore this value applications should consider it a hint. " http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setTrafficClass(int) Let's do simple things, and when it becomes complicated, just think twice before injected convoluted code. > NioDatagramConnector doesn't takes the TrafficClass value set to his > DatagramSessionConfig > --- > > Key: DIRMINA-539 > URL: https://issues.apache.org/jira/browse/DIRMINA-539 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M1 > Environment: WinXP, RHEL5 (probably not important) >Reporter: martin krivosik >Assignee: Emmanuel Lecharny > Fix For: 2.0.0-M4 > > Original Estimate: 0.33h > Remaining Estimate: 0.33h > > client sending datagrams without taking care to the trafficClas set in the > config, so the ToS byte is not set in the packet sent from client. > client code: > NioDatagramAcceptor acceptor = new NioDatagramAcceptor(); > DatagramSessionConfig dcfg = > ((NioDatagramAcceptor)acceptor).getSessionConfig(); > dcfg.setTrafficClass(tosByte); > InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP, > port); > acceptor.bind(bindAddrPort); > -> connecting to another computer with NioDatagramConnector. > for me it looks like in the newHandle method of NioDatagramConnector is not > cared about TrafficClass (like it is done in NioDatagramAcceptor.open()) > The server part with the accceptor is OK and the correct ToS byte is set in > the packet. > (the same problem may be in the socket, i have to check it) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig
[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648705#action_12648705
]
Edouard De Oliveira commented on DIRMINA-539:
-
what about this one ?
boolean setTrafficClassIfAvailable(Socket socket) {
try {
int tc = socket.getTrafficClass();
socket.setTrafficClass((~tc)&0x001E);
return (tc != socket.getTrafficClass());
} catch (Exception e) {
return false;
}
}
does the job and informs the user if not done + no unnecessary tests like the
previous one which would have lead to something like
if (isSetTrafficClassAvailable(mysocket)) {
// set traffic class
;
}
> NioDatagramConnector doesn't takes the TrafficClass value set to his
> DatagramSessionConfig
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-M4
>
> Original Estimate: 0.33h
> Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the
> config, so the ToS byte is not set in the packet sent from client.
> client code:
> NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
> DatagramSessionConfig dcfg =
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
> dcfg.setTrafficClass(tosByte);
> InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP,
> port);
> acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in
> the packet.
> (the same problem may be in the socket, i have to check it)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig
[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648692#action_12648692
]
Emmanuel Lecharny commented on DIRMINA-539:
---
What we can do is something like :
boolean isSetTrafficClassAvailable(Socket socket) {
try {
int tc = socket.getTrafficClass();
socket.setTrafficClass((~tc)&0x001E);
boolean supported = (tc != socket.getTrafficClass());
socket.setTrafficClass(tc);
return supported;
} catch (Exception e) {
return false;
}
}
but it seems a bit overkilling...
> NioDatagramConnector doesn't takes the TrafficClass value set to his
> DatagramSessionConfig
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-M4
>
> Original Estimate: 0.33h
> Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the
> config, so the ToS byte is not set in the packet sent from client.
> client code:
> NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
> DatagramSessionConfig dcfg =
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
> dcfg.setTrafficClass(tosByte);
> InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP,
> port);
> acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in
> the packet.
> (the same problem may be in the socket, i have to check it)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Re : Re : [Votes] MINA 2.0-RC1
Maarten Bosteels wrote: [x] Freeze the code, move to MINA 2.0-RC1 But I agree with Julien, that the docs should improve before going to RC We just have to define a clear roadmap for doco. What about releasing 2.0.0-M4, and fix the doco for 2.0.0-RC1 ? -1 for "using a N.5 for unstable versions, and N.0 for stable versions." Ok. I really dislike conventions based on numbers. We already discussed this in the past : http://mina.markmail.org/message/hymzddmoteiatcwq Milestone -> Release Candidate -> General Availability is a well know version naming scheme It's described here: http://mina.apache.org/downloads.html Well, if it has already been discussed, forget it. No need to rehash things over and over... Thanks Maarten ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Commented: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig
[
https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648684#action_12648684
]
Emmanuel Lecharny commented on DIRMINA-539:
---
I think that all those checks (can we set/get traffic class on a
socket/datagram) is totally useless. Either you can, or you can't, but in the
second case, it simply does nothing.
Now, the current implementation is totally FU, because we do things like :
public void setTrafficClass(int trafficClass) {
if (DefaultDatagramSessionConfig.isSetTrafficClassAvailable()) {
try {
c.socket().setTrafficClass(trafficClass);
...
with :
public static boolean isSetTrafficClassAvailable() {
return SET_TRAFFIC_CLASS_AVAILABLE;
}
and, ultimately :
private static final boolean SET_TRAFFIC_CLASS_AVAILABLE = false;
This is a dead end : the isSetTrafficClassAvailable() will always return false.
Here is what I suggest : we simply get rid of all those controls, and let the
user set/get the traffic class at will. If the underlaying network does not
support it, well, it's fine, no harm.
> NioDatagramConnector doesn't takes the TrafficClass value set to his
> DatagramSessionConfig
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Emmanuel Lecharny
> Fix For: 2.0.0-M4
>
> Original Estimate: 0.33h
> Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the
> config, so the ToS byte is not set in the packet sent from client.
> client code:
> NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
> DatagramSessionConfig dcfg =
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
> dcfg.setTrafficClass(tosByte);
> InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP,
> port);
> acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in
> the packet.
> (the same problem may be in the socket, i have to check it)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny reassigned DIRMINA-539: - Assignee: Emmanuel Lecharny (was: Julien Vermillard) > NioDatagramConnector doesn't takes the TrafficClass value set to his > DatagramSessionConfig > --- > > Key: DIRMINA-539 > URL: https://issues.apache.org/jira/browse/DIRMINA-539 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M1 > Environment: WinXP, RHEL5 (probably not important) >Reporter: martin krivosik >Assignee: Emmanuel Lecharny > Fix For: 2.0.0-M4 > > Original Estimate: 0.33h > Remaining Estimate: 0.33h > > client sending datagrams without taking care to the trafficClas set in the > config, so the ToS byte is not set in the packet sent from client. > client code: > NioDatagramAcceptor acceptor = new NioDatagramAcceptor(); > DatagramSessionConfig dcfg = > ((NioDatagramAcceptor)acceptor).getSessionConfig(); > dcfg.setTrafficClass(tosByte); > InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP, > port); > acceptor.bind(bindAddrPort); > -> connecting to another computer with NioDatagramConnector. > for me it looks like in the newHandle method of NioDatagramConnector is not > cared about TrafficClass (like it is done in NioDatagramAcceptor.open()) > The server part with the accceptor is OK and the correct ToS byte is set in > the packet. > (the same problem may be in the socket, i have to check it) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648680#action_12648680 ] David Latorre commented on FTPSERVER-136: - Patch applied in 718667. The solution should work but there are a lot of nasty hacks in the code. We should want to unify all the different methods which transform a String into an InetAddress ( we should throw a single Exception then). > incorrent IP used in opening data channel > - > > Key: FTPSERVER-136 > URL: https://issues.apache.org/jira/browse/FTPSERVER-136 > Project: FtpServer > Issue Type: Bug > Environment: Windows XP >Reporter: Amichai Rothman >Assignee: David Latorre >Priority: Minor > Fix For: 1.0-M4 > > > The IP used in opening the data channel (DATA command) appears to be > determined when the ftp server starts, and never updated again. On systems > where the IP address might change (such as any dynamic dns host) this causes > all data connections to fail, and requires a full restart of the service > whenever the IP address changes (which makes the availability of the ftp > server unreliable for practical use). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Re : Re : [Votes] MINA 2.0-RC1
[x] Freeze the code, move to MINA 2.0-RC1 But I agree with Julien, that the docs should improve before going to RC -1 for "using a N.5 for unstable versions, and N.0 for stable versions." I really dislike conventions based on numbers. We already discussed this in the past : http://mina.markmail.org/message/hymzddmoteiatcwq Milestone -> Release Candidate -> General Availability is a well know version naming scheme It's described here: http://mina.apache.org/downloads.html I really don't see why we would change the version naming scheme again. Of course it's a matter of taste so we can have long discussions about it ... (not sure that it would be productive though) regards, Maarten On Tue, Nov 18, 2008 at 2:53 PM, Emmanuel Lecharny <[EMAIL PROTECTED]>wrote: > Edouard De Oliveira wrote: > >> By drawing aside N.1 and N.2 do you mean we will only do bug fixes on the >> 2.0 branch and new features will only go to 2.5 branch ? I'm not saying i >> disagree i just want to make your statement more clear. >> >> > This is exactly what I have in mind. However, it's just a convention. It's > all about the message we want to carry to our users. > > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
Re: [Votes] MINA 2.0-RC1
On Tue, 18 Nov 2008 12:04:14 +0100 Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Hi guys, > > I think it's time to stop discussing for ever and to start a vote. > > MINA 2.0.0-Mx is around for months now, and we have more and more > users developing applications around it. We have tons of proposal to > improve MINA, but many of them are pretty drastic, and may jeopardize > our users' investment. OTOS, if we close MINA 2.0 now, we also close > the door to some very important features and improvement we want to > have in MINA, which will be differed for months if we start a 3.0. > > So the best would be to determinate which strategy should be the > best. Here is a proposal. > [snip..] > [] Continue to add new features to MINA 2.0 milestones until we reach > a stable point > [X] Freeze the code, move to MINA 2.0-RC1 > [] I abstain > > [snip..] Agreeing on feature freeze but until doc isn't better no way to release an RC. Julien signature.asc Description: PGP signature
[jira] Updated: (DIRMINA-638) DefaultSocketSessionConfig creates some connection to itself.
[
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-638:
--
Affects Version/s: (was: 2.0.0-M3)
Fix Version/s: (was: 2.0.0-M4)
Just kept 1.1.7 as the problem is fixed for 2.0.0-M3 (hopefully)
> DefaultSocketSessionConfig creates some connection to itself.
> -
>
> Key: DIRMINA-638
> URL: https://issues.apache.org/jira/browse/DIRMINA-638
> Project: MINA
> Issue Type: Bug
>Affects Versions: 1.1.7
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 1.1.8
>
>
> For some unknown reason, the DefaultSocketSessionConfig class is creating a
> ServerSocket, and create a connection :
> static {
> initializeTestAddresses();
> boolean success = false;
> for (Entry e :
> TEST_ADDRESSES.entrySet()) {
> success = initializeDefaultSocketParameters(e.getKey(),
> e.getValue());
> if (success) {
> break;
> }
> }
> private static void initializeTestAddresses() {
> try {
> TEST_ADDRESSES.put(new InetSocketAddress(0),
> InetAddress.getByAddress(new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0,
> 0, 0, 1 }));
> TEST_ADDRESSES.put(new InetSocketAddress(0),
> InetAddress.getByAddress(new byte[] { 127, 0, 0, 1 }));
> } catch (UnknownHostException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> private static boolean
> initializeDefaultSocketParameters(InetSocketAddress bindAddress, InetAddress
> connectAddress) {
> ServerSocket ss = null;
> Socket socket = null;
> try {
> ss = new ServerSocket();
> ss.bind(bindAddress);
> socket = new Socket();
> socket.connect(new InetSocketAddress(connectAddress,
> ss.getLocalPort()), 1);
> initializeDefaultSocketParameters(socket);
> return true;
> } catch (IOException ioe) {
> return false;
> } finally {
> if (socket != null) {
> try {
> socket.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> if (ss != null) {
> try {
> ss.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
>}
> }
> The _only_ reason why this code exists is to setup the default values for the
> socket configuration.
> Not only is this bad code, but also a totally wrong thing to do : in many
> environment, creating sockets this way will lead to breakages (Applet, etc).
> It as to be fixed urgently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-628) Windows Firewall security issue when configuring socket
[ https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-628: -- Affects Version/s: (was: 2.0.0-M3) Fix Version/s: (was: 2.0.0-M4) Fixed on 2.0.0-M4 > Windows Firewall security issue when configuring socket > --- > > Key: DIRMINA-628 > URL: https://issues.apache.org/jira/browse/DIRMINA-628 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 1.1.7 > Environment: Windows Vista 32 and 64-bit >Reporter: Mauritz Lovgren >Assignee: Emmanuel Lecharny >Priority: Critical > Fix For: 1.1.8 > > > When upgrading to MINA 1.1.7, we suddenly get Windows Firewall dialog > complaining about our software trying to perform an operation that needs to > be blocked / unblocked before continuing. > This does NOT happen with MINA 1.1.5. > Tried to identify where in MINA this happens, but no exceptions are thrown by > the Java code and the application continues without errors after Windows > Firewall dialog has been closed, either by allowing the application to > continue by unblocking it, or by blocking the offending operation. > This might not seem to be a big problem, since after unblocking the > application once the firewall security dialog is avoided in subsequent > application startups, but for a restricted Vista user (as most of our > customer clients are), the dialog will appear at every application startup > since a restricted user does not have the permission to unblock the > application. > Our client application only starts one outbound (client) connection towards > our server application and should not at any sircumstance start a listening > socket on the client machine. > The problem can be verified by removing any existing Vista firewall rules for > all Java processes and start a MINA client that creates one outbound client > socket towards another machine. A windows firewall security dialog should > appear on the client machine. Try the same thing with MINA 1.1.5 and no > security dialog appears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-628) Windows Firewall security issue when configuring socket
[ https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648624#action_12648624 ] Emmanuel Lecharny commented on DIRMINA-628: --- It should be fixed in 2.0 trunk : http://svn.apache.org/viewvc?rev=718595&view=rev > Windows Firewall security issue when configuring socket > --- > > Key: DIRMINA-628 > URL: https://issues.apache.org/jira/browse/DIRMINA-628 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 1.1.7, 2.0.0-M3 > Environment: Windows Vista 32 and 64-bit >Reporter: Mauritz Lovgren >Assignee: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-M4, 1.1.8 > > > When upgrading to MINA 1.1.7, we suddenly get Windows Firewall dialog > complaining about our software trying to perform an operation that needs to > be blocked / unblocked before continuing. > This does NOT happen with MINA 1.1.5. > Tried to identify where in MINA this happens, but no exceptions are thrown by > the Java code and the application continues without errors after Windows > Firewall dialog has been closed, either by allowing the application to > continue by unblocking it, or by blocking the offending operation. > This might not seem to be a big problem, since after unblocking the > application once the firewall security dialog is avoided in subsequent > application startups, but for a restricted Vista user (as most of our > customer clients are), the dialog will appear at every application startup > since a restricted user does not have the permission to unblock the > application. > Our client application only starts one outbound (client) connection towards > our server application and should not at any sircumstance start a listening > socket on the client machine. > The problem can be verified by removing any existing Vista firewall rules for > all Java processes and start a MINA client that creates one outbound client > socket towards another machine. A windows firewall security dialog should > appear on the client machine. Try the same thing with MINA 1.1.5 and no > security dialog appears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-638) DefaultSocketSessionConfig creates some connection to itself.
[
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648623#action_12648623
]
Emmanuel Lecharny commented on DIRMINA-638:
---
It should be fixed in 2.0.0-M3-SNAPSHOT
> DefaultSocketSessionConfig creates some connection to itself.
> -
>
> Key: DIRMINA-638
> URL: https://issues.apache.org/jira/browse/DIRMINA-638
> Project: MINA
> Issue Type: Bug
>Affects Versions: 1.1.7, 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4, 1.1.8
>
>
> For some unknown reason, the DefaultSocketSessionConfig class is creating a
> ServerSocket, and create a connection :
> static {
> initializeTestAddresses();
> boolean success = false;
> for (Entry e :
> TEST_ADDRESSES.entrySet()) {
> success = initializeDefaultSocketParameters(e.getKey(),
> e.getValue());
> if (success) {
> break;
> }
> }
> private static void initializeTestAddresses() {
> try {
> TEST_ADDRESSES.put(new InetSocketAddress(0),
> InetAddress.getByAddress(new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0,
> 0, 0, 1 }));
> TEST_ADDRESSES.put(new InetSocketAddress(0),
> InetAddress.getByAddress(new byte[] { 127, 0, 0, 1 }));
> } catch (UnknownHostException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> private static boolean
> initializeDefaultSocketParameters(InetSocketAddress bindAddress, InetAddress
> connectAddress) {
> ServerSocket ss = null;
> Socket socket = null;
> try {
> ss = new ServerSocket();
> ss.bind(bindAddress);
> socket = new Socket();
> socket.connect(new InetSocketAddress(connectAddress,
> ss.getLocalPort()), 1);
> initializeDefaultSocketParameters(socket);
> return true;
> } catch (IOException ioe) {
> return false;
> } finally {
> if (socket != null) {
> try {
> socket.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> if (ss != null) {
> try {
> ss.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
>}
> }
> The _only_ reason why this code exists is to setup the default values for the
> socket configuration.
> Not only is this bad code, but also a totally wrong thing to do : in many
> environment, creating sockets this way will lead to breakages (Applet, etc).
> It as to be fixed urgently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-628) Windows Firewall security issue when configuring socket
[ https://issues.apache.org/jira/browse/DIRMINA-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny reassigned DIRMINA-628: - Assignee: Emmanuel Lecharny > Windows Firewall security issue when configuring socket > --- > > Key: DIRMINA-628 > URL: https://issues.apache.org/jira/browse/DIRMINA-628 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 1.1.7, 2.0.0-M3 > Environment: Windows Vista 32 and 64-bit >Reporter: Mauritz Lovgren >Assignee: Emmanuel Lecharny >Priority: Critical > Fix For: 2.0.0-M4, 1.1.8 > > > When upgrading to MINA 1.1.7, we suddenly get Windows Firewall dialog > complaining about our software trying to perform an operation that needs to > be blocked / unblocked before continuing. > This does NOT happen with MINA 1.1.5. > Tried to identify where in MINA this happens, but no exceptions are thrown by > the Java code and the application continues without errors after Windows > Firewall dialog has been closed, either by allowing the application to > continue by unblocking it, or by blocking the offending operation. > This might not seem to be a big problem, since after unblocking the > application once the firewall security dialog is avoided in subsequent > application startups, but for a restricted Vista user (as most of our > customer clients are), the dialog will appear at every application startup > since a restricted user does not have the permission to unblock the > application. > Our client application only starts one outbound (client) connection towards > our server application and should not at any sircumstance start a listening > socket on the client machine. > The problem can be verified by removing any existing Vista firewall rules for > all Java processes and start a MINA client that creates one outbound client > socket towards another machine. A windows firewall security dialog should > appear on the client machine. Try the same thing with MINA 1.1.5 and no > security dialog appears. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-638) DefaultSocketSessionConfig creates some connection to itself.
[
https://issues.apache.org/jira/browse/DIRMINA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny reassigned DIRMINA-638:
-
Assignee: Emmanuel Lecharny
> DefaultSocketSessionConfig creates some connection to itself.
> -
>
> Key: DIRMINA-638
> URL: https://issues.apache.org/jira/browse/DIRMINA-638
> Project: MINA
> Issue Type: Bug
>Affects Versions: 1.1.7, 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M4, 1.1.8
>
>
> For some unknown reason, the DefaultSocketSessionConfig class is creating a
> ServerSocket, and create a connection :
> static {
> initializeTestAddresses();
> boolean success = false;
> for (Entry e :
> TEST_ADDRESSES.entrySet()) {
> success = initializeDefaultSocketParameters(e.getKey(),
> e.getValue());
> if (success) {
> break;
> }
> }
> private static void initializeTestAddresses() {
> try {
> TEST_ADDRESSES.put(new InetSocketAddress(0),
> InetAddress.getByAddress(new byte[] { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,0, 0,
> 0, 0, 1 }));
> TEST_ADDRESSES.put(new InetSocketAddress(0),
> InetAddress.getByAddress(new byte[] { 127, 0, 0, 1 }));
> } catch (UnknownHostException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> private static boolean
> initializeDefaultSocketParameters(InetSocketAddress bindAddress, InetAddress
> connectAddress) {
> ServerSocket ss = null;
> Socket socket = null;
> try {
> ss = new ServerSocket();
> ss.bind(bindAddress);
> socket = new Socket();
> socket.connect(new InetSocketAddress(connectAddress,
> ss.getLocalPort()), 1);
> initializeDefaultSocketParameters(socket);
> return true;
> } catch (IOException ioe) {
> return false;
> } finally {
> if (socket != null) {
> try {
> socket.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
> if (ss != null) {
> try {
> ss.close();
> } catch (IOException e) {
> ExceptionMonitor.getInstance().exceptionCaught(e);
> }
> }
>}
> }
> The _only_ reason why this code exists is to setup the default values for the
> socket configuration.
> Not only is this bad code, but also a totally wrong thing to do : in many
> environment, creating sockets this way will lead to breakages (Applet, etc).
> It as to be fixed urgently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Re : Re : [Votes] MINA 2.0-RC1
Edouard De Oliveira wrote: By drawing aside N.1 and N.2 do you mean we will only do bug fixes on the 2.0 branch and new features will only go to 2.5 branch ? I'm not saying i disagree i just want to make your statement more clear. This is exactly what I have in mind. However, it's just a convention. It's all about the message we want to carry to our users. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re : Re : [Votes] MINA 2.0-RC1
You're right using a N.5 notation for instable work in progress is ok to me 2.0.0-Mx should indeed be used for an almost frozen API (sometimes minor changes that can't be postponed are needed) N.0.x are and should be bug fixes By drawing aside N.1 and N.2 do you mean we will only do bug fixes on the 2.0 branch and new features will only go to 2.5 branch ? I'm not saying i disagree i just want to make your statement more clear. Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php De : Emmanuel Lecharny <[EMAIL PROTECTED]> À : dev@mina.apache.org Envoyé le : Mardi, 18 Novembre 2008, 14h32mn 17s Objet : Re: Re : [Votes] MINA 2.0-RC1 > This will allow on focusing a big road map for 3.0 maybe hitting some 2.1,2.2 > on the road to progressively introduce some changes and see how community > reacts to them. > May I suggest that we use a clear notation for 'unstable' versions? With the current one (ie, 2.0.0-Mx), people tend to think that it's stable (stable <=> API is frozen). What about using a N.5 for unstable versions, and N.0 for stable versions? For instance, 2.5 will be unstable, and will be renamed 3.0-RC1 as soon as we have frozen the API. IMO, having N.1, N.2 etc is not necessarily a good idea. There is some confusion between N.0 and N.1 versions, as N.0.x are already bug fixes. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [jira] Commented: (FTPSERVER-184) IODataConnection ASCII mode does not work as expected.
I've a couple of classes to handle the ASCII transfer mode. Since
these classes are inherited from InputStream and OutputStream, you
should be able to plug these in very easily by just wrapping the
original stream into the new stream. I used these classes in my FTP
Client implementation. We should be able to use these in the Server as
well with no (or little) modifications.
I've attached the classes for you to take a look at.
Regards,
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Mon, Nov 17, 2008 at 3:26 PM, Niklas Gustavsson (JIRA)
<[EMAIL PROTECTED]> wrote:
>
>[
> https://issues.apache.org/jira/browse/FTPSERVER-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648348#action_12648348
> ]
>
> Niklas Gustavsson commented on FTPSERVER-184:
> -
>
> David, would you like to work on this for M4 or should we reschedule it for
> now? I do think we should fix this, but it could be done for 1.0
>
>> IODataConnection ASCII mode does not work as expected.
>> --
>>
>> Key: FTPSERVER-184
>> URL: https://issues.apache.org/jira/browse/FTPSERVER-184
>> Project: FtpServer
>> Issue Type: Improvement
>> Components: Core
>>Affects Versions: 1.0-M2, 1.0-M3
>>Reporter: David Latorre
>>Assignee: Niklas Gustavsson
>> Fix For: 1.0-M4
>>
>>
>> New lines in files sent in ASCII mode are transformed into /r/n no matter
>> what platform the ftp server is running on. But if I'm not wrong, the new
>> EOL should be equal to "line.separator" . If ASCII mode is going to be
>> supported, this ought to be changed.
>>
>> The code in IODataConnection.transfer()
>> {
>> if (isAscii) {
>> for (int i = 0; i < count; ++i) {
>> byte b = buff[i];
>> if (b == '\n' && !lastWasCR) {
>> bos.write('\r');
>> }
>> if (b == '\r') {
>> lastWasCR = true;
>> } else {
>> lastWasCR = false;
>> }
>> bos.write(b);
>> }
>> }
>> }
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
Re: Re : [Votes] MINA 2.0-RC1
This will allow on focusing a big road map for 3.0 maybe hitting some 2.1,2.2 on the road to progressively introduce some changes and see how community reacts to them. May I suggest that we use a clear notation for 'unstable' versions? With the current one (ie, 2.0.0-Mx), people tend to think that it's stable (stable <=> API is frozen). What about using a N.5 for unstable versions, and N.0 for stable versions? For instance, 2.5 will be unstable, and will be renamed 3.0-RC1 as soon as we have frozen the API. IMO, having N.1, N.2 etc is not necessarily a good idea. There is some confusion between N.0 and N.1 versions, as N.0.x are already bug fixes. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re : [Votes] MINA 2.0-RC1
[x] Freeze the code, move to MINA 2.0-RC1 > Get 2.0 out, let users migrate, drop 1.0 and 1.1. +1 1.0 and 1.1 have been supported some significant time moreover generally speaking 1.0 to 2.0 is a breeze and imporves perfs so we can consider that our users can migrate fast and at a low cost. This will allow on focusing a big road map for 3.0 maybe hitting some 2.1,2.2 on the road to progressively introduce some changes and see how community reacts to them. We need clear roadmaps and timeframes to pinpoint a 'real' goal and make it real. My 2 cents Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php De : Eero Nevalainen <[EMAIL PROTECTED]> À : dev@mina.apache.org Envoyé le : Mardi, 18 Novembre 2008, 12h49mn 29s Objet : Re: [Votes] MINA 2.0-RC1 Emmanuel Lecharny wrote: > [] Continue to add new features to MINA 2.0 milestones until we reach a > stable point > [] Freeze the code, move to MINA 2.0-RC1 > [] I abstain Non-binding [x] Freeze the code, move to MINA 2.0-RC1 Get 2.0 out, let users migrate, drop 1.0 and 1.1. -- Eero Nevalainen
RE: [Votes] MINA 2.0-RC1
> Emmanuel Lecharny [mailto:[EMAIL PROTECTED] wrote: > > [] Continue to add new features to MINA 2.0 milestones until we reach a > stable point > [X] Freeze the code, move to MINA 2.0-RC1 > [] I abstain > > If we select (1), we will have to determinate the clear roadmap, > otherwise we won't be able to release 2.0 before 2017... A clear roadmap for 3.0 would be fine, too. Even if the roadmap isn't met, its a point where you can head to. regards Steve
Re:
[X] Freeze the code, move to MINA 2.0-RC1 On Nov 18, 2008, at 4:04 AM, wrote: Hi guys, I think it's time to stop discussing for ever and to start a vote. MINA 2.0.0-Mx is around for months now, and we have more and more users developing applications around it. We have tons of proposal to improve MINA, but many of them are pretty drastic, and may jeopardize our users' investment. OTOS, if we close MINA 2.0 now, we also close the door to some very important features and improvement we want to have in MINA, which will be differed for months if we start a 3.0. So the best would be to determinate which strategy should be the best. Here is a proposal. [] Continue to add new features to MINA 2.0 milestones until we reach a stable point [] Freeze the code, move to MINA 2.0-RC1 [] I abstain If we select (1), we will have to determinate the clear roadmap, otherwise we won't be able to release 2.0 before 2017... If we pick (2), we have to check the open JIRAs, fix them, and define a timeframe for 2.0-RC1 release (and it should be a matter of weeks, not months) Guys, it's up to you ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Votes] MINA 2.0-RC1
[X] Freeze the code, move to MINA 2.0-RC1 -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [Votes] MINA 2.0-RC1
On Tue, Nov 18, 2008 at 12:04 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > [X] Freeze the code, move to MINA 2.0-RC1 Let's go! /niklas
Re: [Votes] MINA 2.0-RC1
Emmanuel Lecharny wrote: [] Continue to add new features to MINA 2.0 milestones until we reach a stable point [] Freeze the code, move to MINA 2.0-RC1 [] I abstain Non-binding [x] Freeze the code, move to MINA 2.0-RC1 Get 2.0 out, let users migrate, drop 1.0 and 1.1. -- Eero Nevalainen
Re: [Votes] MINA 2.0-RC1
[X] Freeze the code, move to MINA 2.0-RC1 On Tue, Nov 18, 2008 at 6:04 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > Hi guys, > > I think it's time to stop discussing for ever and to start a vote. > > MINA 2.0.0-Mx is around for months now, and we have more and more users > developing applications around it. We have tons of proposal to improve MINA, > but many of them are pretty drastic, and may jeopardize our users' > investment. OTOS, if we close MINA 2.0 now, we also close the door to some > very important features and improvement we want to have in MINA, which will > be differed for months if we start a 3.0. > > So the best would be to determinate which strategy should be the best. Here > is a proposal. > > [] Continue to add new features to MINA 2.0 milestones until we reach a > stable point > [] Freeze the code, move to MINA 2.0-RC1 > [] I abstain > > If we select (1), we will have to determinate the clear roadmap, otherwise > we won't be able to release 2.0 before 2017... > If we pick (2), we have to check the open JIRAs, fix them, and define a > timeframe for 2.0-RC1 release (and it should be a matter of weeks, not > months) > > Guys, it's up to you ! > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
[Votes] MINA 2.0-RC1
Hi guys, I think it's time to stop discussing for ever and to start a vote. MINA 2.0.0-Mx is around for months now, and we have more and more users developing applications around it. We have tons of proposal to improve MINA, but many of them are pretty drastic, and may jeopardize our users' investment. OTOS, if we close MINA 2.0 now, we also close the door to some very important features and improvement we want to have in MINA, which will be differed for months if we start a 3.0. So the best would be to determinate which strategy should be the best. Here is a proposal. [] Continue to add new features to MINA 2.0 milestones until we reach a stable point [] Freeze the code, move to MINA 2.0-RC1 [] I abstain If we select (1), we will have to determinate the clear roadmap, otherwise we won't be able to release 2.0 before 2017... If we pick (2), we have to check the open JIRAs, fix them, and define a timeframe for 2.0-RC1 release (and it should be a matter of weeks, not months) Guys, it's up to you ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Commented: (FTPSERVER-205) missing user management docs
[
https://issues.apache.org/jira/browse/FTPSERVER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648561#action_12648561
]
Gary Bell commented on FTPSERVER-205:
-
Ok, FTPSERVER-218 added a refresh() method to the PropertiesUserManager, so now
you can use that.
https://issues.apache.org/jira/browse/FTPSERVER-218
=== Snippet from onSite() method call ===
String cmd = request.getArgument().toUpperCase();
if ("UPDATE ACCTS".equals(cmd)) {
// admin has hand-edited the user file and wants to let the server know...
((PropertiesUserManager) server.getUserManager()).refresh(); //server is an
instance of DefaultFtpServer created earlier..
return FtpletResult.SKIP; // prevent further processing.
=
> missing user management docs
>
>
> Key: FTPSERVER-205
> URL: https://issues.apache.org/jira/browse/FTPSERVER-205
> Project: FtpServer
> Issue Type: Bug
>Affects Versions: 1.0-M3
>Reporter: Amichai Rothman
>Assignee: Niklas Gustavsson
> Fix For: 1.0-M4
>
>
> There is no mention in the docs of how to manage users (i.e. add new ones,
> etc.). There's one page which mentions the admin GUI app which is not
> available in the distribution (see issue FTPSERVER-201). As a new user on a
> new installation, I could not find the mechanism by which I can add and
> administer users on the server, which makes it pretty much unusable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 2.0.0-M4 release soon ?
On Tue, Nov 18, 2008 at 10:17 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > I think that we have room for many milestones before a 2.0. I still think we should aim to get 2.0 out, without any major changes. After that, we can start thinking of 2.1 or 3.0. So, I would not like to do many more milestones. To me, M4 should be the last one before we to the end game for 2.0 /niklas
Re: 2.0.0-M4 release soon ?
Steve Ulrich wrote: Hi! +1 for M4 soon and before merging back Big changes tend to have big bugs, so these changes have to be well tested. I think that we have room for many milestones before a 2.0. Moving from milestone to milestone while adding new features is easier than doing a big bang approach, IMO. Btw, tests are a real issue in MINA. We can test well many helper classes (IoBuffer, Chain, etc), but when it comes to asynchronous networking, it's really difficult to cover all of our bases. We may need to think about how we can create a better test environment. May be we need a dedicated platform to do that ? wdyt ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
RE: 2.0.0-M4 release soon ?
Hi! +1 for M4 soon and before merging back Big changes tend to have big bugs, so these changes have to be well tested. Steve > Emmanuel Lecharny [mailto:[EMAIL PROTECTED] wrote > > Hi guys, > > what about releasing a 2.0.0-M4 soon ? As I've worked those last few > weeks on MINA in order to get it used in Directory, and as it's a > success so far (works great, performances are better - around 10% speed > increas -), I may need a release to get what I have worked on be put > back in Directory trunk. > > Also I think we fixed some important bugs, plus done some cleaning and > javadoced a bit more the code. > > So wdyt ? > > Also : there are a few more issues associated with 2.0.0-M4, and I > think > we can try to fix some of them, as I can wait a few days or even a > couple of weeks before merging my own code in Directory. > > I also think it would be a good idea to define a new roadmap, injecting > into it most of the discussion and suggestions we have had those last > two monts. Namely : > - Removing of MessageSent > - Chain refactoring > - Moving from autoextensible IoBuffer to something more versatile and > with a zero-copy strategy > - Merging SessionCreate and SessionOpened events > - Rethinking the preAdd/PostAdd and preRemove/postRemove methods > - Checking the SSL Filter to see if it should be a filter > - Refactoring the handler to make it a Filter > - Adding a simpler ProtocolCodec Filter > - Get rid of mandatory statistics > - Suppress the double call to Write() done to get the number of sent > messages > - Define more precisely the Future we are using (why don't we inherit > from the java 5 Future class ?) > - and may be more. > > I think we also have to determinate if we should do all that for 2.0, > or > if we must release 2.0 asap, and start a 3.0 branch. We already have > discussed extensively about this dilemma,without stating a position, > and > I can't see how we can go without a vote. > > Again, wdyt ? > > Thanks ! > > PS: Even if it was not a piece of cake, MINA 2 migration in ADS went > pretty smooth, considering that we have 5 servers using it (LDAP, NTP, > KERBEROS, DNS, DHCP, plus the internal replication system). As I said, > performance is better. I must admit that I spent more time to play with > MINA's internal than to do the migration (3 weeks to compare with the 3 > days it took me to migrate). I run the server with a small load test (1 > million request done, with many clients), and everything went fine. I > will do a bigger tests in the next few weeks, trying to make the server > run a couple of days, being hammered by thousands of requests per > second :) > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org >
