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 Mark Proctor <li...@markproctor.com> on 2006/12/17 00:40:26 UTC
ftpserver and ssl
Whats the status on out of the box SFTP - is it 100%? assuming clients
can only upload, is it acceptable for that?
Mark
Re: ftpserver and ssl
Posted by Mark Proctor <li...@markproctor.com>.
Don't think I need JMS, at this stage, I was just going to use jakarta
pipeline to get the files processed. But JMS for the future would be
useful.
Mark
Niklas Gustavsson wrote:
> Mark Proctor wrote:
>> Up to 20 simultaneous connections, a hundred or so connections a day
>> and several hundred megabytes of data a day - mostly pdf and xml
>> files. This isn't that extreme, just want to make sure I don't make a
>> choice I regret, if I hook up apache ftp. The reason why I want to
>> use java, over proftpd, is the service is "put" only, once the files
>> are delivered they are moved elsewhere for processing - at the moment
>> it scans the disk for file additions, figured a messaging based
>> solution would be more robust.
>
> I think that the number of concurrent connections will be your first
> limiting factor. However, I have used the perf-test module to test 100
> concurrent connections (three different test scenarios: noop, retrive
> and store) on my laptop without any issues.
>
> But, I would note that FtpServer has not yet been heavily tested nor
> optimized for performance or scalability. But of course we're happy to
> work with you if you run into any troubles!
>
> If you with "messaging based solution" mean JMS support you might be
> in luck. I got a JMS backed file system implementation on my todo
> list. If you would like to work with me on this I would be happy to :-)
>
> /niklas
>
>
Re: test failure in trunk
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Mark Proctor wrote:
> fixed!!! You have the global static variable that is being set by one
> test setUp, this is then set incorrectly for all tests. For now I added
> a setUp to FtpLetContainerTestTemplate:
> protected void setUp() throws Exception {
> MockFtplet.callback = new MockFtpletCallBack();
> MockFtplet.callback.returnValue = FtpletEnum.RET_DEFAULT;
> }
Thanks, patch applied at rev 488161.
> However this seems rather fragile, so hopefully someone can refactor
> this unit test to make it more robust.
The funny callback construction exists so that it's possible to run some
other tests where the ftplet is setup using the properties
configuration. I will likely change these tests soon as one can soon
(haven't commited all the changes yet) set up the Ftplet from Java instead.
/niklas
Re: test failure in trunk
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Mark Proctor wrote:
> admin-gui fails because you have a test directory but no tests - so
> either remove the directory or add tests.
How are you running the tests to make them fail? I run them from mvn
from the project root, mvn directly under admin-gui and from Eclipse
without failure. Might be that you have an old version of Maven or of
the Surefire plugin. What Maven version are you using and could you try
running it with mvn -U to make sure it updates the plugins?
Anyways, I'll remove the directly as we don't need it :-)
/niklas
Re: test failure in trunk
Posted by Mark Proctor <li...@markproctor.com>.
admin-gui fails because you have a test directory but no tests - so
either remove the directory or add tests.
Mark
Mark Proctor wrote:
> fixed!!! You have the global static variable that is being set by one
> test setUp, this is then set incorrectly for all tests. For now I
> added a setUp to FtpLetContainerTestTemplate:
> protected void setUp() throws Exception {
> MockFtplet.callback = new MockFtpletCallBack();
> MockFtplet.callback.returnValue = FtpletEnum.RET_DEFAULT;
> }
>
> However this seems rather fragile, so hopefully someone can refactor
> this unit test to make it more robust.
>
> Mark
>
> Mark Proctor wrote:
>> I'm looking into the code it seems that the setUp() is not always
>> working, there it references a public static value and sets it to
>> FtpletEnum.RET_DEFAULT, however when I'm debugging the code, on the
>> times it doesn't work, its switched too RET_SKIP which causes the
>> array iterator to exit after the first FtpLet execution. Sorry for
>> the running commentry, wasn't expecting to debug this, anyway I'll
>> keep looking.
>>
>> Mark.
>> Mark Proctor wrote:
>>> I tried again this time all the tests in the package
>>> org.apache.ftpserver.ftplet this time only testOnLogin failed. But
>>> its the same thing:
>>> assertEquals( 2, calls.size() )
>>> Its expecting 2, but getting one. Is there a quick fix to
>>> stabalise this?
>>>
>>> Mark
>>> Mark Proctor wrote:
>>>> The test fails when running in both Eclipse and Maven. However if I
>>>> run the class
>>>> org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest on its own,
>>>> and not as part of a set of tests, then it passes.
>>>>
>>>> Mark
>>>> Mark Proctor wrote:
>>>>> I'm just trying trunk and there is a test failure:
>>>>> org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest
>>>>> testOnUploadUniqueEnd(.....)
>>>>> AssertionFailed: expected:<2> but was:<1>
>>>>>
>>>>> Is trunk stable, or is there another recent release I should be
>>>>> using?
>>>>>
>>>>> Mark
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: test failure in trunk
Posted by Mark Proctor <li...@markproctor.com>.
fixed!!! You have the global static variable that is being set by one
test setUp, this is then set incorrectly for all tests. For now I added
a setUp to FtpLetContainerTestTemplate:
protected void setUp() throws Exception {
MockFtplet.callback = new MockFtpletCallBack();
MockFtplet.callback.returnValue = FtpletEnum.RET_DEFAULT;
}
However this seems rather fragile, so hopefully someone can refactor
this unit test to make it more robust.
Mark
Mark Proctor wrote:
> I'm looking into the code it seems that the setUp() is not always
> working, there it references a public static value and sets it to
> FtpletEnum.RET_DEFAULT, however when I'm debugging the code, on the
> times it doesn't work, its switched too RET_SKIP which causes the
> array iterator to exit after the first FtpLet execution. Sorry for the
> running commentry, wasn't expecting to debug this, anyway I'll keep
> looking.
>
> Mark.
> Mark Proctor wrote:
>> I tried again this time all the tests in the package
>> org.apache.ftpserver.ftplet this time only testOnLogin failed. But
>> its the same thing:
>> assertEquals( 2, calls.size() )
>> Its expecting 2, but getting one. Is there a quick fix to stabalise
>> this?
>>
>> Mark
>> Mark Proctor wrote:
>>> The test fails when running in both Eclipse and Maven. However if I
>>> run the class org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest
>>> on its own, and not as part of a set of tests, then it passes.
>>>
>>> Mark
>>> Mark Proctor wrote:
>>>> I'm just trying trunk and there is a test failure:
>>>> org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest
>>>> testOnUploadUniqueEnd(.....)
>>>> AssertionFailed: expected:<2> but was:<1>
>>>>
>>>> Is trunk stable, or is there another recent release I should be using?
>>>>
>>>> Mark
>>>>
>>>
>>>
>>
>>
>
>
Re: test failure in trunk
Posted by Mark Proctor <li...@markproctor.com>.
I'm looking into the code it seems that the setUp() is not always
working, there it references a public static value and sets it to
FtpletEnum.RET_DEFAULT, however when I'm debugging the code, on the
times it doesn't work, its switched too RET_SKIP which causes the array
iterator to exit after the first FtpLet execution. Sorry for the
running commentry, wasn't expecting to debug this, anyway I'll keep
looking.
Mark.
Mark Proctor wrote:
> I tried again this time all the tests in the package
> org.apache.ftpserver.ftplet this time only testOnLogin failed. But
> its the same thing:
> assertEquals( 2, calls.size() )
> Its expecting 2, but getting one. Is there a quick fix to stabalise
> this?
>
> Mark
> Mark Proctor wrote:
>> The test fails when running in both Eclipse and Maven. However if I
>> run the class org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest
>> on its own, and not as part of a set of tests, then it passes.
>>
>> Mark
>> Mark Proctor wrote:
>>> I'm just trying trunk and there is a test failure:
>>> org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest
>>> testOnUploadUniqueEnd(.....)
>>> AssertionFailed: expected:<2> but was:<1>
>>>
>>> Is trunk stable, or is there another recent release I should be using?
>>>
>>> Mark
>>>
>>
>>
>
>
Re: test failure in trunk
Posted by Mark Proctor <li...@markproctor.com>.
I tried again this time all the tests in the package
org.apache.ftpserver.ftplet this time only testOnLogin failed. But its
the same thing:
assertEquals( 2, calls.size() )
Its expecting 2, but getting one. Is there a quick fix to stabalise this?
Mark
Mark Proctor wrote:
> The test fails when running in both Eclipse and Maven. However if I
> run the class org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest
> on its own, and not as part of a set of tests, then it passes.
>
> Mark
> Mark Proctor wrote:
>> I'm just trying trunk and there is a test failure:
>> org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest
>> testOnUploadUniqueEnd(.....)
>> AssertionFailed: expected:<2> but was:<1>
>>
>> Is trunk stable, or is there another recent release I should be using?
>>
>> Mark
>>
>
>
Re: test failure in trunk
Posted by Mark Proctor <li...@markproctor.com>.
The test fails when running in both Eclipse and Maven. However if I run
the class org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest on its
own, and not as part of a set of tests, then it passes.
Mark
Mark Proctor wrote:
> I'm just trying trunk and there is a test failure:
> org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest
> testOnUploadUniqueEnd(.....)
> AssertionFailed: expected:<2> but was:<1>
>
> Is trunk stable, or is there another recent release I should be using?
>
> Mark
>
test failure in trunk
Posted by Mark Proctor <li...@markproctor.com>.
I'm just trying trunk and there is a test failure:
org.apache.ftpserver.ftplet.DefaultFtpLetContainerTest
testOnUploadUniqueEnd(.....)
AssertionFailed: expected:<2> but was:<1>
Is trunk stable, or is there another recent release I should be using?
Mark
Re: ftpserver and ssl
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Mark Proctor wrote:
> Up to 20 simultaneous connections, a hundred or so connections a day
> and several hundred megabytes of data a day - mostly pdf and xml files.
> This isn't that extreme, just want to make sure I don't make a choice I
> regret, if I hook up apache ftp. The reason why I want to use java, over
> proftpd, is the service is "put" only, once the files are delivered
> they are moved elsewhere for processing - at the moment it scans the
> disk for file additions, figured a messaging based solution would be
> more robust.
I think that the number of concurrent connections will be your first
limiting factor. However, I have used the perf-test module to test 100
concurrent connections (three different test scenarios: noop, retrive
and store) on my laptop without any issues.
But, I would note that FtpServer has not yet been heavily tested nor
optimized for performance or scalability. But of course we're happy to
work with you if you run into any troubles!
If you with "messaging based solution" mean JMS support you might be in
luck. I got a JMS backed file system implementation on my todo list. If
you would like to work with me on this I would be happy to :-)
/niklas
Re: ftpserver and ssl
Posted by Mark Proctor <li...@markproctor.com>.
Up to 20 simultaneous connections, a hundred or so connections a day
and several hundred megabytes of data a day - mostly pdf and xml files.
This isn't that extreme, just want to make sure I don't make a choice I
regret, if I hook up apache ftp. The reason why I want to use java, over
proftpd, is the service is "put" only, once the files are delivered
they are moved elsewhere for processing - at the moment it scans the
disk for file additions, figured a messaging based solution would be
more robust.
Mark
Niklas Gustavsson wrote:
> Mark Proctor wrote:
>> sorry not SFTP, I meant just ssl - SFTP is a SSH server subsystem, I
>> guess thats out of scope for the apache FTP project.
>>
>> Also what's the stability and scalability like, compared to say proftpd?
>>
>> Mark
>> Mark Proctor wrote:
>>> Whats the status on out of the box SFTP - is it 100%? assuming
>>> clients can only upload, is it acceptable for that?
>
> It should be 100% for all operations (e.g. upload, download, list).
> Please tell me if that's not true because that's a bug then :-)
>
> We should also support both explicit and implicit SSL (as instructed
> by the client with AUTH or by having an SSL socket to start with) as
> well as security of the data channel (via PROT).
>
> When it comes to performance and scalability I'm not sure. Since
> protftp has been around for so long and got so much usage, while we
> haven't (as far as I know) spent so much time on performance, my bet
> would be on protftp for now.
>
> As just discussed on this list, I'm looking into moving us onto MINA.
> MINA seems to have great performance numbers so I'm hoping that should
> help us a long way.
>
> Do you have any specific numbers in mind as for performance and
> scalability? Might be worth testing with our perf-test module.
>
> /niklas
>
>
Re: ftpserver and ssl
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Mark Proctor wrote:
> sorry not SFTP, I meant just ssl - SFTP is a SSH server subsystem, I
> guess thats out of scope for the apache FTP project.
>
> Also what's the stability and scalability like, compared to say proftpd?
>
> Mark
> Mark Proctor wrote:
>> Whats the status on out of the box SFTP - is it 100%? assuming clients
>> can only upload, is it acceptable for that?
It should be 100% for all operations (e.g. upload, download, list).
Please tell me if that's not true because that's a bug then :-)
We should also support both explicit and implicit SSL (as instructed by
the client with AUTH or by having an SSL socket to start with) as well
as security of the data channel (via PROT).
When it comes to performance and scalability I'm not sure. Since protftp
has been around for so long and got so much usage, while we haven't
(as far as I know) spent so much time on performance, my bet would be on
protftp for now.
As just discussed on this list, I'm looking into moving us onto MINA.
MINA seems to have great performance numbers so I'm hoping that should
help us a long way.
Do you have any specific numbers in mind as for performance and
scalability? Might be worth testing with our perf-test module.
/niklas
Re: ftpserver and ssl
Posted by Mark Proctor <li...@markproctor.com>.
sorry not SFTP, I meant just ssl - SFTP is a SSH server subsystem, I
guess thats out of scope for the apache FTP project.
Also what's the stability and scalability like, compared to say proftpd?
Mark
Mark Proctor wrote:
> Whats the status on out of the box SFTP - is it 100%? assuming clients
> can only upload, is it acceptable for that?
>
> Mark
>