From d31079a05cf8df33d307ee1e78d1e7d37e492ab9 Mon Sep 17 00:00:00 2001 From: Iwein Fuld Date: Fri, 6 May 2011 09:09:03 +0200 Subject: [PATCH] INT-1889 Add note regarding unlocking to reference documentation. When a NioLocker acquires locks from the FileReadingMessageSource, they are not released by Spring integration. There is no way to do that without surprising a user, so we leave it up to the user to do the unlocking when needed. --- docs/src/reference/docbook/file.xml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/src/reference/docbook/file.xml b/docs/src/reference/docbook/file.xml index 61a924a94b..0c02365238 100644 --- a/docs/src/reference/docbook/file.xml +++ b/docs/src/reference/docbook/file.xml @@ -124,6 +124,15 @@ ]]> + + + When a file inbound adapter is configured with a locker, it will take the responsibility to acquire a + lock before the file is allowed to be received. + It will not assume the responsibility to unlock the file. + If you have processed the file and keeping the locks hanging around you have a memory leak. If this is + a problem in your case you should call FileLocker.unlock(File file) yourself at the appropriate time. + + When filtering and locking files is not enough it might be needed to control the way files are listed entirely. To implement this type of requirement you can use an implementation of DirectoryScanner.