You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ftpserver-dev@incubator.apache.org by Peter Kostouros <kp...@melbpc.org.au> on 2007/08/26 03:52:24 UTC

DefaultMaxLoginTest and CustomMaxLoginTest failing on Linux

Hi

DefaultMaxLoginTest and CustomMaxLoginTest are failing on a Unix/Linux 
environment: SocketExceptions are raised whereas 
FTPConnectionClosedExceptions are expected.

FTPConnectionClosedException documentation mentions that such exceptions 
are raised when an FTPReply.SERVICE_NOT_AVAILABLE|| 
<http://commons.apache.org/net/apidocs/org/apache/commons/net/ftp/FTPReply.html#SERVICE_NOT_AVAILABLE>| 
|response (421) is received to a failed FTP command. I have not noticed 
this error under a Windows environment.

Here is the surefire report for DefaultMaxLoginTest.

-------------------------------------------------------------------------------
Test set: org.apache.ftpserver.clienttests.DefaultMaxLoginTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.693 
sec <<< FAILURE!
testLogin(org.apache.ftpserver.clienttests.DefaultMaxLoginTest)  Time 
elapsed: 1.686 sec  <<< ERROR!
java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(SocketInputStream.java:168)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
    at java.io.FilterInputStream.read(FilterInputStream.java:66)
    at java.io.PushbackInputStream.read(PushbackInputStream.java:122)
    at 
org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75)
    at 
org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
    at 
org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114)
    at 
org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535)
    at java.lang.Thread.run(Thread.java:619)
    at java.lang.Thread.run(Thread.java:619)

-- 

Regards

Peter

As always the organisation disavows knowledge of this email


Re: DefaultMaxLoginTest and CustomMaxLoginTest failing on Linux

Posted by Niklas Gustavsson <ni...@protocol7.com>.
Peter Kostouros wrote:
> Is it worthwhile adding SocketException catch clauses to tests expecting 
> FTPConnectionClosedException exceptions? or is something else going on 
> that should not?

I'm not sure. I'm assuming the IP stack implementation (Linux vs Windows 
in this case) can have different views on whether a socket is connected 
or not. Adding a check for SocketException would probably not be a bad idea.

/niklas


Re: DefaultMaxLoginTest and CustomMaxLoginTest failing on Linux

Posted by Peter Kostouros <kp...@melbpc.org.au>.
Hi

I had a look at the commons ftp code and the following snippet may help 
us understand what is going on:

/***
     * Sends an FTP command to the server, waits for a reply and returns the
     * numerical response code.  After invocation, for more detailed
     * information, the actual reply text can be accessed by calling
     * {@link #getReplyString  getReplyString } or
     * {@link #getReplyStrings  getReplyStrings }.
     * <p>
     * @param command  The text representation of the  FTP command to send.
     * @param args The arguments to the FTP command.  If this parameter is
     *             set to null, then the command is sent with no argument.
     * @return The integer value of the FTP reply code returned by the 
server
     *         in response to the command.
     * @exception FTPConnectionClosedException
     *      If the FTP server prematurely closes the connection as a result
     *      of the client being idle or some other reason causing the server
     *      to send FTP reply code 421.  This exception may be caught either
     *      as an IOException or independently as itself.
     * @exception IOException  If an I/O error occurs while either 
sending the
     *      command or receiving the server reply.
     ***/
    public int sendCommand(String command, String args) throws IOException
    {
        String message;

        __commandBuffer.setLength(0);
        __commandBuffer.append(command);

        if (args != null)
        {
            __commandBuffer.append(' ');
            __commandBuffer.append(args);
        }
        __commandBuffer.append(SocketClient.NETASCII_EOL);

        try{
        _controlOutput.write(message = __commandBuffer.toString());
        _controlOutput.flush();
        }
        catch (SocketException e)
        {
            if (!isConnected() || !socketIsConnected(_socket_))  <<<<<<<<<<
            {
                throw new FTPConnectionClosedException("Connection 
unexpectedly closed.");
            }
            else
            {
                throw e;
            }
        }
   

        if (_commandSupport_.getListenerCount() > 0)
            _commandSupport_.fireCommandSent(command, message);

        __getReply();
        return _replyCode;
    }


Is it worthwhile adding SocketException catch clauses to tests expecting 
FTPConnectionClosedException exceptions? or is something else going on 
that should not?


Niklas Gustavsson wrote:
> Hi
>
> I've commited a change for this. Not really sure what causes the 
> problem but the test now allows for a SocketException as well.
>
> Keep on reporting!
>
> /niklas
>
> Peter Kostouros wrote:
>> Hi
>>
>> DefaultMaxLoginTest and CustomMaxLoginTest are failing on a 
>> Unix/Linux environment: SocketExceptions are raised whereas 
>> FTPConnectionClosedExceptions are expected.
>>
>> FTPConnectionClosedException documentation mentions that such 
>> exceptions are raised when an FTPReply.SERVICE_NOT_AVAILABLE|| 
>> <http://commons.apache.org/net/apidocs/org/apache/commons/net/ftp/FTPReply.html#SERVICE_NOT_AVAILABLE>| 
>> |response (421) is received to a failed FTP command. I have not 
>> noticed this error under a Windows environment.
>>
>> Here is the surefire report for DefaultMaxLoginTest.
>>
>> ------------------------------------------------------------------------------- 
>>
>> Test set: org.apache.ftpserver.clienttests.DefaultMaxLoginTest
>> ------------------------------------------------------------------------------- 
>>
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.693 
>> sec <<< FAILURE!
>> testLogin(org.apache.ftpserver.clienttests.DefaultMaxLoginTest)  Time 
>> elapsed: 1.686 sec  <<< ERROR!
>> java.net.SocketException: Connection reset


-- 

Regards

Peter

As always the organisation disavows knowledge of this email


Re: DefaultMaxLoginTest and CustomMaxLoginTest failing on Linux

Posted by Niklas Gustavsson <ni...@protocol7.com>.
Hi

I've commited a change for this. Not really sure what causes the problem 
but the test now allows for a SocketException as well.

Keep on reporting!

/niklas

Peter Kostouros wrote:
> Hi
> 
> DefaultMaxLoginTest and CustomMaxLoginTest are failing on a Unix/Linux 
> environment: SocketExceptions are raised whereas 
> FTPConnectionClosedExceptions are expected.
> 
> FTPConnectionClosedException documentation mentions that such exceptions 
> are raised when an FTPReply.SERVICE_NOT_AVAILABLE|| 
> <http://commons.apache.org/net/apidocs/org/apache/commons/net/ftp/FTPReply.html#SERVICE_NOT_AVAILABLE>| 
> |response (421) is received to a failed FTP command. I have not noticed 
> this error under a Windows environment.
> 
> Here is the surefire report for DefaultMaxLoginTest.
> 
> ------------------------------------------------------------------------------- 
> 
> Test set: org.apache.ftpserver.clienttests.DefaultMaxLoginTest
> ------------------------------------------------------------------------------- 
> 
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.693 
> sec <<< FAILURE!
> testLogin(org.apache.ftpserver.clienttests.DefaultMaxLoginTest)  Time 
> elapsed: 1.686 sec  <<< ERROR!
> java.net.SocketException: Connection reset
>    at java.net.SocketInputStream.read(SocketInputStream.java:168)
>    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>    at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
>    at java.io.FilterInputStream.read(FilterInputStream.java:66)
>    at java.io.PushbackInputStream.read(PushbackInputStream.java:122)
>    at 
> org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75) 
> 
>    at 
> org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170) 
> 
>    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>    at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
>    at 
> org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114) 
> 
>    at 
> org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535) 
> 
>    at java.lang.Thread.run(Thread.java:619)
>    at java.lang.Thread.run(Thread.java:619)
>