commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Falco (Jira)" <>
Subject [jira] [Commented] (VFS-299) Listeners on DefaultFileMonitor not deregistered on stop()
Date Fri, 04 Oct 2019 10:28:00 GMT


Falco commented on VFS-299:

Despite being more than nine years old, I believe this issue still relevant. I took the liberty
to archive above example code in a runnable example project: []

To my opinion, I do not know if {{stop}} should remove the listeners. This would remove the
functionality to pause listening for file events using {{stop}}, and to resume listening for
the same files with {{start}} (without re-registration of said files).

If a method removed filesystem listeners, it should be {{removeFile}}. This appears logical
to me, since {{addFile}} registered the filesystem listener.
In fact, adding, removing, and re-adding file registrations to the file monitor triggers doubles
the change events as demonstrated in [].

* Let {{DefaultFileMonitor#removeFile}} remove the file system listener.
* Decide what happens on {{DefaultFileMonitor#stop}}:
** Keep the current state: it's duty of the client code to remove all file registrations after
calling {{stop}} *or*
** Alter behavior and make {{stop}} remove all registrations of watched files using (fixed)
{{removeFile}} (with implications described above)

> Listeners on DefaultFileMonitor not deregistered on stop()
> ----------------------------------------------------------
>                 Key: VFS-299
>                 URL:
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: windows xp
>            Reporter: Josua Troesch
>            Priority: Minor
> If I 
> 1. register a File to a DefaultFileMonitor
> 2. stop() that DefaultFileMonitor
> 3. create a new DefaultFileMonitor and
> 4. register the same File to it
> 5. write to the File
> I get the {{FileChangeEvent}} on both listeners, on the one registered to the new DefaultFileMonitor
(as expected) but also on the one registered to the stopped DefaultFileMonitor. I tracked
it down to the {{LocalFileSystem.listenerMap}} containing both listeners for the File. In
my project I fixed this behaviour as follows:
> Extended the {{stop()}} method on {{DefaultFileMonitor}}:
> public void stop() {
>     this.shouldRun = false;
> 	// Inserted this bit
> 	for (FileMonitorAgent agent : (Collection<FileMonitorAgent>)monitorMap.values())
> 		agent.removeListeners();
> 	}
> }
> And adding the method to the {{DefaultFileMonitor$FileMonitorAgent}}:
> public void removeListeners() {
> 	file.getFileSystem().removeListener(file, fm.getFileListener());
> }

This message was sent by Atlassian Jira

View raw message