You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Amila Maharachchi (JIRA)" <ji...@apache.org> on 2012/08/19 09:55:37 UTC

[jira] [Updated] (SYNAPSE-907) VFSTransportListener locks a folder if a non-matching file is put in to it

     [ https://issues.apache.org/jira/browse/SYNAPSE-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amila Maharachchi updated SYNAPSE-907:
--------------------------------------

    Attachment: SYNAPSE_907.patch

Attaching the patch SYNAPSE-907.patch with the fix.
                
> VFSTransportListener locks a folder if a non-matching file is put in to it
> --------------------------------------------------------------------------
>
>                 Key: SYNAPSE-907
>                 URL: https://issues.apache.org/jira/browse/SYNAPSE-907
>             Project: Synapse
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.1
>         Environment: I have tried this with a ftp/sftp location
>            Reporter: Amila Maharachchi
>            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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org