file.exists() timeout?

Discussion in 'Java' started by Gilbert Ostlethwaite, Jan 25, 2007.

  1. Hi

    Windows 2003 Server, JDK 1.5.0_09

    I have a servlet that is trying to access a .jpg file located on
    another server. The servlet builds a file object and uses the .exists()
    method to check that its got a valid path/filename and then constructs
    a FileInputStream to read the data. Although I know its got a valid UNC
    path exists() returns false. I've even tried mounting the remote
    directory to the server and hardcoding the path, but still no joy.

    Removing the exists() test and opening the FileInputStream also fails
    to return the data

    Because of some routing issues (yet to be resolved) the connection to
    the remote server is extremely slow. the same servlet running on a
    server on a different segment of the network with a better connection
    speed works as expected, so I was wondering if there's a timeout issue
    with accessing remote files and, if so, how do I change this.

    Is there any other reason why file.exists() would fail to find a file
    that Windows can find?

    Regards
    Roger
     
    Gilbert Ostlethwaite, Jan 25, 2007
    #1
    1. Advertising

  2. On Jan 26, 3:41 am, "Gilbert Ostlethwaite"
    <> wrote:
    ...
    > I have a servlet that is trying to access a .jpg file located on
    > another server. ..

    (snip)

    Can you produce an URL for that JPG?
    (I do not quite get all this talk about files.)

    Andrew T.
     
    Andrew Thompson, Jan 25, 2007
    #2
    1. Advertising

  3. Gilbert Ostlethwaite wrote:

    > Is there any other reason why file.exists() would fail to find a file
    > that Windows can find?


    E.g. the Java-process is running with a different user than
    the one you use for testing. Happens very often when installing
    a java application as service. By default this service is
    installed as "local user" so the user is not allowed to access
    ressources like a SMB-share.

    AFAIK the exists-method of java.io.File is just doing a native
    call and without looking into the C-sources I assume that it's
    just calling the corresponding Windows-API-call.


    Regards, Lothar
    --
    Lothar Kimmeringer E-Mail:
    PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

    Always remember: The answer is forty-two, there can only be wrong
    questions!
     
    Lothar Kimmeringer, Jan 25, 2007
    #3
  4. Gilbert Ostlethwaite

    Oliver Wong Guest

    "Andrew Thompson" <> wrote in message
    news:...
    > On Jan 26, 3:41 am, "Gilbert Ostlethwaite"
    > <> wrote:
    > ..
    >> I have a servlet that is trying to access a .jpg file located on
    >> another server. ..

    > (snip)
    >
    > Can you produce an URL for that JPG?
    > (I do not quite get all this talk about files.)


    I don't think the problem has anything to do with the contents of the
    file being accessed. Windows allows you to specify filenames that refer to
    files that exists on remote machines on a LAN (e.g. instead of
    "C:\myDirectory\myFile.txt", you could use
    \\remoteComputerName\remoteDirectory\remoteFile.txt) and the OS is supposed
    to abstract any special handling that remote file access might have in
    comparison to local file handling (i.e. as a programmer, you don't need to
    make your Windows programming "network aware" -- as long as you use MS's
    file handling API, it's all support automatically for you).

    I'm a bit fuzzy about this part of the OP's probelm description, but it
    sounds like the computer the Java application is running on can access the
    file just fine (when using Windows Explorer, for example), but the Java
    application itself is unable to access the file, and the OP suspects the
    problem might have something to do with timing-out, as the LAN connection is
    apparently very slow.

    - Oliver
     
    Oliver Wong, Jan 25, 2007
    #4
  5. Gilbert Ostlethwaite

    Real Gagnon Guest


    > Is there any other reason why file.exists() would fail to find a file
    > that Windows can find?


    Maybe the "\" are not escaped to "\\".

    ex. "\\server\dir\file" to "\\\\server\\dir\\file"

    Bye.
    --
    Real Gagnon from Quebec, Canada
    * Looking for Java or PB code examples ? Visit Real's How-to
    * http://www.rgagnon.com/howto.html
     
    Real Gagnon, Jan 25, 2007
    #5

  6. > > Is there any other reason why file.exists() would fail to find a file
    > > that Windows can find?E.g. the Java-process is running with a different user than

    > the one you use for testing. Happens very often when installing
    > a java application as service. By default this service is
    > installed as "local user" so the user is not allowed to access
    > ressources like a SMB-share.
    >
    > AFAIK the exists-method of java.io.File is just doing a native
    > call and without looking into the C-sources I assume that it's
    > just calling the corresponding Windows-API-call.
    >


    There may be something in this. Further testing shows that my servlet
    can create and read a File() object, when the physical file is located
    on the same physical server that the servlet is running on. However, if
    the file is located on a different server then my servlet cannot read
    the file regardless whether I use a UNC path or mount the remote drive
    directly via Windows Explorer.

    This is using Suns JDK 1.5.0_09 on a Windows 2003 SP1 server. The file
    that I'm trying to read is also on a Windows 2003 SP1 server. If I drop
    back to Suns JDK 1.4.2_13 then everything works as expected.


    Regards
    Roger
     
    Gilbert Ostlethwaite, Jan 26, 2007
    #6
  7. On 25 Jan, 17:56, "Andrew Thompson" <> wrote:
    > On Jan 26, 3:41 am, "Gilbert Ostlethwaite"<> wrote:..> I have a servlet that is trying to access a .jpg file located on
    > > another server. ..(snip)

    >
    > Can you produce an URL for that JPG?
    > (I do not quite get all this talk about files.)
    >


    The servlet on server A is acting like a proxy by reading a File()
    object that points to a .jpg file located on Server B and sending the
    contents of the FileInputStream() to the client.

    Regards
    Roger
     
    Gilbert Ostlethwaite, Jan 26, 2007
    #7
  8. Gilbert Ostlethwaite

    Oliver Wong Guest

    "Gilbert Ostlethwaite" <> wrote in message
    news:...
    >
    >> > Is there any other reason why file.exists() would fail to find a file
    >> > that Windows can find?E.g. the Java-process is running with a different
    >> > user than

    >> the one you use for testing. Happens very often when installing
    >> a java application as service. By default this service is
    >> installed as "local user" so the user is not allowed to access
    >> ressources like a SMB-share.
    >>
    >> AFAIK the exists-method of java.io.File is just doing a native
    >> call and without looking into the C-sources I assume that it's
    >> just calling the corresponding Windows-API-call.
    >>

    >
    > There may be something in this. Further testing shows that my servlet
    > can create and read a File() object, when the physical file is located
    > on the same physical server that the servlet is running on. However, if
    > the file is located on a different server then my servlet cannot read
    > the file regardless whether I use a UNC path or mount the remote drive
    > directly via Windows Explorer.
    >
    > This is using Suns JDK 1.5.0_09 on a Windows 2003 SP1 server. The file
    > that I'm trying to read is also on a Windows 2003 SP1 server. If I drop
    > back to Suns JDK 1.4.2_13 then everything works as expected.


    Try producing an SSCCE that demonstrates the problem (preferably stand
    alone application, instead of servlet, unless the problem only occurs in
    servlets). http://mindprod.com/jgloss/sscce.html

    If you can show the problem in a dozen lines of code, and show that it
    works in 1.4, but not 1.5, you can probably file it as a regression bug to
    Sun. Also, have you considered trying 1.6?

    - Oliver
     
    Oliver Wong, Jan 26, 2007
    #8
  9. Gilbert Ostlethwaite wrote:

    > There may be something in this. Further testing shows that my servlet
    > can create and read a File() object, when the physical file is located
    > on the same physical server that the servlet is running on. However, if
    > the file is located on a different server then my servlet cannot read
    > the file regardless whether I use a UNC path or mount the remote drive
    > directly via Windows Explorer.


    Again, in what type of server-process is the servlet running?
    Is the server-process running as stand-alone process (i.e. there
    is a user logged into Windows and the application is running
    inside a window or the console) or as service (shown as entry
    in the services-list).

    If it's running as service, what user runs it (you can see
    that if you look into the properties of the service, alter-
    natively System.getProperty("user.name") should help as well)?

    If it's running as local user, there is no way to get access
    to files on the share or other remote ressource.


    Regards, Lothar
    --
    Lothar Kimmeringer E-Mail:
    PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

    Always remember: The answer is forty-two, there can only be wrong
    questions!
     
    Lothar Kimmeringer, Feb 5, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bob Johnson
    Replies:
    0
    Views:
    3,783
    Bob Johnson
    Aug 7, 2003
  2. Do
    Replies:
    2
    Views:
    6,389
  3. Totan
    Replies:
    0
    Views:
    1,007
    Totan
    Apr 17, 2006
  4. Ulf Meinhardt
    Replies:
    8
    Views:
    6,165
  5. Mark Probert

    Timeout::timeout and Socket timeout

    Mark Probert, Oct 6, 2004, in forum: Ruby
    Replies:
    1
    Views:
    1,298
    Brian Candler
    Oct 6, 2004
Loading...

Share This Page