Re: [VFS] FileChangeEvent, inotify, and file changes outside JVM

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [VFS] FileChangeEvent, inotify, and file changes outside JVM

Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] FileChangeEvent, inotify, and file changes outside JVM

ogjunk-commons
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS] FileChangeEvent, inotify, and file changes outside JVM

Mario Ivankovits
Hi!

>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?
>  
I cant promise anything. And even then it should not be part of VFS at
first.
It fits best in commons-io (utils for local file handling) or in a new
project (at sourceforge?)

But hey, its a very interesting stuff .... maybe it might happen.

Ciao,
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS][JFileWatch] FileChangeEvent, inotify, and file changes outside JVM

Mario Ivankovits
In reply to this post by ogjunk-commons
Hi!
>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 have setup some java classes and jni interface to interact with
inotify from within java.
It should be abstract enough to create jni wrapper for windows/mac too,
it would be nice is someone else could do this later.

If I find some time tomorrow (Moday) I will setup a website for this and
provide a link here.


Ciao,
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VFS][JFileWatch] FileChangeEvent, inotify, and file changes outside JVM

Mario Ivankovits
In reply to this post by ogjunk-commons
Hello!

>So yes, that probably means it's time for a JNI piece for Winblows, Mac
>and Linux.

Please find JFileWatch (License: ASF 2.0) at

http://l3x.net/imwiki/Wiki.jsp?page=JFileWatch

Its state is experimental and not meant to be bugfree nor finished. I
just wanted to see what could be possible, tough it looks promising.


Now that it is not a jakarta project we should move any further
conversion to private mail, or are other users on this list interested too?


If someone might help in building a windows library I would be happy!


---
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]