Directory as a queue

[Palych]

Задача: сваливать сообщения в таблицу.
Причём база довольно далеко, а времени на запись много тратить нельзя.
Как полагается берём queuing system (IBM MQ), пишем туда, а потом не торопясь перекидываем в базу.
Вопрос: а ну как вместо MQ каждое сообщение писать в файл в некоей директории?
И соответственно читать содержимое директории, обрабатывать файлы и удалять их?
Где подвох?

[Teh Instructor]

... вместо MQ каждое сообщение писать в файл в некоей директории?
И соответственно читать содержимое директории, обрабатывать файлы и удалять их?
Где подвох?

Нет подвоха. Так многие и делают. Единственное, надо избегать ситуаций, когда не до конца записанный файл начинает обрабатываться. Для этого файл сначала записывают где-то в другом месте на том же диске, а потом перемещают в ту папку, которая служит как очередь.
И если обработчиков очереди несколько и они работают параллельно - тот же трюк с обработкой. Сначала файл перемещают (это атомарная операция) а оттуда уже обрабатывают и удаляют.

[Palych]

Единственное, надо избегать ситуаций, когда не до конца записанный файл начинает обрабатываться.

А в чём проблема? Пишем в конец, читаем с начала.
Получается FIFO...

[Teh Instructor]

Единственное, надо избегать ситуаций, когда не до конца записанный файл начинает обрабатываться.

А в чём проблема? Пишем в конец, читаем с начала.
Получается FIFO...

Логика сложнее получается. Придется обрабатывать ситуации если читатель прочитал данные, которые еще не целостные (типа логический "блок" не до конца записан).
Проще с самого начала определить, что если есть файл, то это целый блок информации готовый к обработке. И полагаться на атомарность операции перемещения файла.

[Palych]

Придется обрабатывать ситуации если читатель прочитал данные, которые еще не целостные (типа логический "блок" не до конца записан).

А чего там обрабатывать?
Файл представляет собой "логический блок": одно сообщение. От начала до EOF.
Если читатель читает, а писатель ещё не дописал - читатель просто остановится...

[Palych]

Если читатель читает, а писатель ещё не дописал - читатель просто остановится...

Извиняюсь - куйню сковал!
Выдал желаемое за действительное.

[Palych]

Единственное, надо избегать ситуаций, когда не до конца записанный файл начинает обрабатываться. Для этого файл сначала записывают где-то в другом месте на том же диске, а потом перемещают в ту папку, которая служит как очередь.
И если обработчиков очереди несколько и они работают параллельно - тот же трюк с обработкой. Сначала файл перемещают (это атомарная операция) а оттуда уже обрабатывают и удаляют.

Кстати, в принципе лучше не перемещать файлы, а переименовывать их.
Перемещение - это изменение двух директорий, а переименование - одной...

[Palych]

Update (Если кому интересно)
обнаружилась весьма пакостная вешь: Походу чтение директории и удаление файлов при определённых условиях (например много файлов) бывают не consistent:
можно увидеть файл, который был удалён, причём около секунды назад.
RHEL 5, ext3, как я понимаю - диск на каком-то SAN...

[Teh Instructor]

Update (Если кому интересно)
обнаружилась весьма пакостная вешь: Походу чтение директории и удаление файлов при определённых условиях (например много файлов) бывают не consistent:
можно увидеть файл, который был удалён, причём около секунды назад.
RHEL 5, ext3, как я понимаю - диск на каком-то SAN...

Это нормальное дело, особенно заметно на SAN из-за сетевых задержек
Поэтому если несколько параллельных обработчиков разбирают очередь которая сделана как папка диске, перед тем как обрабатывать они должны файл перемещать "к себе", туда где его никто не может трогать. На этой операции перемещения конфликты и будут разрешаться - кто-то будет получать ошибку при этом

[Palych]

Похоже дело в моей дремучести: проблема выскакивала в одном процессе (JVM)
Я решил на старости лет заюзать java NIO.
Директорию читал через Files.newDirectoryStream(), а файлы перекидывал через Files.move()...
Похоже DirectoryStream кеширует что-то внутре...
А каноны предписывают SecureDirectoryStream для таких вещей.

[Леонид Ильич Брежнев]

А каноны предписывают SecureDirectoryStream для таких вещей.

http://tamanmohamed.blogspot.com/2012/0 ... tream.html
http://www.java2s.com/Code/Java/JDK-7/U ... Stream.htm

[iDesperado]

Update (Если кому интересно)
обнаружилась весьма пакостная вешь: Походу чтение директории и удаление файлов при определённых условиях (например много файлов) бывают не consistent:
можно увидеть файл, который был удалён, причём около секунды назад.
RHEL 5, ext3, как я понимаю - диск на каком-то SAN...

вы почитайте о линуксовых фс хоть что-то, а то сейчас наворотите. линукс позволяет удалить открытые другими процессами файлы, просто реально удаление произойдет когда последний процесс файл закроет файл

[Palych]

Update (Если кому интересно)
обнаружилась весьма пакостная вешь: Походу чтение директории и удаление файлов при определённых условиях (например много файлов) бывают не consistent:
можно увидеть файл, который был удалён, причём около секунды назад.
RHEL 5, ext3, как я понимаю - диск на каком-то SAN...

вы почитайте о линуксовых фс хоть что-то, а то сейчас наворотите. линукс позволяет удалить открытые другими процессами файлы, просто реально удаление произойдет когда последний процесс файл закроет файл

Я всегда думал что unlink не трогает файл, но изменяет директорию. Неужели и это не так? "Ах, я этого не вынесу! "
В моём случае я вижу файл после удаления вторично проходя по директории с помошью Files.newDirectoryStream().