[
https://issues.apache.org/jira/browse/CASSANDRA-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260391#comment-14260391
]
Joshua McKenzie commented on CASSANDRA-8390:
--------------------------------------------
It looks like the windows defender mini filter driver is still active in the
kernel from the attached msinfo output: WinDefend / Windows Defender Service
still live, wdfilter driver (Windows Defender Mini-Filter Driver) still loaded
in kernel.
I don't see any of the expected errors from your procmon trace for the first
file mentioned in the server log above - the messages for that file around that
time stamp show:
{noformat}
"Time of Day","Process Name","PID","Operation","Path","Result","Detail"
"10:28:12.8039785
AM","System","4","IRP_MJ_SET_INFORMATION","C:\progs\apache-cassandra-2.1.2\data\data\system\schema_columnfamilies-45f5b36024bc3f83a3631034ea4fa697\system-schema_columnfamilies-ka-879-Data.db","SUCCESS","Type:
SetEndOfFileInformationFile, EndOfFile: 1,012"
"10:28:12.8039968
AM","System","4","FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION","C:\progs\apache-cassandra-2.1.2\data\data\system\schema_columnfamilies-45f5b36024bc3f83a3631034ea4fa697\system-schema_columnfamilies-ka-879-Data.db","SUCCESS","SyncType:
SyncTypeOther"
"10:28:12.8040110
AM","System","4","FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION","C:\progs\apache-cassandra-2.1.2\data\data\system\schema_columnfamilies-45f5b36024bc3f83a3631034ea4fa697\system-schema_columnfamilies-ka-879-Data.db","SUCCESS",""
{noformat}
When I run a local synthetic file deletion sharing error (what you're seeing),
my procmon output shows the following:
{noformat}
"Time of Day","Process Name","PID","Operation","Path","Result","Detail"
"1:46:45.8623305
PM","Explorer.EXE","4804","IRP_MJ_CREATE","C:\tmp\testfile.txt","SHARING
VIOLATION","Desired Access: Read Attributes, Delete, Synchronize, Disposition:
Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read,
Write, Delete, AllocationSize: n/a"
"1:46:45.8654532
PM","Explorer.EXE","4804","IRP_MJ_CREATE","C:\tmp\testfile.txt","SHARING
VIOLATION","Desired Access: Read Attributes, Delete, Read Control, Synchronize,
Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
"1:46:45.8655184
PM","Explorer.EXE","4804","IRP_MJ_CREATE","C:\tmp\testfile.txt","SHARING
VIOLATION","Desired Access: Read Attributes, Delete, Synchronize, Disposition:
Open, Options: Sequential Access, Synchronous IO Non-Alert, Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
"1:46:45.8658356
PM","Explorer.EXE","4804","IRP_MJ_CREATE","C:\tmp\testfile.txt","SHARING
VIOLATION","Desired Access: Read Attributes, Delete, Read Control, Synchronize,
Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
"1:46:45.8658914
PM","Explorer.EXE","4804","IRP_MJ_CREATE","C:\tmp\testfile.txt","SHARING
VIOLATION","Desired Access: Read Attributes, Delete, Synchronize, Disposition:
Open, Options: Sequential Access, Synchronous IO Non-Alert, Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
"1:46:45.9305935
PM","Explorer.EXE","4804","IRP_MJ_CREATE","C:\tmp\testfile.txt","SHARING
VIOLATION","Desired Access: Generic Read/Write, Disposition: Open, Options: No
Buffering, Synchronous IO Non-Alert, Non-Directory File, Attributes: N,
ShareMode: None, AllocationSize: n/a"
"1:46:45.9524313
PM","Explorer.EXE","4804","IRP_MJ_CREATE","C:\tmp\testfile.txt","SHARING
VIOLATION","Desired Access: Generic Read/Write, Disposition: Open, Options: No
Buffering, Synchronous IO Non-Alert, Non-Directory File, Attributes: N,
ShareMode: None, AllocationSize: n/a"
{noformat}
Since your procmon trace has nothing other than RESULT: SUCCESS in it,
unfortunately it doesn't give us any more information as to the problem at hand.
The only other suggestion I have is to completely stop the Windows Defender
service and see if you can still reproduce. Beyond that I'm out of ideas -
[~philipthompson] could you try reproducing this on a win7 machine?
> The process cannot access the file because it is being used by another process
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-8390
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8390
> Project: Cassandra
> Issue Type: Bug
> Reporter: Ilya Komolkin
> Assignee: Joshua McKenzie
> Fix For: 2.1.3
>
> Attachments: NoHostAvailableLogs.zip
>
>
> 21:46:27.810 [NonPeriodicTasks:1] ERROR o.a.c.service.CassandraDaemon -
> Exception in thread Thread[NonPeriodicTasks:1,5,main]
> org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException:
> E:\Upsource_12391\data\cassandra\data\kernel\filechangehistory_t-a277b560764611e48c8e4915424c75fe\kernel-filechangehistory_t-ka-33-Index.db:
> The process cannot access the file because it is being used by another
> process.
>
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:135)
> ~[cassandra-all-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:121)
> ~[cassandra-all-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTable.delete(SSTable.java:113)
> ~[cassandra-all-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableDeletingTask.run(SSTableDeletingTask.java:94)
> ~[cassandra-all-2.1.1.jar:2.1.1]
> at
> org.apache.cassandra.io.sstable.SSTableReader$6.run(SSTableReader.java:664)
> ~[cassandra-all-2.1.1.jar:2.1.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_71]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_71]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> ~[na:1.7.0_71]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> ~[na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_71]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]
> Caused by: java.nio.file.FileSystemException:
> E:\Upsource_12391\data\cassandra\data\kernel\filechangehistory_t-a277b560764611e48c8e4915424c75fe\kernel-filechangehistory_t-ka-33-Index.db:
> The process cannot access the file because it is being used by another
> process.
>
> at
> sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> ~[na:1.7.0_71]
> at
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> ~[na:1.7.0_71]
> at
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> ~[na:1.7.0_71]
> at
> sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
> ~[na:1.7.0_71]
> at
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> ~[na:1.7.0_71]
> at java.nio.file.Files.delete(Files.java:1079) ~[na:1.7.0_71]
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:131)
> ~[cassandra-all-2.1.1.jar:2.1.1]
> ... 11 common frames omitted
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
