Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <20050506131107.84730.qmail@web31103.mail.mud.yahoo.com>
Date: Fri, 6 May 2005 06:11:07 -0700 (PDT)
From: <ogjunk-commons@yahoo.com>
Reply-To: ogjunk-commons@yahoo.com
Subject: Re: [VFS] FileChangeEvent, inotify, and file changes outside JVM
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
In-Reply-To: 6667
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi Mario,

Having the option to let DefaultFileMonitor sleep is a good option,
although it sounds to me like that's only a short-term help.  That
would be really cool and useful would be VFS support for instant file
change event updates, and if it didn't have to keep references to all
"known" files in memory.

So yes, that probably means it's time for a JNI piece for Winblows, Mac
and Linux.  I'm not good with C/C++, and hence with JNI, but that link
I sent....
http://www.ibm.com/developerworks/linux/library/l-inotify.html - has
some C code that may help somebody going with at least inotify/Linux
support.

I'm not sure how active VFS is, and how many people are working on it. 
How realistic would it be to hope to see support for this in the next
few months from VFS?

Thanks,
Otis


--- Mario Ivankovits <mario@ops.co.at> wrote:
> Hi!
> >Regarding DefaultFileMonitor - how scalable is this?  More
> precisely,
> >say I wanted to build yet another desktop indexing/search tool, and
> >thus monitor _everything_, or a few hundred or thousands of
> >directories, would DefaultFileMonitor be able to handle it?
> >
> >I know, it depends on CPU, memory, etc., but have people tested it
> with
> >more than a few dozen directories?
> >  
> The latest changes to the DefaultFileMonitor (not commited yet) 
> introduces a new function which allows you to configure it to sleep 
> every e.g. 1000 scanned files.
> So it should be possible to let it run very passive.
> 
> A problem might be that it will keep the whole filestructure in
> memory 
> and thus it might be a problem with memory if you try to index a
> large 
> filesystem.
> You have to try to see if this could be a way.
> However, if you are bound to local files only it might be better to
> use 
> JNI to access the os filesystem-events.
> 
> Maybe its time to start off a new project for this ...
> 
> Ciao,
> Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org