Запись нескольких экземпляров в одну и ту же смонтированную папку с использованием компонента camel-file

У нас есть требование записывать в один файл, используя несколько экземпляров интерфейса camel, работающих одновременно. Файл находится в общей файловой системе Windows, которая была смонтирована на сервере JBoss с использованием SMB.

Мы используем компонент файла верблюда для записи файла из каждого экземпляра как локального файла. Ниже приведен URI конечной точки в контексте верблюда.

file:/fuse/server/location/proc?fileName=abc.csv&fileExist=Append

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

Мы используем JBoss Fuse 6.0.0, а интерфейс написан с использованием версии camel 2.10.

Как это исправить? Это проблема с монтированием SMB или интерфейс должен ее обрабатывать.


person Yoogi    schedule 03.12.2015    source источник
comment
Если несколько производителей записывают в один и тот же файл, да, я вижу, как добавляется мусор, поскольку они перезаписывают доступ друг к другу. Файл не является объектом, который может быть записан сразу многими производителями, поэтому, например, если вы откроете файл csv в Excel, а затем в блокноте и попытаетесь сохранить версию блокнота, он будет жаловаться, что файл заблокирован. Вам нужно будет сериализовать доступ к файлу. Файл не сможет обрабатывать записи двух производителей без какого-либо контроля над тем, кто пишет первым и т. Д. Подумайте о блокировке файла.   -  person Namphibian    schedule 04.12.2015
comment
Я предполагал, что об этом позаботится компонент "верблюжий файл". Означает ли это, что мне приходится обрабатывать то же самое вручную.   -  person Yoogi    schedule 04.12.2015
comment
Это действительно зависит от файловой системы. Вероятно, Java лучше работает с файловыми системами с открытым исходным кодом, поскольку их инженеры могут создавать байтовый код, специфичный для этой файловой системы, и они в конце концов могут читать исходный код. С SMB суды заставили MS открыть протокол, поэтому общие ресурсы SMB хороши, но все еще остается много серых зон. Мое предложение состоит в том, чтобы вместо того, чтобы эти производители отправляли данные в файл, заставляйте их отправлять их в компонент очереди, такой как seda, и позволять очереди сообщений одно за другим, а seda обрабатывать сообщения, поскольку это будет очередь FIFO. Нет необходимости делать это вручную.   -  person Namphibian    schedule 04.12.2015


Ответы (1)


Я просмотрел исходный код соответствующего компонента camel (https://github.com/apache/camel/tree/master/camel-core/src/main/java/org/apache/camel/component/file) и нет встроенной поддержки одновременного доступа к одному файлу с нескольких JVM. Тем не менее, одновременный доступ из одной JVM обрабатывается.

Я думаю, у вас есть два основных варианта удовлетворения ваших требований:

  1. Напишите код для поддержки общего доступа к одному файлу. Компонент файла верблюда выглядит так, как будто он был создан с учетом расширения, или вы можете просто создать отдельный компонент для этого.
  2. Поскольку @Namphibian предлагает использовать некоторую систему очередей для сериализации ваших записей (хотя я не думаю, что seda будет работать, поскольку она не охватывает JVMS.

Мое решение - использовать ActiveMQ. Каждый экземпляр вашего приложения будет отправлять сообщения в единую общую очередь. Некоторые другие процессы затем потребляли бы сообщения от MQ и записывали их на диск.

Если бы один процесс потреблял все сообщения MQ, одновременная запись в файловую систему отсутствовала.

Более надежным решением было бы запускать ActiveMQ в кластере (возможно, с узлом в каждом из ваших экземпляров приложения). Посмотрите на «JMSXGroupID», чтобы предотвратить одновременное использование сообщений.

person Paul M    schedule 04.12.2015
comment
Я согласен с Полом. Лучше всего добавить систему обмена сообщениями впереди, а затем попросить другой camelcontext забрать сообщение и записать в файл. - person Souciance Eqdam Rashti; 05.12.2015