[ https://issues.apache.org/jira/browse/CASSANDRA-6736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919566#comment-13919566 ]
Bill Mitchell commented on CASSANDRA-6736: ------------------------------------------ That's a bit awkward, as the JUnit test cases live within the framework of a complete application, and stripping it down to something more minimal, that does not carry all of our application framework, will be a little work. As I've already built a 2.0.5 version with the leak detect patch, if you want me to try a version with a larger test or diagnostic patch, that would be straightforward. I'll drop you an email to explore other options. > Windows7 AccessDeniedException on commit log > --------------------------------------------- > > Key: CASSANDRA-6736 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6736 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Windows 7, quad core, 8GB RAM, single Cassandra node, > Cassandra 2.0.5 with leakdetect patch from CASSANDRA-6283 > Reporter: Bill Mitchell > Assignee: Joshua McKenzie > Attachments: 2014-02-18-22-16.log > > > Similar to the data file deletion of CASSANDRA-6283, under heavy load with > logged batches, I am seeing a problem where the Commit log cannot be deleted: > ERROR [COMMIT-LOG-ALLOCATOR] 2014-02-18 22:15:58,252 CassandraDaemon.java > (line 192) Exception in thread Thread[COMMIT-LOG-ALLOCATOR,5,main] > FSWriteError in C:\Program Files\DataStax > Community\data\commitlog\CommitLog-3-1392761510706.log > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:120) > at > org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:150) > at > org.apache.cassandra.db.commitlog.CommitLogAllocator$4.run(CommitLogAllocator.java:217) > at > org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95) > at > org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) > at java.lang.Thread.run(Unknown Source) > Caused by: java.nio.file.AccessDeniedException: C:\Program Files\DataStax > Community\data\commitlog\CommitLog-3-1392761510706.log > at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) > at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) > at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source) > at java.nio.file.Files.delete(Unknown Source) > at > org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:116) > ... 5 more > (Attached in 2014-02-18-22-16.log is a larger excerpt from the cassandra.log.) > In this particular case, I was trying to do 100 million inserts into two > tables in parallel, one with a single wide row and one with narrow rows, and > the error appeared after inserting 43,151,232 rows. So it does take a while > to trip over this timing issue. > It may be aggravated by the size of the batches. This test was writing 10,000 > rows to each table in a batch. > When I try switching the same test from using a logged batch to an unlogged > batch, and no such failure appears. So the issue could be related to the use > of large, logged batches, or it could be that unlogged batches just change > the probability of failure. -- This message was sent by Atlassian JIRA (v6.2#6252)