Thread-Probleme mit Webanwendung und Verzeichnisüberwachung mit Spring und Apache Commons IO

Question

Ich entwickle eine Webanwendung mit Spring Framework 4.2 mit Apache Tomcat 8.5. Wenn ich eine Datei in einem Verzeichnis ändere, muss ich eine Methode in einem Bean-Objekt aufrufen, um die Informationen neu zu laden. Ich arbeite mit Apache Commons IO, um das Verzeichnis zu überwachen, aber wenn ich die Anwendung deimplementiere, lebt der Thread, der das Verzeichnis scannt, noch.

Dies ist der Code die Änderungen

final File directory = new File(groupsDirectory); 
    FileAlterationObserver fao = new FileAlterationObserver(directory); 
    fao.addListener(new FileAlterationListenerImpl()); 
    final FileAlterationMonitor monitor = new FileAlterationMonitor(pollingInterval); 
    monitor.addObserver(fao); 
    monitor.start(); 

Und das ist die Botschaft, die Tomcat zeigt mir zu sehen, wenn ich die Webapplikation deimplementieren:

22-May-2016 19: 13: 14,377 WARNUNG [http-nio-8084-exec-12] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads Die Webanwendung [Argo] scheint einen Thread mit dem Namen [Thread-12] gestartet zu haben, konnte ihn jedoch nicht stoppen. Dies führt sehr wahrscheinlich zu einem Speicherleck. Stack-Ablaufverfolgung des Threads: java.lang.Thread.sleep (systemeigene Methode) org.apache.commons.io.monitor.FileAlterationMonitor.run (FileAlterationMonitor.java:188) java.lang.Thread.run (Thread.java : 745

) ist, können Sie

Answer 1

Was haben ein ServletContextListener zu implementieren, wie in diesem Beitrag beschrieben: Call method on undeploy from a Java web-application

Dann sollten Sie den Monitor in der contextDestroyed() Methode Ihrer ServletContextListener stoppen können.

Ich würde empfehlen, ein Factory-Objekt, das auf die statische Monitor-Instanz hält, dann können Sie Anrufe an die Fabrik und nicht die ServletContextListener Deal mit dem Monitor direkt haben.

Die Fabrik für die gesamte Lebensdauer des Klassenlader bestehen würde (zum Beispiel der Dauer des Webapp gestartet wird)

Answer 2

Ich benutzen nur die Anmerkung @PreDestroy den Monitor zu stoppen, bevor die Anwendungen beendet.

@Component 
public class GroupsMonitor { 

    private final FileAlterationMonitor monitor; 

    @Autowired 
    public GroupsMonitor(@Value("${groups.directory}") String groupsDirectory, 
      @Value("${groups.intervalMonitor}") long pollingInterval) throws Exception { 
     final File directory = new File(groupsDirectory); 
     FileAlterationObserver fao = new FileAlterationObserver(directory); 
     fao.addListener(new FileAlterationListenerImpl()); 
     monitor = new FileAlterationMonitor(pollingInterval); 
     monitor.addObserver(fao); 
     monitor.start(); 
    } 

    @PreDestroy 
    public void stop() { 
     try { 
      monitor.stop(); 
     } catch (Exception ex) { 
      Logger.getLogger(StopWatcher.class.getName()).log(Level.SEVERE, null, ex); 
     } 
    } 
}