You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Rory Winston <ro...@gmail.com> on 2009/03/01 23:19:25 UTC
Re: FTPClient Stalls on STOR
Hi Meeraj
Currently, FTPClient doesnt support keepalive, but I suspect that it
probably should. I'll raise a JIRA ticket.
Thanks
Rory
On 27 Feb 2009, at 19:29, Meeraj Kunnumpurath wrote:
> Hi,
> The problem is F5 has a timeout set to five minutes. The transfer
> works with
> a native Solaris FTP client, which I think does some kind of keep
> alive.
> Does, FTPClient allow doing some kind of keep alive.
>
> Ta
> Meeraj
>
> On Wed, Feb 25, 2009 at 1:35 PM, sebb <se...@gmail.com> wrote:
>
>> On 25/02/2009, Meeraj Kunnumpurath <mk...@googlemail.com>
>> wrote:
>>> I have narrowed this down further. If the client (FTPClient) and
>>> server
>> are
>>> on the same Solarix box it works and it also works across different
>> Solaris
>>> boxes. However, if I put an F5 load balancer in the middle it
>> consistently
>>> fails on 1.7 Gb.
>>
>> That suggest that F5 may be implicated.
>>
>> Does it fail with OS FTP client and F5 load balancer?
>>
>>> Ta
>>> Meeraj
>>>
>>> On Wed, Feb 25, 2009 at 4:48 AM, Meeraj Kunnumpurath <
>>>
>>> mkunnumpurath@googlemail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> 1. Native Solaris FTP client and Solaris FTP server works
>>>> 2. Commons Net FTPClient on OSX and OSX FTP server works
>>>> 3. Commons Net FTPClient on Solaris and Solaris FTP server doesn't
>> work
>>>>
>>>> Unfortunately, I can't get the OSX client connected to Solaris or
>>>> the
>> other
>>>> way around.
>>>>
>>>> Many thanks
>>>> Meeraj
>>>>
>>>>
>>>> On Wed, Feb 25, 2009 at 4:11 AM, sebb <se...@gmail.com> wrote:
>>>>
>>>>> On 25/02/2009, Meeraj Kunnumpurath <mk...@googlemail.com>
>> wrote:
>>>>>> Just to add some more information, the same code with same
>>>>> configurations
>>>>>> runs fine on OSX.
>>>>>
>>>>> Is that client OSX, server OSX or both?
>>>>>
>>>>> What happens if you run the client on Solaris and the server on
>>>>> OSX?
>>>>>
>>>>> What about another FTP Client (e.g. one that comes with the OS) -
>> does
>>>>> that work OK?
>>>>>
>>>>> The error looks more like a server issue rather than a client
>>>>> issue -
>>>>> perhaps there is a TCP stack configuration problem on the server.
>>>>>
>>>>>>
>>>>>> On Wed, Feb 25, 2009 at 2:22 AM, Meeraj Kunnumpurath <
>>>>>> mkunnumpurath@googlemail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am trying to send a large file (2 gig) to a remote server
>> using
>>>>>>> FTPClient. And the transfer consistently stalls at around 1.7
>> gig and
>>>>> throws
>>>>>>> the below exception subsequently. Interestingly, if I run five
>>>>> concurrent
>>>>>>> threads each with its own instance of FTPClient, all of then
>> hang
>>>>> when the
>>>>>>> cumulative transfer gets to around 1.7 gig. Both my client and
>> server
>>>>> are
>>>>>>> running on Solaris 10 X64 (64 bit AMD Optron). Any pointers
>> would be
>>>>> of
>>>>>>> great help.
>>>>>>> org.osoa.sca.ServiceUnavailableException:
>> java.net.SocketException:
>>>>> Broken
>>>>>>> pipe
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .binding
>> .ftp.runtime.FtpTargetInterceptor.invoke(FtpTargetInterceptor.java:
>> 117)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .proxy.jdk.JDKInvocationHandler.invoke(JDKInvocationHandler.java:168)
>>>>>>>
>>>>>>> at $Proxy30.receiveData(Unknown Source)
>>>>>>> at
>>>>>>>
>>>>>
>> com
>> .voca
>> .bgc
>> .gateway
>> .router.FtpPassThroughRouter.receiveData(FtpPassThroughRouter.java:
>> 45)
>>>>>>>
>>>>>>> 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:585)
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .pojo.component.InvokerInterceptor.invoke(InvokerInterceptor.java:
>> 162)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .pojo.component.InvokerInterceptor.invoke(InvokerInterceptor.java:
>> 130)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .binding.ftp.runtime.BindingFtpLet.onUpload(BindingFtpLet.java:91)
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .ftp
>> .server.handler.StorRequestHandler.transfer(StorRequestHandler.java:
>> 169)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .ftp
>> .server.handler.StorRequestHandler.service(StorRequestHandler.java:
>> 107)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j.ftp.server.host.FtpHandler.messageReceived(FtpHandler.java:99)
>>>>>>> at
>>>>>>>
>>>>>
>> org.apache.mina.core.filterchain.DefaultIoFilterChain
>> $TailFilter.messageReceived(DefaultIoFilterChain.java:722)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .apache
>> .mina
>> .core
>> .filterchain
>> .DefaultIoFilterChain
>> .callNextMessageReceived(DefaultIoFilterChain.java:434)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org.apache.mina.core.filterchain.DefaultIoFilterChain.access
>> $1200(DefaultIoFilterChain.java:48)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl
>> $1.messageReceived(DefaultIoFilterChain.java:802)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org.apache.mina.filter.codec.ProtocolCodecFilter
>> $ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:392)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .apache
>> .mina
>> .filter
>> .codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:
>> 228)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .apache
>> .mina
>> .core
>> .filterchain
>> .DefaultIoFilterChain
>> .callNextMessageReceived(DefaultIoFilterChain.java:434)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org.apache.mina.core.filterchain.DefaultIoFilterChain.access
>> $1200(DefaultIoFilterChain.java:48)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl
>> $1.messageReceived(DefaultIoFilterChain.java:802)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:
>> 59)
>>>>>>> at
>> org.apache.mina.core.session.IoEvent.run(IoEvent.java:64)
>>>>>>> at
>>>>>>>
>>>>>
>> org.sca4j.ftp.server.host.SCA4JExecutorService
>> $1.execute(SCA4JExecutorService.java:47)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j.host.work.DefaultPausableWork.run(DefaultPausableWork.java:
>> 103)
>>>>>>> at
>>>>>>>
>>>>>
>> org.sca4j.threadpool.ThreadPoolWorkScheduler
>> $DecoratingWork.run(ThreadPoolWorkScheduler.java:112)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
>> 417)
>>>>>>> at
>>>>>>>
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
>>>>>>> at
>> java.util.concurrent.FutureTask.run(FutureTask.java:123)
>>>>>>> at
>>>>>>>
>>>>>
>> java.util.concurrent.ThreadPoolExecutor
>> $Worker.runTask(ThreadPoolExecutor.java:650)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> java.util.concurrent.ThreadPoolExecutor
>> $Worker.run(ThreadPoolExecutor.java:675)
>>>>>>>
>>>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>>>> Caused by: java.net.SocketException: Broken pipe
>>>>>>> at java.net.SocketOutputStream.socketWrite0(Native
>> Method)
>>>>>>> at
>>>>>>>
>> java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
>>>>>>> at
>>>>> java.net.SocketOutputStream.write(SocketOutputStream.java:136)
>>>>>>> at
>>>>>>>
>>>>>
>> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:
>> 65)
>>>>>>> at
>>>>> java.io.BufferedOutputStream.write(BufferedOutputStream.java:78)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .apache
>> .commons
>> .net.io.ToNetASCIIOutputStream.write(ToNetASCIIOutputStream.java:80)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .apache
>> .commons
>> .net.io.ToNetASCIIOutputStream.write(ToNetASCIIOutputStream.java:116)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .apache
>> .commons.net.io.SocketOutputStream.write(SocketOutputStream.java:72)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .binding
>> .ftp
>> .runtime.FtpTargetInterceptor.storeFile(FtpTargetInterceptor.java:
>> 207)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .binding
>> .ftp
>> .runtime.FtpTargetInterceptor.transfer(FtpTargetInterceptor.java:164)
>>>>>>>
>>>>>>> at
>>>>>>>
>>>>>
>> org
>> .sca4j
>> .binding
>> .ftp.runtime.FtpTargetInterceptor.invoke(FtpTargetInterceptor.java:
>> 110)
>>>>>>>
>>>>>>> Thanks
>>>>>>> Meeraj
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: user-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: FTPClient Stalls on STOR
Posted by Rory Winston <ro...@gmail.com>.
Yes. The control connection is what is timing out. I've seen other
clients (FileZilla etc) use a timer to send NOOPs over the control
connection periodically.
And Meeraj, yes, I think there may be a potential race condition with
NOOPs being executed whilst another command is currently pending.
On 3 Mar 2009, at 22:14, sebb wrote:
> Aren't there two connections involved here - i.e. the control and data
> connections?
>
> Surely the data connection will be kept alive by the STOR command; the
> NOOP is presumably only needed on the control connection?
>
> I would question whether the F5 load balancer is working correctly if
> it fails to take the data connection traffic into account. But I could
> be wrong.
>
> On 03/03/2009, Meeraj Kunnumpurath <mk...@googlemail.com>
> wrote:
>> Hi,
>>
>> That is what I have done.
>>
>> If I do the STOR and NOOP on two threads, isn't there a possible race
>> condition with the response for STOR and NOOP coming back the same
>> time as
>> they share the same socket?
>> Ta
>>
>> Meeraj
>>
>>
>> On Tue, Mar 3, 2009 at 6:54 PM, Daniel F. Savarese
>> <df...@savarese.org> wrote:
>>
>>>
>>> In message <66...@eircom.net>, Rory
>>> Winston
>>> writ
>>> es:
>>>> Currently, FTPClient doesnt support keepalive, but I suspect that
>>>> it
>>>> probably should. I'll raise a JIRA ticket.
>>>
>>> There's nothing stopping the programmer fromn sending a NOOP every
>>> t seconds over the control connection. However, if one expects
>>> FTPClient to do it automatically, then, sure, it doesn't support it.
>>>
>>> daniel
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: FTPClient Stalls on STOR
Posted by sebb <se...@gmail.com>.
Aren't there two connections involved here - i.e. the control and data
connections?
Surely the data connection will be kept alive by the STOR command; the
NOOP is presumably only needed on the control connection?
I would question whether the F5 load balancer is working correctly if
it fails to take the data connection traffic into account. But I could
be wrong.
On 03/03/2009, Meeraj Kunnumpurath <mk...@googlemail.com> wrote:
> Hi,
>
> That is what I have done.
>
> If I do the STOR and NOOP on two threads, isn't there a possible race
> condition with the response for STOR and NOOP coming back the same time as
> they share the same socket?
> Ta
>
> Meeraj
>
>
> On Tue, Mar 3, 2009 at 6:54 PM, Daniel F. Savarese <df...@savarese.org> wrote:
>
> >
> > In message <66...@eircom.net>, Rory Winston
> > writ
> > es:
> > >Currently, FTPClient doesnt support keepalive, but I suspect that it
> > >probably should. I'll raise a JIRA ticket.
> >
> > There's nothing stopping the programmer fromn sending a NOOP every
> > t seconds over the control connection. However, if one expects
> > FTPClient to do it automatically, then, sure, it doesn't support it.
> >
> > daniel
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: FTPClient Stalls on STOR
Posted by Meeraj Kunnumpurath <mk...@googlemail.com>.
Hi,
That is what I have done.
If I do the STOR and NOOP on two threads, isn't there a possible race
condition with the response for STOR and NOOP coming back the same time as
they share the same socket?
Ta
Meeraj
On Tue, Mar 3, 2009 at 6:54 PM, Daniel F. Savarese <df...@savarese.org> wrote:
>
> In message <66...@eircom.net>, Rory Winston
> writ
> es:
> >Currently, FTPClient doesnt support keepalive, but I suspect that it
> >probably should. I'll raise a JIRA ticket.
>
> There's nothing stopping the programmer fromn sending a NOOP every
> t seconds over the control connection. However, if one expects
> FTPClient to do it automatically, then, sure, it doesn't support it.
>
> daniel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>