[jira] [Created] (CASSANDRA-3640) Dynamic Snitch does not compute scores if no direct reads hit the node.
Dynamic Snitch does not compute scores if no direct reads hit the node. --- Key: CASSANDRA-3640 URL: https://issues.apache.org/jira/browse/CASSANDRA-3640 Project: Cassandra Issue Type: Bug Reporter: Edward Capriolo Priority: Minor We can into an interesting situation. We added 2 nodes to our cluster. Strangely this node performed worse then other nodes. It had more IOwait for example. The impact was not major but it was noticeable. Later I determined that this Cassandra node was not in our client's list of nodes and our clients do not auto discover. I confirmed that the host did not have any scores inside it's dynamic snitch. It is counter intuitive that a node receiving less or no direct user requests would perform worse then others. I am not sure of the dynamic that caused this. I understand that DSnitch is supposed to have it's own view of the world, maybe it could share information with neighbours. Again this is more of a client configuration issue then a direct Cassandra issue, but I found it quite interesting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3321) Node joins/Node moves should build caches
Node joins/Node moves should build caches -- Key: CASSANDRA-3321 URL: https://issues.apache.org/jira/browse/CASSANDRA-3321 Project: Cassandra Issue Type: New Feature Reporter: Edward Capriolo Priority: Minor Cassandra use case: high rate of low latency reads served mostly from caches. When a new node is joined data is streamed to it. However it is born into a 'cold world'. It does not have the benefit of saved caches. Clients with auto-discovery will find it and start sending requests it's way. If the request rate is high enough and clients are aggressive enough the Cassandra node could run out of sockets. This feature would build 'best effort' caches possibly by sampling entries from the caches of nodes the data was streamed from. With this even a newly joined node should have cache warming. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3281) Add an AbstractType anytype which stores meta data on a per column basis
Add an AbstractType anytype which stores meta data on a per column basis Key: CASSANDRA-3281 URL: https://issues.apache.org/jira/browse/CASSANDRA-3281 Project: Cassandra Issue Type: New Feature Reporter: Edward Capriolo Priority: Minor A pet project of mine is an AbstractType for Cassandra that stores metadata of the type in the column. https://github.com/edwardcapriolo/Cassandra-AnyType I described my use case any my design decisions here. https://github.com/edwardcapriolo/Cassandra-AnyType/blob/master/README . The biggest cases were needing to support null and '' as keys, column names, and column values, however I also think the technique used to serialize Java Objects as JSON but compare as a Java object is novel. Side node: (The AbstractType interface has changed multiple times between 0.6.X, 0.7.X, and 1.0.0-beta. I hope it stabilizes! ) If people would like AnyType (or parts of it ) incorporated into Cassandra that would be great. I am willing to tweak change it based on other peoples ideas. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
