2016-09-07 12 views
3

Google은 Jboss v6 Linux 플랫폼에서 실행되는 Camel v2.16.1을 기반으로하는 통합 시스템을 보유하고 있습니다. 서로 다른 폴링 속도로 동시에 실행되는 여러 인터페이스가 있습니다.Apache Camel GenericFileOperationFailedException : '파일 이름을 바꿀 수 없습니다'교환 잠금

Camel이 'done'폴더에 백업하지 못해 '파일 이름을 바꿀 수 없습니다'라는 문제가 간헐적으로 발생하여 FTP 소스에서 파일을 성공적으로 처리하고 전송했습니다. 낙타 응용 프로그램을 다시 시작하면 문제가 해결됩니다. 정기적으로는 석영 스케줄러에 의해, 경로 트리거에서

는 는 기본적으로

: FTP를 통해 소스로부터

  1. 가 픽업 파일을
  2. 가이를 처리, smooks + XSL 변환을
  3. 플랫 생성 제공 파일을 FTP를 통해 엔드 포인트에 보내십시오.

원본 디렉터리에서 여러 파일을 읽으면 모든 파일이 처리되기 전에 임시 파일에 함께 추가됩니다.

ftp://xxxx/export?antInclude=dsciord_ * .DAT & inProgressRepository = # warehouseIntegrationIdempotentRepository & preMove = in_progress_bpo/$ 간단한 {날짜 : 지금 : YYYYMMDDhhmm 형식}

카멜 FTP 구성은 다음 URL 사용/$ 단순 {파일 이름} & 이동 = 수행 & consumer.bridgeErrorHandler = 사실

  1. 은 0,123,893,148에서 파일을 dsciord_*.dat 읽기디렉토리
  2. inprogressRepository 사용자 정의 inprogressRepository을 사용하여 읽은 파일 이름을 로컬 db에 저장합니다 (두 번째 클러스터 노드와의 충돌 문제를 방지하기 위해 수행되었지만 현재는 단일 노드 만 생방송입니다). 이 옵션은 필요하지 않으므로 프로세스 속도가 빨라질 수 있습니다.
  3. in_progress_bpo/201609061522 디렉토리로 파일을 이동합니다. 여기서 하위 디렉토리는 date_timestamp를 기반으로 만들어집니다.
  4. 일단 처리가 완료되면 in_progress_bpo/201609061522/done 하위 디렉토리로 이동하십시오.

경로는 문제없이 작동하지만 때로는 파일을 완료 폴더로 이동할 수 없습니다 (아래 오류 참조). 이 경우에도 경로가 다음 폴링주기에서 성공적으로 계속되는 경우도 있지만 다른 경우 석영 스케줄러가 폴링을 트리거하더라도 경로가 소스/내보내기 디렉토리의 파일을 감지하지 못하는 상태가됩니다 거기에 파일이 있어도.

org.apache.camel.component.file.GenericFileOperationFailedException가 : 파일 이름을 바꿀 수 없습니다 : RemoteFile을을 [in_progress_bpo/201609060502/dsciord_3605752.dat]에 : RemoteFile을 [in_progress_bpo/201609060502/수행/dsciord_3605752.dat]

주 : 우리는 우리의 인터페이스를 처리 할 수 ​​

  1. ConsumerTemplate의 단일 인스턴스를 사용하고 있습니다.
  2. 사용자 정의 inprogressRepository은 읽은 파일 이름을 저장합니다.

분명히 소스 파일을 잠그고있는 시스템이 있어야하며 이로 인해 Camel 경로가 추가 파일 처리를 중지하게됩니다.

이 문제를 디버깅/해결하는 데 도움이되는 아이디어 나 제안 사항이 있으면 알려 주시면 감사하겠습니다. camel-users 포럼을 통해 읽은 문제는 Windows 관련 배포를 처리하는 것처럼 보입니다. Smooks는 입력 스트림을 닫지 못하는 경우가 있습니다. 내가 확인 했으므로 Smooks가 기본 입력 스트림을 닫지 못하는 org.milyn.templating.xslt.XslTemplateProcessor#bypass 메서드를 사용하지 않습니다.

답변

0

마침내 문제를 재현하고 식별 할 수있었습니다.

우리가 대상 서버에 한 번 성공적으로 FTP-ED로 처리 된 파일을 이동하는 상대 경로를 사용하고 있음을 감안할 때 :

../../../u/4gl_upload/warehouse_integration_2/trs-server/export/in_progress_bpo/done/in_progress_bpo/201609081030/done

그러나 올바른 경로를 통해 올바른 경로를 따라 이동하여 처리 된 파일을 이동하는 대신 낙타 소비자가 현재 작업 디렉토리에서 시작하여 새로운 하위 디렉토리 트리를 만듭니다. 다음과 같습니다. 그러므로 문제. 그것이 어디에 있는지 알지 못하며 자체적으로 재설정되지 않습니다.

/U/4gl_upload/warehouse_integration_2/TRS 서버/U/4gl_upload/warehouse_integration_2/TRS 서버/수출/in_progress_bpo/201609081030

이는 수단 옵션 단계적 = 거짓으로 재현 그것은 서브 디렉토리를 트래버스 단계별로 하나의 단계로

여전히 최상의 솔루션이 무엇인지 모릅니다.

+0

나는 낙타의 ConsumerTemplate을 사용하지 않았다. 대신 문제를 해결하기 위해 원격 FTP 서버에서 파일을 읽는 사용자 지정 방식을 사용했습니다. 빠르고, 신뢰할 수 있으며 절대 경로를 지정할 수 있습니다! –

+0

mmhh .. 윈도우 사용에 문제가 있습니다. –