[
https://issues.apache.org/jira/browse/CASSANDRA-19779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870320#comment-17870320
]
Maxwell Guo edited comment on CASSANDRA-19779 at 8/2/24 2:30 AM:
-----------------------------------------------------------------
```
this is fine. I know about the existence of that. It does not matter it is at
both places because the second creation of the same directory is no-op. We also
can not just call the method which creates all directories in advance, because
if we did that, at the time we would call
DatabaseDescriptor.createAllDirectories(), this method would fail, because the
values of the directories are not set yet. They are all resolved after
applyConfig() is done. So the best solution is to just call this explicitly as
I did and keep the rest untouched otherwise it gets messy pretty fast.
```
[~smiklosovic] Thank you for your reply. I understand what you said and I agree
with your current approach, and +1 on what you have done , I just think that we
should add a line of log to explain why we created this commitlog directory
here or left some comments on the code .
I will create a ticket for part 2.
was (Author: maxwellguo):
``
this is fine. I know about the existence of that. It does not matter it is at
both places because the second creation of the same directory is no-op. We also
can not just call the method which creates all directories in advance, because
if we did that, at the time we would call
DatabaseDescriptor.createAllDirectories(), this method would fail, because the
values of the directories are not set yet. They are all resolved after
applyConfig() is done. So the best solution is to just call this explicitly as
I did and keep the rest untouched otherwise it gets messy pretty fast.
``
[~smiklosovic] Thank you for your reply. I understand what you said and I agree
with your current approach, and +1 on what you have done , I just think that we
should add a line of log to explain why we created this commitlog directory
here or left some comments on the code .
I will create a ticket for part 2.
> direct IO support is always evaluated to false upon the very first start of a
> node
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-19779
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19779
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Tools
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 5.0-rc
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When I extract the distribution tarball and I want to use tools in tools/bin,
> there is this warn log visible every time for tools when they are started
> (does not happen on "help" command, obviously)
> {code:java}
> WARN 14:25:11,835 Unable to determine block size for commit log directory:
> null {code}
> This is because we introduced this (1) in CASSANDRA-18464
> What that does is that it will go and try to create a temporary file in
> commit log directory to get "block size" for a "file store" that file is in.
> The problem with that is that when we just extract a tarball and run the
> tools - Cassandra was never started - then such commit log directory does not
> exist yet, so it tries to create a temporary file in a non-existing
> directory, which fails, hence the log message.
> The fix is to check if commitlog dir exists and return / skip the resolution
> of block size if it does not.
> Another approach might be to check if this is executed in the context of a
> tool and skip it from resolution altogether. The problem with this is that
> not all tools we have in bin/log call DatabaseDescriptor.
> toolInitialization() so we might combine these two.
> (1)
> [https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L1455-L1462]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
