[jira] [Created] (CASSANDRA-2791) Redhat spec file needs some enhancements for 0.8 and beyond
Redhat spec file needs some enhancements for 0.8 and beyond --- Key: CASSANDRA-2791 URL: https://issues.apache.org/jira/browse/CASSANDRA-2791 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 0.8.0 Reporter: Nate McCall Fix For: 0.8.2, 1.0 Version and Release need to be brought up to date. Also need to account for multiple 'apache-cassandra' jars. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2475) Prepared statements
[ https://issues.apache.org/jira/browse/CASSANDRA-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054089#comment-13054089 ] Nate McCall commented on CASSANDRA-2475: Usually I would side with Eric's point about re-use on these types of arguments, but in the context of a prepared statement, I'm willing to add some complexity hoops at the client level if it buys me a noticeable performance gain over a standard statement. Prepared statements --- Key: CASSANDRA-2475 URL: https://issues.apache.org/jira/browse/CASSANDRA-2475 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Eric Evans Labels: cql Fix For: 1.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2882) describe_ring should include datacenter/topology information
[ https://issues.apache.org/jira/browse/CASSANDRA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065496#comment-13065496 ] Nate McCall commented on CASSANDRA-2882: This should be considered related to CASSANDRA-1777 I think both of these are crucial to providing clients that can take advantage of topologies. describe_ring should include datacenter/topology information Key: CASSANDRA-2882 URL: https://issues.apache.org/jira/browse/CASSANDRA-2882 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Priority: Minor describe_ring is great for getting a list of nodes in the cluster, but it doesn't provide any information about the network topology which prevents it's use in a multi-dc setup. It would be nice if we added another list to the TokenRange object containing the DC information. Optimally I could have ask any Cassandra node for this information and on the client-side prefer local nodes but be able to fail to remote nodes without requiring another lookup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2938) NotFoundException doing a quick succession of insert/get's on the same CF or rowkey
[
https://issues.apache.org/jira/browse/CASSANDRA-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate McCall updated CASSANDRA-2938:
---
Description:
*Issue*
* A customer complained about pycassa.cassandra.c08.ttypes.NotFoundException:
NotFoundException()
* This issue is related to a quick succession of insert/get's.
* Customer's AWS instance on EBS: 1 row with 10K columns, with sleep code:
fails 1/10 inserts
* 3-node test cluster on Rackspace.
** We could not reproduce this with the sleep code left in. This was tested
with the SimpleStrategy and NetworkTopologyStrategy.
** 1 row with 10K columns, without sleep code: fails 1/500 inserts
** 10K row with 1 column, without sleep code: Script passes 2 in 5 attempts.
When it fails, it is at about the 4000-5000th insert.
*Stack*
{code}
Traceback (most recent call last):
File t910.py, line 56, in module
test()
File t910.py, line 43, in test
db.get('testraw', columns=[key, ])
File
/usr/local/lib/python2.6/dist-packages/pycassa-1.1.0-py2.6.egg/pycassa/columnfamily.py,
line 391, in get
read_consistency_level or self.read_consistency_level)
File
/usr/local/lib/python2.6/dist-packages/pycassa-1.1.0-py2.6.egg/pycassa/pool.py,
line 380, in new_f
result = getattr(super(ConnectionWrapper, self), f.__name__)(*args,
**kwargs)
File
/usr/local/lib/python2.6/dist-packages/pycassa-1.1.0-py2.6.egg/pycassa/cassandra/c08/Cassandra.py,
line 422, in get
return self.recv_get()
File
/usr/local/lib/python2.6/dist-packages/pycassa-1.1.0-py2.6.egg/pycassa/cassandra/c08/Cassandra.py,
line 449, in recv_get
raise result.nfe
pycassa.cassandra.c08.ttypes.NotFoundException: NotFoundException()
{code}
*Script - also attached*
{code}
#!/usr/bin/python
import time
import pycassa
from pycassa import system_manager
from pycassa.system_manager import *
def test():
m = pycassa.system_manager.SystemManager('cathy1:9160')
pool = pycassa.pool.ConnectionPool('testraw',
server_list=['cathy1:9160', ], timeout=5, pool_size=16,
max_overflow=0, prefill=False, pool_timeout=30, max_retries=8)
kspaces = m.list_keyspaces()
if not 'testraw' in kspaces:
m.create_keyspace('testraw', 3)
cfs = m.get_keyspace_column_families('testraw')
if 'testraw' not in cfs:
m.create_column_family('testraw', 'testraw',
comparator_type=system_manager.BYTES_TYPE,
default_validation_class=system_manager.BYTES_TYPE,
row_cache_size=1024 * 1024, key_cache_size=0)
db = pycassa.ColumnFamily(pool, 'testraw',
read_consistency_level=pycassa.ConsistencyLevel.QUORUM,
write_consistency_level=pycassa.ConsistencyLevel.QUORUM)
try:
for i in range(1):
print 'Inserting %d' % i
# The following code generates 1 row with 10K columns
key = str(i)
db.insert('testraw', {key: ''})
db.get('testraw', columns=[key, ])
# The following code generates 10K rows with 1 columns
#key = 'key' + str(i)
#db.insert(key, {str(i) : ''})
#db.get(key, columns=[str(i), ])
# time.sleep(.1)
finally:
print 'Done'
m.drop_keyspace('testraw')
if __name__ == '__main__':
test()
{code}
was:
*Issue*
* A customer complained about pycassa.cassandra.c08.ttypes.NotFoundException:
NotFoundException()
* This issue is related to a quick succession of insert/get's. See:
[http://support.datastax.com/tickets/910]
* Customer's AWS instance on EBS: 1 row with 10K columns, with sleep code:
fails 1/10 inserts
* 3-node test cluster on Rackspace.
** We could not reproduce this with the sleep code left in. This was tested
with the SimpleStrategy and NetworkTopologyStrategy.
** 1 row with 10K columns, without sleep code: fails 1/500 inserts
** 10K row with 1 column, without sleep code: Script passes 2 in 5 attempts.
When it fails, it is at about the 4000-5000th insert.
*Stack*
{code}
Traceback (most recent call last):
File t910.py, line 56, in module
test()
File t910.py, line 43, in test
db.get('testraw', columns=[key, ])
File
/usr/local/lib/python2.6/dist-packages/pycassa-1.1.0-py2.6.egg/pycassa/columnfamily.py,
line 391, in get
read_consistency_level or self.read_consistency_level)
File
/usr/local/lib/python2.6/dist-packages/pycassa-1.1.0-py2.6.egg/pycassa/pool.py,
line 380, in new_f
result = getattr(super(ConnectionWrapper, self), f.__name__)(*args,
**kwargs)
File
/usr/local/lib/python2.6/dist-packages/pycassa-1.1.0-py2.6.egg/pycassa/cassandra/c08/Cassandra.py,
line 422, in get
return
[jira] [Updated] (CASSANDRA-2998) Remove dependency on old version of cdh3 in any builds
[ https://issues.apache.org/jira/browse/CASSANDRA-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-2998: --- Attachment: 2998_0.8.txt (0.8) Removes CDH repo, uses hadoop 0.20.203.0 from maven central. Remove dependency on old version of cdh3 in any builds -- Key: CASSANDRA-2998 URL: https://issues.apache.org/jira/browse/CASSANDRA-2998 Project: Cassandra Issue Type: Task Reporter: Jeremy Hanna Labels: lhf Attachments: 2998_0.8.txt This is nothing against cloudera or cdh. For a time we had depended on a version of cdh3 which included a fix required to make hadoop output streaming work with Cassandra. However, in 0.8.x, output streaming support has been removed. We should therefore remove dependency on the cloudera maven repo and cdh and replace them with hadoop-0.20.203 or whatever the current stable release is for hadoop for the build. This likely just involves removing the cloudera maven repo and replacing the cdh maven build dependencies with apache stable release dependencies. This would be in the main build.xml. Worth checking would be the dependencies in the examples and/or contrib modules. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2998) Remove dependency on old version of cdh3 in any builds
[ https://issues.apache.org/jira/browse/CASSANDRA-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-2998: --- Attachment: 2998_1.0.txt Same for 1.0 Remove dependency on old version of cdh3 in any builds -- Key: CASSANDRA-2998 URL: https://issues.apache.org/jira/browse/CASSANDRA-2998 Project: Cassandra Issue Type: Task Reporter: Jeremy Hanna Labels: lhf Attachments: 2998_0.8.txt, 2998_1.0.txt This is nothing against cloudera or cdh. For a time we had depended on a version of cdh3 which included a fix required to make hadoop output streaming work with Cassandra. However, in 0.8.x, output streaming support has been removed. We should therefore remove dependency on the cloudera maven repo and cdh and replace them with hadoop-0.20.203 or whatever the current stable release is for hadoop for the build. This likely just involves removing the cloudera maven repo and replacing the cdh maven build dependencies with apache stable release dependencies. This would be in the main build.xml. Worth checking would be the dependencies in the examples and/or contrib modules. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3038) nodetool snapshot does not handle keyspace arguments correctly
nodetool snapshot does not handle keyspace arguments correctly -- Key: CASSANDRA-3038 URL: https://issues.apache.org/jira/browse/CASSANDRA-3038 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.4 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Given the following invocation: ./bin/nodetool snapshot Keyspace1 -t keyspace1_snapshot -h localhost Snapshots are made for all keyspaces Given a multi-keyspace invocation: ./bin/nodetool snapshot Keyspace1 Keyspace2 Keyspac3 -t keyspace1_snapshot -h localhost Snapshots will be made for Keyspace2 and Keyspace3 but not Keyspace1. It appears there is just some antiquated command argument noodling in NodeCmd#handleSnapshots -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3038) nodetool snapshot does not handle keyspace arguments correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-3038: --- Attachment: 3038.txt Change to just make a copy of the cmdArgs array without modifying position. nodetool snapshot does not handle keyspace arguments correctly -- Key: CASSANDRA-3038 URL: https://issues.apache.org/jira/browse/CASSANDRA-3038 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.4 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Attachments: 3038.txt Given the following invocation: ./bin/nodetool snapshot Keyspace1 -t keyspace1_snapshot -h localhost Snapshots are made for all keyspaces Given a multi-keyspace invocation: ./bin/nodetool snapshot Keyspace1 Keyspace2 Keyspac3 -t keyspace1_snapshot -h localhost Snapshots will be made for Keyspace2 and Keyspace3 but not Keyspace1. It appears there is just some antiquated command argument noodling in NodeCmd#handleSnapshots -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3042) Implement authentication in Pig loadFunc
Implement authentication in Pig loadFunc Key: CASSANDRA-3042 URL: https://issues.apache.org/jira/browse/CASSANDRA-3042 Project: Cassandra Issue Type: Improvement Components: Hadoop Affects Versions: 0.8.4 Reporter: Nate McCall Priority: Minor Using already existing options for authentication in ConfigHelper, and adding a call to client#login just before client#set_keyspace to in CassandraStorage#initSchema -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2176) Add configuration setting to cap the number of Thrift connections
[ https://issues.apache.org/jira/browse/CASSANDRA-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999466#comment-12999466 ] Nate McCall commented on CASSANDRA-2176: I think I would prefer to get a TimeoutException back as this falls into the general category of that node is pretty busy right now and I would take the same avoidance strategy as with other TimeoutException cases. Add configuration setting to cap the number of Thrift connections - Key: CASSANDRA-2176 URL: https://issues.apache.org/jira/browse/CASSANDRA-2176 Project: Cassandra Issue Type: Improvement Components: API Reporter: Jonathan Ellis Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.3 Attachments: 0001-CASSANDRA-2176-limit-connected-clients-and-config.txt Original Estimate: 4h Remaining Estimate: 4h At least until CASSANDRA-1405 is done, it's useful to have a connection cap to prevent misbehaving clients from DOSing the server. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-2231) Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal
[ https://issues.apache.org/jira/browse/CASSANDRA-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001709#comment-13001709 ] Nate McCall commented on CASSANDRA-2231: I see what tjake means here in that we want to duplicate the structure of a thrift message for the column name, but that is essentially the flexibility we need in order to make JPA relationships work over even a moderate number of entities. Eg. if for every index type we want to add, we need to add a new CF, this will quickly become as infeasible (this is inherently why we cannot use 2ndary indexes to begin with). Per Ed's last comment, how about a combination of Sylvain's approach with a more dynamic encoding scheme that included a 'type' field between the length and the data? Add CompositeType comparer to the comparers provided in org.apache.cassandra.db.marshal --- Key: CASSANDRA-2231 URL: https://issues.apache.org/jira/browse/CASSANDRA-2231 Project: Cassandra Issue Type: Improvement Components: Contrib Affects Versions: 0.7.3 Reporter: Ed Anuff Priority: Minor Attachments: 0001-Add-compositeType.patch, edanuff-CassandraCompositeType-1e253c4.zip CompositeType is a custom comparer that makes it possible to create comparable composite values out of the basic types that Cassandra currently supports, such as Long, UUID, etc. This is very useful in both the creation of custom inverted indexes using columns in a skinny row, where each column name is a composite value, and also when using Cassandra's built-in secondary index support, where it can be used to encode the values in the columns that Cassandra indexes. One scenario for the usage of these is documented here: http://www.anuff.com/2010/07/secondary-indexes-in-cassandra.html. Source for contribution is attached and has been previously maintained on github here: https://github.com/edanuff/CassandraCompositeType -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2379) ByteBufferUtil#bytes(String) can produce undesired results for some characters
ByteBufferUtil#bytes(String) can produce undesired results for some characters -- Key: CASSANDRA-2379 URL: https://issues.apache.org/jira/browse/CASSANDRA-2379 Project: Cassandra Issue Type: Bug Reporter: Nate McCall The difference between getBytes(java.nio.charset.Charset) vs. getBytes([charsetname]) on some platforms (mac it seems) can be substantial. From the java.lang.String javadoc for the former: This method always replaces malformed-input and unmappable-character sequences with this charset's default replacement byte array... vs. the latter: The behavior of this method when this string cannot be encoded in the default charset is unspecified. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2379) ByteBufferUtil#bytes(String) can produce undesired results for some characters
[ https://issues.apache.org/jira/browse/CASSANDRA-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-2379: --- Attachment: 2379.txt Patch for ByteBufferUtil to use the Charset.defaultCharset for consistency with the decoding methods ByteBufferUtil#bytes(String) can produce undesired results for some characters -- Key: CASSANDRA-2379 URL: https://issues.apache.org/jira/browse/CASSANDRA-2379 Project: Cassandra Issue Type: Bug Reporter: Nate McCall Attachments: 2379.txt The difference between getBytes(java.nio.charset.Charset) vs. getBytes([charsetname]) on some platforms (mac it seems) can be substantial. From the java.lang.String javadoc for the former: This method always replaces malformed-input and unmappable-character sequences with this charset's default replacement byte array... vs. the latter: The behavior of this method when this string cannot be encoded in the default charset is unspecified. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2379) ByteBufferUtil#bytes(String) can produce undesired results for some characters
[ https://issues.apache.org/jira/browse/CASSANDRA-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010776#comment-13010776 ] Nate McCall commented on CASSANDRA-2379: We have a testcase for this in Hector which periodically fails on macs (uses ByteBufferUtil method for verification of results): https://github.com/rantav/hector/blob/master/core/src/test/java/me/prettyprint/cassandra/serializers/StringSerializerTest.java ByteBufferUtil#bytes(String) can produce undesired results for some characters -- Key: CASSANDRA-2379 URL: https://issues.apache.org/jira/browse/CASSANDRA-2379 Project: Cassandra Issue Type: Bug Reporter: Nate McCall Attachments: 2379.txt The difference between getBytes(java.nio.charset.Charset) vs. getBytes([charsetname]) on some platforms (mac it seems) can be substantial. From the java.lang.String javadoc for the former: This method always replaces malformed-input and unmappable-character sequences with this charset's default replacement byte array... vs. the latter: The behavior of this method when this string cannot be encoded in the default charset is unspecified. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2379) ByteBufferUtil#bytes(String) can produce undesired results for some characters
[ https://issues.apache.org/jira/browse/CASSANDRA-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011024#comment-13011024 ] Nate McCall commented on CASSANDRA-2379: Looks like this is safe to mark as a dupe of CASSANDRA-2367 as, per Gary's comment, the charset is being specified as UTF-8 ByteBufferUtil#bytes(String) can produce undesired results for some characters -- Key: CASSANDRA-2379 URL: https://issues.apache.org/jira/browse/CASSANDRA-2379 Project: Cassandra Issue Type: Bug Reporter: Nate McCall Attachments: 2379.txt The difference between getBytes(java.nio.charset.Charset) vs. getBytes([charsetname]) on some platforms (mac it seems) can be substantial. From the java.lang.String javadoc for the former: This method always replaces malformed-input and unmappable-character sequences with this charset's default replacement byte array... vs. the latter: The behavior of this method when this string cannot be encoded in the default charset is unspecified. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2486) preserve KsDef backwards compatibility for Thrift clients
[ https://issues.apache.org/jira/browse/CASSANDRA-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020376#comment-13020376 ] Nate McCall commented on CASSANDRA-2486: Patch applies clean (provided thrift classes are rebuilt). Unit tests pass as do hector's system_*_keyspace tests. preserve KsDef backwards compatibility for Thrift clients - Key: CASSANDRA-2486 URL: https://issues.apache.org/jira/browse/CASSANDRA-2486 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 0.8 Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.8 Attachments: 2486.txt CASSANDRA-1263 broke client compatibility; we can't preserve it entirely (we'll continue to resturn replication_factor in strategy option rather than try to guess somehow if client is an old one) but we can accommodate old clients on write and leave the KsDef signature compatible which (I think) will make it easier for client authors. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2526) Add ant support to generate CQL documentation from textile source
[ https://issues.apache.org/jira/browse/CASSANDRA-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13022847#comment-13022847 ] Nate McCall commented on CASSANDRA-2526: Looks like some folks were having the same initial frustrations I did. The fusesource folks have re-packaged this in github and gotten it included in maven central: http://repo2.maven.org/maven2/org/fusesource/wikitext/ GH project: https://github.com/fusesource/wikitext Add ant support to generate CQL documentation from textile source - Key: CASSANDRA-2526 URL: https://issues.apache.org/jira/browse/CASSANDRA-2526 Project: Cassandra Issue Type: Task Affects Versions: 0.8 beta 1 Reporter: Jonathan Ellis Assignee: Nate McCall Priority: Minor Fix For: 0.8.0 possibly useful links: - http://help.eclipse.org/helios/topic/org.eclipse.mylyn.wikitext.help.ui/help/Markup-Conversion.html#ConversionusingAntbuildscripts - http://www.mvnbrowser.com/artifact-details.html?groupId=org.eclipse.mylyn.wikitextartifactId=wikitext -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2526) Add ant support to generate CQL documentation from textile source
[ https://issues.apache.org/jira/browse/CASSANDRA-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024838#comment-13024838 ] Nate McCall commented on CASSANDRA-2526: Looks like they have an issue which leaves out message resource bundles for the ant task when they roll their jar files. I have an email with a patch sent out, so will wait to hear back. If not, we can just fork and deploy our own cut of just the ant task which will play nice with their existing jars. Ie. we would end up with two jars instead of one: wikitext-core.jar (packaged fusesource) wikitext-ant-task.jar (packaged by DataStax) The goal would be to get wikitext-ant-task avaialable on maven central as well. Ideally I just hear back from fusesource and they will fix + redeploy. Add ant support to generate CQL documentation from textile source - Key: CASSANDRA-2526 URL: https://issues.apache.org/jira/browse/CASSANDRA-2526 Project: Cassandra Issue Type: Task Affects Versions: 0.8 beta 1 Reporter: Jonathan Ellis Assignee: Nate McCall Priority: Minor Fix For: 0.8.0 possibly useful links: - http://help.eclipse.org/helios/topic/org.eclipse.mylyn.wikitext.help.ui/help/Markup-Conversion.html#ConversionusingAntbuildscripts - http://www.mvnbrowser.com/artifact-details.html?groupId=org.eclipse.mylyn.wikitextartifactId=wikitext -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2526) Add ant support to generate CQL documentation from textile source
[ https://issues.apache.org/jira/browse/CASSANDRA-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13025290#comment-13025290 ] Nate McCall commented on CASSANDRA-2526: Patch was accepted: https://github.com/fusesource/wikitext/commit/8fc22fc3fa54bd2cb0896d0b1ee38c37422ad9f9 Waiting to hear back on status of point release. Add ant support to generate CQL documentation from textile source - Key: CASSANDRA-2526 URL: https://issues.apache.org/jira/browse/CASSANDRA-2526 Project: Cassandra Issue Type: Task Affects Versions: 0.8 beta 1 Reporter: Jonathan Ellis Assignee: Nate McCall Priority: Minor Fix For: 0.8.0 possibly useful links: - http://help.eclipse.org/helios/topic/org.eclipse.mylyn.wikitext.help.ui/help/Markup-Conversion.html#ConversionusingAntbuildscripts - http://www.mvnbrowser.com/artifact-details.html?groupId=org.eclipse.mylyn.wikitextartifactId=wikitext -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2526) Add ant support to generate CQL documentation from textile source
[ https://issues.apache.org/jira/browse/CASSANDRA-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-2526: --- Attachment: 2526.txt Attaching patch intended to work with: http://github.com/riptano/wikitext-core-ant This patch will not work unless the above is installed locally. However, this project has been submitted for inclusion to maven central and should be available thusly in the next few days at which time the package retrieval will work. Add ant support to generate CQL documentation from textile source - Key: CASSANDRA-2526 URL: https://issues.apache.org/jira/browse/CASSANDRA-2526 Project: Cassandra Issue Type: Task Affects Versions: 0.8 beta 1 Reporter: Jonathan Ellis Assignee: Nate McCall Priority: Minor Fix For: 0.8.1 Attachments: 2526.txt possibly useful links: - http://help.eclipse.org/helios/topic/org.eclipse.mylyn.wikitext.help.ui/help/Markup-Conversion.html#ConversionusingAntbuildscripts - http://www.mvnbrowser.com/artifact-details.html?groupId=org.eclipse.mylyn.wikitextartifactId=wikitext -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2526) Add ant support to generate CQL documentation from textile source
[ https://issues.apache.org/jira/browse/CASSANDRA-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031978#comment-13031978 ] Nate McCall edited comment on CASSANDRA-2526 at 5/11/11 7:29 PM: - Attaching patch intended to work with: http://github.com/riptano/wikitext-core-ant This patch will not work unless the above is installed locally. However, this project has been submitted for inclusion to maven central and should be available thusly in the next few days at which time the package retrieval will work. See: https://issues.sonatype.org/browse/OSSRH-1691 for tracking maven central inclusion efforts. was (Author: zznate): Attaching patch intended to work with: http://github.com/riptano/wikitext-core-ant This patch will not work unless the above is installed locally. However, this project has been submitted for inclusion to maven central and should be available thusly in the next few days at which time the package retrieval will work. Add ant support to generate CQL documentation from textile source - Key: CASSANDRA-2526 URL: https://issues.apache.org/jira/browse/CASSANDRA-2526 Project: Cassandra Issue Type: Task Affects Versions: 0.8 beta 1 Reporter: Jonathan Ellis Assignee: Nate McCall Priority: Minor Fix For: 0.8.1 Attachments: 2526.txt possibly useful links: - http://help.eclipse.org/helios/topic/org.eclipse.mylyn.wikitext.help.ui/help/Markup-Conversion.html#ConversionusingAntbuildscripts - http://www.mvnbrowser.com/artifact-details.html?groupId=org.eclipse.mylyn.wikitextartifactId=wikitext -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2526) Add ant support to generate CQL documentation from textile source
[ https://issues.apache.org/jira/browse/CASSANDRA-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-2526: --- Attachment: 2526v2.txt Accepted on maven central. 2526v2.txt Patch contains the correct maven coordinates for such. Add ant support to generate CQL documentation from textile source - Key: CASSANDRA-2526 URL: https://issues.apache.org/jira/browse/CASSANDRA-2526 Project: Cassandra Issue Type: Task Affects Versions: 0.8 beta 1 Reporter: Jonathan Ellis Assignee: Nate McCall Priority: Minor Fix For: 0.8.1 Attachments: 2526.txt, 2526v2.txt possibly useful links: - http://help.eclipse.org/helios/topic/org.eclipse.mylyn.wikitext.help.ui/help/Markup-Conversion.html#ConversionusingAntbuildscripts - http://www.mvnbrowser.com/artifact-details.html?groupId=org.eclipse.mylyn.wikitextartifactId=wikitext -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4578) Dead lock in mutation stage when many concurrent writes to few columns
[
https://issues.apache.org/jira/browse/CASSANDRA-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nate McCall updated CASSANDRA-4578:
---
Attachment: 4578-1.0-backport.txt
Against cassandra-1.0 latest. Only differs in line numbers, otherwise no
issues. All tests pass.
Dead lock in mutation stage when many concurrent writes to few columns
--
Key: CASSANDRA-4578
URL: https://issues.apache.org/jira/browse/CASSANDRA-4578
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0
Environment: 15 cassandra instances
CentOS5
8 Core 64GB Memory
java version 1.6.0_33
Java(TM) SE Runtime Environment (build 1.6.0_33-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode)
Reporter: Suguru Namura
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.1.5
Attachments: 4578-1.0-backport.txt, 4578.txt,
threaddump-1344957574788.tdump
When I send many request to increment counters to few counter columns,
sometimes mutation stage cause dead lock. When it happened, all of mutation
threads are locked and do not accept updates any more.
{noformat}
MutationStage:432 - Thread t@1389
java.lang.Thread.State: TIMED_WAITING
at java.lang.Object.wait(Native Method)
- waiting on b90b45b (a org.apache.cassandra.utils.SimpleCondition)
at java.lang.Object.wait(Object.java:443)
at java.util.concurrent.TimeUnit.timedWait(TimeUnit.java:292)
at
org.apache.cassandra.utils.SimpleCondition.await(SimpleCondition.java:54)
at
org.apache.cassandra.service.AbstractWriteResponseHandler.get(AbstractWriteResponseHandler.java:55)
at
org.apache.cassandra.db.CounterMutationVerbHandler.doVerb(CounterMutationVerbHandler.java:51)
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:59)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- locked 4b1b0a6f (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
{noformat}
--
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-4924) Make CQL 3 data accessible via thrift.
[
https://issues.apache.org/jira/browse/CASSANDRA-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13491844#comment-13491844
]
Nate McCall commented on CASSANDRA-4924:
I can't really know my schema programmatically unless describe_keyspace works
as advertised (advertised != buried in a readme or similar).
If we are looking for usability, intentionally adding impedance mismatch
between CQL3 and thrift is not helping.
Make CQL 3 data accessible via thrift.
--
Key: CASSANDRA-4924
URL: https://issues.apache.org/jira/browse/CASSANDRA-4924
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.0
Reporter: amorton
Following the changes from CASSANDRA-4377 data created using CQL 3 is not
visible via the thrift interface.
This goes against the spirit of many comments by the project that the thrift
API is not going away. These statements and ones such as Internally, both
CQL3 and thrift use the same storage engine, so all future improvements to
this engine will impact both of them equally.
(http://www.datastax.com/dev/blog/thrift-to-cql3) and the CQL3 and thrift
examples given here
http://www.datastax.com/dev/blog/cql3-for-cassandra-experts gave the
impression CQL 3 was a layer on top of the core storage engine. It now
appears to be an incompatible format change.
It makes it impossible to explain to existing using users how CQL 3 stores
it's data.
It also creates an all or nothing approach to trying CQL 3.
My request is to make all data written by CQL 3 readable via the thrift API.
An example of using the current 1.2 trunk is below:
{noformat}
cqlsh:cass_college CREATE TABLE UserTweets
... (
... tweet_idbigint,
... user_name text,
... bodytext,
... timestamp timestamp,
... PRIMARY KEY (user_name, tweet_id)
... );
cqlsh:cass_college INSERT INTO
... UserTweets
... (tweet_id, body, user_name, timestamp)
... VALUES
... (1, 'The Tweet', 'fred', 1352150816917);
cqlsh:cass_college
cqlsh:cass_college
cqlsh:cass_college select * from UserTweets;
user_name | tweet_id | body | timestamp
---+--+---+--
fred |1 | The Tweet | 2012-11-06 10:26:56+1300
{noformat}
and in the CLI
{noformat}
[default@cass_college] show schema;
create keyspace cass_college
with placement_strategy = 'SimpleStrategy'
and strategy_options = {replication_factor : 3}
and durable_writes = true;
use cass_college;
[default@cass_college] list UserTweets;
UserTweets not found in current keyspace.
[default@cass_college]
{noformat}
--
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-4924) Make CQL 3 data accessible via thrift.
[
https://issues.apache.org/jira/browse/CASSANDRA-4924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13491876#comment-13491876
]
Nate McCall commented on CASSANDRA-4924:
bq. How do you keep a tool written for C* 1.0, that doesn't know these fields
exists, from misinterpreting it based on the fields that it does know about?
Like this is the first change on the CfDef struct? We've been managing that on
the client for the past 2.5 years with well typed exceptions (most times :)
when you do something dumb. All version of cassandra and hector 0.8 -- 1.0
-- 1.1 work with as much as possible. Interop works fine - just don't do
anything with programatic keyspace/cf stuff is a frequent reply on our mail
list for such. Users are fine with that.
Make CQL 3 data accessible via thrift.
--
Key: CASSANDRA-4924
URL: https://issues.apache.org/jira/browse/CASSANDRA-4924
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.0
Reporter: amorton
Following the changes from CASSANDRA-4377 data created using CQL 3 is not
visible via the thrift interface.
This goes against the spirit of many comments by the project that the thrift
API is not going away. These statements and ones such as Internally, both
CQL3 and thrift use the same storage engine, so all future improvements to
this engine will impact both of them equally.
(http://www.datastax.com/dev/blog/thrift-to-cql3) and the CQL3 and thrift
examples given here
http://www.datastax.com/dev/blog/cql3-for-cassandra-experts gave the
impression CQL 3 was a layer on top of the core storage engine. It now
appears to be an incompatible format change.
It makes it impossible to explain to existing using users how CQL 3 stores
it's data.
It also creates an all or nothing approach to trying CQL 3.
My request is to make all data written by CQL 3 readable via the thrift API.
An example of using the current 1.2 trunk is below:
{noformat}
cqlsh:cass_college CREATE TABLE UserTweets
... (
... tweet_idbigint,
... user_name text,
... bodytext,
... timestamp timestamp,
... PRIMARY KEY (user_name, tweet_id)
... );
cqlsh:cass_college INSERT INTO
... UserTweets
... (tweet_id, body, user_name, timestamp)
... VALUES
... (1, 'The Tweet', 'fred', 1352150816917);
cqlsh:cass_college
cqlsh:cass_college
cqlsh:cass_college select * from UserTweets;
user_name | tweet_id | body | timestamp
---+--+---+--
fred |1 | The Tweet | 2012-11-06 10:26:56+1300
{noformat}
and in the CLI
{noformat}
[default@cass_college] show schema;
create keyspace cass_college
with placement_strategy = 'SimpleStrategy'
and strategy_options = {replication_factor : 3}
and durable_writes = true;
use cass_college;
[default@cass_college] list UserTweets;
UserTweets not found in current keyspace.
[default@cass_college]
{noformat}
--
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-1311) Triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492883#comment-13492883 ] Nate McCall commented on CASSANDRA-1311: That brings up a point - what about DROP TRIGGER semantics? I'd call that 'minimum essential' as well. bq. We should bring up the trigger class in a separate class loader (or some other method) so they can be reloaded. Appealing, but two non-trivial issues with dynamic classloading, IME: - leaks that keep the classloader from getting collected and end up with an OOM in PermGen that takes down the whole JVM (number of 'public static final' refs in cassandra code base could/will be linked to will exacerbate this) - coordinating such in a cluster == hard (tomcat folks never really got it right) You could get all OSGi, but that's a mess unto itself. Otherwise, super glad to see this issue resurrected :) Triggers Key: CASSANDRA-1311 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311 Project: Cassandra Issue Type: New Feature Reporter: Maxim Grinev Assignee: Vijay Fix For: 1.3 Attachments: HOWTO-PatchAndRunTriggerExample.txt, HOWTO-PatchAndRunTriggerExample-update1.txt, ImplementationDetails.pdf, ImplementationDetails-update1.pdf, trunk-967053.txt, trunk-984391-update1.txt, trunk-984391-update2.txt Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation. Please find the motivation, triggers description and list of applications: http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/ An example of using triggers for indexing: http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/ Implementation details are attached. -- 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-4949) Expose reload trigger functionality to nodetool to orchestrate trigger (re)loads across the cluster
Nate McCall created CASSANDRA-4949: -- Summary: Expose reload trigger functionality to nodetool to orchestrate trigger (re)loads across the cluster Key: CASSANDRA-4949 URL: https://issues.apache.org/jira/browse/CASSANDRA-4949 Project: Cassandra Issue Type: New Feature Affects Versions: 1.3 Reporter: Nate McCall Pending completion of CASSANDRA-1311, this would expose the load/reload trigger library functionality to nodetool -- 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] [Comment Edited] (CASSANDRA-1311) Triggers
[ https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13495247#comment-13495247 ] Nate McCall edited comment on CASSANDRA-1311 at 11/12/12 1:31 PM: -- bq. Currently there is a JMX to load the new jars and we also watch triggers directory every minute to looking for new JAR's, I am inclined to removing the watch part for safety and let the user call the JMX to reload the jar's. In the use cases I see for this, a timer would not give me enough control in orchestrating an update to the trigger code. I would much prefer JMX - could be more easily hooked into nodetool for all at once as well. (Edit) thought about this update orchestration for a minute, created CASSANDRA-4949 for using nodetool for such. was (Author: zznate): bq. Currently there is a JMX to load the new jars and we also watch triggers directory every minute to looking for new JAR's, I am inclined to removing the watch part for safety and let the user call the JMX to reload the jar's. In the use cases I see for this, a timer would not give me enough control in orchestrating an update to the trigger code. I would much prefer JMX - could be more easily hooked into nodetool for all at once as well. Triggers Key: CASSANDRA-1311 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311 Project: Cassandra Issue Type: New Feature Reporter: Maxim Grinev Assignee: Vijay Fix For: 1.3 Attachments: HOWTO-PatchAndRunTriggerExample.txt, HOWTO-PatchAndRunTriggerExample-update1.txt, ImplementationDetails.pdf, ImplementationDetails-update1.pdf, trunk-967053.txt, trunk-984391-update1.txt, trunk-984391-update2.txt Asynchronous triggers is a basic mechanism to implement various use cases of asynchronous execution of application code at database side. For example to support indexes and materialized views, online analytics, push-based data propagation. Please find the motivation, triggers description and list of applications: http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/ An example of using triggers for indexing: http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/ Implementation details are attached. -- 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-4718) More-efficient ExecutorService for improved throughput
[ https://issues.apache.org/jira/browse/CASSANDRA-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13512023#comment-13512023 ] Nate McCall commented on CASSANDRA-4718: Sorta related - Guava's Futures class has some interesting grouping functionality: http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/util/concurrent/Futures.html#allAsList(java.lang.Iterable) More-efficient ExecutorService for improved throughput -- Key: CASSANDRA-4718 URL: https://issues.apache.org/jira/browse/CASSANDRA-4718 Project: Cassandra Issue Type: Improvement Reporter: Jonathan Ellis Priority: Minor Currently all our execution stages dequeue tasks one at a time. This can result in contention between producers and consumers (although we do our best to minimize this by using LinkedBlockingQueue). One approach to mitigating this would be to make consumer threads do more work in bulk instead of just one task per dequeue. (Producer threads tend to be single-task oriented by nature, so I don't see an equivalent opportunity there.) BlockingQueue has a drainTo(collection, int) method that would be perfect for this. However, no ExecutorService in the jdk supports using drainTo, nor could I google one. What I would like to do here is create just such a beast and wire it into (at least) the write and read stages. (Other possible candidates for such an optimization, such as the CommitLog and OutboundTCPConnection, are not ExecutorService-based and will need to be one-offs.) AbstractExecutorService may be useful. The implementations of ICommitLogExecutorService may also be useful. (Despite the name these are not actual ExecutorServices, although they share the most important properties of one.) -- 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-5126) Upgrade version of Jackson to avoid concurrency issues with M/R tasks
Nate McCall created CASSANDRA-5126: -- Summary: Upgrade version of Jackson to avoid concurrency issues with M/R tasks Key: CASSANDRA-5126 URL: https://issues.apache.org/jira/browse/CASSANDRA-5126 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.2.0, 1.1.8 Reporter: Nate McCall Priority: Minor Older version of Jackson ASL has a concurrency issue. See http://jira.codehaus.org/browse/JACKSON-237 This can be triggered in some environments when running M/R tasks and the wrong version of jackson gets picked up. -- 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-5126) Upgrade version of Jackson to avoid concurrency issues with M/R tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-5126: --- Attachment: 5126.txt Updates Jackson core and asl to latest 1.9.x Upgrade version of Jackson to avoid concurrency issues with M/R tasks - Key: CASSANDRA-5126 URL: https://issues.apache.org/jira/browse/CASSANDRA-5126 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.1.8, 1.2.0 Reporter: Nate McCall Priority: Minor Attachments: 5126.txt Older version of Jackson ASL has a concurrency issue. See http://jira.codehaus.org/browse/JACKSON-237 This can be triggered in some environments when running M/R tasks and the wrong version of jackson gets picked up. -- 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] [Reopened] (CASSANDRA-5126) Upgrade version of Jackson to avoid concurrency issues with M/R tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall reopened CASSANDRA-5126: Not so - looks like *only* 1.1 has the patch applied. cassandra-1.2 and trunk both still reference older versions. Upgrade version of Jackson to avoid concurrency issues with M/R tasks - Key: CASSANDRA-5126 URL: https://issues.apache.org/jira/browse/CASSANDRA-5126 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.1.8, 1.2.0 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 1.2.2 Attachments: 5126.txt Older version of Jackson ASL has a concurrency issue. See http://jira.codehaus.org/browse/JACKSON-237 This can be triggered in some environments when running M/R tasks and the wrong version of jackson gets picked up. -- 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-5126) Upgrade version of Jackson to avoid concurrency issues with M/R tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13547277#comment-13547277 ] Nate McCall commented on CASSANDRA-5126: So - looks like the jars were updated in the lib dir, but not in the build.xml. The ramifications of this are that *anything* referencing cassandra on maven central will have the older versions of jackson brought in as dependencies (cough. DSE. cough.). Upgrade version of Jackson to avoid concurrency issues with M/R tasks - Key: CASSANDRA-5126 URL: https://issues.apache.org/jira/browse/CASSANDRA-5126 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.1.8, 1.2.0 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 1.2.2 Attachments: 5126.txt Older version of Jackson ASL has a concurrency issue. See http://jira.codehaus.org/browse/JACKSON-237 This can be triggered in some environments when running M/R tasks and the wrong version of jackson gets picked up. -- 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] [Comment Edited] (CASSANDRA-5126) Upgrade version of Jackson to avoid concurrency issues with M/R tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13547277#comment-13547277 ] Nate McCall edited comment on CASSANDRA-5126 at 1/8/13 9:20 PM: So - looks like the jars were updated in the lib dir, but not in the build.xml. The ramifications of this are that *anything* referencing cassandra on maven central will have the older versions of jackson brought in as dependencies. was (Author: zznate): So - looks like the jars were updated in the lib dir, but not in the build.xml. The ramifications of this are that *anything* referencing cassandra on maven central will have the older versions of jackson brought in as dependencies (cough. DSE. cough.). Upgrade version of Jackson to avoid concurrency issues with M/R tasks - Key: CASSANDRA-5126 URL: https://issues.apache.org/jira/browse/CASSANDRA-5126 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 1.1.8, 1.2.0 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 1.2.2 Attachments: 5126.txt Older version of Jackson ASL has a concurrency issue. See http://jira.codehaus.org/browse/JACKSON-237 This can be triggered in some environments when running M/R tasks and the wrong version of jackson gets picked up. -- 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-1771) Script in debian/cassandra.in.sh is significantly out of date
Script in debian/cassandra.in.sh is significantly out of date - Key: CASSANDRA-1771 URL: https://issues.apache.org/jira/browse/CASSANDRA-1771 Project: Cassandra Issue Type: Bug Affects Versions: 0.7 beta 3, 0.7 beta 2, 0.7 beta 1 Reporter: Nate McCall Priority: Minor Fix For: 0.7.0 Looks like the correct version is in TRUNK given the 0.7 environment property changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1777) The describe_host API method is misleading in that it returns the interface associated with gossip traffic
The describe_host API method is misleading in that it returns the interface associated with gossip traffic -- Key: CASSANDRA-1777 URL: https://issues.apache.org/jira/browse/CASSANDRA-1777 Project: Cassandra Issue Type: Bug Reporter: Nate McCall If the hardware is configured to use separate interfaces for thrift and gossip, the gossip interface will be returned, given the results come out of the ReplicationStrategy eventually. I understand the approach, but given this is on the API, it effective worthless in situations of host auto discovery via describe_ring from a client. I actually see this as the primary use case of this method - why else would I care about the gossip iface from the client perspective? It's current form should be relegated to JMX only. At the same time, we should add port information as well. describe_splits probably has similar issues. I see the potential cart-before-horse issues here and that this will probably be non-trivial to fix, but I think give me a set of all the hosts to which I can talk is pretty important from a client perspective. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1805) refactor and remove contrib/
[ https://issues.apache.org/jira/browse/CASSANDRA-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966186#action_12966186 ] Nate McCall commented on CASSANDRA-1805: The maven/pom.xml is pretty outdated. It has some useful stuff in it for deployment, testing and project-level detail though. If there is a maven ticket open (do we want to do that?) it should be attached to such as a starting point. Either way it should be pruned as it's current state will only be a source of confusion. refactor and remove contrib/ Key: CASSANDRA-1805 URL: https://issues.apache.org/jira/browse/CASSANDRA-1805 Project: Cassandra Issue Type: Task Reporter: Jonathan Ellis Priority: Minor Fix For: 0.8 Contrib is a mix of examples, tools, and miscellanea that probably doesn't belong in our source tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1805) refactor and remove contrib/
[ https://issues.apache.org/jira/browse/CASSANDRA-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966204#action_12966204 ] Nate McCall commented on CASSANDRA-1805: Per contrib/javautils/.../CassandraServiceDataCleaner we use that heavily for test setup and tear down in Hector. I've got no problem appropriating it if there is not a good place for it. refactor and remove contrib/ Key: CASSANDRA-1805 URL: https://issues.apache.org/jira/browse/CASSANDRA-1805 Project: Cassandra Issue Type: Task Reporter: Jonathan Ellis Priority: Minor Fix For: 0.8 Contrib is a mix of examples, tools, and miscellanea that probably doesn't belong in our source tree. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1808) Duplicate JVM_OPTS set in RPM
[ https://issues.apache.org/jira/browse/CASSANDRA-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall resolved CASSANDRA-1808. Resolution: Not A Problem RPMs maintained at http://rpm.riptano.com are provided for convenience by and the sole responsibility of Riptano. Duplicate JVM_OPTS set in RPM - Key: CASSANDRA-1808 URL: https://issues.apache.org/jira/browse/CASSANDRA-1808 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.7.0 rc 1 Environment: CentOS 5.4 and RPM found here: http://rpm.riptano.com/EL/6/x86_64/cassandra07-0.7.0-0rc1.el6.noarch.rpm Reporter: Thor Carpenter Priority: Minor After installing 0.7RC1 RPM on CentOS and starting the cassandra service I am confused by the presence of duplicate and conflicting JVM params. There seem to be multiple places where JVM_OPTS are set. Executing find on clean install reveals multiple files that set JVM_OPTS. According to the mailing list, the correct file is cassandra-env.sh although which one is unclear. It would be less confusing if this redundancy was removed. For Reference: find / -name cassandra*.sh /etc/cassandra/cassandra-env.sh /usr/share/cassandra/conf/cassandra-env.sh /usr/share/cassandra/cassandra.in.sh ps aux | grep cassandra 100 8881 51.5 54.0 620988 135616 ? Sl 21:55 0:02 /usr/bin/java -Xdebug *-Xms128M -Xmx1G* -XX:TargetSurvivorRatio=90 -XX:+AggressiveOpts -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0 -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -ea -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 *-Xms122M -Xmx122M* -XX:+HeapDumpOnOutOfMemoryError -Xss128k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Djava.net.preferIPv4Stack=true -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dlog4j.configuration=log4j-server.properties -Dcassandra-pidfile=/var/run/cassandra/cassandra.pid -cp /etc/cassandra:/usr/share/cassandra/antlr-3.1.3.jar:/usr/share/cassandra/apache-cassandra-0.7.0-rc1-SNAPSHOT.jar:/usr/share/cassandra/apache-cassandra.jar:/usr/share/cassandra/avro-1.4.0-fixes.jar:/usr/share/cassandra/avro-1.4.0-sources-fixes.jar:/usr/share/cassandra/commons-cli-1.1.jar:/usr/share/cassandra/commons-codec-1.2.jar:/usr/share/cassandra/commons-collections-3.2.1.jar:/usr/share/cassandra/commons-lang-2.4.jar:/usr/share/cassandra/concurrentlinkedhashmap-lru-1.1.jar:/usr/share/cassandra/guava-r05.jar:/usr/share/cassandra/high-scale-lib.jar:/usr/share/cassandra/jackson-core-asl-1.4.0.jar:/usr/share/cassandra/jackson-mapper-asl-1.4.0.jar:/usr/share/cassandra/jetty-6.1.21.jar:/usr/share/cassandra/jetty-util-6.1.21.jar:/usr/share/cassandra/jline-0.9.94.jar:/usr/share/cassandra/json-simple-1.1.jar:/usr/share/cassandra/jug-2.0.0.jar:/usr/share/cassandra/libthrift-0.5.jar:/usr/share/cassandra/log4j-1.2.16.jar:/usr/share/cassandra/servlet-api-2.5-20081211.jar:/usr/share/cassandra/slf4j-api-1.6.1.jar:/usr/share/cassandra/slf4j-log4j12-1.6.1.jar:/usr/share/cassandra/snakeyaml-1.6.jar org.apache.cassandra.thrift.CassandraDaemon -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1851) Publish cassandra artifacts to the maven central repository
[ https://issues.apache.org/jira/browse/CASSANDRA-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971041#action_12971041 ] Nate McCall commented on CASSANDRA-1851: FYI - the repository at http://maven.riptano.com was created initially to satisfy the immediate demands of dependencies in the Hector client. It's basically just a list of dependencies, but If there is anything there in our makeshift cassandra pom file you can re-use please help yourself. Otherwise, this is great as it means that we can put Hector up for Maven Central inclusion as well :-) Thanks Stephen! Publish cassandra artifacts to the maven central repository --- Key: CASSANDRA-1851 URL: https://issues.apache.org/jira/browse/CASSANDRA-1851 Project: Cassandra Issue Type: Improvement Components: Packaging Affects Versions: 0.7.0 rc 2, 0.7.1, 0.8, 0.7.0 Reporter: Stephen Connolly Priority: Minor See http://markmail.org/search/?q=list:org.apache.incubator.cassandra-dev#query:list%3Aorg.apache.incubator.cassandra-dev+page:1+mid:bmcd3ir33p3psqze+state:results I will be attaching a patch to this issue once I have got the ANT build to a state where it can push the cassandra artifacts to the maven central repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1862) StorageProxy throws an InvalidRequestException in readProtocol during bootstrap
StorageProxy throws an InvalidRequestException in readProtocol during bootstrap --- Key: CASSANDRA-1862 URL: https://issues.apache.org/jira/browse/CASSANDRA-1862 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 rc 2 Reporter: Nate McCall Priority: Minor Fix For: 0.7.0 Though the error message provides details, IRE is supposed to signify poorly formed API requests. In the context of a client request, an UnavailableException is more appropriate. This would allow the client to take action like removing the node from its host list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1862) StorageProxy throws an InvalidRequestException in readProtocol during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1862: --- Attachment: 1862.txt Changes exception type to UnavailalbeException StorageProxy throws an InvalidRequestException in readProtocol during bootstrap --- Key: CASSANDRA-1862 URL: https://issues.apache.org/jira/browse/CASSANDRA-1862 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 rc 2 Reporter: Nate McCall Priority: Minor Fix For: 0.7.0 Attachments: 1862.txt Though the error message provides details, IRE is supposed to signify poorly formed API requests. In the context of a client request, an UnavailableException is more appropriate. This would allow the client to take action like removing the node from its host list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1862) StorageProxy throws an InvalidRequestException in readProtocol during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1862: --- Attachment: 1862_0.6.txt Backport to 0.6 StorageProxy throws an InvalidRequestException in readProtocol during bootstrap --- Key: CASSANDRA-1862 URL: https://issues.apache.org/jira/browse/CASSANDRA-1862 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 rc 2 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.7.0 Attachments: 1862.txt, 1862_0.6.txt Though the error message provides details, IRE is supposed to signify poorly formed API requests. In the context of a client request, an UnavailableException is more appropriate. This would allow the client to take action like removing the node from its host list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (CASSANDRA-1862) StorageProxy throws an InvalidRequestException in readProtocol during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall reopened CASSANDRA-1862: StorageProxy throws an InvalidRequestException in readProtocol during bootstrap --- Key: CASSANDRA-1862 URL: https://issues.apache.org/jira/browse/CASSANDRA-1862 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 rc 2 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.7.0 Attachments: 1862.txt, 1862_0.6.txt Though the error message provides details, IRE is supposed to signify poorly formed API requests. In the context of a client request, an UnavailableException is more appropriate. This would allow the client to take action like removing the node from its host list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1862) StorageProxy throws an InvalidRequestException in readProtocol during bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971751#action_12971751 ] Nate McCall commented on CASSANDRA-1862: I think this is extremely minor (the exception declaration of the method did not change) and brings us in line with the API as specified in cassandra.thrift: IRE: Invalid request could mean keyspace or column family does not exist, required parameters are missing, or a parameter is malformed... vs. UE: Not all the replicas required could be created and/or read. StorageProxy throws an InvalidRequestException in readProtocol during bootstrap --- Key: CASSANDRA-1862 URL: https://issues.apache.org/jira/browse/CASSANDRA-1862 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.0 rc 2 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.7.0 Attachments: 1862.txt, 1862_0.6.txt Though the error message provides details, IRE is supposed to signify poorly formed API requests. In the context of a client request, an UnavailableException is more appropriate. This would allow the client to take action like removing the node from its host list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1872) Provide ability send notifications via JMX when an SSTable is written
Provide ability send notifications via JMX when an SSTable is written - Key: CASSANDRA-1872 URL: https://issues.apache.org/jira/browse/CASSANDRA-1872 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.1 Reporter: Nate McCall One application of interest is the immediate backup of new SSTables. Relying on JMX's MBeanNotificationInfo would be a minimally intrusive to add listeners to CFS to facilitate this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1890) Updates and tweaks to spec file for easier support of candidate and beta releases
Updates and tweaks to spec file for easier support of candidate and beta releases - Key: CASSANDRA-1890 URL: https://issues.apache.org/jira/browse/CASSANDRA-1890 Project: Cassandra Issue Type: Improvement Affects Versions: 0.7.0 rc 2, 0.7.0 rc 1, 0.7 beta 3, 0.7 beta 2, 0.7 beta 1 Reporter: Nate McCall Assignee: Nate McCall Fix For: 0.7.0 Updates URL, license declaration. Add conflicts and obsoletes tags for existing RPM packages. Removed JNA dependency as that is not on stock yum repos. Unfortunately, yum does not widely support conditional Requires extensions yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1890) Updates and tweaks to spec file for easier support of candidate and beta releases
[ https://issues.apache.org/jira/browse/CASSANDRA-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12973956#action_12973956 ] Nate McCall commented on CASSANDRA-1890: @Nick - A release of 1 will be greater than rc3. I could not figure out a way to do this given our naming history that would not involve at least some handjiving. I'd be open to requiring the release be passed in, but I think this might be good enough. Thanks Eric. Updates and tweaks to spec file for easier support of candidate and beta releases - Key: CASSANDRA-1890 URL: https://issues.apache.org/jira/browse/CASSANDRA-1890 Project: Cassandra Issue Type: Improvement Affects Versions: 0.7 beta 1, 0.7 beta 2, 0.7 beta 3, 0.7.0 rc 1, 0.7.0 rc 2 Reporter: Nate McCall Assignee: Nate McCall Fix For: 0.7.0 Attachments: 1890.txt Updates URL, license declaration. Add conflicts and obsoletes tags for existing RPM packages. Removed JNA dependency as that is not on stock yum repos. Unfortunately, yum does not widely support conditional Requires extensions yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1890) Updates and tweaks to spec file for easier support of candidate and beta releases
[ https://issues.apache.org/jira/browse/CASSANDRA-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12973960#action_12973960 ] Nate McCall commented on CASSANDRA-1890: You would think, but installing *rc3 and then upgrading to *1 works, the other way around gives an error. Updates and tweaks to spec file for easier support of candidate and beta releases - Key: CASSANDRA-1890 URL: https://issues.apache.org/jira/browse/CASSANDRA-1890 Project: Cassandra Issue Type: Improvement Affects Versions: 0.7 beta 1, 0.7 beta 2, 0.7 beta 3, 0.7.0 rc 1, 0.7.0 rc 2 Reporter: Nate McCall Assignee: Nate McCall Fix For: 0.7.0 Attachments: 1890.txt Updates URL, license declaration. Add conflicts and obsoletes tags for existing RPM packages. Removed JNA dependency as that is not on stock yum repos. Unfortunately, yum does not widely support conditional Requires extensions yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1453) stress.java
[ https://issues.apache.org/jira/browse/CASSANDRA-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12974668#action_12974668 ] Nate McCall commented on CASSANDRA-1453: As opposed to warmup, what about dropping into a shell like w/ the cli? Then having ability to rerun the original or send new stress runs from a warm jvm. stress.java --- Key: CASSANDRA-1453 URL: https://issues.apache.org/jira/browse/CASSANDRA-1453 Project: Cassandra Issue Type: New Feature Components: Tools Reporter: Jonathan Ellis Assignee: Pavel Yaskevich Priority: Minor Fix For: 0.7.1 Attachments: stress-v2.patch, stress.patch stress.py seems to scale poorly past a fairly small number of threads/processes. (against a 3-node, RF=1 cluster, I got 3x as much throughput with 4 machines running stress.py -t 32, as running 1 with -t 128. these were 8-core client machines, and -t 128 reported only 50% cpu used.) since we ship with the thrift java api pre-built, this would also mean not making people build thrift before using the stress test, which is at best a pain for newcomers and on Windows a major hurdle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1918) redhat spec file does not copy the RH specific cassandra.in.sh file correctly
redhat spec file does not copy the RH specific cassandra.in.sh file correctly - Key: CASSANDRA-1918 URL: https://issues.apache.org/jira/browse/CASSANDRA-1918 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.7.0 rc 3 cassandra.in.sh is improperly pulled from [cassandra home]/conf as opposed to [cassandra home]/redhat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1918) redhat spec file does not copy the RH specific cassandra.in.sh file correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1918: --- Attachment: 1918.txt pulls in correct env properties redhat spec file does not copy the RH specific cassandra.in.sh file correctly - Key: CASSANDRA-1918 URL: https://issues.apache.org/jira/browse/CASSANDRA-1918 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.7.0 rc 3 Attachments: 1918.txt cassandra.in.sh is improperly pulled from [cassandra home]/conf as opposed to [cassandra home]/redhat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1918) redhat spec file does not copy the RH specific cassandra.in.sh file correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall resolved CASSANDRA-1918. Resolution: Invalid Indeed - this is an error on my part, I think I had stepped on this somehow out on our build machine. Marking as invalid. Thanks for filtering, Nick. redhat spec file does not copy the RH specific cassandra.in.sh file correctly - Key: CASSANDRA-1918 URL: https://issues.apache.org/jira/browse/CASSANDRA-1918 Project: Cassandra Issue Type: Bug Components: Packaging Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.7.1 Attachments: 1918.txt cassandra.in.sh is improperly pulled from [cassandra home]/conf as opposed to [cassandra home]/redhat -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1979) CassandraServiceDataCleaner.prepare() fails with IOException.
[ https://issues.apache.org/jira/browse/CASSANDRA-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1979: --- Attachment: 1979.txt This code path had not been tested in a while. Test case had the following issues: - not using bytebuffer - storage-config param from 0.6 - non-framed transport Patch brings everything up to date with current trunk. CassandraServiceDataCleaner.prepare() fails with IOException. - Key: CASSANDRA-1979 URL: https://issues.apache.org/jira/browse/CASSANDRA-1979 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.7.0 Environment: Windows XP Reporter: Chris Ng Assignee: Nate McCall Attachments: 1979.txt CassandraServiceDataCleaner.prepare() fails with an IOException if run in isolation. It seems that initializing the DataDescriptor creates a new CommitLog file, and then the cleaner tries to delete this file and fails. 16:06:07.204 [main] INFO o.a.c.config.DatabaseDescriptor - Loading settings from file:/C:/workspace/sandbox/target/classes/cassandra.yaml 16:06:07.282 [main] DEBUG o.a.c.config.DatabaseDescriptor - Syncing log with a period of 1 16:06:07.282 [main] INFO o.a.c.config.DatabaseDescriptor - DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard 16:06:07.797 [main] DEBUG o.a.c.config.DatabaseDescriptor - setting auto_bootstrap to false 16:06:07.797 [main] INFO o.a.c.db.commitlog.CommitLogSegment - Creating new commitlog segment target/var/lib/cassandra/commitlog\CommitLog-1294934767797.log 16:06:07.813 [main] DEBUG o.apache.cassandra.io.util.FileUtils - Deleting CommitLog-1294934767797.log Exception in thread main java.io.IOException: Failed to delete C:\workspace\sandbox\target\var\lib\cassandra\commitlog\CommitLog-1294934767797.log at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:54) at org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:201) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanDir(CassandraServiceDataCleaner.java:99) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanupDataDirectories(CassandraServiceDataCleaner.java:53) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.prepare(CassandraServiceDataCleaner.java:44) at cng.sandbox.App.main(App.java:15) This also seems to leave a bunch of threads running in the background, so the process has to be manually killed. This was tested with the javautils in the 0.7.0 branch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1979) CassandraServiceDataCleaner.prepare() fails with IOException.
[ https://issues.apache.org/jira/browse/CASSANDRA-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12981965#action_12981965 ] Nate McCall commented on CASSANDRA-1979: I'm not sure this belongs in contrib anymore as it will just get out of date again. I would prefer we remove it in favor of doing something smarter in refactoring out o.a.c.SchemaLoader and friends in the test/unit tree to a module of some sort and including that on the test classpath of the main build file. (In conjunction with CASSANDRA-1848 perhaps?) CassandraServiceDataCleaner.prepare() fails with IOException. - Key: CASSANDRA-1979 URL: https://issues.apache.org/jira/browse/CASSANDRA-1979 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.7.0 Environment: Windows XP Reporter: Chris Ng Assignee: Nate McCall Attachments: 1979.txt CassandraServiceDataCleaner.prepare() fails with an IOException if run in isolation. It seems that initializing the DataDescriptor creates a new CommitLog file, and then the cleaner tries to delete this file and fails. 16:06:07.204 [main] INFO o.a.c.config.DatabaseDescriptor - Loading settings from file:/C:/workspace/sandbox/target/classes/cassandra.yaml 16:06:07.282 [main] DEBUG o.a.c.config.DatabaseDescriptor - Syncing log with a period of 1 16:06:07.282 [main] INFO o.a.c.config.DatabaseDescriptor - DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard 16:06:07.797 [main] DEBUG o.a.c.config.DatabaseDescriptor - setting auto_bootstrap to false 16:06:07.797 [main] INFO o.a.c.db.commitlog.CommitLogSegment - Creating new commitlog segment target/var/lib/cassandra/commitlog\CommitLog-1294934767797.log 16:06:07.813 [main] DEBUG o.apache.cassandra.io.util.FileUtils - Deleting CommitLog-1294934767797.log Exception in thread main java.io.IOException: Failed to delete C:\workspace\sandbox\target\var\lib\cassandra\commitlog\CommitLog-1294934767797.log at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:54) at org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:201) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanDir(CassandraServiceDataCleaner.java:99) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanupDataDirectories(CassandraServiceDataCleaner.java:53) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.prepare(CassandraServiceDataCleaner.java:44) at cng.sandbox.App.main(App.java:15) This also seems to leave a bunch of threads running in the background, so the process has to be manually killed. This was tested with the javautils in the 0.7.0 branch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1979) CassandraServiceDataCleaner.prepare() fails with IOException.
[ https://issues.apache.org/jira/browse/CASSANDRA-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1979: --- Attachment: 1979.txt Oops - diff'ed from wrong level. New patched diff'ed from top level. CassandraServiceDataCleaner.prepare() fails with IOException. - Key: CASSANDRA-1979 URL: https://issues.apache.org/jira/browse/CASSANDRA-1979 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.7.0 Environment: Windows XP Reporter: Chris Ng Assignee: Nate McCall Attachments: 1979.txt CassandraServiceDataCleaner.prepare() fails with an IOException if run in isolation. It seems that initializing the DataDescriptor creates a new CommitLog file, and then the cleaner tries to delete this file and fails. 16:06:07.204 [main] INFO o.a.c.config.DatabaseDescriptor - Loading settings from file:/C:/workspace/sandbox/target/classes/cassandra.yaml 16:06:07.282 [main] DEBUG o.a.c.config.DatabaseDescriptor - Syncing log with a period of 1 16:06:07.282 [main] INFO o.a.c.config.DatabaseDescriptor - DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard 16:06:07.797 [main] DEBUG o.a.c.config.DatabaseDescriptor - setting auto_bootstrap to false 16:06:07.797 [main] INFO o.a.c.db.commitlog.CommitLogSegment - Creating new commitlog segment target/var/lib/cassandra/commitlog\CommitLog-1294934767797.log 16:06:07.813 [main] DEBUG o.apache.cassandra.io.util.FileUtils - Deleting CommitLog-1294934767797.log Exception in thread main java.io.IOException: Failed to delete C:\workspace\sandbox\target\var\lib\cassandra\commitlog\CommitLog-1294934767797.log at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:54) at org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:201) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanDir(CassandraServiceDataCleaner.java:99) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanupDataDirectories(CassandraServiceDataCleaner.java:53) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.prepare(CassandraServiceDataCleaner.java:44) at cng.sandbox.App.main(App.java:15) This also seems to leave a bunch of threads running in the background, so the process has to be manually killed. This was tested with the javautils in the 0.7.0 branch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1979) CassandraServiceDataCleaner.prepare() fails with IOException.
[ https://issues.apache.org/jira/browse/CASSANDRA-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1979: --- Attachment: (was: 1979.txt) CassandraServiceDataCleaner.prepare() fails with IOException. - Key: CASSANDRA-1979 URL: https://issues.apache.org/jira/browse/CASSANDRA-1979 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.7.0 Environment: Windows XP Reporter: Chris Ng Assignee: Nate McCall Attachments: 1979.txt CassandraServiceDataCleaner.prepare() fails with an IOException if run in isolation. It seems that initializing the DataDescriptor creates a new CommitLog file, and then the cleaner tries to delete this file and fails. 16:06:07.204 [main] INFO o.a.c.config.DatabaseDescriptor - Loading settings from file:/C:/workspace/sandbox/target/classes/cassandra.yaml 16:06:07.282 [main] DEBUG o.a.c.config.DatabaseDescriptor - Syncing log with a period of 1 16:06:07.282 [main] INFO o.a.c.config.DatabaseDescriptor - DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard 16:06:07.797 [main] DEBUG o.a.c.config.DatabaseDescriptor - setting auto_bootstrap to false 16:06:07.797 [main] INFO o.a.c.db.commitlog.CommitLogSegment - Creating new commitlog segment target/var/lib/cassandra/commitlog\CommitLog-1294934767797.log 16:06:07.813 [main] DEBUG o.apache.cassandra.io.util.FileUtils - Deleting CommitLog-1294934767797.log Exception in thread main java.io.IOException: Failed to delete C:\workspace\sandbox\target\var\lib\cassandra\commitlog\CommitLog-1294934767797.log at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:54) at org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:201) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanDir(CassandraServiceDataCleaner.java:99) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanupDataDirectories(CassandraServiceDataCleaner.java:53) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.prepare(CassandraServiceDataCleaner.java:44) at cng.sandbox.App.main(App.java:15) This also seems to leave a bunch of threads running in the background, so the process has to be manually killed. This was tested with the javautils in the 0.7.0 branch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1979) CassandraServiceDataCleaner.prepare() fails with IOException.
[ https://issues.apache.org/jira/browse/CASSANDRA-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982750#action_12982750 ] Nate McCall commented on CASSANDRA-1979: Per my comments on CASSANDRA-1805 I'm fine appropriating this. We have an issue open to break out some other testing utils into a non-hector-core dependent 'test-utils' module anyhoo. CassandraServiceDataCleaner.prepare() fails with IOException. - Key: CASSANDRA-1979 URL: https://issues.apache.org/jira/browse/CASSANDRA-1979 Project: Cassandra Issue Type: Bug Components: Contrib Affects Versions: 0.7.0 Environment: Windows XP Reporter: Chris Ng Assignee: Nate McCall Fix For: 0.7.1 Attachments: 1979.txt CassandraServiceDataCleaner.prepare() fails with an IOException if run in isolation. It seems that initializing the DataDescriptor creates a new CommitLog file, and then the cleaner tries to delete this file and fails. 16:06:07.204 [main] INFO o.a.c.config.DatabaseDescriptor - Loading settings from file:/C:/workspace/sandbox/target/classes/cassandra.yaml 16:06:07.282 [main] DEBUG o.a.c.config.DatabaseDescriptor - Syncing log with a period of 1 16:06:07.282 [main] INFO o.a.c.config.DatabaseDescriptor - DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard 16:06:07.797 [main] DEBUG o.a.c.config.DatabaseDescriptor - setting auto_bootstrap to false 16:06:07.797 [main] INFO o.a.c.db.commitlog.CommitLogSegment - Creating new commitlog segment target/var/lib/cassandra/commitlog\CommitLog-1294934767797.log 16:06:07.813 [main] DEBUG o.apache.cassandra.io.util.FileUtils - Deleting CommitLog-1294934767797.log Exception in thread main java.io.IOException: Failed to delete C:\workspace\sandbox\target\var\lib\cassandra\commitlog\CommitLog-1294934767797.log at org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:54) at org.apache.cassandra.io.util.FileUtils.deleteRecursive(FileUtils.java:201) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanDir(CassandraServiceDataCleaner.java:99) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.cleanupDataDirectories(CassandraServiceDataCleaner.java:53) at org.apache.cassandra.contrib.utils.service.CassandraServiceDataCleaner.prepare(CassandraServiceDataCleaner.java:44) at cng.sandbox.App.main(App.java:15) This also seems to leave a bunch of threads running in the background, so the process has to be manually killed. This was tested with the javautils in the 0.7.0 branch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2050) AbstractDaemon unnecessarily uses jetty inteface
AbstractDaemon unnecessarily uses jetty inteface Key: CASSANDRA-2050 URL: https://issues.apache.org/jira/browse/CASSANDRA-2050 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.1, 0.7.2, 0.8 Reporter: Nate McCall Assignee: Nate McCall AbstractDaemon's CleaningThreadPool need not implement this jetty interface. Removing this would allow us to remove jetty dependency altogether. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2050) AbstractDaemon unnecessarily uses jetty interface
[ https://issues.apache.org/jira/browse/CASSANDRA-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-2050: --- Summary: AbstractDaemon unnecessarily uses jetty interface (was: AbstractDaemon unnecessarily uses jetty inteface) AbstractDaemon unnecessarily uses jetty interface - Key: CASSANDRA-2050 URL: https://issues.apache.org/jira/browse/CASSANDRA-2050 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.1, 0.7.2, 0.8 Reporter: Nate McCall Assignee: Nate McCall AbstractDaemon's CleaningThreadPool need not implement this jetty interface. Removing this would allow us to remove jetty dependency altogether. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2050) AbstractDaemon unnecessarily uses jetty interface
[ https://issues.apache.org/jira/browse/CASSANDRA-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-2050: --- Attachment: 2050.txt Remove jetty import and interface impl on AbstractDaemon. I think this was only needed for avro plumbing. AbstractDaemon unnecessarily uses jetty interface - Key: CASSANDRA-2050 URL: https://issues.apache.org/jira/browse/CASSANDRA-2050 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.1, 0.7.2, 0.8 Reporter: Nate McCall Assignee: Nate McCall Attachments: 2050.txt AbstractDaemon's CleaningThreadPool need not implement this jetty interface. Removing this would allow us to remove jetty dependency altogether. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-2050) AbstractDaemon unnecessarily uses jetty interface
[ https://issues.apache.org/jira/browse/CASSANDRA-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-2050: --- Priority: Minor (was: Major) AbstractDaemon unnecessarily uses jetty interface - Key: CASSANDRA-2050 URL: https://issues.apache.org/jira/browse/CASSANDRA-2050 Project: Cassandra Issue Type: Bug Affects Versions: 0.7.1, 0.7.2, 0.8 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Attachments: 2050.txt AbstractDaemon's CleaningThreadPool need not implement this jetty interface. Removing this would allow us to remove jetty dependency altogether. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-2152) Encryption options are not validated correctly in DatabaseDescriptor
Encryption options are not validated correctly in DatabaseDescriptor Key: CASSANDRA-2152 URL: https://issues.apache.org/jira/browse/CASSANDRA-2152 Project: Cassandra Issue Type: Bug Affects Versions: 0.8 Reporter: Nate McCall Assignee: Nate McCall Fix For: 0.8 Missing configuration for encryption_options introduced via CASSANDRA-1567 result in an obtuse NPE from MessagingService -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CASSANDRA-2152) Encryption options are not validated correctly in DatabaseDescriptor
[ https://issues.apache.org/jira/browse/CASSANDRA-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-2152: --- Attachment: 2152.txt checks for null before reference Encryption options are not validated correctly in DatabaseDescriptor Key: CASSANDRA-2152 URL: https://issues.apache.org/jira/browse/CASSANDRA-2152 Project: Cassandra Issue Type: Bug Affects Versions: 0.8 Reporter: Nate McCall Assignee: Nate McCall Fix For: 0.8 Attachments: 2152.txt Missing configuration for encryption_options introduced via CASSANDRA-1567 result in an obtuse NPE from MessagingService -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CASSANDRA-1214) Make standard IO the default
[ https://issues.apache.org/jira/browse/CASSANDRA-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12886037#action_12886037 ] Nate McCall commented on CASSANDRA-1214: I have not hit this issue yet, but has anyone tried using the -XX:MaxDirectMemorySize option? Make standard IO the default Key: CASSANDRA-1214 URL: https://issues.apache.org/jira/browse/CASSANDRA-1214 Project: Cassandra Issue Type: Bug Affects Versions: 0.7 Reporter: James Golick The way mmap()'d IO is handled in cassandra is dangerous. It allocates potentially massive buffers without any care for bounding the total size of the program's buffers. As the node's dataset grows, this *will* lead to swapping and instability. This is a dangerous and wrong default for a couple of reasons. 1) People are likely to test cassandra with the default settings. This issue is insidious because it only appears when you have sufficient data in a certain node, there is absolutely no way to control it, and it doesn't at all respect the memory limits that you give to the JVM. That can all be ascertained by reading the code, and people should certainly do their homework, but nevertheless, cassandra should ship with sane defaults that don't break down when you cross some magic unknown threshold. 2) It's deceptive. Unless you are extremely careful with capacity planning, you will get bit by this. Most people won't really be able to use this in production, so why get them excited about performance that they can't actually have? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12886965#action_12886965 ] Nate McCall commented on CASSANDRA-475: --- TFramedTransport maxLength is just a frame buffer size. It defaults to 2^31-1 in the latest thrift. Im not sure tweaking that buys us much given the following. TBinaryProtocol.readLength is what needs to be set. *NOTE*: The value provided here will effectively be the max column size (there is no overhead due to thrift's delimitation granularity). This should be configurable with a sane default. How about thrift_max_message_length with a default of 1 (in MB). (This is the default max_packet_size in mysql, so might be easier to grok if we match that). sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12886997#action_12886997 ] Nate McCall commented on CASSANDRA-475: --- Yes, maxLength does directly control the size of the input byte[] on TFramedTransport, so it is succeptible to the same issue. I would like to change thrift_framed_transport to thrift_framed_transport_size with 0 (in MB as well) as the default indicating TSocket over TFramedTransport sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12886999#action_12886999 ] Nate McCall commented on CASSANDRA-475: --- Looks like the thrift folks have changed the parameterization of TBase: THRIFT-759 Unfortunately, this beat our patch for THRIFT-601 by a couple of days. Thoughts? sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12887056#action_12887056 ] Nate McCall edited comment on CASSANDRA-475 at 7/10/10 12:58 PM: - We are agreed on the importance of this. The changes on the surface seem trivial, since Comparator is widely used already. My concerns here are strictly schedule related given the process overhead involved in touching so many files in active development. I'm going to have to put this down temporarily, until I can focus on this and make the change a one-shot deal (or as close to that as possible). EDIT: I just added CASSANDRA-1266 to track the jar upgrade separately so we don't muddy the waters on this issue. was (Author: zznate): We are agreed on the importance of this. The changes on the surface seem trivial, since Comparator is widely used already. My concerns here are strictly schedule related given the process overhead involved in touching so many files in active development. I'm going to have to put this down temporarily, until I can focus on this and make the change a one-shot deal (or as close to that as possible). sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12887056#action_12887056 ] Nate McCall commented on CASSANDRA-475: --- We are agreed on the importance of this. The changes on the surface seem trivial, since Comparator is widely used already. My concerns here are strictly schedule related given the process overhead involved in touching so many files in active development. I'm going to have to put this down temporarily, until I can focus on this and make the change a one-shot deal (or as close to that as possible). sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1266) Upgrade thrift jar to support more robust transport and protocol
Upgrade thrift jar to support more robust transport and protocol Key: CASSANDRA-1266 URL: https://issues.apache.org/jira/browse/CASSANDRA-1266 Project: Cassandra Issue Type: Improvement Reporter: Nate McCall Fix For: 0.7 We need a newer thrift jar in order to support CASSANDRA-475. Unfortunately, the thrift patch which supports this also has a change to the parameterization of TBase which will involve us touching a lot of files to make this upgrade. See the comments on that ticket for more detail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12887063#action_12887063 ] Nate McCall commented on CASSANDRA-475: --- I can continue with the config modifications required if the changes mentioned above are cool sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1266) Upgrade thrift jar to support more robust transport and protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12887079#action_12887079 ] Nate McCall commented on CASSANDRA-1266: No - apparently I am. (Still getting my head around how thrift generation process works). Upgrade thrift jar to support more robust transport and protocol Key: CASSANDRA-1266 URL: https://issues.apache.org/jira/browse/CASSANDRA-1266 Project: Cassandra Issue Type: Improvement Reporter: Nate McCall Fix For: 0.7 We need a newer thrift jar in order to support CASSANDRA-475. Unfortunately, the thrift patch which supports this also has a change to the parameterization of TBase which will involve us touching a lot of files to make this upgrade. See the comments on that ticket for more detail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1266) Upgrade thrift jar to support more robust transport and protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1266: --- Attachment: libthrift-r959516.jar Attached thrift lib. Regenerating appears to be the only needed change. Verified nosetests all pass Upgrade thrift jar to support more robust transport and protocol Key: CASSANDRA-1266 URL: https://issues.apache.org/jira/browse/CASSANDRA-1266 Project: Cassandra Issue Type: Improvement Reporter: Nate McCall Fix For: 0.7 Attachments: libthrift-r959516.jar We need a newer thrift jar in order to support CASSANDRA-475. Unfortunately, the thrift patch which supports this also has a change to the parameterization of TBase which will involve us touching a lot of files to make this upgrade. See the comments on that ticket for more detail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-475: -- Attachment: trunk-475-config.txt trunk-475-src.txt - trunk-475-config.txt updates the yaml config - trunk-475-src.txt updates java src sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-475-config.txt, trunk-475-src.txt Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12887129#action_12887129 ] Nate McCall edited comment on CASSANDRA-475 at 7/10/10 9:08 PM: - trunk-475-config.txt updates the yaml config - trunk-475-src.txt updates java src EDIT: I dropped in a default setting of 256mb in the Converter when someone had framed transport configured in storage-conf. Was not sure what all to do there except add a sane default and a warning message. was (Author: zznate): - trunk-475-config.txt updates the yaml config - trunk-475-src.txt updates java src sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-475-config.txt, trunk-475-src.txt Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-475: -- Attachment: trunk-475-src-2.txt Come to think, nice to have completeness-wise and was easy enough to add. trunk-475-src-2.txt superseeds trunk-475-src.txt sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-475-config.txt, trunk-475-src-2.txt Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-475: -- Attachment: (was: trunk-475-src-2.txt) sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-475-config.txt, trunk-475-src-3.txt Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-475: -- Attachment: trunk-475-src-3.txt I'm gonna blame that one on your central-TX weather melting my brain. trunk-475-src-3.txt replaces trunk-475-src-2.txt, fixes comparisson induced by mild heat stroke. sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-475-config.txt, trunk-475-src-3.txt Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888918#action_12888918 ] Nate McCall commented on CASSANDRA-475: --- THRIFT-820 created and patch submitted. Waiting on their review and feedback. sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-475-config.txt, trunk-475-src-3.txt Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1294) MIsc license inclusion booboos with recent index commits
[ https://issues.apache.org/jira/browse/CASSANDRA-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1294: --- Attachment: trunk-1249-license-headers.txt the radio button for attachment license is strangely ironic here. MIsc license inclusion booboos with recent index commits Key: CASSANDRA-1294 URL: https://issues.apache.org/jira/browse/CASSANDRA-1294 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7 Reporter: Nate McCall Priority: Minor Attachments: trunk-1249-license-headers.txt Noticed some missing license headers, a duped header in one case when going over changes in CASSANDRA-1154 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1294) MIsc license inclusion booboos with recent index commits
MIsc license inclusion booboos with recent index commits Key: CASSANDRA-1294 URL: https://issues.apache.org/jira/browse/CASSANDRA-1294 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7 Reporter: Nate McCall Priority: Minor Noticed some missing license headers, a duped header in one case when going over changes in CASSANDRA-1154 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1294) MIsc license inclusion booboos with recent index commits
[ https://issues.apache.org/jira/browse/CASSANDRA-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12889508#action_12889508 ] Nate McCall commented on CASSANDRA-1294: Agree with Folke on this in principal, however javadoc seemed to be the most prevalent style in the codebase. Another patch for someone more OCD than myself perhaps. MIsc license inclusion booboos with recent index commits Key: CASSANDRA-1294 URL: https://issues.apache.org/jira/browse/CASSANDRA-1294 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7 Reporter: Nate McCall Assignee: Nate McCall Priority: Minor Fix For: 0.7 Attachments: trunk-1249-license-headers.txt Noticed some missing license headers, a duped header in one case when going over changes in CASSANDRA-1154 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1301) Table needs to be aware of indexed column CFSes so they can be flushed correctly
Table needs to be aware of indexed column CFSes so they can be flushed correctly Key: CASSANDRA-1301 URL: https://issues.apache.org/jira/browse/CASSANDRA-1301 Project: Cassandra Issue Type: Sub-task Reporter: Nate McCall -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1301) Table needs to be aware of indexed column CFSes so they can be flushed correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12889998#action_12889998 ] Nate McCall commented on CASSANDRA-1301: Suggestion via jbellis per IRC discussion: we should probably have them flushed first, before the live ones. Table needs to be aware of indexed column CFSes so they can be flushed correctly Key: CASSANDRA-1301 URL: https://issues.apache.org/jira/browse/CASSANDRA-1301 Project: Cassandra Issue Type: Sub-task Reporter: Nate McCall -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1301) Table needs to be aware of indexed column CFSes so they can be flushed correctly
[ https://issues.apache.org/jira/browse/CASSANDRA-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1301: --- Attachment: trunk-1301-table.txt Patch Table to check and flush indexed column CFSes if they exist for the CFS being flushed Table needs to be aware of indexed column CFSes so they can be flushed correctly Key: CASSANDRA-1301 URL: https://issues.apache.org/jira/browse/CASSANDRA-1301 Project: Cassandra Issue Type: Sub-task Reporter: Nate McCall Attachments: trunk-1301-table.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1306) Forcing a major compaction on an CF with indexed sub columns occasionally causes an error
Forcing a major compaction on an CF with indexed sub columns occasionally causes an error - Key: CASSANDRA-1306 URL: https://issues.apache.org/jira/browse/CASSANDRA-1306 Project: Cassandra Issue Type: Bug Affects Versions: 0.7 Reporter: Nate McCall Note that is is a function of ColumnFamilyStore's forceMajorCompaction ERROR 14:33:31,430 Uncaught exception in thread Thread[CompactionExecutor:1,5,main] java.util.concurrent.ExecutionException: java.io.IOException: Keys must be written in ascending order. at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.afterExecute(DebuggableThreadPoolExecutor.java:87) at org.apache.cassandra.db.CompactionManager$CompactionExecutor.afterExecute(CompactionManager.java:659) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:888) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Keys must be written in ascending order. at org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:69) at org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:86) at org.apache.cassandra.db.CompactionManager.doCompaction(CompactionManager.java:350) at org.apache.cassandra.db.CompactionManager$5.call(CompactionManager.java:227) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ... 2 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1306) Forcing a major compaction on an CF with indexed sub columns occasionally causes an error
[ https://issues.apache.org/jira/browse/CASSANDRA-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1306: --- Component/s: Core Forcing a major compaction on an CF with indexed sub columns occasionally causes an error - Key: CASSANDRA-1306 URL: https://issues.apache.org/jira/browse/CASSANDRA-1306 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7 Reporter: Nate McCall Note that is is a function of ColumnFamilyStore's forceMajorCompaction ERROR 14:33:31,430 Uncaught exception in thread Thread[CompactionExecutor:1,5,main] java.util.concurrent.ExecutionException: java.io.IOException: Keys must be written in ascending order. at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.afterExecute(DebuggableThreadPoolExecutor.java:87) at org.apache.cassandra.db.CompactionManager$CompactionExecutor.afterExecute(CompactionManager.java:659) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:888) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.IOException: Keys must be written in ascending order. at org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:69) at org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:86) at org.apache.cassandra.db.CompactionManager.doCompaction(CompactionManager.java:350) at org.apache.cassandra.db.CompactionManager$5.call(CompactionManager.java:227) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ... 2 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-475) sending random data crashes thrift service
[ https://issues.apache.org/jira/browse/CASSANDRA-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-475: -- Attachment: trunk-475-src-4.txt Resets the input and output protocol on each after each successful call to process in CustomTThreadPoolServer passes nosetests and stress.py with 5 million rows sending random data crashes thrift service -- Key: CASSANDRA-475 URL: https://issues.apache.org/jira/browse/CASSANDRA-475 Project: Cassandra Issue Type: Bug Components: Core Reporter: Eric Evans Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-475-config.txt, trunk-475-src-3.txt, trunk-475-src-4.txt Use dd if=/dev/urandom count=1 | nc $host 9160 as a handy recipe for shutting a cassandra instance down. Thrift has spoken (see THRIFT-601), but Don't Do That is probably an insufficient answer for our users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1258) rebuild indexes after streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1258: --- Attachment: trunk-1258-src.txt Patches for allowing CFS to accept a recovered SSTableReader from which to retrieve the indexed columns. Having this on CFS allows for other uses such as added indexes after the fact, and providing mbean hooks into rebuilding indexes. rebuild indexes after streaming --- Key: CASSANDRA-1258 URL: https://issues.apache.org/jira/browse/CASSANDRA-1258 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-1258-src.txt since index CFSes are private, they won't be streamed with other sstables. which is good, because the normal partitioner logic wouldn't stream the right parts anyway. seems like the right solution is to extend SSTW.maybeRecover to rebuild indexes as well. (this has the added benefit of being able to use streaming as a relatively straightforward bulk loader.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1258) rebuild indexes after streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1258: --- Attachment: (was: trunk-1258-src.txt) rebuild indexes after streaming --- Key: CASSANDRA-1258 URL: https://issues.apache.org/jira/browse/CASSANDRA-1258 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Nate McCall Fix For: 0.7 since index CFSes are private, they won't be streamed with other sstables. which is good, because the normal partitioner logic wouldn't stream the right parts anyway. seems like the right solution is to extend SSTW.maybeRecover to rebuild indexes as well. (this has the added benefit of being able to use streaming as a relatively straightforward bulk loader.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1258) rebuild indexes after streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1258: --- Attachment: trunk-1258-src.txt replacing patch file for minor code style change rebuild indexes after streaming --- Key: CASSANDRA-1258 URL: https://issues.apache.org/jira/browse/CASSANDRA-1258 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-1258-src.txt since index CFSes are private, they won't be streamed with other sstables. which is good, because the normal partitioner logic wouldn't stream the right parts anyway. seems like the right solution is to extend SSTW.maybeRecover to rebuild indexes as well. (this has the added benefit of being able to use streaming as a relatively straightforward bulk loader.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-1258) rebuild indexes after streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12890589#action_12890589 ] Nate McCall edited comment on CASSANDRA-1258 at 7/21/10 12:54 PM: -- Patches for allowing CFS to accept a recovered SSTableReader from which to retrieve the indexed columns. Having this on CFS allows for other uses such as added indexes after the fact, and providing mbean hooks into rebuilding indexes. Edit: this won't flush correctly unless the patch in CASSANDRA-1301 is applied as well. was (Author: zznate): Patches for allowing CFS to accept a recovered SSTableReader from which to retrieve the indexed columns. Having this on CFS allows for other uses such as added indexes after the fact, and providing mbean hooks into rebuilding indexes. rebuild indexes after streaming --- Key: CASSANDRA-1258 URL: https://issues.apache.org/jira/browse/CASSANDRA-1258 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Nate McCall Fix For: 0.7 Attachments: trunk-1258-src.txt since index CFSes are private, they won't be streamed with other sstables. which is good, because the normal partitioner logic wouldn't stream the right parts anyway. seems like the right solution is to extend SSTW.maybeRecover to rebuild indexes as well. (this has the added benefit of being able to use streaming as a relatively straightforward bulk loader.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1258) rebuild indexes after streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1258: --- Attachment: (was: trunk-1258-src.txt) rebuild indexes after streaming --- Key: CASSANDRA-1258 URL: https://issues.apache.org/jira/browse/CASSANDRA-1258 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Nate McCall Fix For: 0.7 beta 1 Attachments: trunk-1258-src-2.txt since index CFSes are private, they won't be streamed with other sstables. which is good, because the normal partitioner logic wouldn't stream the right parts anyway. seems like the right solution is to extend SSTW.maybeRecover to rebuild indexes as well. (this has the added benefit of being able to use streaming as a relatively straightforward bulk loader.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1258) rebuild indexes after streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1258: --- Attachment: trunk-1258-src-2.txt New patch file rebases on most recent trunk rebuild indexes after streaming --- Key: CASSANDRA-1258 URL: https://issues.apache.org/jira/browse/CASSANDRA-1258 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Nate McCall Fix For: 0.7 beta 1 Attachments: trunk-1258-src-2.txt since index CFSes are private, they won't be streamed with other sstables. which is good, because the normal partitioner logic wouldn't stream the right parts anyway. seems like the right solution is to extend SSTW.maybeRecover to rebuild indexes as well. (this has the added benefit of being able to use streaming as a relatively straightforward bulk loader.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1258) rebuild indexes after streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1258: --- Attachment: trunk-1258-src-2.txt rebuild indexes after streaming --- Key: CASSANDRA-1258 URL: https://issues.apache.org/jira/browse/CASSANDRA-1258 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Nate McCall Fix For: 0.7 beta 1 Attachments: trunk-1258-src-2.txt since index CFSes are private, they won't be streamed with other sstables. which is good, because the normal partitioner logic wouldn't stream the right parts anyway. seems like the right solution is to extend SSTW.maybeRecover to rebuild indexes as well. (this has the added benefit of being able to use streaming as a relatively straightforward bulk loader.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CASSANDRA-1258) rebuild indexes after streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12891316#action_12891316 ] Nate McCall edited comment on CASSANDRA-1258 at 7/22/10 4:28 PM: - New patch file rebases on most recent trunk. Edit: added additional logging statement on completion for more visibility. was (Author: zznate): New patch file rebases on most recent trunk rebuild indexes after streaming --- Key: CASSANDRA-1258 URL: https://issues.apache.org/jira/browse/CASSANDRA-1258 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Nate McCall Fix For: 0.7 beta 1 Attachments: trunk-1258-src-2.txt since index CFSes are private, they won't be streamed with other sstables. which is good, because the normal partitioner logic wouldn't stream the right parts anyway. seems like the right solution is to extend SSTW.maybeRecover to rebuild indexes as well. (this has the added benefit of being able to use streaming as a relatively straightforward bulk loader.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1258) rebuild indexes after streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12891683#action_12891683 ] Nate McCall commented on CASSANDRA-1258: I had started adding this on SSTR initially, but there wasnt any other query stuff going on there, so it seemed out of place - not a very compelling argument, but this was my first time with the plumbing. I have no problem moving it to SSTR - so let me know. I had forgotten I left the constructor in their (I had started messing around with creating indexes after the fact and meant to take it out). Let me know about SSTR and I'll rebase and get rid of the constructor. rebuild indexes after streaming --- Key: CASSANDRA-1258 URL: https://issues.apache.org/jira/browse/CASSANDRA-1258 Project: Cassandra Issue Type: Sub-task Components: Core Reporter: Jonathan Ellis Assignee: Nate McCall Fix For: 0.7 beta 1 Attachments: trunk-1258-src-2.txt since index CFSes are private, they won't be streamed with other sstables. which is good, because the normal partitioner logic wouldn't stream the right parts anyway. seems like the right solution is to extend SSTW.maybeRecover to rebuild indexes as well. (this has the added benefit of being able to use streaming as a relatively straightforward bulk loader.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1157) add support for multiple indexexpressions
[
https://issues.apache.org/jira/browse/CASSANDRA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12891893#action_12891893
]
Nate McCall commented on CASSANDRA-1157:
test_thrift_server fails with the message below.
There are two issues here though:
1) it looks like the RowPredicate is not getting reset with the IndexClause
(ln: 1251), when I add that, I get a similar error from the next scan about
unable to scan unindexed column again because RowPredicate is not reset.
After reseting, I still get the same error.
2) Though the system test implies indexed and non-indexed will play nice on the
same IndexExpression, ThriftValidation does not agree, throwing an exception on
the first missing column encountered.
Initial error after rebase and patches applied:
nate:cassandra-TRUNK$ python=test nosetests
--tests=system.test_thrift_server:TestMutations.test_index_scan
/usr/local/lib/python2.6/dist-packages/thrift/Thrift.py:58: DeprecationWarning:
BaseException.message has been deprecated as of Python 2.6
self.message = message
E
==
ERROR: system.test_thrift_server.TestMutations.test_index_scan
--
Traceback (most recent call last):
File /var/lib/python-support/python2.6/nose/case.py, line 182, in runTest
self.test(*self.arg)
File
/home/nate/workspace/cassandra-TRUNK/test/system/test_thrift_server.py, line
1252, in test_index_scan
_expect_exception(lambda: client.scan(cp, rp, sp, ConsistencyLevel.ONE),
InvalidRequestException)
File
/home/nate/workspace/cassandra-TRUNK/test/system/test_thrift_server.py, line
173, in _expect_exception
raise Exception('expected %s; got %s' % (type_.__name__, r))
Exception: expected InvalidRequestException; got
[KeySlice(columns=[ColumnOrSuperColumn(column=Column(ttl=None,
name='birthdate', value='\x00\x00\x00\x00\x00\x00\x00\x01',
clock=Clock(timestamp=0)), super_column=None)], key='key1')]
--
Ran 1 test in 2.430s
add support for multiple indexexpressions
-
Key: CASSANDRA-1157
URL: https://issues.apache.org/jira/browse/CASSANDRA-1157
Project: Cassandra
Issue Type: Sub-task
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Fix For: 0.7 beta 1
Attachments: 1157.txt
we should:
- use the statistics from CASSANDRA-1155 to figure out which index has the
highest selectivity, and start with that
- if other indexes have high selectivity (average number of columns in an
index row is less than 1% of total in that CF), we should do a merge join
- otherwise, just loop the results from the first and reject un-satisfied
expressions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1157) add support for multiple indexexpressions
[ https://issues.apache.org/jira/browse/CASSANDRA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate McCall updated CASSANDRA-1157: --- Attachment: 1157_thrift_validation_fix_w_tests.txt modified thrift validation to allow for indexed and unindexed columns in the same expression as long as there are more than one valid one add support for multiple indexexpressions - Key: CASSANDRA-1157 URL: https://issues.apache.org/jira/browse/CASSANDRA-1157 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Assignee: Jonathan Ellis Fix For: 0.7 beta 1 Attachments: 1157.txt, 1157_thrift_validation_fix_w_tests.txt we should: - use the statistics from CASSANDRA-1155 to figure out which index has the highest selectivity, and start with that - if other indexes have high selectivity (average number of columns in an index row is less than 1% of total in that CF), we should do a merge join - otherwise, just loop the results from the first and reject un-satisfied expressions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
