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] [Commented] (SYNAPSE-907) VFSTransportListener locks a folder if a non-matching file is put in to it
Date Sun, 19 Aug 2012 07:53:37 GMT

    [ https://issues.apache.org/jira/browse/SYNAPSE-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437474#comment-13437474
] 

Amila Maharachchi commented on SYNAPSE-907:
-------------------------------------------

I simplified the logic for processing files inside a folder as follows.

1. Check whether the file name matches with the patter provided
2. If it matches only we will try to get a lock on the file and process it
3. If it doesn't match, we'll do nothing. I added a debug log saying "Non-matching file +
filename".

Amila.
                
> 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
>
>
> 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