Hudson build is still unstable: MINA-tru nk-jdk1.5-windows » Apache MINA Core #18
See http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.5-windows/org.apache.mina$mina-core/changes
Hudson build is still unstable: MINA-trunk-jdk1.5-windows #18
See http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.5-windows/changes
[jira] Commented: (DIRMINA-785) Half-duplex close of TCP channel
[ https://issues.apache.org/jira/browse/DIRMINA-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866077#action_12866077 ] Jan Tauš commented on DIRMINA-785: -- I created patch of MINA(2.0.0.RC1) and AsyncWeb(trunk) (both attached) for my use. The problem is that it is application protocol dependent what to do when the input is closed. So my patch sends new event inputClose(IoSession) to the filter chain instead closing the session. The default handling of this event is to close the session. The patch of the AsyncWeb adds the handling of the new event to the SingleHttpSessionIoHandler. If there exists HTTP service context then the context is marked to close HTTP connection after a response is commited. If the context doesn't exists the session is closed immediately. Half-duplex close of TCP channel Key: DIRMINA-785 URL: https://issues.apache.org/jira/browse/DIRMINA-785 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 2.0.0-M6 Reporter: Jan Tauš Current MINA implementation doesn't support half-duplex close as described in RFC-793 section 3.5. Closing a Connection. After the read in AbstractPollingIoProcessor#read() fails due to closed of the input stream whole NioSocketSession#channel is scheduled to close. In such situation only the input part should be closed with call to SocketChannel#socket().shutdownInput(). The whole channel should be closed only after the IoSession#close() call. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-785) Half-duplex close of TCP channel
[ https://issues.apache.org/jira/browse/DIRMINA-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Tauš updated DIRMINA-785: - Attachment: patch-mina-2.0.0-RC1.diff patch-asyncweb-2.0.0-r942061.diff Patch enabling half-duplex close in MINA and AsyncWeb Half-duplex close of TCP channel Key: DIRMINA-785 URL: https://issues.apache.org/jira/browse/DIRMINA-785 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 2.0.0-M6 Reporter: Jan Tauš Attachments: patch-asyncweb-2.0.0-r942061.diff, patch-mina-2.0.0-RC1.diff Current MINA implementation doesn't support half-duplex close as described in RFC-793 section 3.5. Closing a Connection. After the read in AbstractPollingIoProcessor#read() fails due to closed of the input stream whole NioSocketSession#channel is scheduled to close. In such situation only the input part should be closed with call to SocketChannel#socket().shutdownInput(). The whole channel should be closed only after the IoSession#close() call. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Getting involved
Welcome Michael ! Passion is the key factor, and since you have been using MINA for quite some time.. it would be real good to have you on the team :) cheers ashish On Mon, May 10, 2010 at 7:12 PM, Emmanuel Lecharny elecha...@gmail.com wrote: On 5/10/10 3:26 PM, Michaël Figuière wrote: Hi all, Hi Michaël ! So far I've been using Mina for 2 years and I've been following the mina-dev list for some months. This seems to be a good point in time for me to start getting involved in Mina ! Some words about me. I've been working on various Java / JEE projects for some large companies in France for 4 years and I'm quite interested in any network and distributed stuff, whether they are in Java, C or anything else. While loving such low level things, i also enjoy to design simple to use high level API that make complicated things simpler : that seems to make Mina a nice fit for me :-) Great ! Thanks you all for the nice work you give and have given to the community. See you later on this mailing list ! Just FYI guys, Michaël is someone I met 2 years ago, and we have had many heated discussion about MINA while drinking beers (oops, Michaël does not drink at all :/ ). I have engaged him many times to be part of the effort, and I'm pleased to see him posting for the first time ! Michaël, we are currently trying to close MINA 2.0, and as you can see on the ML, we are closing the existing JIRAs. I consider that MINA 2.0 is not a version we want to change a lot, this is the reason we have started some discussion about MINA 3.0. Apache projects are based on merit, and this merit is established by contributions. So feel free to participate, we hope that your contributions will be good enough for the existing community to grant you some commit karma ! For those who thnk they can bring some value to the project, don't be scared to participate : people tend to think that Apache committers are some kind of half gods. That's *not* the case. We are just plain gods ;) Seriously, we are just average coders who are passionate about code, and dedicated to offer the best we can to our users. What makes the difference is the way we work : - it's a community, so expect your contributions to be challenged, - it's a community, so be sure that you'll get some help - it's a community, so what you can't solve, someone else will All in all, it's just about being a community, with a few rules ! -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
On Mon, May 10, 2010 at 5:56 PM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: Is there some solution we could base consensus on? Since it's a question of either explicitly declaring namespaces or explicitly not doing so (to reduce cluttering if I've understood you correctly), there seems to be hard to find a common ground. I would like to propose two different ways forward. Either, get input from the greater community, this decision is not really down to only us two. Perhaps as a vote. Or, and this would be my preferred option at this time, give this change some further time. The change has only been in trunk for a few days and very limited development has occurred since. Thus, I'm not sure we have yet evaluated (used in anger) the changes sufficiently to dismiss them. If you or others still don't find any value in declaring namespaces and find them annoying then, let's discuss further or call a vote at that time. /niklas
Hudson build is back to stable : MINA-tr unk-jdk1.5-windows » Apache MINA Core #19
See http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.5-windows/org.apache.mina$mina-core/19/changes
Hudson build is back to stable : MINA-trunk-jdk1.5-windows #19
See http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.5-windows/19/changes
cancel a build on hudson
Hello, In a naive attempt to temporarily fix DIRMINA-784, I created an infinite loop and now hudson has fell victim of that. Can someone with the needed privileges, cancel http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/21/ I (think I) have fixed the infinite loop. And maybe we should specify a timeout for the tests in the pom ? regards, Maarten
Build failed in Hudson: MINA-trunk-jdk1.6-windows #21
See http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/21/changes Changes: [maarten] trying to fix DIRMINA-784 (root-cause not yet fixed) -- Failed to access build log java.io.InterruptedIOException at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:199) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) at hudson.model.Run.getLog(Run.java:1407) at hudson.tasks.MailSender.createFailureMail(MailSender.java:238) at hudson.tasks.MailSender.getMail(MailSender.java:134) at hudson.tasks.MailSender.execute(MailSender.java:82) at hudson.maven.MavenModuleSetBuild$RunnerImpl.cleanUp(MavenModuleSetBuild.java:616) at hudson.model.Run.run(Run.java:1285) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:304) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122)
Re: cancel a build on hudson
On Tue, May 11, 2010 at 3:06 PM, Maarten Bosteels mbosteels@gmail.com wrote: In a naive attempt to temporarily fix DIRMINA-784, I created an infinite loop and now hudson has fell victim of that. Can someone with the needed privileges, cancel http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/21/ Done. And maybe we should specify a timeout for the tests in the pom ? Fixed in Hudson. /niklas
Hudson build is back to normal : MINA-trunk-jdk1.5-ubuntu #19
See http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.5-ubuntu/19/changes
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
On Tue, May 11, 2010 at 13:21, Niklas Gustavsson nik...@protocol7.com wrote: On Mon, May 10, 2010 at 5:56 PM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: Is there some solution we could base consensus on? Since it's a question of either explicitly declaring namespaces or explicitly not doing so (to reduce cluttering if I've understood you correctly), there seems to be hard to find a common ground. I would like to propose two different ways forward. Either, get input from the greater community, this decision is not really down to only us two. Perhaps as a vote. Or, and this would be my preferred option at this time, give this change some further time. The change has only been in trunk for a few days and very limited development has occurred since. Thus, I'm not sure we have yet evaluated (used in anger) the changes sufficiently to dismiss them. If you or others still don't find any value in declaring namespaces and find them annoying then, let's discuss further or call a vote at that time. Agreed. This is good. The only thing which nags me is that the current trunk has the xmlns= issue, my patch makes the problem go away, but it is not a fix. Bernd
Re: [VOTE] Release SSHD 0.4.0 (third try)
+1 On Mon, May 10, 2010 at 21:44, Guillaume Nodet gno...@gmail.com wrote: I've uploaded a RC for SSHD 0.4.0 at https://repository.apache.org/content/repositories/orgapachemina-026/ The release notes are available at https://cwiki.apache.org/SSHD/sshd-040.html Please review and vote. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release SSHD 0.4.0 (third try)
+1 Jeff On May 11, 2010, at 9:24 AM, Guillaume Nodet wrote: +1 On Mon, May 10, 2010 at 21:44, Guillaume Nodet gno...@gmail.com wrote: I've uploaded a RC for SSHD 0.4.0 at https://repository.apache.org/content/repositories/orgapachemina-026/ The release notes are available at https://cwiki.apache.org/SSHD/sshd-040.html Please review and vote. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release SSHD 0.4.0 (third try)
+1 Regards, Sai Pullabhotla On Mon, May 10, 2010 at 9:44 PM, Guillaume Nodet gno...@gmail.com wrote: I've uploaded a RC for SSHD 0.4.0 at https://repository.apache.org/content/repositories/orgapachemina-026/ The release notes are available at https://cwiki.apache.org/SSHD/sshd-040.html Please review and vote. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [VOTE] Release SSHD 0.4.0 (third try)
+1 On Tue, May 11, 2010 at 9:28 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: +1 Regards, Sai Pullabhotla On Mon, May 10, 2010 at 9:44 PM, Guillaume Nodet gno...@gmail.com wrote: I've uploaded a RC for SSHD 0.4.0 at https://repository.apache.org/content/repositories/orgapachemina-026/ The release notes are available at https://cwiki.apache.org/SSHD/sshd-040.html Please review and vote. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
On Tue, May 11, 2010 at 3:55 PM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: The only thing which nags me is that the current trunk has the xmlns= issue, my patch makes the problem go away, but it is not a fix. How do I reproduce this issue so that I can look into fixing it? /niklas
Re: [VOTE] Release SSHD 0.4.0 (third try)
On Tue, May 11, 2010 at 4:44 AM, Guillaume Nodet gno...@gmail.com wrote: Please review and vote. I have not tested the functionality (Sai et al seems to be doing a good job at that) but have instead focused on the boring stuff like licenses. Looks good. +1 /niklas
scp / sftp
Hi all, Today I noticed your client scp/sftp tests are using JSCH objects. Is there a way to do it using SSHD client objects ? (ie- channelfor sftp/scp). Thanks ! Doron
Re: scp / sftp
Well, we don't have any SFTP or SCP client yet, so I guess the answer is no for now. On Tue, May 11, 2010 at 17:15, Doron Fediuck doron.fedi...@gmail.comwrote: Hi all, Today I noticed your client scp/sftp tests are using JSCH objects. Is there a way to do it using SSHD client objects ? (ie- channelfor sftp/scp). Thanks ! Doron -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
