[jira] [Created] (CASSANDRA-12840) Cassandra doesn't start on MINGW32 (Windows)
Amichai Rothman created CASSANDRA-12840:
---
Summary: Cassandra doesn't start on MINGW32 (Windows)
Key: CASSANDRA-12840
URL: https://issues.apache.org/jira/browse/CASSANDRA-12840
Project: Cassandra
Issue Type: Bug
Environment: MINGW32_NT-6.1 on Windows 7 (e.g. git bash)
Reporter: Amichai Rothman
The Cassandra script fails due to missing cygpath path conversion in a MINGW32
environment, such as when running from git bash (installed by default when
installing Git for Windows).
The fix is to modify the line
{quote}
CYGWIN*)
{quote}
to
{quote}
CYGWIN*|MINGW*)
{quote}
in the cassandra script, in the case statement that checks for a cygwin
environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12840) Cassandra doesn't start on MINGW32 (Windows)
[
https://issues.apache.org/jira/browse/CASSANDRA-12840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amichai Rothman updated CASSANDRA-12840:
Attachment: CASSANDRA-12840.patch
> Cassandra doesn't start on MINGW32 (Windows)
>
>
> Key: CASSANDRA-12840
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12840
> Project: Cassandra
> Issue Type: Bug
> Environment: MINGW32_NT-6.1 on Windows 7 (e.g. git bash)
>Reporter: Amichai Rothman
> Attachments: CASSANDRA-12840.patch
>
>
> The Cassandra script fails due to missing cygpath path conversion in a
> MINGW32 environment, such as when running from git bash (installed by default
> when installing Git for Windows).
> The fix is to modify the line
> {quote}
> CYGWIN*)
> {quote}
> to
> {quote}
> CYGWIN*|MINGW*)
> {quote}
> in the cassandra script, in the case statement that checks for a cygwin
> environment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-5338) scripts fail when paths contain space
Amichai Rothman created CASSANDRA-5338: -- Summary: scripts fail when paths contain space Key: CASSANDRA-5338 URL: https://issues.apache.org/jira/browse/CASSANDRA-5338 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.2.2 Environment: Kubuntu 12.10 (GNU bash 4.2.37), and Windows XP (msysgit GNU bash 3.1.0) Reporter: Amichai Rothman Priority: Minor The shell scripts fail when the cassandra or java dirs contain spaces. -- 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
[jira] [Updated] (CASSANDRA-5338) scripts fail when paths contain space
[ https://issues.apache.org/jira/browse/CASSANDRA-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amichai Rothman updated CASSANDRA-5338: --- Attachment: fix_spaces_in_paths.patch The patch needs testing on other platforms. > scripts fail when paths contain space > - > > Key: CASSANDRA-5338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5338 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.2.2 > Environment: Kubuntu 12.10 (GNU bash 4.2.37), and Windows XP (msysgit > GNU bash 3.1.0) >Reporter: Amichai Rothman >Priority: Minor > Attachments: fix_spaces_in_paths.patch > > > The shell scripts fail when the cassandra or java dirs contain spaces. -- 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
[jira] [Commented] (CASSANDRA-5338) scripts fail when paths contain space
[ https://issues.apache.org/jira/browse/CASSANDRA-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13600975#comment-13600975 ] Amichai Rothman commented on CASSANDRA-5338: btw, this problem would be easily alleviated if there wasn't so much duplication in the scripts, some of which get updated and others forgotten... why not consolidate the duplication into a single master script? For backwards compatibility, the existing scripts can continue to exist but just call the master script with appropriate parameters. > scripts fail when paths contain space > - > > Key: CASSANDRA-5338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5338 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.2.2 > Environment: Kubuntu 12.10 (GNU bash 4.2.37), and Windows XP (msysgit > GNU bash 3.1.0) >Reporter: Amichai Rothman >Priority: Minor > Attachments: fix_spaces_in_paths.patch > > > The shell scripts fail when the cassandra or java dirs contain spaces. -- 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
[jira] [Created] (CASSANDRA-5340) use getopts instead of getopt in shell script
Amichai Rothman created CASSANDRA-5340: -- Summary: use getopts instead of getopt in shell script Key: CASSANDRA-5340 URL: https://issues.apache.org/jira/browse/CASSANDRA-5340 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.2 Environment: Windows XP msysgit GNU bash 3.1.0 Reporter: Amichai Rothman Priority: Minor I don't know what the officially supported platforms are or what versions of sh they support... however I do know that the cassandra startup script fails on at least one platform (Windows XP/msysgit) since it uses the external utility getopt which is not available there. Using the shell built-in getopts command instead, or parsing the command line manually, would fix the problem. I'm no shell expert, but a little searching came up with the fact that the getopt utility is not required by POSIX (which a script comment claims needs to be adhered to) whereas getopts is standard and more portable. Some claim getopt is better when long option names need to be supported, however cassandra doesn't use those anyway. Unless someone knows of a supported platform that doesn't support getopts, the script should be changed to use it instead of getopt. If such a platform exists, perhaps using neither (manually parsing args) should be considered - it's not too much work, and there are plenty of existing templates for doing this to build on, and that would provide the best portability across platforms. -- 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
[jira] [Commented] (CASSANDRA-6471) Executing a prepared CREATE KEYSPACE multiple times doesn't work
[ https://issues.apache.org/jira/browse/CASSANDRA-6471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13846142#comment-13846142 ] Amichai Rothman commented on CASSANDRA-6471: Does this apply to 2.0.x as well? > Executing a prepared CREATE KEYSPACE multiple times doesn't work > > > Key: CASSANDRA-6471 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6471 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Trivial > Fix For: 1.2.13 > > Attachments: 6471.txt > > > See user reports on the java driver JIRA: > https://datastax-oss.atlassian.net/browse/JAVA-223. Preparing CREATE KEYSPACE > queries is not particularly useful but there is no reason for it to be broken. > The reason is that calling KSPropDef/CFPropDef.validate() methods are not > idempotent. Attaching simple patch to fix. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CASSANDRA-5895) JDK7 u40 stack size fixes
[
https://issues.apache.org/jira/browse/CASSANDRA-5895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781344#comment-13781344
]
Amichai Rothman commented on CASSANDRA-5895:
I'm having the same problem with Oracle JDK 1.7.0_40. Will the fix be applied
on 1.2.x as well? Or is that no longer supported?
> JDK7 u40 stack size fixes
> -
>
> Key: CASSANDRA-5895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5895
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: cassandra, as launched by the default script by JDK
> 1.7.0_40 using CCM
>Reporter: John Sumsion
> Attachments:
> 0001-Increasing-stack-size-to-avoid-error-on-OpenJDK-7-u4.patch,
> 0002-Ignoring-files-produced-by-ant-build.patch
>
>
> I use Archlinux, and the latest OpenJDK, and run my cassandra via @pcmanus's
> ccm.
> When I tried the cassandra-2.0.0 branch via:
> {noformat}
> $ ccm create dev -v git:cassandra-2.0.0
> {noformat}
> Then when I say:
> {noformat}
> $ ccm populate -n3
> $ ccm node1 start -v
> {noformat}
> I get the following error:
> {noformat}
> xss = -ea -javaagent:/home/blah/.ccm/repository/1.2.2/lib/jamm-0.2.5.jar
> -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1985M -Xmx1985M
> -Xmn496M -XX:+HeapDumpOnOutOfMemoryError -Xss180k
> The stack size specified is too small, Specify at least 228k
> Error starting node node1
> Standard error output is:
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> {noformat}
> I tracked it down to conf/cassandra-env.sh, and changed the -Xss180k =>
> -Xss228k and the node started.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-5338) scripts fail when paths contain space
[ https://issues.apache.org/jira/browse/CASSANDRA-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619566#comment-13619566 ] Amichai Rothman commented on CASSANDRA-5338: The duplication thing is a related thought that could prevent the issue from creeping back again in the future, and making the fix easier, but the actual bug is the whitespace handling, which is unrelated to bug #5301 (which is resolved as wontfix in any case). > scripts fail when paths contain space > - > > Key: CASSANDRA-5338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5338 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 1.2.2 > Environment: Kubuntu 12.10 (GNU bash 4.2.37), and Windows XP (msysgit > GNU bash 3.1.0) >Reporter: Amichai Rothman >Priority: Minor > Attachments: fix_spaces_in_paths.patch > > > The shell scripts fail when the cassandra or java dirs contain spaces. -- 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
[jira] [Commented] (CASSANDRA-12840) Cassandra doesn't start on MINGW32 (Windows)
[
https://issues.apache.org/jira/browse/CASSANDRA-12840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360636#comment-16360636
]
Amichai Rothman commented on CASSANDRA-12840:
-
Any reason this wasn't fixed in over a year? It's a tiny and straightforward
fix.
> Cassandra doesn't start on MINGW32 (Windows)
>
>
> Key: CASSANDRA-12840
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12840
> Project: Cassandra
> Issue Type: Bug
> Environment: MINGW32_NT-6.1 on Windows 7 (e.g. git bash)
>Reporter: Amichai Rothman
>Priority: Major
> Attachments: CASSANDRA-12840.patch
>
>
> The Cassandra script fails due to missing cygpath path conversion in a
> MINGW32 environment, such as when running from git bash (installed by default
> when installing Git for Windows).
> The fix is to modify the line
> {quote}
> CYGWIN*)
> {quote}
> to
> {quote}
> CYGWIN*|MINGW*)
> {quote}
> in the cassandra script, in the case statement that checks for a cygwin
> environment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11901) Per-query timestamps in batches
[ https://issues.apache.org/jira/browse/CASSANDRA-11901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16719440#comment-16719440 ] Amichai Rothman commented on CASSANDRA-11901: - Yes please. This will allow creating ordered batch statements, which are needed in some situations and requested by many users who fall into the unordered batch pitfall (see several other cassandra/datastax issues). Adding "USING TIMESTAMP" to many queries in an application is error prone and hardly a reasonable solution when it could/should be done generically in a few lines of code (e.g. a trivial OrderedBatchStatement class using an internal client timestamp generator). > Per-query timestamps in batches > --- > > Key: CASSANDRA-11901 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11901 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Michael Penick >Priority: Minor > Labels: client-impacting, protocolv5 > > A possible enhancement to be added in protocol V5? > This would allow queries in batches to send timestamps at the protocol level > instead of having to append "USING TIMESTAMP" to constituent query strings. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-8812) JVM Crashes on Windows x86
Amichai Rothman created CASSANDRA-8812: -- Summary: JVM Crashes on Windows x86 Key: CASSANDRA-8812 URL: https://issues.apache.org/jira/browse/CASSANDRA-8812 Project: Cassandra Issue Type: Bug Environment: Windows 7 running x86(32-bit) Oracle JDK 1.8.0_u31 Reporter: Amichai Rothman Attachments: crashtest.tgz Under Windows (32 or 64 bit) with the 32-bit Oracle JDK, the JVM may crash due to EXCEPTION_ACCESS_VIOLATION. This happens inconsistently. The attached test project can recreate the crash - sometimes it works successfully, sometimes there's a Java exception in the log, and sometimes the hotspot JVM crash shows up (regardless of whether the JUnit test results in success - you can ignore that). Run it a bunch of times to see the various outcomes. Note that both when the Java exception is thrown and when the JVM crashes, the stack trace is almost the same - they both eventually occur in CommitLogSegment.sync when accessing the buffer (MappedByteBuffer): if it happens to be in buffer.force(), then the Java exception is thrown, and if it's in one of the buffer.put() calls before it, then the JVM crashes. This possibly exposes a JVM bug as well in this case. So it basically looks like a race condition which results in the buffer sometimes being used after it is no longer valid. I recreated this on a PC with Windows 7 64-bit running the 32-bit Oracle JDK, as well as on a modern.ie virtualbox image of Windows 7 32-bit running the JDK, and it happens both with JDK 7 and JDK 8. Also defining an explicit dependency on cassandra 2.1.2 (as opposed to the cassandra-unit dependency on 2.1.0) doesn't make a difference. At some point in my testing I've also seen a Java-level exception on Linux, but I can't recreate it at the moment with this test project, so I can't guarantee it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8812) JVM Crashes on Windows x86
[ https://issues.apache.org/jira/browse/CASSANDRA-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amichai Rothman updated CASSANDRA-8812: --- Description: Under Windows (32 or 64 bit) with the 32-bit Oracle JDK, the JVM may crash due to EXCEPTION_ACCESS_VIOLATION. This happens inconsistently. The attached test project can recreate the crash - sometimes it works successfully, sometimes there's a Java exception in the log, and sometimes the hotspot JVM crash shows up (regardless of whether the JUnit test results in success - you can ignore that). Run it a bunch of times to see the various outcomes. It also contains a sample hotspot error log. Note that both when the Java exception is thrown and when the JVM crashes, the stack trace is almost the same - they both eventually occur when the PERIODIC-COMMIT-LOG-SYNCER thread calls CommitLogSegment.sync and accesses the buffer (MappedByteBuffer): if it happens to be in buffer.force(), then the Java exception is thrown, and if it's in one of the buffer.put() calls before it, then the JVM crashes. This possibly exposes a JVM bug as well in this case. So it basically looks like a race condition which results in the buffer sometimes being used after it is no longer valid. I recreated this on a PC with Windows 7 64-bit running the 32-bit Oracle JDK, as well as on a modern.ie virtualbox image of Windows 7 32-bit running the JDK, and it happens both with JDK 7 and JDK 8. Also defining an explicit dependency on cassandra 2.1.2 (as opposed to the cassandra-unit dependency on 2.1.0) doesn't make a difference. At some point in my testing I've also seen a Java-level exception on Linux, but I can't recreate it at the moment with this test project, so I can't guarantee it. was: Under Windows (32 or 64 bit) with the 32-bit Oracle JDK, the JVM may crash due to EXCEPTION_ACCESS_VIOLATION. This happens inconsistently. The attached test project can recreate the crash - sometimes it works successfully, sometimes there's a Java exception in the log, and sometimes the hotspot JVM crash shows up (regardless of whether the JUnit test results in success - you can ignore that). Run it a bunch of times to see the various outcomes. Note that both when the Java exception is thrown and when the JVM crashes, the stack trace is almost the same - they both eventually occur in CommitLogSegment.sync when accessing the buffer (MappedByteBuffer): if it happens to be in buffer.force(), then the Java exception is thrown, and if it's in one of the buffer.put() calls before it, then the JVM crashes. This possibly exposes a JVM bug as well in this case. So it basically looks like a race condition which results in the buffer sometimes being used after it is no longer valid. I recreated this on a PC with Windows 7 64-bit running the 32-bit Oracle JDK, as well as on a modern.ie virtualbox image of Windows 7 32-bit running the JDK, and it happens both with JDK 7 and JDK 8. Also defining an explicit dependency on cassandra 2.1.2 (as opposed to the cassandra-unit dependency on 2.1.0) doesn't make a difference. At some point in my testing I've also seen a Java-level exception on Linux, but I can't recreate it at the moment with this test project, so I can't guarantee it. > JVM Crashes on Windows x86 > -- > > Key: CASSANDRA-8812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8812 > Project: Cassandra > Issue Type: Bug > Environment: Windows 7 running x86(32-bit) Oracle JDK 1.8.0_u31 >Reporter: Amichai Rothman > Attachments: crashtest.tgz > > > Under Windows (32 or 64 bit) with the 32-bit Oracle JDK, the JVM may crash > due to EXCEPTION_ACCESS_VIOLATION. This happens inconsistently. The attached > test project can recreate the crash - sometimes it works successfully, > sometimes there's a Java exception in the log, and sometimes the hotspot JVM > crash shows up (regardless of whether the JUnit test results in success - you > can ignore that). Run it a bunch of times to see the various outcomes. It > also contains a sample hotspot error log. > Note that both when the Java exception is thrown and when the JVM crashes, > the stack trace is almost the same - they both eventually occur when the > PERIODIC-COMMIT-LOG-SYNCER thread calls CommitLogSegment.sync and accesses > the buffer (MappedByteBuffer): if it happens to be in buffer.force(), then > the Java exception is thrown, and if it's in one of the buffer.put() calls > before it, then the JVM crashes. This possibly exposes a JVM bug as well in > this case. So it basically looks like a race condition which results in the > buffer sometimes being used after it is no longer valid. > I recreated this on a PC with Windows 7 64-bit running the 32-bit Oracle JDK, > as well as on a modern.ie virtualbox image of Windows 7 32-bi
[jira] [Commented] (CASSANDRA-8812) JVM Crashes on Windows x86
[ https://issues.apache.org/jira/browse/CASSANDRA-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14323297#comment-14323297 ] Amichai Rothman commented on CASSANDRA-8812: I don't know if it's related or not, but it's suspicious that the segment's sync method in some cases closes itself without it being removed from its associated segment manager... > JVM Crashes on Windows x86 > -- > > Key: CASSANDRA-8812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8812 > Project: Cassandra > Issue Type: Bug > Environment: Windows 7 running x86(32-bit) Oracle JDK 1.8.0_u31 >Reporter: Amichai Rothman > Attachments: crashtest.tgz > > > Under Windows (32 or 64 bit) with the 32-bit Oracle JDK, the JVM may crash > due to EXCEPTION_ACCESS_VIOLATION. This happens inconsistently. The attached > test project can recreate the crash - sometimes it works successfully, > sometimes there's a Java exception in the log, and sometimes the hotspot JVM > crash shows up (regardless of whether the JUnit test results in success - you > can ignore that). Run it a bunch of times to see the various outcomes. It > also contains a sample hotspot error log. > Note that both when the Java exception is thrown and when the JVM crashes, > the stack trace is almost the same - they both eventually occur when the > PERIODIC-COMMIT-LOG-SYNCER thread calls CommitLogSegment.sync and accesses > the buffer (MappedByteBuffer): if it happens to be in buffer.force(), then > the Java exception is thrown, and if it's in one of the buffer.put() calls > before it, then the JVM crashes. This possibly exposes a JVM bug as well in > this case. So it basically looks like a race condition which results in the > buffer sometimes being used after it is no longer valid. > I recreated this on a PC with Windows 7 64-bit running the 32-bit Oracle JDK, > as well as on a modern.ie virtualbox image of Windows 7 32-bit running the > JDK, and it happens both with JDK 7 and JDK 8. Also defining an explicit > dependency on cassandra 2.1.2 (as opposed to the cassandra-unit dependency on > 2.1.0) doesn't make a difference. At some point in my testing I've also seen > a Java-level exception on Linux, but I can't recreate it at the moment with > this test project, so I can't guarantee it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8812) JVM Crashes on Windows x86
[
https://issues.apache.org/jira/browse/CASSANDRA-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14324775#comment-14324775
]
Amichai Rothman commented on CASSANDRA-8812:
Sure, I just ran it a few more times (with cassandra-all 2.1.2, if any of the
line numbers changed) and got several of these:
{noformat}
2015-02-17 11:35:13,470 | PERIODIC-COMMIT-LOG-SYNCER | o.a.c.d.c.CommitLog |
ERROR | CommitLog.java:367 | Failed to persist commits to disk. Commit disk
failure policy is stop; terminating thread
org.apache.cassandra.io.FSWriteError: java.io.IOException: The handle is invalid
at
org.apache.cassandra.db.commitlog.CommitLogSegment.sync(CommitLogSegment.java:329)
~[cassandra-all-2.1.2.jar:2.1.2]
at
org.apache.cassandra.db.commitlog.CommitLog.sync(CommitLog.java:195)~[cassandra-all-2.1.2.jar:2.1.2]
at
org.apache.cassandra.db.commitlog.AbstractCommitLogService$1.run(AbstractCommitLogService.java:81)
~[cassandra-all-2.1.2.jar:2.1.2]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_31]
Caused by: java.io.IOException: The handle is invalid
at java.nio.MappedByteBuffer.force0(Native Method) ~[na:1.8.0_31]
at java.nio.MappedByteBuffer.force(MappedByteBuffer.java:203)
~[na:1.8.0_31]
at
org.apache.cassandra.db.commitlog.CommitLogSegment.sync(CommitLogSegment.java:315)
~[cassandra-all-2.1.2.jar:2.1.2]
... 3 common frames omitted
{noformat}
However in the past I also got exceptions with an exactly identical stack trace
other than a different IOException message "Attempt to access invalid address"
instead of "The handle is invalid".
> JVM Crashes on Windows x86
> --
>
> Key: CASSANDRA-8812
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8812
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7 running x86(32-bit) Oracle JDK 1.8.0_u31
>Reporter: Amichai Rothman
>Assignee: Joshua McKenzie
> Attachments: crashtest.tgz
>
>
> Under Windows (32 or 64 bit) with the 32-bit Oracle JDK, the JVM may crash
> due to EXCEPTION_ACCESS_VIOLATION. This happens inconsistently. The attached
> test project can recreate the crash - sometimes it works successfully,
> sometimes there's a Java exception in the log, and sometimes the hotspot JVM
> crash shows up (regardless of whether the JUnit test results in success - you
> can ignore that). Run it a bunch of times to see the various outcomes. It
> also contains a sample hotspot error log.
> Note that both when the Java exception is thrown and when the JVM crashes,
> the stack trace is almost the same - they both eventually occur when the
> PERIODIC-COMMIT-LOG-SYNCER thread calls CommitLogSegment.sync and accesses
> the buffer (MappedByteBuffer): if it happens to be in buffer.force(), then
> the Java exception is thrown, and if it's in one of the buffer.put() calls
> before it, then the JVM crashes. This possibly exposes a JVM bug as well in
> this case. So it basically looks like a race condition which results in the
> buffer sometimes being used after it is no longer valid.
> I recreated this on a PC with Windows 7 64-bit running the 32-bit Oracle JDK,
> as well as on a modern.ie virtualbox image of Windows 7 32-bit running the
> JDK, and it happens both with JDK 7 and JDK 8. Also defining an explicit
> dependency on cassandra 2.1.2 (as opposed to the cassandra-unit dependency on
> 2.1.0) doesn't make a difference. At some point in my testing I've also seen
> a Java-level exception on Linux, but I can't recreate it at the moment with
> this test project, so I can't guarantee it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8812) JVM Crashes on Windows x86
[ https://issues.apache.org/jira/browse/CASSANDRA-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14326853#comment-14326853 ] Amichai Rothman commented on CASSANDRA-8812: I ran a build from the 2.1.2 tag and recreated the exceptions and JVM crash, then applied the attached patch, rebuilt and ran it quite a few more times and was unable to reproduce them again, so the patch seems to fix the issue. I still get occasional failures (which were there before the patch as well) due to what looks like CASSANDRA-8390, but that's a separate issue. Thanks guys for the quick solution! > JVM Crashes on Windows x86 > -- > > Key: CASSANDRA-8812 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8812 > Project: Cassandra > Issue Type: Bug > Environment: Windows 7 running x86(32-bit) Oracle JDK 1.8.0_u31 >Reporter: Amichai Rothman >Assignee: Benedict > Attachments: 8812.txt, crashtest.tgz > > > Under Windows (32 or 64 bit) with the 32-bit Oracle JDK, the JVM may crash > due to EXCEPTION_ACCESS_VIOLATION. This happens inconsistently. The attached > test project can recreate the crash - sometimes it works successfully, > sometimes there's a Java exception in the log, and sometimes the hotspot JVM > crash shows up (regardless of whether the JUnit test results in success - you > can ignore that). Run it a bunch of times to see the various outcomes. It > also contains a sample hotspot error log. > Note that both when the Java exception is thrown and when the JVM crashes, > the stack trace is almost the same - they both eventually occur when the > PERIODIC-COMMIT-LOG-SYNCER thread calls CommitLogSegment.sync and accesses > the buffer (MappedByteBuffer): if it happens to be in buffer.force(), then > the Java exception is thrown, and if it's in one of the buffer.put() calls > before it, then the JVM crashes. This possibly exposes a JVM bug as well in > this case. So it basically looks like a race condition which results in the > buffer sometimes being used after it is no longer valid. > I recreated this on a PC with Windows 7 64-bit running the 32-bit Oracle JDK, > as well as on a modern.ie virtualbox image of Windows 7 32-bit running the > JDK, and it happens both with JDK 7 and JDK 8. Also defining an explicit > dependency on cassandra 2.1.2 (as opposed to the cassandra-unit dependency on > 2.1.0) doesn't make a difference. At some point in my testing I've also seen > a Java-level exception on Linux, but I can't recreate it at the moment with > this test project, so I can't guarantee it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8390) The process cannot access the file because it is being used by another process
[
https://issues.apache.org/jira/browse/CASSANDRA-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327600#comment-14327600
]
Amichai Rothman commented on CASSANDRA-8390:
I'm seeing the same exceptions. Running on a modern.ie virtualbox Windows 7
(32-bit) image with Oracle JDK 1.8.0u31 and a few utilities installed but no
antivirus. The issue is recreated easily when running the test project attached
to CASSANDRA-8812 (with an added cassandra-all 2.1.2 or 2.1.3 in the pom, with
or without the 8812 patch). The errors show up ~90% of the time when running
the test. I tried running the 'handle' utility many times during the tests, but
all of the cassandra data files show up as being used only by the java process
(I also ran the test with 'mvn test -DforkMode=never' to rule out any strange
interaction between the maven JVM and the test JVM.) It happens not only with
deletions but sometimes also with move/rename:
{noformat}
Caused by: java.nio.file.FileSystemException:
target\embeddedCassandra\data\system\schema_columnfamilies-45f5b36024bc3f83a3631034ea4fa697\system-schema_columnfamilies-tmp-ka-9-Index.db
->
target\embeddedCassandra\data\system\schema_columnfamilies-45f5b36024bc3f83a3631034ea4fa697\system-schema_columnfamilies-ka-9-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.8.0_31]
at
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
~[na:1.8.0_31]
at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301)
~[na:1.8.0_31]
at
sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
~[na:1.8.0_31]
at java.nio.file.Files.move(Files.java:1395) ~[na:1.8.0_31]
at
org.apache.cassandra.io.util.FileUtils.atomicMoveWithFallback(FileUtils.java:184)
~[cassandra-all-2.1.3-SNAPSHOT.jar:2.1.3-SNAPSHOT]
at
org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:166)
~[cassandra-all-2.1.3-SNAPSHOT.jar:2.1.3-SNAPSHOT]
... 18 common frames omitted
{noformat}
If there's any other info I can provide that might help, or run the test with
any patches, it's no problem to recreate. You might want to change the
resolution/status.
> 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: CassandraDiedWithDiskAccessModeStandardLogs.7z, FSD.PNG,
> NoHostAvailableLogs.zip
>
>
> {code}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:\
[jira] [Commented] (CASSANDRA-8390) The process cannot access the file because it is being used by another process
[
https://issues.apache.org/jira/browse/CASSANDRA-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327646#comment-14327646
]
Amichai Rothman commented on CASSANDRA-8390:
Is it possible that the issue isn't really with another process, but just
another thread in the same process or some fd leak from not closing/releasing
it properly somewhere under some circumstances?
> 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: CassandraDiedWithDiskAccessModeStandardLogs.7z, FSD.PNG,
> NoHostAvailableLogs.zip
>
>
> {code}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{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8390) The process cannot access the file because it is being used by another process
[
https://issues.apache.org/jira/browse/CASSANDRA-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14338277#comment-14338277
]
Amichai Rothman commented on CASSANDRA-8390:
Can someone please reopen this issue? Multiple users can recreate it, but being
closed we can't vote for it, and it may be overlooked by devs...
> 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: CassandraDiedWithDiskAccessModeStandardLogs.7z, FSD.PNG,
> NoHostAvailableLogs.zip
>
>
> {code}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{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8390) The process cannot access the file because it is being used by another process
[
https://issues.apache.org/jira/browse/CASSANDRA-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amichai Rothman updated CASSANDRA-8390:
---
Attachment: recreate-CASSANDRA-8390.tgz
Added recreate-CASSANDRA-8390.tgz test project for your convenience (see env
details in previous comment).
> 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: CassandraDiedWithDiskAccessModeStandardLogs.7z, FSD.PNG,
> NoHostAvailableLogs.zip, recreate-CASSANDRA-8390.tgz
>
>
> {code}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{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8153) PreparedStatements broken when column family is recreated
Amichai Rothman created CASSANDRA-8153: -- Summary: PreparedStatements broken when column family is recreated Key: CASSANDRA-8153 URL: https://issues.apache.org/jira/browse/CASSANDRA-8153 Project: Cassandra Issue Type: Bug Components: Core Reporter: Amichai Rothman The scenario: 1. Create a PreparedStatement which references some column family. 2. Cache the PreparedStatement instance (afaik this is standard practice). 3. Execute the statement - it works. 4. Drop the column family. 5. Recreate the column family. 6. Execute the statement - it fails (and will forever fail). This scenario worked properly on earlier versions. As of 2.1.0, it's broken - the prepared statement seems to be bound to the deleted column family and is not re-bound to the new one. At a glance, this may be caused by CASSANDRA-5202. Workaround: client code must invalidate its PreparedStatement cache when a DROP query is executed (on column family, keyspace, and possibly others). The best fix would be to keep the cf_ids as an internal implementation detail, and make sure the query (which references the column family by name) continues to work by re-resolving the cf to the new one, rather than breaking client code due to this implementation detail. An alternative fix would be to document this code-breaking change and instruct clients to implement the workaround in their prepared statement caches. I'm not familiar with any of these internals (other than the several hours I spent trying to figure out why my unit tests started failing), so if anything in this report is incorrect, feel free to correct it :-) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8390) The process cannot access the file because it is being used by another process
[
https://issues.apache.org/jira/browse/CASSANDRA-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346897#comment-14346897
]
Amichai Rothman commented on CASSANDRA-8390:
fwiw, I just recreated the environment from scratch to make sure no third-party
software is causing this:
1. Installed the Windows 7 VirtualBox VM from scratch (2G RAM, 2 processors).
2. Installed jdk-8u40-windows-i586.exe.
3. Installed (extracted) apache-maven-3.2.5.zip.
4. Added jdk and maven bin folders to system path, and added JAVA_HOME env
variable.
5. Extracted the attached project (converted to zip so it opens natively on
Windows).
6. Ran 'mvn test' from console in project folder.
Sure enough, the build failed due to this issue.
Host is Linux 64-bit (probably doesn't matter), with VM image on an
NTFS-formatted spinning disk (maybe speed matters).
> 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: CassandraDiedWithDiskAccessModeStandardLogs.7z, FSD.PNG,
> NoHostAvailableLogs.zip, recreate-CASSANDRA-8390.tgz
>
>
> {code}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{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8390) The process cannot access the file because it is being used by another process
[
https://issues.apache.org/jira/browse/CASSANDRA-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14347698#comment-14347698
]
Amichai Rothman commented on CASSANDRA-8390:
Is there any possible workaround that a client can use until we get to 3.0?
> 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: 3.0
>
> Attachments: CassandraDiedWithDiskAccessModeStandardLogs.7z, FSD.PNG,
> NoHostAvailableLogs.zip, recreate-CASSANDRA-8390.tgz
>
>
> {code}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{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8390) The process cannot access the file because it is being used by another process
[
https://issues.apache.org/jira/browse/CASSANDRA-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14348623#comment-14348623
]
Amichai Rothman commented on CASSANDRA-8390:
That's wonderful!
I can confirm that it works - I applied the CASSANDRA-8535 v2 patch, along with
the patch from CASSANDRA-8812, to the 2.1.3 tag and the test project which
previously failed on both issues now always succeeds.
Thanks [~JoshuaMcKenzie] for you work on these issues! Looking forward to a
2.1.4 that works on Windows...
Until then, I've added my vote to CASSANDRA-8535 for good morale :-)
> 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: 3.0
>
> Attachments: CassandraDiedWithDiskAccessModeStandardLogs.7z, FSD.PNG,
> NoHostAvailableLogs.zip, recreate-CASSANDRA-8390.tgz
>
>
> {code}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{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
