[jira] [Commented] (CASSANDRA-2356) make the debian package never start by default

[Dave Cunningham (JIRA)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195028#comment-14195028
 ] 

Dave Cunningham commented on CASSANDRA-2356:


As a new user this confused the hell out of me.  Not auto-starting in Debian is 
a good start.  It would also be good if Cassandra gave more useful error 
messages when nodes come together after being started on their own.

> make the debian package never start by default
> --
>
> Key: CASSANDRA-2356
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2356
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Jeremy Hanna
>Assignee: Michael Shuler
>Priority: Minor
>  Labels: debian, packaging
> Fix For: 3.0
>
> Attachments: 2356.txt
>
>
> Currently the debian package that installs cassandra starts cassandra by 
> default.  It sounds like that is a standard debian packaging convention.  
> However, if you want to bootstrap a new node and want to configure it before 
> it creates any sort of state information, it's a pain.  I would think that 
> the common use case would be to have it install all of the init scripts and 
> such but *not* have it start up by default.  That way an admin can configure 
> cassandra with seed, token, host, etc. information and then start it.  That 
> makes it easier to programmatically do this as well - have chef/puppet 
> install cassandra, do some configuration, then do the service start.
> With the current setup, it sounds like cassandra creates state on startup 
> that has to be cleaned before a new configuration can take effect.  So the 
> process of installing turns into:
> * install debian package
> * shutdown cassandra
> * clean out state (data/log dirs)
> * configure cassandra
> * start cassandra
> That seems suboptimal for the default case, especially when trying to 
> automate new nodes being bootstrapped.
> Another case might be when a downed node comes back up and starts by default 
> and tries to claim a token that has already been claimed by another newly 
> bootstrapped node.  Rob is more familiar with that case so I'll let him 
> explain it in the comments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CASSANDRA-8226) Cannot call a column 'timestamp'

[Dave Cunningham (JIRA)]

Dave Cunningham created CASSANDRA-8226:
--

 Summary: Cannot call a column 'timestamp'
 Key: CASSANDRA-8226
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8226
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: [cqlsh 5.0.1 | Cassandra 2.1.1 | CQL spec 3.2.0 | Native 
protocol v3]

Reporter: Dave Cunningham


create table test(date text, timestamp timeuuid, stuff text, PRIMARY KEY(date, 
timestamp));
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
insert into test(date, timestamp, stuff) values ('20141030', now(), 'test');
select * from test where date = '20141030' order by timestamp limit 1;
Traceback (most recent call last):
  File "bin/cqlsh", line 861, in onecmd
self.handle_statement(st, statementtext)
  File "bin/cqlsh", line 901, in handle_statement
return self.handle_parse_error(cmdword, tokens, parsed, srcstr)
  File "bin/cqlsh", line 910, in handle_parse_error
return self.perform_statement(cqlruleset.cql_extract_orig(tokens, srcstr))
  File "bin/cqlsh", line 935, in perform_statement
result = self.perform_simple_statement(stmt)
  File "bin/cqlsh", line 968, in perform_simple_statement
self.print_result(rows, self.parse_for_table_meta(statement.query_string))
  File "bin/cqlsh", line 946, in parse_for_table_meta
parsed = cqlruleset.cql_parse(query_string)[1]
IndexError: list index out of range




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)