synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Maharachchi (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SYNAPSE-907) VFSTransportListener locks a folder if a non-matching file is put in to it
Date Sun, 19 Aug 2012 07:55:37 GMT

     [ 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


Mime
View raw message