ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: problem with work files created in cache by ivy:resolve (ivy 1.4)
Date Thu, 11 Oct 2007 11:48:23 GMT
Buck, Robert wrote:
> Hi,
> I am new to this thread. I don't mean to butt in, but I have one
> question regarding it, and this may be slightly unrelated...
> I see mention use of the FileLock class. When I saw a reference to this,
> I was immediately concerned.
> IVY itself does NOT use FileLock, correct?  (I hope not)
> The reason I ask is that at VeriSign we discovered that FileLock does
> not work on any of the NFS devices we have. The class itself throws an
> exception, whose localized message effectively states, "FileLock is
> unsupported on NFS devices.".

to put it differently: NFS has historically not supported locking, be a 
stateless UDP-based protocol from the early eighties, designed to 
support diskless 68K workstations on 1 mbit LAN.

> Additionally, there are many File oriented
> classes in NIO that either: (a) do not work at all, or (b) are a LOT
> slower than old IO for IO intensive applications.

Is this documented somewhere?

> So this is all to say, please, only use NIO when you have NFS, NetAPP,
> or EMC, hardware to test on, and you can prove with complete certainty
> the individual API works. You may be surprised to find that the more
> crucial parts of NIO is effectively broken.

1. do they provide VMWare images of their OS?
2. netapp servers do support file locking with other protocols (e.g 
samba)(*). So perhaps the issue is choice of NFS rather than modern 

(*) Though they have other defects, like the #of files in a directory is 
limited to 65K.

testing over NFS is something that could be done between two linux 
images in a vmware cluster. testing on EMC hardware? Unlikely, unless 
EMC want to donate kit to apache, the way others do.

Steve Loughran        
Author: Ant in Action 

View raw message