RE: [Vote] Create a MINA subproject to implement a SSH server based on Mina
Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [X] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA D Notice to recipient: The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity. If this email originates from the U.K. please note that Bank of America, N.A., London Branch and Banc of America Securities Limited are authorised and regulated by the Financial Services Authority. For all U.K. corporate disclosures, please refer to www.bankofamerica.com/ukcompanies
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
On Thu, 20 Nov 2008 00:21:12 +0100 Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [X] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA signature.asc Description: PGP signature
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
[X] +1 Yes, accept the SSH server as a sub-project -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : Re : [Votes] MINA 2.0-RC1
[x] Freeze the code, move to MINA 2.0-RC1 But if we can freeze in M4, and work on doco for RC1, that would be fine ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
[X] +1 Yes, accept the SSH server as a sub-project Maarten
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
+1 On Thu, Nov 20, 2008 at 12:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Closed: (FTPSERVER-220) does not processed correct user's empty password
[ https://issues.apache.org/jira/browse/FTPSERVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gorobchuk closed FTPSERVER-220. Resolution: Fixed bug is not reproduced since was fixed config reader and empty value of password is stored as empty string instead of NULL in the M3 version. However, I think code which is described above shows not good idea for checking user existing. does not processed correct user's empty password Key: FTPSERVER-220 URL: https://issues.apache.org/jira/browse/FTPSERVER-220 Project: FtpServer Issue Type: Bug Components: Server Affects Versions: 1.0-M3 Reporter: Oleg Gorobchuk Assignee: Niklas Gustavsson Fix For: 1.0-M4 In the case if user has declared empty password server does not allow to connect user. Empty password does not processed for normal user and anonymous and for all encrypted modes. Sources of problem. 1. command PASS blocked using empty password since in this case request contains NULL instead password value and command generates error 501 2. In the case of using properties way of user management the class PropertiesUserManager, for case of configured empty password, makes decision that user does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
[X] +1 Yes, accept the SSH server as a sub-project
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
+1 On Wed, Nov 19, 2008 at 6:21 PM, Emmanuel Lecharny [EMAIL PROTECTED]wrote: Hi guys, Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Resolved: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre resolved FTPSERVER-136. - Resolution: Fixed 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.
[jira] Closed: (FTPSERVER-136) incorrent IP used in opening data channel
[ https://issues.apache.org/jira/browse/FTPSERVER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-136. --- Amichai can you test this? I have to find an automatic and portable way to test this. You can change your ip address (e.g, with ifconfig in Unix) and test if connection still works . But since ipaliasing in my linux box doesn't work and actually changes the ip address rather than adding a new one I cannot automate tests. 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: [Vote] Create a MINA subproject to implement a SSH server based on Mina
[X] +1 Yes, accept the SSH server as a sub-project Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Wed, Nov 19, 2008 at 5:21 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina
+1 Jeff On Nov 20, 2008, at 2:52 AM, Guillaume Nodet wrote: +1 On Thu, Nov 20, 2008 at 12:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Hi guys, Guillaume Nodet has written a SSH server based on MINA, and as we discussed it last week, it would be interesting to have it as a subproject. It's time for a formal vote then : [] +1 Yes, accept the SSH server as a sub-project [] +/-0 I don't really care [] -1 Nope, it does not belong to MINA -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (DIRMINA-639) WriteFuture are never updated after a session.write()
WriteFuture are never updated after a session.write() - Key: DIRMINA-639 URL: https://issues.apache.org/jira/browse/DIRMINA-639 Project: MINA Issue Type: Bug Affects Versions: 2.0.0-M3 Reporter: Emmanuel Lecharny Priority: Blocker Fix For: 2.0.0-M4 While expecting the writeFuture to be updated when the write has been done, it's never done. This is a major problem as you can't rely on this to bail a connection based on a slow client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-222) Enhance the Ftplet.afterCommand method to include the result of the command that was executed
[ https://issues.apache.org/jira/browse/FTPSERVER-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Pullabhotla updated FTPSERVER-222: -- Attachment: ftpserver_patch.txt The patch with the enhancements mentioned. Enhance the Ftplet.afterCommand method to include the result of the command that was executed - Key: FTPSERVER-222 URL: https://issues.apache.org/jira/browse/FTPSERVER-222 Project: FtpServer Issue Type: Improvement Components: Ftplets Reporter: Sai Pullabhotla Fix For: 1.0-M4 Attachments: ftpserver_patch.txt The aftterCommand method in the Ftplet interface is a great way to listen for events from the FtpServer, however, this call back method does not tell anything about the result of the command execution. Change the signature of this method to include the result of the command. More information on this is available at http://www.mail-archive.com/[EMAIL PROTECTED]/msg00407.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FTPSERVER-222) Enhance the Ftplet.afterCommand method to include the result of the command that was executed
[ https://issues.apache.org/jira/browse/FTPSERVER-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson closed FTPSERVER-222. --- Resolution: Fixed Assignee: Niklas Gustavsson Modified patch applied in rev 719389. Thanks for your work on this! The modifications: * Fixed broken tests * Did not include the FtpReply in the DefaultFtplet callbacks (like onLogin) since it would silently break every DefaultFtplet subclass out there. If you need the reply, you need to override afterCommand. Hope your okay with these changes Sai? if you got the time, I would love to see some unit tests for this patch. Enhance the Ftplet.afterCommand method to include the result of the command that was executed - Key: FTPSERVER-222 URL: https://issues.apache.org/jira/browse/FTPSERVER-222 Project: FtpServer Issue Type: Improvement Components: Ftplets Reporter: Sai Pullabhotla Assignee: Niklas Gustavsson Fix For: 1.0-M4 Attachments: ftpserver_patch.txt The aftterCommand method in the Ftplet interface is a great way to listen for events from the FtpServer, however, this call back method does not tell anything about the result of the command execution. Change the signature of this method to include the result of the command. More information on this is available at http://www.mail-archive.com/[EMAIL PROTECTED]/msg00407.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-222) Enhance the Ftplet.afterCommand method to include the result of the command that was executed
[ https://issues.apache.org/jira/browse/FTPSERVER-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649511#action_12649511 ] Sai Pullabhotla commented on FTPSERVER-222: --- Sorry, I did not even look at the test packages. Did not configure them as source folders in my eclipse. I left the following TODO's in the DefaultFtplet class for you to consider: 1. TODO remove unncessary throws clause from onXXXStart and onXXXEnd methods. 2. TODO consider splitting the onLogin method into two - onLoginStart and onLoginEnd, fire these two methods on the PASS command. I think we can ignore #1, but #2 makes sense so these methods are consistent with the rest. Regarding test cases, I'm not sure what you are looking, if you could provide me some details, I will see what I can do. Sai Pullabhotla Phone: (402) 408-5753 Fax: (402) 408-6861 www.jMethods.com On Thu, Nov 20, 2008 at 3:56 PM, Niklas Gustavsson (JIRA) Enhance the Ftplet.afterCommand method to include the result of the command that was executed - Key: FTPSERVER-222 URL: https://issues.apache.org/jira/browse/FTPSERVER-222 Project: FtpServer Issue Type: Improvement Components: Ftplets Reporter: Sai Pullabhotla Assignee: Niklas Gustavsson Fix For: 1.0-M4 Attachments: ftpserver_patch.txt The aftterCommand method in the Ftplet interface is a great way to listen for events from the FtpServer, however, this call back method does not tell anything about the result of the command execution. Change the signature of this method to include the result of the command. More information on this is available at http://www.mail-archive.com/[EMAIL PROTECTED]/msg00407.html. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-639) WriteFuture are updated long after a session.write() is done
[ https://issues.apache.org/jira/browse/DIRMINA-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-639: -- Description: While expecting the writeFuture to be updated when the write has been done, it's done only when we get out of the chain. This is a major problem as you can't rely on this to bail a connection based on a slow client. Typically, we may stack thousands of message into the writeQueuebuffer, as the flush is only done when we have gone though the whole chain, and back. The only way to get the data be blushed immediately is to add an executorFilter on the WRITE eventType, in order to create a new thread to handle this flush, otherwise we have to wait for the current processor to be done with the chain processing. was:While expecting the writeFuture to be updated when the write has been done, it's never done. This is a major problem as you can't rely on this to bail a connection based on a slow client. Summary: WriteFuture are updated long after a session.write() is done (was: WriteFuture are never updated after a session.write()) WriteFuture are updated long after a session.write() is done Key: DIRMINA-639 URL: https://issues.apache.org/jira/browse/DIRMINA-639 Project: MINA Issue Type: Bug Affects Versions: 2.0.0-M3 Reporter: Emmanuel Lecharny Priority: Blocker Fix For: 2.0.0-M4 While expecting the writeFuture to be updated when the write has been done, it's done only when we get out of the chain. This is a major problem as you can't rely on this to bail a connection based on a slow client. Typically, we may stack thousands of message into the writeQueuebuffer, as the flush is only done when we have gone though the whole chain, and back. The only way to get the data be blushed immediately is to add an executorFilter on the WRITE eventType, in order to create a new thread to handle this flush, otherwise we have to wait for the current processor to be done with the chain processing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Compression bug - solved
Hey everyone,
After more than one year of living next to the compression bug we were able to
find the reason for it. The exceptions where several but in general they looked
like this:
2007.04.24 23:29:04
[org.jivesoftware.openfire.nio.ConnectionHandler.exceptionCaught(ConnectionHand
ler.java:109)]
java.lang.ArrayIndexOutOfBoundsException: -2147483646
at com.jcraft.jzlib.Deflate.deflate_slow(Deflate.java:1131)
at com.jcraft.jzlib.Deflate.deflate(Deflate.java:1567)
at com.jcraft.jzlib.ZStream.deflate(ZStream.java:133)
at org.apache.mina.filter.support.Zlib.deflate(Zlib.java:176)
at
org.apache.mina.filter.CompressionFilter.filterWrite(CompressionFilter.java:198
)
at
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(Ab
stractIoFilterChain.java:445)
at
org.apache.mina.common.support.AbstractIoFilterChain.access$1400(AbstractIoFilt
erChain.java:54)
at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(Ab
stractIoFilterChain.java:824)
at
org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:
292)
at
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(Ab
stractIoFilterChain.java:445)
at
org.apache.mina.common.support.AbstractIoFilterChain.access$1400(AbstractIoFilt
erChain.java:54)
at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(Ab
stractIoFilterChain.java:824)
at
org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilte
r.java:227)
at
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(Ab
stractIoFilterChain.java:445)
at
org.apache.mina.common.support.AbstractIoFilterChain.access$1400(AbstractIoFilt
erChain.java:54)
at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(Ab
stractIoFilterChain.java:824)
at
org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.filterWrite(Abs
tractIoFilterChain.java:727)
at
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(Ab
stractIoFilterChain.java:445)
at
org.apache.mina.common.support.AbstractIoFilterChain.fireFilterWrite(AbstractIo
FilterChain.java:436)
at
org.apache.mina.transport.socket.nio.SocketSessionImpl.write0(SocketSessionImpl
.java:196)
at org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:149)
at org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:135)
at org.jivesoftware.openfire.nio.NIOConnection.deliver(NIOConnection.java:201)
The problem was hard to detect since it was a concurrency problem. Here is a
diff for MINA 1.1.8:
Index:
filter-compression/src/main/java/org/apache/mina/filter/CompressionFilter.java
===
---
filter-compression/src/main/java/org/apache/mina/filter/CompressionFilter.java
(revision 719471)
+++
filter-compression/src/main/java/org/apache/mina/filter/CompressionFilter.java
(working copy)
@@ -188,7 +188,10 @@
// Ignore empty buffers
nextFilter.filterWrite(session, writeRequest);
} else {
-ByteBuffer outBuf = deflater.deflate(inBuffer);
+ByteBuffer outBuf;
+synchronized (deflater) {
+outBuf = deflater.deflate(inBuffer);
+}
inBuffer.release();
nextFilter.filterWrite(session, new WriteRequest(outBuf,
writeRequest.getFuture()));
Hope that helps.
Regards,
-- Gato
