synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (SYNAPSE-907) VFSTransportListener locks a folder if a non-matching file is put in to it
Date Thu, 18 Jul 2013 19:32:49 GMT


Hudson commented on SYNAPSE-907:

SUCCESS: Integrated in Synapse - Trunk #4619 (See [])
Applying the patch to SYNAPSE-907. This will make sure that the VFS listener never tries to
lock a file that doesn't match the configured file pattern regex. Also it will make sure that
each acquired lock is eventually released. (hiranya: rev 1504582)
* /synapse/trunk/java/modules/transports/core/vfs/src/main/java/org/apache/synapse/transport/vfs/

> VFSTransportListener locks a folder if a non-matching file is put in to it
> --------------------------------------------------------------------------
>                 Key: SYNAPSE-907
>                 URL:
>             Project: Synapse
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.1
>         Environment: I have tried this with a ftp/sftp location
>            Reporter: Amila Maharachchi
>            Assignee: Hiranya Jayathilaka
>            Priority: Blocker
>              Labels: lock, vfs
>             Fix For: FUTURE
>         Attachments: SYNAPSE_907.patch
> Create a VFS proxy, provide a file name pattern and a file uri to listen in. Then put
a file with a non-matching file name patter to the mentioned folder. VFSTransportListener
locks the folder without checking whether the file pattern matches and this lock is not released.
After that even if we put a correct file, it cannot be processed due to the lock.
> Following code segment is the culprit.
> VFSTransportListener#scanFileOrDirectory
> else if (!(!entry.isFileLockingEnabled() || (entry.isFileLockingEnabled()
>                                 && VFSUtils.acquireLock(fsManager, fileObject)))
>                                 log.isDebugEnabled()) {
>                             log.debug("Couldn't get the lock for processing the file
: "
>                                     + child.getName());
>                         }
> this passes the wrong fileobject to acquire the lock (this should pass child intead of
the fileObject). Even we fix this place, this logic is wrong. We dont need to acquire a lock
for a non-matching file.
> I have rectified the logic and I'll provide a patch for this.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message