Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

client side ftp stuck in CLOSE_WAIT state if

Roger P
2012-08-29
2012-09-21
  • Roger P
    Roger P
    2012-08-29

    Hi, All:

    Thanks to JUpload. My applet, which use ftp to upload file, needs to do some
    work on the file uploaded, and I have defined my own uploadpolicy and override
    the afterupload() processing.

    Somehow I found that, in my added code in afterupload() - which use apache
    http client to do some post, and might throw network IOException - throws
    IOExceptions and I caught it to do some handling ... the client side, when
    using netstat -t, will show there's still an ftp socket in CLOSE_WAIT state.
    If I make the exception case happens 5 times, I can see client side 5 ftp
    connection which are all in CLOSE_WAIT state to stay for > 10 hours. The
    server side netstat -t output does not have ftp connection shown while above
    case happens.

    The client side is in ubuntu running firefox, using JDK 1.6.0_21. Not sure
    about windows's client applet behavior.

    Further digging I found that the new FileUploadManagerThreadImpl thread will
    be launched while uploading, and I'm able to get that thread from my
    uploadpolicy, getting JUploadConcext, then get JUploadPanel, then
    getFileUploadManagerThread() to get that thread, but I'm not sure if it's a
    good idea to do anything to it, like to call .stop() (which is not recommended
    to do on a thread).

    If close the user browser tab, the above ftp connection which is in CLOSE_WAIT
    will be gone. But I can't bet on that and don't want to see lots of CLOSE_WAIT
    ftp connection on the client side, even the ftp is finished and exception is
    somewhere else ...

    Thanks in advance for any hint ! ....

    Roger

     
  • Hi,

    My opinion is that you didn't catch the Exception : you need to properly close
    the opened connections, even when receiving an exception. Typically, the java
    key work 'finally' is your friend here.

    Hope this helps.

    BTW : The applet has some technical documentation. But it's hardly accessible.

    I just did an update of the JUpload web site.

    The following link is now available from the main menu (how upload works) :
    http://jupload.sourceforge.net/apidocs/wjhk/jupload2/upload/package-
    summary.html

    Etienne

     
  • Roger P
    Roger P
    2012-09-11

    Hi, Etienne:

    Thanks for the reply. To illustrate the case of my exception handling, here
    are short code snippet of my UploadPolicy file, which extends
    DefaultUploadPolicy:

    ....
    @Override
    public void afterUpload(Exception e, String serverOutput) throws
    JUploadException {
    super.afterUpload(e, serverOutput);
    displayDebug("\nin afterUpload():\n" + serverOutput, 1);
    .....
    ....
    try {
    // use Apache Common HttpClient to call some other web services to process on
    this file
    // which might throw IOException ...
    DefaultHttpClient httpclient = new DefaultHttpClient(httpParams);
    ...
    ...
    } catch (EncoderException e1) {
    e1.printStackTrace();
    } catch (ClientProtocolException e1) {
    e1.printStackTrace();
    } catch (IOException e1) {
    e1.printStackTrace();
    this.jlbpp.setText("Connection error: " + e1.getMessage());
    JOptionPane.showMessageDialog(this.gui_container, "Connection error: " +
    e1.getMessage() + " , please close this applet and try again !", "Warning",
    JOptionPane.WARNING_MESSAGE);

    // *****
    // here is where my question is: when IOException happens here, client side
    has CLOSE_WAIT socket open
    // I tried to get the thread of FileUploadManagerThreadImpl here and call the
    stop() of it,
    // but doesn't seem to release the connection, client side sill shows socket
    is CLOSE_WAIT in netstat -t
    // to make this exception happen, just kill the tomcat which serve this applet
    from a jsp page ...
    // if I do it three times, I got 3 CLOSE_WAIT left in client side, waited more
    than 10 hours and they're still sitting there ...
    // and if I close the applet page, all 3 CLOSE_WAIT socket will be cleared ...
    // *****

    } finally {
    httpclient.getConnectionManager().shutdown();
    }

    }

     
  • If I read correctly :
    1) Your code hav both HTTP and FTP connections (as the FTP ones get in the
    CLOSE_WAIT status)
    2) When IOException occurs, you close the HTTP connection,

    ... not the FTP one.

    Correct ?

    Etienne

     
  • Roger P
    Roger P
    2012-09-13

    That's exactly my question. How do I close that ftp connection ? ...

    My FTP connection is defined in the "postURL" param using
    "ftp://<ftp_server>/path" of the applet loading page. My UploadPolicy only
    handle beforeUpload() and afterUpload(), and use default behavior to take care
    of ftp part. I have HTTP connection established in my afterUpload, which I
    close in the finally() block.

    Any hint to get that ftp connection from client side ? ... if I can get to it,
    I definitely can close that. Thanks !

    Roger

     
  • Roger P
    Roger P
    2012-09-14

    Hi, Etienne:

    Could this be browser specific ? ... I mean the browser which launched the JVM
    to run applet ? ... My client is using FireFox on CentOS 5.5. For now I can
    simply add a JOptionPane.showMessageDialog() to prompt user to close that
    page.

    I further checked and saw the ftp connection is closed in the cleanAll() of
    class FileUploadThreadFTP. In my case of exception, it never gets to run the
    cleanAll(), where I should expect to see some debug message like: " Not
    connected".

    00115 11:47:12.343 FileUploadThreadFTP thread in UploadFileData.uploadFile
    (amount:2670702, getUploadLength(): 2670702)
    00116 11:47:12.559 FileUploadThreadFTP thread HTTP status:
    00117 11:47:12.575 FileUploadThreadFTP thread After do upload
    00118 11:47:12.575 FileUploadThreadFTP thread End of the FileUploadThread
    00119 11:47:12.577 FileUploadManagerThreadImpl thread Upload finished
    normally. 1 file(s) uploaded in 0 seconds. Average upload speed: 8505
    (kbytes/s)
    00120 11:47:12.578 FileUploadManagerThreadImpl thread
    00120 11:47:12.578 FileUploadManagerThreadImpl thread in afterUpload():
    00121 11:47:12.582 FileUploadManagerThreadImpl thread executing request http:
    //xxx.xx.xx.xx/userupload/ImageUpload?IMAGE_NAME=xxxxxxxxxxx.........

    00122 11:47:12.582 FileUploadManagerThreadImpl thread
    00122 11:47:12.582 FileUploadManagerThreadImpl thread response from server
    side:
    00123 11:48:14.202 FileUploadManagerThreadImpl thread End of the
    FileUploadManagerThreadImpl

    What I can think of now is the place above where I handle the exception, from
    my uploadPolicy, getting JUploadConcext, then get JUploadPanel, then
    getFileUploadManagerThread(), then get the fileUploadThread (where the
    FileUploadThreadFTP is the impl class), then somehow call cleanAll() or
    disconnect of it ? ....

    Roger

     
  • Hi,

    Ok, I re-read the extract you gave, based on the actual DefaultUploadPolicy
    code.

    It seems like the resources are not properly clean in DefaultFileUploadThread,
    when an error occurs in UploadPolicy.afterUpload().

    I just commited a new version of DefaultFileUploadThread. You can get by
    browsing the SVN, or by checking it out.

    Can you give it a try, and confirm if it works for you or not?

    Etienne

     
  • Roger P
    Roger P
    2012-09-18

    Hi, Etienne:

    It works ! ... Thanks, after adding the cleanAll() call in the finally() block
    of run() in DefaultFileUploadThread, the ftp connection is closed and no
    longer shows CLOSE_WAIT. Rev 1645 is good and verified closed the ftp socket
    when exception happens ...

    Thanks again, case closed !

    Roger