commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Haldane (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (VFS-487) File creation events missed when deleted then re-created within poll delay
Date Fri, 09 Aug 2013 03:58:49 GMT

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

Sam Haldane updated VFS-487:
----------------------------

    Description: 
To reproduce:
* create a file monitor and add a directory with at least one child file
* set delay to 5 seconds and start the monitor
* delete a child file, wait for monitor to detect deletion
* re-create the child file within 5 seconds
* creation event is not detected

This is mainly due to this block being at the start of the main loop instead of the end:

{code:java}
            while (!this.deleteStack.empty())
            {
                this.removeFile(this.deleteStack.pop());
            }
{code}

When this is executed the file is in the stack from the previous poll and the file has already
been re-created. {{removeFile}} calls {{FileMonitorAgent#resetChildrenList}} which updates
the children list for that agent (which will contain the newly created file), but doesn't
update the monitor map. The subsequent call to {{FileMonitorAgent#check}} in the main loop
then doesn't detect the new file.

Moving the above block to the end of the main loop would prevent most occurrences of this
issue, but the implementation is still racy.

  was:
To reproduce:
* create a file monitor and add a directory with at least one child file
* set delay to 5 seconds and start the monitor
* delete a child file, wait for monitor to detect deletion
* re-create the child file within 5 seconds
* creation event is not detected

This is mainly due to this block being at the start of the main loop instead of the end:

{code:java}
            while (!this.deleteStack.empty())
            {
                this.removeFile(this.deleteStack.pop());
            }
{code}

When this is executed, the file has already been re-created. {{removeFile}} calls {{FileMonitorAgent#resetChildrenList}}
which updates the children list for that agent (which will contain the newly created file),
but doesn't update the monitor map. The subsequent call to {{FileMonitorAgent#check}} in the
main loop then doesn't detect the new file.

Moving the above block to the end of the main loop would prevent most occurrences of this
issue, but the implementation is still racy.

    
> File creation events missed when deleted then re-created within poll delay
> --------------------------------------------------------------------------
>
>                 Key: VFS-487
>                 URL: https://issues.apache.org/jira/browse/VFS-487
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Sam Haldane
>
> To reproduce:
> * create a file monitor and add a directory with at least one child file
> * set delay to 5 seconds and start the monitor
> * delete a child file, wait for monitor to detect deletion
> * re-create the child file within 5 seconds
> * creation event is not detected
> This is mainly due to this block being at the start of the main loop instead of the end:
> {code:java}
>             while (!this.deleteStack.empty())
>             {
>                 this.removeFile(this.deleteStack.pop());
>             }
> {code}
> When this is executed the file is in the stack from the previous poll and the file has
already been re-created. {{removeFile}} calls {{FileMonitorAgent#resetChildrenList}} which
updates the children list for that agent (which will contain the newly created file), but
doesn't update the monitor map. The subsequent call to {{FileMonitorAgent#check}} in the main
loop then doesn't detect the new file.
> Moving the above block to the end of the main loop would prevent most occurrences of
this issue, but the implementation is still racy.

--
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: http://www.atlassian.com/software/jira

Mime
View raw message