Использование camel-smb SMB забирает (большие) файлы, пока они все еще записываются в

При попытке создать циклическое перемещение файлов обнаружил странное поведение с readLock. Создайте большой файл (около 100 МБ) и перенесите его с помощью SMB из папки в папку.

ОТ:

smb2://smbuser:****@localhost:4455/user/out?antInclude=FILENAME*&consumer.bridgeErrorHandler=true&delay=10000&inProgressRepository=%23inProgressRepository&readLock=changed&readLockMinLength=1&readLockCheckInterval=1000&readLockTimeout=5000&streamDownload=true&username=smbuser&delete=true

TO:

smb2://smbuser:****@localhost:4455/user/in?username=smbuser

Создайте еще один поток, чтобы переместить файл обратно из папки IN в папку OUT. После некоторых передач файл будет получен, но все еще будет записан другим маршрутом, и передача будет выполнена с файлом гораздо меньшего размера, что приведет к частичному файлу в месте назначения.

ОТ:

smb2://smbuser:****@localhost:4455/user/in?antInclude=FILENAME*&delete=true&readLock=changed&readLockMinLength=1&readLockCheckInterval=1000&readLockTimeout=5000&streamDownload=false&delay=10000

TO:

smb2://smbuser:****@localhost:4455/user/out

Вопрос: почему мой readLock не работает должным образом (требуется p.s. streamDownload)?

ОБНОВЛЕНИЕ: оказывается, это происходит только на общем ресурсе Windows samba и с streamDownload = true. Итак, что-то с разбивкой на части. Любые советы приветствуются.


apache-camel samba camel-ftp
person Orbita    schedule 29.09.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Решение требует, чтобы стратегия опроса не автоматически выбирала файл и не знала о readLock (в процессе) на другой стороне. Поэтому я уменьшил задержку до 5 секунд, а в части FROM с обеих сторон добавил readLockMinAge до 5 секунд, чтобы проверить время изменения файла. Поскольку потоковая передача выполняется каждую секунду, этого времени достаточно, чтобы предотвратить блокировку чтения.

Объяснение того, почему происходит ранее упомянутая ситуация:

  1. Когда маршрут готовится к отправке из исходящей папки, большой файл (1 ГБ) выполняется, фрагмент за фрагментом, в папку в папке. В конце потоковой передачи файл помечается для удаления с помощью camel-smbj, и файл получает статус STATUS_DELETE_PENDING.
  2. Теперь другая часть этого процесса начинает отправлять только что поступивший файл в папку out и обнаруживает, что этот файл уже существует. Из-за стратегии по умолчанию fileExists = Override. Он пытается удалить (впоследствии сохранить) существующий файл (который все еще не удален с предыдущего шага) и получает исключение, которое приводит к потере некоторых фрагментов InputStream.
person Orbita    schedule 09.10.2020