Re: Why shaded Datastax java-driver?
Well good to know. Then I think the optional="true" attribute of the java driver in build.xml is misleading. If you didn't include the java driver, you're not able to build cassandra as far as I'm trying. I've already suggested a cassandra-common.jar in another topic (Cassandra client) and I'm glad that I'm not the only one thinking about such thing. Is there any chance that the idea would be considered by upstream? - Original Message - > Some of the tools use the driver, and there is some reliance on classes > for user defined types that come from the driver. I suppose ideally > these would get split out into a cassandra-common.jar, or such. > > > "Shaded" in this case means that the jar contains code from netty, but > the package structure is changed so that there are no conflicts with a > real netty jar. >
Cassandra client
Greetings, I'm interested in having cassandra client installed separately. I thought that java classes in cassandra-all.jar are those needed by cassandra server. Also that the cassandra-clientutil.jar would hold all the necessary classes to run nodetool and all other sstabletools. My asumptions were wrong so I wonder, what is the meaning of classes to jars distribution here in the latest 3.9 release. Wouldn't it be more convenient to distributed the classes to jars like this? cassandra-common : classes needed by both server and client-utilities (and stress) cassandra-server : classes needed by server only cassnadra-client : classes needed by client only I know there are two extra jars in the latest 3.9 release (thrift, stress). I also know that the thrift support is going to be dropped in future versions so I realy don't care about casses in thrift.jar. And the stress tools once again I guess this jar should contain only those extra classes needed by stress tools. Thaks for your replies. Tomas
Why shaded Datastax java-driver?
Hello list, why is datastax java-driver so tightly fixed to the cassandra base? Is there any reason to have it as a shaded dependency? And what even a shaded dependency is? I'd be glad for any response. Thanks Tomas
Re: Three scripts needed to run the server, Why?
Thanks guys for joining the discussion, I hope you don't mind if I continue to
argue a bit more.
The core intelligence and functionality of Cassandra server lays in the Java
classes, which reside in jar archives. This is the place where the main
functionality updates take place. To ease the use of the classes there is,
let's call it "wrapper" script (bin/cassandra), which sets up the environment
for the classes to provide the functionality. This wrapper uses two other
scripts: one of which sits in bin (the include) and the other in etc (the env
file). I agree that the files in bin should not be edited by the users, but the
following quotes from the wrapper script state the opposite:
"Any serious use-case though will likely require customization of the include."
"Developers and enthusiasts can put a customized include file at
~/.cassandra.in.sh."
According to these the include file is no different from the environment file.
But why would you have two separate files meant for the same purpose? What is
more important is that to "configure" the options in both scripts the user has
to be somewhat familiar with bash. The "bashy" stuff could be well hidden from
the user in the wrapper script and the configuration options could be sitting
in the cassandra.yaml file in the key-value pairs fashion like the other ones.
When solving some issues that the users run into they would provide just a
single configuration file and the maintainer would easily reproduce the issue
by plugging in the single config file. Regarding the updating, only the wrapper
script would be updated of course and the user modified config file would stay
untouched in etc directory. Speaking about flexibility and the use-case when
there is a upstream default, admin specific and user specific configuration, it
is not a problem at all. Making the config file modular would do the job. There
won't be any duplicity. In case user does not care about the configuration and
just wants to run the server out of the box there are always default options
embedded in the java classes.
What do you think? I don't think my solution is ideal and I'd be glad to hear
where my assumptions are wrong.
Tomas
- Original Message -
> Standard unix/linux systems policy is that editable configurable files
> go under /etc. It is not proper to edit files under /{s}bin or
> /usr/{s}bin. $PATH contains /{s}bin and /usr/{s}bin files as executables
> that can be run by a user, so that's why the basic separation of the
> runnable files and tunable configuration files that are intended to be
> edited.
>
> There may be multiple executables in /{s}bin and /usr/{s}bin that use
> the common configurations under /etc - they may not be just single
> purpose. If there were all configs contained in each executable script,
> we would be repeating ourselves, as well as possibly creating unexpected
> results, if they are not all aligned by the user.
>
> Additionally, package managers like apt and rpm should not overwrite
> configuration files, if they have been edited, so hopefully, upgrades
> won't hose a user-edited change under /etc. (Back them up, regardless).
> If there is a fundamental change to the executables it /usr/{s}bin, they
> will be overwritten by package managers, since users are expected to not
> edit those.
>
> This is all really basic system administration and common policy for
> most different software packages. Group common configs where they are
> meant to be edited and split out various configs when it makes sense or
> they may be utilized by various executables.
>
> The user may deviate from these common practices as they see fit, but
> may also introduce self inflicted problems. :)
>
> --
> Kind regards,
> Michael
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
Three scripts needed to run the server, Why?
Greetings, I've been working with Cassandra for more than a year but I still wonder about one thing: To run the server there is a bash script (cassandra) which uses another script (cassandra.in.sh) which uses yet another bash script (cassandra-env.sh). What is the reason behind this? Why there is not only a single file setting up the environment and running the server? Thanks for your answers Tomas - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Three scripts needed to run the server, Why?
Thanks for the answer, it did not help much. I have read this several times and this I already know, It still does not answer the question, why there is the need for three files instead of a single file. Not to mention multiple different config files. All these files are more or less configuration file which set up the environment and properties of the server. Why can't there be a single file that one would modify in order to tweak the server to his or her needs. In the current situation you have to search many different files to find the place where the option is configured. - Original Message - > > The bin/cassandra script has an explanation > (https://github.com/apache/cassandra/blob/trunk/bin/cassandra#L24): > > # As a convenience, a fragment of shell is sourced in order to set one or > # more of these variables. This so-called `include' can be placed in a > # number of locations and will be searched for in order. The lowest > # priority search path is the same directory as the startup script, and > # since this is the location of the sample in the project tree, it should > # almost work Out Of The Box. > # > # Any serious use-case though will likely require customization of the > # include. For production installations, it is recommended that you copy > # the sample to one of /usr/share/cassandra/cassandra.in.sh, > # /usr/local/share/cassandra/cassandra.in.sh, or > # /opt/cassandra/cassandra.in.sh and make your modifications there. > # > #[...] > # > # If you would rather configure startup entirely from the environment, you > # can disable the include by exporting an empty CASSANDRA_INCLUDE, or by > # ensuring that no include files exist in the aforementioned search list. > # Be aware that you will be entirely responsible for populating the needed > # environment variables. > > You can use just a single environment file, if you so wish. > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Porting cqlsh to Python 3
Hi, the clock for Python 2.7 is ticking [1], and yes, there are still more than two years, but sooner or later cqlsh should be ported to Python 3. Is anybody already working on it or just considers to work on it? What is the long time plan for cqlsh? Should it be in Python forever or is the another plan? What was the original reason for the client for Cassandra being written in python? Too many questions? Sorry for that, I'm just curious. My main idea was to get involved in the discussion about cqlsh and python 3. And if there is not one already I would like to start it. Tomas [1] https://pythonclock.org/ - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Porting cqlsh to Python 3
Yeah thanks, I've seen this issue on jira, but it is pretty outdated, and I wondered if there are any other means of discussing the topic other than the old jira. - Original Message - > Related: https://issues.apache.org/jira/browse/CASSANDRA-10190 > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Cassandra did not start listening for CQL clients
Thanks Mike, now I remember this option, but I thought it was set to true by default. Any reasons why false is the default? - Original Message - > Hi Tomas, > > Try adding: > > start_native_transport: true > > to your config. > > Cheers, > MikeA > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Cassandra did not start listening for CQL clients
Done. https://issues.apache.org/jira/browse/CASSANDRA-13656 - Original Message - > Open a jira for it and lets change it? > > > -- > Jeff Jirsa > > > > On Jun 29, 2017, at 8:04 AM, Mike Adamson <madam...@datastax.com> wrote: > > > > I've honestly no idea but it is still defaulting to false in Config.java. > > I'm assuming it will change to defaulting to true when thrift is finally > > removed. > > > >> On Thu, 29 Jun 2017 at 15:34 Tomas Repik <tre...@redhat.com> wrote: > >> > >> Thanks Mike, > >> > >> now I remember this option, but I thought it was set to true by default. > >> Any reasons why false is the default? > >> > >> - Original Message - > >>> Hi Tomas, > >>> > >>> Try adding: > >>> > >>> start_native_transport: true > >>> > >>> to your config. > >>> > >>> Cheers, > >>> MikeA > >>> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Cassandra did not start listening for CQL clients
Hello, I've tried to create a minimal config file that is needed to start Cassandra server. Is it even possible? What is the minimal set of options that need to be set in the cassandra.yaml file in order for Cassandra to run flawlessly. These are the options I use: commitlog_sync: periodic commitlog_sync_period_in_ms: 1 partitioner: org.apache.cassandra.dht.Murmur3Partitioner endpoint_snitch: SimpleSnitch seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: "127.0.0.1" I gotta be missing something because the server does not start listening for CQL clients and cqlsh can't be used therefore. Thanks in advance for your replies. Tomas - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Is concurrent_batchlog_writes option used/implemented?
Hi, while browsing the options for setting up Cassandra at [1] I found an option `concurrent_batchlog_writes`. This is mentioned only in this documentation but I could not find it in the config file nor in the source code. Any comments regarding this are welcome. Thanks Tomas [1] https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html#configCassandra_yaml__commonProps - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Is concurrent_batchlog_writes option used/implemented?
And yet another glitch in the documentation at: https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html#configCassandra_yaml__cqlTruncateequest_timeout_in_ms I guess it should be truncate_timeout_in_ms instead. Is there a more proper way I should use to report these kind of issues? If yes, thanks for giving any directions. Tomas - Original Message - > Thanks for information I thought this would be the case ... > > I found another option that is not documented properly: > allocate_tokens_for_local_replication_factor [1] option is not found in any > config file instead the allocate_tokens_for_keyspace option is present. I > guess it is the replacement for the former but I can't see it documented > anywhere. Thanks for clarification. > > Tomas > > [1] > https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html#configCassandra_yaml__allocate_tokens_for_local_replication_factor > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
