This week's book giveaway is in the Other Languages forum.
We're giving away four copies of Rust Web Development and have Bastian Gruber on-line!
See this thread for details.
Win a copy of Rust Web Development this week in the Other Languages forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

listFiles() randomly throws i/o error

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Using a vended product that relies on J2SE and uses basic listFiles(java.io.filter) to get at contents of a directory. For some reason, on one of our platforms (HP intel running Linux RHEL 3, JDK 1.5), this call is, according to our vendor, "occasionally" returning null (implying that pathname has suddenly become unaccessible) when trying to read a directory.

Most of the time there's no issue (i.e. we discover, open, read and parse the 1000s of files resident here), but when there is, it happens w/out pattern (varying time to error) and happens whether or not directory is local or remote disk. The app using this framework is viewing a dir w/ 130k files, reads about 50 at a time (via separate threads), and moves the "finished" files to an archive directory.

We've had better success moving handful of files into a working directory and running against the smaller dir, but for various reasons this isn't ideal for us.

Also oddly, we have no issues running on our older IBM hardware (slower, less RAM, different bus, etc., but same RHEL version and patch level and JDK).

Vendor is working to come up w/ better error description and a recovery method (currently, program simply ends).

Any ideas on what underlying issue is would be much appreciated.

Thanks,

Chris
 
Ranch Hand
Posts: 180
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's not ideal but you might try decompiling the vendors code and checking out what they are actually doing under the covers (using Jad - http://www.kpdus.com/jad.html or something similar). Sometimes this can reveal the real bug and at least maybe you can find a better work-around (or push on the vendor a bit harder).

It seems odd that such a core java method would fail like that... you might also search Sun's bug database to see if there are any bug tickets reported on this (unless it is truly the vendors issue).

Good luck.

Chris (nice name by the way)
 
reply
    Bookmark Topic Watch Topic
  • New Topic