Шаблон наблюдателя: задержка действия после запуска события - PullRequest
Новая
       22

Шаблон наблюдателя: задержка действия после запуска события

0 голосов
/ 02 ноября 2018

Мой код работает правильно. У меня просто вопрос с точки зрения дизайна.

Вы можете скопировать / вставить как класс, так и тестовый класс - они должны работать "из коробки".

Описание проблемы:

У меня есть класс, который просматривает каталог для новых / измененных / удаленных файлов и запускает событие в случае каких-либо изменений. Это реализовано с использованием шаблона наблюдателя. 

interface IFileObserver
{
    void onFileChange(String filename, String action);
}

public class FileWatcher implements Runnable
{

private Path _directory;
private WatchService _watchService;
private List<IFileObserver> _fileObserverList;

public FileWatcher(Path directory)
{
    _directory = directory;
    try
    {
        _watchService = FileSystems.getDefault().newWatchService();
        _directory.register(_watchService, ENTRY_CREATE, ENTRY_MODIFY, ENTRY_DELETE);
        _fileObserverList = new ArrayList<>();
    }
    catch (IOException e)
    {
        System.err.println("Unable to create FileWatcher object!");
    }
}

public void register(IFileObserver fileObserver)
{
    _fileObserverList.add(fileObserver);
}

private void updatesEvent(String filename, String action)
{
    for (IFileObserver observer : _fileObserverList)
    {
        observer.onFileChange(filename, action);
    }
}

private void startWatching()
{
    WatchKey key = null;
    boolean reset = true;
    while(reset)
    {
        try
        {
            key = _watchService.take();
            outerloop:
            for (WatchEvent<?> event : key.pollEvents())
            {
                String filename = event.context().toString();
                WatchEvent.Kind<?> kind = event.kind();
                switch(kind.name())
                {
                    case "ENTRY_CREATE":
                        updatesEvent(filename, kind.name());
                        // Files on create will normally trigger ENTRY_CREATE and ENTRY_MODIFY
                        // break to outerloop will prevent catching ENTRY_MODIFY when create is expected
                        break outerloop;
                    case "ENTRY_MODIFY":
                    case "ENTRY_DELETE":
                        updatesEvent(filename, kind.name());
                        break;
                }
            }
        }
        catch (InterruptedException e)
        {
            System.out.println("Retrieving watch key interrupted!");
        }

        reset = key.reset();
    }
}

@Override
public void run()
{
    startWatching();
}

Проблема в том, что для использования данных, отправленных событием, я должен был до Thread.sleep раньше. Как вы можете видеть в моих тестах ниже, я использую Thread.sleep (100) перед каждым блоком подтверждения - без этого тесты не пройдут. 

public class FileWatcherTest implements IFileObserver
{
private int _updatesCount = 0;
private String _filename;
private String _action;

@Test
public void FileWatcher() throws IOException, InterruptedException
{
    File directory = new File(System.getProperty("user.dir"));
    assertTrue(directory.exists());
    assertSame(0, _updatesCount);

    Path path = Paths.get(directory.getPath());
    FileWatcher fileWatcher = new FileWatcher(path);
    fileWatcher.register(this);

    Thread thread = new Thread(fileWatcher);
    thread.start();

    String filename = "the-file-name.txt";
    File file = new File(filename);
    if (file.exists())
    {
        file.delete();
    }

    assertTrue(createFile(file));
    Thread.sleep(100);

    assertSame(1, _updatesCount);
    assertEquals(filename, _filename);
    assertEquals("ENTRY_CREATE", _action);

    assertTrue(modifyFile(file));
    Thread.sleep(100);

    assertSame(2, _updatesCount);
    assertEquals(filename, _filename);
    assertEquals("ENTRY_MODIFY", _action);

    Thread.sleep(250);
    assertTrue(deleteFile(file));
    Thread.sleep(100);

    assertSame(3, _updatesCount);
    assertEquals(filename, _filename);
    assertEquals("ENTRY_DELETE", _action);
}

private boolean deleteFile(File file)
{
    return file.delete();
}
private boolean modifyFile(File file) throws IOException
{
    FileWriter writer = new FileWriter(file, true);
    writer.append("another line appended by ENTRY_MODIFY");
    writer.close();
    return true;
}
private boolean createFile(File file) throws FileNotFoundException, UnsupportedEncodingException
{
    PrintWriter writer = new PrintWriter(file, "UTF-8");
    writer.println("The first line");
    writer.println("The second line");
    writer.close();
    return file.exists();
}

@Override
public void onFileChange(String filename, String action)
{
    _filename = filename;
    _action = action;
    _updatesCount++;
}

Но я нахожу это нехорошим, потому что, если кто-то еще использует этот класс, он не будет знать, что вам нужно спать, и это вызовет проблемы.

Может ли Thread.sleep (100) быть каким-либо образом принудительным, т. Е. В каждой реализации интерфейса IFileObserver?

1 Ответ

0 голосов
/ 03 ноября 2018

То, что вы сказали, правильно. Когда вы получаете уведомление о создании в течение 100 миллисекунд в вашей системе, это занимает около 8400 в моем. Таким образом, лучший дизайн теста - ожидание изменения логического состояния в течение определенного периода вместо простого Thread.sleep. Что-то вроде 

private void waitUntilUpdateCountChangesFrom(int count) throws InterruptedException {
    int sleepTime = 10;
    int maxPolls = 10000/sleepTime;
    int i=0;
    for (; i<maxPolls; i++) {
        if (_updatesCount != count) {
            break;
        }
        Thread.sleep(sleepTime); // sleeps a little to give a turn to file watcher thread
    };
    System.out.println("waited " + (i*sleepTime) + " milliseconds");
}

Тогда назовите это как 

    assertTrue(modifyFile(file));

    waitUntilUpdateCountChangesFrom(1);

    assertSame(2, _updatesCount);
    assertEquals(filename, _filename);
    assertEquals("ENTRY_MODIFY", _action);

Еще одна вещь, которую я заметил, заключается в том, что иногда в моей системе я получаю, что ENTRY_MODIFY тоже получает первым для создания файла. Поэтому может быть хорошей идеей ожидать MODIFY или CREATE для создания файла, как показано ниже: - 

    assertTrue(createFile(file));

    waitUntilUpdateCountChangesFrom(0);

    assertSame(1, _updatesCount);
    assertEquals(filename, _filename);
    List<String> createActions = Arrays.asList("ENTRY_CREATE", "ENTRY_MODIFY");
    assertTrue(createActions.contains(_action));

Мой процесс обработки был почти таким, как указано ниже: - 

    Going to create .... 
    Received event: ENTRY_CREATE on file: the-file-name.txt
    waited 8440 milliseconds
    Going to modify .... 
    Received event: ENTRY_MODIFY on file: the-file-name.txt
    waited 8430 milliseconds
    Going to delete .... 
    Received event: ENTRY_DELETE on file: the-file-name.txt
    waited 8420 milliseconds
...