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:35:37 UTC
[jira] [Created] (SYNAPSE-907) VFSTransportListener locks a folder
if a non-matching file is put in to it
Amila Maharachchi created SYNAPSE-907:
-----------------------------------------
Summary: 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
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
[jira] [Updated] (SYNAPSE-907) VFSTransportListener locks a folder
if a non-matching file is put in to it
Posted by "Amila Maharachchi (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (SYNAPSE-907) VFSTransportListener locks a
folder if a non-matching file is put in to it
Posted by "Amila Maharachchi (JIRA)" <ji...@apache.org>.
[ 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