[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=13102001#comment-13102001 ] Jonathan Ellis commented on CASSANDRA-2882: --- No. It still needs to be constant across the cluster or things break. 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 Assignee: Mark Guzman Priority: Minor Labels: lhf Fix For: 1.1 Attachments: 0001-CASSANDRA-2882-feedback-changes.patch, 0001-CASSANDRA-2882-patch-w-o-generated-files.patch, 0001-CASSANDRA-2882-rebased.patch, 0001-added-the-host-addr-to-the-EndpointDetail-class.-det.patch, 0001-adding-an-additional-parameter-to-the-TokenRange-res.patch, 0001-final-cleaned-up-2882-changes.patch 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-3172) Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3172: -- Priority: Minor (was: Major) Fix Version/s: (was: 1.1) The point of LOCAL_QUORUM is that is gives you read/write consistency within the datacenter. EACH_QUORUM gives you read/write consistency across all DCs (so you can write at EACH_QUORUM and read at LOCAL_QUORUM for instance). I don't see any reason to use ANY_QUORUM over just CL.TWO for instance. Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover --- Key: CASSANDRA-3172 URL: https://issues.apache.org/jira/browse/CASSANDRA-3172 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Priority: Minor Currently we provide CL.LOCAL_QUORUM and CL.EACH_QUORUM. CL.ANY_QUORUM would operate like CL.LOCAL_QUORUM if a local quorum is possible, if it is not the coordinator would use its knowledge to select the fastest/closest node in another datacenter to attempt another LOCAL_QUORUM in. This would allow for simple reliable cross datacenter failover without putting the intelligence in the client. The client is intrinsically at a disadvantage since it doesn't have a current full picture of the rings. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3173) Add RPC_PORT to ApplicationState
[ https://issues.apache.org/jira/browse/CASSANDRA-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3173. --- Resolution: Won't Fix Fix Version/s: (was: 1.1) Assignee: (was: Mark Guzman) as explained on CASSANDRA-2882 Add RPC_PORT to ApplicationState Key: CASSANDRA-3173 URL: https://issues.apache.org/jira/browse/CASSANDRA-3173 Project: Cassandra Issue Type: Improvement Reporter: Mark Guzman Priority: Minor Labels: lhf Attachments: 0001-CASSANDRA-3173-adding-RPC_PORT-to-the-local-node-det.patch We currently maintain RPC_ADDRESS to help support clients. This would add the RPC_PORT allowing the data to drive client interactions, instead of conventions. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3150) ColumnFormatRecordReader loops forever
[
https://issues.apache.org/jira/browse/CASSANDRA-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mck SembWever updated CASSANDRA-3150:
-
Attachment: attempt_201109071357_0044_m_003040_0.grep-get_range_slices.log
Debug from a task that was still running at 1200%
The initial split for this CFRR is
30303030303031333131313739353337303038d4e7f72db2ed11e09d7c68b59973a5d8 :
303030303030313331323631393735313231381778518cc00711e0acb968b59973a5d8
This job was run with
cassandra.input.split.size=196608
cassandra.range.batch.size=16000
therefore there shouldn't be more than 13 calls to get_range_slices(..) in this
task. There was already 166 calls in this log.
What i can see here is that the original split for this task is just way too
big and this comes from {{describe_splits(..)}}
ColumnFormatRecordReader loops forever
--
Key: CASSANDRA-3150
URL: https://issues.apache.org/jira/browse/CASSANDRA-3150
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.4
Reporter: Mck SembWever
Assignee: Mck SembWever
Priority: Critical
Attachments: CASSANDRA-3150.patch,
attempt_201109071357_0044_m_003040_0.grep-get_range_slices.log
From http://thread.gmane.org/gmane.comp.db.cassandra.user/20039
{quote}
bq. Cassandra-0.8.4 w/ ByteOrderedPartitioner
bq. CFIF's inputSplitSize=196608
bq. 3 map tasks (from 4013) is still running after read 25 million rows.
bq. Can this be a bug in StorageService.getSplits(..) ?
getSplits looks pretty foolproof to me but I guess we'd need to add
more debug logging to rule out a bug there for sure.
I guess the main alternative would be a bug in the recordreader paging.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3172) Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102068#comment-13102068 ] Mark Guzman commented on CASSANDRA-3172: CL.TWO doesn't give you consistency depending on the RF right? This is pushing an operation I would be doing on the client up to the server. If I receive an UnavailableException, I would retry with another datacenter. My intent is to move that logic into the coordinator where we can remove the round trip for the UnavailableException and make smarter choices about what dc to try next. Given datacenters A, B and C with A being my local DC. I'd want to write/read from DC A if possible, if we don't have enough nodes to form a quorum within that DC I'd want to bounce to the next DC always favoring a quorum based on RF instead of falling back to CL.TWO or CL.ONE which don't offer similar consistency behavior. Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover --- Key: CASSANDRA-3172 URL: https://issues.apache.org/jira/browse/CASSANDRA-3172 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Priority: Minor Currently we provide CL.LOCAL_QUORUM and CL.EACH_QUORUM. CL.ANY_QUORUM would operate like CL.LOCAL_QUORUM if a local quorum is possible, if it is not the coordinator would use its knowledge to select the fastest/closest node in another datacenter to attempt another LOCAL_QUORUM in. This would allow for simple reliable cross datacenter failover without putting the intelligence in the client. The client is intrinsically at a disadvantage since it doesn't have a current full picture of the rings. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3172) Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102068#comment-13102068 ] Mark Guzman edited comment on CASSANDRA-3172 at 9/10/11 4:01 PM: - CL.TWO doesn't give you consistency depending on the RF right? This is pushing an operation I would be doing on the client up to the server. If I receive an UnavailableException, I would retry with another datacenter. My intent is to move that logic into the coordinator where we can remove the round trip for the UnavailableException and make smarter choices about what dc to try next. Given datacenters A, B and C with A being my local DC. I'd want to write/read from DC A if possible, if we don't have enough nodes to form a quorum within that DC I'd want to bounce to the next DC always favoring a quorum based on RF instead of falling back to CL.TWO or CL.ONE which don't offer similar consistency behavior. Versus LOCAL_QUORUM and EACH_QUORUM, local will fail if we can't meet the quorum requirements in the dc rendering an UnavailableException. Each casts a wider net and fails if any dc doesn't meet the quorum requirements. So in this specific case both would fail because the local quorum would be unavailable. was (Author: segy): CL.TWO doesn't give you consistency depending on the RF right? This is pushing an operation I would be doing on the client up to the server. If I receive an UnavailableException, I would retry with another datacenter. My intent is to move that logic into the coordinator where we can remove the round trip for the UnavailableException and make smarter choices about what dc to try next. Given datacenters A, B and C with A being my local DC. I'd want to write/read from DC A if possible, if we don't have enough nodes to form a quorum within that DC I'd want to bounce to the next DC always favoring a quorum based on RF instead of falling back to CL.TWO or CL.ONE which don't offer similar consistency behavior. Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover --- Key: CASSANDRA-3172 URL: https://issues.apache.org/jira/browse/CASSANDRA-3172 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Priority: Minor Currently we provide CL.LOCAL_QUORUM and CL.EACH_QUORUM. CL.ANY_QUORUM would operate like CL.LOCAL_QUORUM if a local quorum is possible, if it is not the coordinator would use its knowledge to select the fastest/closest node in another datacenter to attempt another LOCAL_QUORUM in. This would allow for simple reliable cross datacenter failover without putting the intelligence in the client. The client is intrinsically at a disadvantage since it doesn't have a current full picture of the rings. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3150) ColumnFormatRecordReader loops forever
[
https://issues.apache.org/jira/browse/CASSANDRA-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102062#comment-13102062
]
Mck SembWever edited comment on CASSANDRA-3150 at 9/10/11 6:02 PM:
---
Debug from a task that was still running at 1200%
The initial split for this CFRR is
30303030303031333131313739353337303038d4e7f72db2ed11e09d7c68b59973a5d8 :
303030303030313331323631393735313231381778518cc00711e0acb968b59973a5d8
This job was run with
cassandra.input.split.size=196608
cassandra.range.batch.size=16000
therefore there shouldn't be more than 13 calls to get_range_slices(..) in this
task. There was already 166 calls in this log.
What i can see here is that the original split for this task is just way too
big and this comes from {{describe_splits(..)}}
which in turn depends on index_interval. Reading
{{StorageService.getSplits(..)}} i would guess that the split can in fact
contain many more keys with the default sampling of 128. Question is how low
can/should i bring index_interval ?
was (Author: michaelsembwever):
Debug from a task that was still running at 1200%
The initial split for this CFRR is
30303030303031333131313739353337303038d4e7f72db2ed11e09d7c68b59973a5d8 :
303030303030313331323631393735313231381778518cc00711e0acb968b59973a5d8
This job was run with
cassandra.input.split.size=196608
cassandra.range.batch.size=16000
therefore there shouldn't be more than 13 calls to get_range_slices(..) in this
task. There was already 166 calls in this log.
What i can see here is that the original split for this task is just way too
big and this comes from {{describe_splits(..)}}
ColumnFormatRecordReader loops forever
--
Key: CASSANDRA-3150
URL: https://issues.apache.org/jira/browse/CASSANDRA-3150
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.4
Reporter: Mck SembWever
Assignee: Mck SembWever
Priority: Critical
Attachments: CASSANDRA-3150.patch,
attempt_201109071357_0044_m_003040_0.grep-get_range_slices.log
From http://thread.gmane.org/gmane.comp.db.cassandra.user/20039
{quote}
bq. Cassandra-0.8.4 w/ ByteOrderedPartitioner
bq. CFIF's inputSplitSize=196608
bq. 3 map tasks (from 4013) is still running after read 25 million rows.
bq. Can this be a bug in StorageService.getSplits(..) ?
getSplits looks pretty foolproof to me but I guess we'd need to add
more debug logging to rule out a bug there for sure.
I guess the main alternative would be a bug in the recordreader paging.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3150) ColumnFormatRecordReader loops forever
[
https://issues.apache.org/jira/browse/CASSANDRA-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102062#comment-13102062
]
Mck SembWever edited comment on CASSANDRA-3150 at 9/10/11 6:04 PM:
---
Debug from a task that was still running at 1200%
The initial split for this CFRR is
30303030303031333131313739353337303038d4e7f72db2ed11e09d7c68b59973a5d8 :
303030303030313331323631393735313231381778518cc00711e0acb968b59973a5d8
This job was run with
cassandra.input.split.size=196608
cassandra.range.batch.size=16000
therefore there shouldn't be more than 13 calls to get_range_slices(..) in this
task. There was already 166 calls in this log.
What i can see here is that the original split for this task is just way too
big and this comes from {{describe_splits(..)}}
which in turn depends on index_interval. Reading
{{StorageService.getSplits(..)}} i would guess that the split can in fact
contain many more keys with the default sampling of 128. Question is how low
can/should i bring index_interval (this cf can have up to 8 billion rows)?
was (Author: michaelsembwever):
Debug from a task that was still running at 1200%
The initial split for this CFRR is
30303030303031333131313739353337303038d4e7f72db2ed11e09d7c68b59973a5d8 :
303030303030313331323631393735313231381778518cc00711e0acb968b59973a5d8
This job was run with
cassandra.input.split.size=196608
cassandra.range.batch.size=16000
therefore there shouldn't be more than 13 calls to get_range_slices(..) in this
task. There was already 166 calls in this log.
What i can see here is that the original split for this task is just way too
big and this comes from {{describe_splits(..)}}
which in turn depends on index_interval. Reading
{{StorageService.getSplits(..)}} i would guess that the split can in fact
contain many more keys with the default sampling of 128. Question is how low
can/should i bring index_interval ?
ColumnFormatRecordReader loops forever
--
Key: CASSANDRA-3150
URL: https://issues.apache.org/jira/browse/CASSANDRA-3150
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.4
Reporter: Mck SembWever
Assignee: Mck SembWever
Priority: Critical
Attachments: CASSANDRA-3150.patch,
attempt_201109071357_0044_m_003040_0.grep-get_range_slices.log
From http://thread.gmane.org/gmane.comp.db.cassandra.user/20039
{quote}
bq. Cassandra-0.8.4 w/ ByteOrderedPartitioner
bq. CFIF's inputSplitSize=196608
bq. 3 map tasks (from 4013) is still running after read 25 million rows.
bq. Can this be a bug in StorageService.getSplits(..) ?
getSplits looks pretty foolproof to me but I guess we'd need to add
more debug logging to rule out a bug there for sure.
I guess the main alternative would be a bug in the recordreader paging.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3172) Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102103#comment-13102103 ] Jonathan Ellis commented on CASSANDRA-3172: --- But if you are switching between DCs you're already saying I don't care very much about consistency after all. Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover --- Key: CASSANDRA-3172 URL: https://issues.apache.org/jira/browse/CASSANDRA-3172 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Priority: Minor Currently we provide CL.LOCAL_QUORUM and CL.EACH_QUORUM. CL.ANY_QUORUM would operate like CL.LOCAL_QUORUM if a local quorum is possible, if it is not the coordinator would use its knowledge to select the fastest/closest node in another datacenter to attempt another LOCAL_QUORUM in. This would allow for simple reliable cross datacenter failover without putting the intelligence in the client. The client is intrinsically at a disadvantage since it doesn't have a current full picture of the rings. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3150) ColumnFormatRecordReader loops forever
[
https://issues.apache.org/jira/browse/CASSANDRA-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102115#comment-13102115
]
Mck SembWever commented on CASSANDRA-3150:
--
There's a lot to learn about cassandra so forgive my ignorance in so many areas.
So how can {{StorageService.getSplits(..)}} be so out of whack? Is there
anything i can tune to better this situation?
(Or is there any other debug i can provide?)
ColumnFormatRecordReader loops forever
--
Key: CASSANDRA-3150
URL: https://issues.apache.org/jira/browse/CASSANDRA-3150
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.4
Reporter: Mck SembWever
Assignee: Mck SembWever
Priority: Critical
Attachments: CASSANDRA-3150.patch,
attempt_201109071357_0044_m_003040_0.grep-get_range_slices.log
From http://thread.gmane.org/gmane.comp.db.cassandra.user/20039
{quote}
bq. Cassandra-0.8.4 w/ ByteOrderedPartitioner
bq. CFIF's inputSplitSize=196608
bq. 3 map tasks (from 4013) is still running after read 25 million rows.
bq. Can this be a bug in StorageService.getSplits(..) ?
getSplits looks pretty foolproof to me but I guess we'd need to add
more debug logging to rule out a bug there for sure.
I guess the main alternative would be a bug in the recordreader paging.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3174) [patch] don't use reference comparison on counts
[patch] don't use reference comparison on counts Key: CASSANDRA-3174 URL: https://issues.apache.org/jira/browse/CASSANDRA-3174 Project: Cassandra Issue Type: Bug Reporter: Dave Brosius Priority: Trivial Attachments: no_ref_compare.diff code compares Longs by reference instead of value -- patch fixes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3174) [patch] don't use reference comparison on counts
[ https://issues.apache.org/jira/browse/CASSANDRA-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3174: Attachment: no_ref_compare.diff [patch] don't use reference comparison on counts Key: CASSANDRA-3174 URL: https://issues.apache.org/jira/browse/CASSANDRA-3174 Project: Cassandra Issue Type: Bug Reporter: Dave Brosius Priority: Trivial Attachments: no_ref_compare.diff code compares Longs by reference instead of value -- patch fixes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3174) [patch] don't use reference comparison on counts
[ https://issues.apache.org/jira/browse/CASSANDRA-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated CASSANDRA-3174: Attachment: no_ref_compare.diff [patch] don't use reference comparison on counts Key: CASSANDRA-3174 URL: https://issues.apache.org/jira/browse/CASSANDRA-3174 Project: Cassandra Issue Type: Bug Reporter: Dave Brosius Priority: Trivial Attachments: no_ref_compare.diff code compares Longs by reference instead of value -- patch fixes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3150) ColumnFormatRecordReader loops forever
[
https://issues.apache.org/jira/browse/CASSANDRA-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102126#comment-13102126
]
Jonathan Ellis commented on CASSANDRA-3150:
---
I don't know. I think what I would do would be to use sstablekeys to
double-check how many rows there really are in the given split range.
ColumnFormatRecordReader loops forever
--
Key: CASSANDRA-3150
URL: https://issues.apache.org/jira/browse/CASSANDRA-3150
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.8.4
Reporter: Mck SembWever
Assignee: Mck SembWever
Priority: Critical
Attachments: CASSANDRA-3150.patch,
attempt_201109071357_0044_m_003040_0.grep-get_range_slices.log
From http://thread.gmane.org/gmane.comp.db.cassandra.user/20039
{quote}
bq. Cassandra-0.8.4 w/ ByteOrderedPartitioner
bq. CFIF's inputSplitSize=196608
bq. 3 map tasks (from 4013) is still running after read 25 million rows.
bq. Can this be a bug in StorageService.getSplits(..) ?
getSplits looks pretty foolproof to me but I guess we'd need to add
more debug logging to rule out a bug there for sure.
I guess the main alternative would be a bug in the recordreader paging.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3174) [patch] don't use reference comparison on counts
[ https://issues.apache.org/jira/browse/CASSANDRA-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3174. --- Resolution: Duplicate duplicate of CASSANDRA-3164 [patch] don't use reference comparison on counts Key: CASSANDRA-3174 URL: https://issues.apache.org/jira/browse/CASSANDRA-3174 Project: Cassandra Issue Type: Bug Reporter: Dave Brosius Priority: Trivial Attachments: no_ref_compare.diff code compares Longs by reference instead of value -- patch fixes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3031) Add 4 byte integer type
[ https://issues.apache.org/jira/browse/CASSANDRA-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Hrazdil updated CASSANDRA-3031: Attachment: cli_help.diff repair mistake in type names in CLI. Add 4 byte integer type --- Key: CASSANDRA-3031 URL: https://issues.apache.org/jira/browse/CASSANDRA-3031 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Environment: any Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: hector, lhf Fix For: 1.0.0 Attachments: apache-cassandra-1.0-dev-SNAPSHOT.jar, apache-cassandra-thrift-1.0-dev-SNAPSHOT.jar, cli_help.diff, drivers.diff, src.diff, test.diff, test.log Cassandra currently lacks support for 4byte fixed size integer data type. Java API Hector and C libcassandra likes to serialize integers as 4 bytes in network order. Problem is that you cant use cassandra-cli to manipulate stored rows. Compatibility with other applications using api following cassandra integer encoding standard is problematic too. Because adding new datatype/validator is fairly simple I recommend to add int4 data type. Compatibility with hector is important because it is most used Java cassandra api and lot of applications are using it. This problem was discussed several times already http://comments.gmane.org/gmane.comp.db.hector.user/2125 https://issues.apache.org/jira/browse/CASSANDRA-2585 It would be nice to have compatibility with cassandra-cli and other applications without rewriting hector apps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3031) Add 4 byte integer type
[ https://issues.apache.org/jira/browse/CASSANDRA-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Hrazdil updated CASSANDRA-3031: Attachment: cli_help.diff Mistake in type name int for CLI. Add 4 byte integer type --- Key: CASSANDRA-3031 URL: https://issues.apache.org/jira/browse/CASSANDRA-3031 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Environment: any Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: hector, lhf Fix For: 1.0.0 Attachments: apache-cassandra-1.0-dev-SNAPSHOT.jar, apache-cassandra-thrift-1.0-dev-SNAPSHOT.jar, cli_help.diff, drivers.diff, src.diff, test.diff, test.log Cassandra currently lacks support for 4byte fixed size integer data type. Java API Hector and C libcassandra likes to serialize integers as 4 bytes in network order. Problem is that you cant use cassandra-cli to manipulate stored rows. Compatibility with other applications using api following cassandra integer encoding standard is problematic too. Because adding new datatype/validator is fairly simple I recommend to add int4 data type. Compatibility with hector is important because it is most used Java cassandra api and lot of applications are using it. This problem was discussed several times already http://comments.gmane.org/gmane.comp.db.hector.user/2125 https://issues.apache.org/jira/browse/CASSANDRA-2585 It would be nice to have compatibility with cassandra-cli and other applications without rewriting hector apps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3031) Add 4 byte integer type
[ https://issues.apache.org/jira/browse/CASSANDRA-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Hrazdil updated CASSANDRA-3031: Attachment: (was: cli_help.diff) Add 4 byte integer type --- Key: CASSANDRA-3031 URL: https://issues.apache.org/jira/browse/CASSANDRA-3031 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Environment: any Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: hector, lhf Fix For: 1.0.0 Attachments: apache-cassandra-1.0-dev-SNAPSHOT.jar, apache-cassandra-thrift-1.0-dev-SNAPSHOT.jar, cli_help.diff, drivers.diff, src.diff, test.diff, test.log Cassandra currently lacks support for 4byte fixed size integer data type. Java API Hector and C libcassandra likes to serialize integers as 4 bytes in network order. Problem is that you cant use cassandra-cli to manipulate stored rows. Compatibility with other applications using api following cassandra integer encoding standard is problematic too. Because adding new datatype/validator is fairly simple I recommend to add int4 data type. Compatibility with hector is important because it is most used Java cassandra api and lot of applications are using it. This problem was discussed several times already http://comments.gmane.org/gmane.comp.db.hector.user/2125 https://issues.apache.org/jira/browse/CASSANDRA-2585 It would be nice to have compatibility with cassandra-cli and other applications without rewriting hector apps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3031) Add 4 byte integer type
[ https://issues.apache.org/jira/browse/CASSANDRA-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Hrazdil updated CASSANDRA-3031: Comment: was deleted (was: repair mistake in type names in CLI.) Add 4 byte integer type --- Key: CASSANDRA-3031 URL: https://issues.apache.org/jira/browse/CASSANDRA-3031 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Environment: any Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: hector, lhf Fix For: 1.0.0 Attachments: apache-cassandra-1.0-dev-SNAPSHOT.jar, apache-cassandra-thrift-1.0-dev-SNAPSHOT.jar, cli_help.diff, drivers.diff, src.diff, test.diff, test.log Cassandra currently lacks support for 4byte fixed size integer data type. Java API Hector and C libcassandra likes to serialize integers as 4 bytes in network order. Problem is that you cant use cassandra-cli to manipulate stored rows. Compatibility with other applications using api following cassandra integer encoding standard is problematic too. Because adding new datatype/validator is fairly simple I recommend to add int4 data type. Compatibility with hector is important because it is most used Java cassandra api and lot of applications are using it. This problem was discussed several times already http://comments.gmane.org/gmane.comp.db.hector.user/2125 https://issues.apache.org/jira/browse/CASSANDRA-2585 It would be nice to have compatibility with cassandra-cli and other applications without rewriting hector apps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3031) Add 4 byte integer type
[ https://issues.apache.org/jira/browse/CASSANDRA-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102151#comment-13102151 ] Jonathan Ellis commented on CASSANDRA-3031: --- also committed. Add 4 byte integer type --- Key: CASSANDRA-3031 URL: https://issues.apache.org/jira/browse/CASSANDRA-3031 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0.0 Environment: any Reporter: Radim Kolar Assignee: Radim Kolar Priority: Minor Labels: hector, lhf Fix For: 1.0.0 Attachments: apache-cassandra-1.0-dev-SNAPSHOT.jar, apache-cassandra-thrift-1.0-dev-SNAPSHOT.jar, cli_help.diff, drivers.diff, src.diff, test.diff, test.log Cassandra currently lacks support for 4byte fixed size integer data type. Java API Hector and C libcassandra likes to serialize integers as 4 bytes in network order. Problem is that you cant use cassandra-cli to manipulate stored rows. Compatibility with other applications using api following cassandra integer encoding standard is problematic too. Because adding new datatype/validator is fairly simple I recommend to add int4 data type. Compatibility with hector is important because it is most used Java cassandra api and lot of applications are using it. This problem was discussed several times already http://comments.gmane.org/gmane.comp.db.hector.user/2125 https://issues.apache.org/jira/browse/CASSANDRA-2585 It would be nice to have compatibility with cassandra-cli and other applications without rewriting hector apps. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3175) Ec2Snitch nodetool issue after upgrade to 0.8.5
Ec2Snitch nodetool issue after upgrade to 0.8.5 --- Key: CASSANDRA-3175 URL: https://issues.apache.org/jira/browse/CASSANDRA-3175 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.5 Environment: Amazon Ec2 with 4 nodes in region ap-southeast. 2 in 1a, 2 in 1b Reporter: Sasha Dolgy Upgraded one ring that has four nodes from 0.8.0 to 0.8.5 with only one minor problem. It relates to Ec2Snitch when running a 'nodetool ring' from two of the four nodes. the rest are all working fine: Address DC RackStatus State Load OwnsToken 148362247927262972740864614603570725035 172.16.12.11ap-southeast1a Up Normal 1.58 MB 24.02% 1909554714494251628118265338228798 172.16.12.10ap-southeast1a Up Normal 1.63 MB 22.11% 56713727820156410577229101238628035242 172.16.14.10ap-southeast1b Up Normal 1.85 MB 33.33% 113427455640312821154458202477256070484 172.16.14.12ap-southeast1b Up Normal 1.36 MB 20.53% 14836224792726297274086461460357072503 works ... on 2 nodes which happen to be on the 172.16.14.0/24 network. the nodes where the error appears are on the 172.16.12.0/24 network and this is what is shown when nodetool ring is run: Address DC RackStatus State Load OwnsToken 148362247927262972740864614603570725035 172.16.12.11ap-southeast1a Up Normal 1.58 MB 24.02% 1909554714494251628118265338228798 172.16.12.10ap-southeast1a Up Normal 1.62 MB 22.11% 56713727820156410577229101238628035242 Exception in thread main java.lang.NullPointerException at org.apache.cassandra.locator.Ec2Snitch.getDatacenter(Ec2Snitch.java:93) at org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:122) at org.apache.cassandra.locator.EndpointSnitchInfo.getDatacenter(EndpointSnitchInfo.java:49) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) 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) I've stopped the node and started it ... still doesn't make a difference. I've also shut down all nodes in the ring so that it was fully offline, and then brought them all back up ... issue still persists on two of the nodes. There are no firewall rules restricting traffic between these nodes. For example, on a node where the
[jira] [Updated] (CASSANDRA-3175) Ec2Snitch nodetool issue after upgrade to 0.8.5
[ https://issues.apache.org/jira/browse/CASSANDRA-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3175: -- Priority: Minor (was: Major) Fix Version/s: 0.8.6 Ec2Snitch nodetool issue after upgrade to 0.8.5 --- Key: CASSANDRA-3175 URL: https://issues.apache.org/jira/browse/CASSANDRA-3175 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.5 Environment: Amazon Ec2 with 4 nodes in region ap-southeast. 2 in 1a, 2 in 1b Reporter: Sasha Dolgy Assignee: Brandon Williams Priority: Minor Labels: ec2snitch, nodetool Fix For: 0.8.6 Upgraded one ring that has four nodes from 0.8.0 to 0.8.5 with only one minor problem. It relates to Ec2Snitch when running a 'nodetool ring' from two of the four nodes. the rest are all working fine: Address DC RackStatus State Load OwnsToken 148362247927262972740864614603570725035 172.16.12.11ap-southeast1a Up Normal 1.58 MB 24.02% 1909554714494251628118265338228798 172.16.12.10ap-southeast1a Up Normal 1.63 MB 22.11% 56713727820156410577229101238628035242 172.16.14.10ap-southeast1b Up Normal 1.85 MB 33.33% 113427455640312821154458202477256070484 172.16.14.12ap-southeast1b Up Normal 1.36 MB 20.53% 14836224792726297274086461460357072503 works ... on 2 nodes which happen to be on the 172.16.14.0/24 network. the nodes where the error appears are on the 172.16.12.0/24 network and this is what is shown when nodetool ring is run: Address DC RackStatus State Load OwnsToken 148362247927262972740864614603570725035 172.16.12.11ap-southeast1a Up Normal 1.58 MB 24.02% 1909554714494251628118265338228798 172.16.12.10ap-southeast1a Up Normal 1.62 MB 22.11% 56713727820156410577229101238628035242 Exception in thread main java.lang.NullPointerException at org.apache.cassandra.locator.Ec2Snitch.getDatacenter(Ec2Snitch.java:93) at org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:122) at org.apache.cassandra.locator.EndpointSnitchInfo.getDatacenter(EndpointSnitchInfo.java:49) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at
[jira] [Assigned] (CASSANDRA-3175) Ec2Snitch nodetool issue after upgrade to 0.8.5
[ https://issues.apache.org/jira/browse/CASSANDRA-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis reassigned CASSANDRA-3175: - Assignee: Brandon Williams Ec2Snitch nodetool issue after upgrade to 0.8.5 --- Key: CASSANDRA-3175 URL: https://issues.apache.org/jira/browse/CASSANDRA-3175 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.5 Environment: Amazon Ec2 with 4 nodes in region ap-southeast. 2 in 1a, 2 in 1b Reporter: Sasha Dolgy Assignee: Brandon Williams Labels: ec2snitch, nodetool Fix For: 0.8.6 Upgraded one ring that has four nodes from 0.8.0 to 0.8.5 with only one minor problem. It relates to Ec2Snitch when running a 'nodetool ring' from two of the four nodes. the rest are all working fine: Address DC RackStatus State Load OwnsToken 148362247927262972740864614603570725035 172.16.12.11ap-southeast1a Up Normal 1.58 MB 24.02% 1909554714494251628118265338228798 172.16.12.10ap-southeast1a Up Normal 1.63 MB 22.11% 56713727820156410577229101238628035242 172.16.14.10ap-southeast1b Up Normal 1.85 MB 33.33% 113427455640312821154458202477256070484 172.16.14.12ap-southeast1b Up Normal 1.36 MB 20.53% 14836224792726297274086461460357072503 works ... on 2 nodes which happen to be on the 172.16.14.0/24 network. the nodes where the error appears are on the 172.16.12.0/24 network and this is what is shown when nodetool ring is run: Address DC RackStatus State Load OwnsToken 148362247927262972740864614603570725035 172.16.12.11ap-southeast1a Up Normal 1.58 MB 24.02% 1909554714494251628118265338228798 172.16.12.10ap-southeast1a Up Normal 1.62 MB 22.11% 56713727820156410577229101238628035242 Exception in thread main java.lang.NullPointerException at org.apache.cassandra.locator.Ec2Snitch.getDatacenter(Ec2Snitch.java:93) at org.apache.cassandra.locator.DynamicEndpointSnitch.getDatacenter(DynamicEndpointSnitch.java:122) at org.apache.cassandra.locator.EndpointSnitchInfo.getDatacenter(EndpointSnitchInfo.java:49) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at
[jira] [Commented] (CASSANDRA-3172) Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
[
https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102162#comment-13102162
]
Mark Guzman commented on CASSANDRA-3172:
The assumption I'm making is that if this occurs then reads most likely will
occur from the same dc I've failed over to. Once I get back over to the
original dc, the further belief is that the background replication between DCs
will have at least propagated the write to some of the nodes. Enough to
hopefully provide a consistent view. That's the intent, the details of how I
get it to do that is up in the air. I may need to pin myself to the other DC
for a period of time, it depends on the details of replication setup like {A:3,
B:3, C:3}. My understanding is that the coordinator will contact a single node
in the other DCs to replicate the write and that this will succeed over time
even if the other DCs can not meet the same consistency requirements at the
time of the original write. Is this correct?
Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
---
Key: CASSANDRA-3172
URL: https://issues.apache.org/jira/browse/CASSANDRA-3172
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Reporter: Mark Guzman
Priority: Minor
Currently we provide CL.LOCAL_QUORUM and CL.EACH_QUORUM. CL.ANY_QUORUM would
operate like CL.LOCAL_QUORUM if a local quorum is possible, if it is not the
coordinator would use its knowledge to select the fastest/closest node in
another datacenter to attempt another LOCAL_QUORUM in. This would allow for
simple reliable cross datacenter failover without putting the intelligence in
the client. The client is intrinsically at a disadvantage since it doesn't
have a current full picture of the rings.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3172) Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
[
https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102162#comment-13102162
]
Mark Guzman edited comment on CASSANDRA-3172 at 9/10/11 10:15 PM:
--
The assumption I'm making is that if this occurs then reads most likely will
occur from the same dc I've failed over to. Once I get back over to the
original dc, the further belief is that the background replication between DCs
will have at least propagated the write to some of the nodes. Enough to
hopefully provide a consistent view. That's the intent. The details of how I
get it to do that is up in the air. I may need to pin myself to the other DC
for a period of time, it depends on the details of replication setup like {A:3,
B:3, C:3}. My understanding is that the coordinator will contact a single node
in the other DCs to replicate the write and that this will succeed over time
even if the other DCs can not meet the same consistency requirements at the
time of the original write. Is this correct?
was (Author: segy):
The assumption I'm making is that if this occurs then reads most likely
will occur from the same dc I've failed over to. Once I get back over to the
original dc, the further belief is that the background replication between DCs
will have at least propagated the write to some of the nodes. Enough to
hopefully provide a consistent view. That's the intent, the details of how I
get it to do that is up in the air. I may need to pin myself to the other DC
for a period of time, it depends on the details of replication setup like {A:3,
B:3, C:3}. My understanding is that the coordinator will contact a single node
in the other DCs to replicate the write and that this will succeed over time
even if the other DCs can not meet the same consistency requirements at the
time of the original write. Is this correct?
Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
---
Key: CASSANDRA-3172
URL: https://issues.apache.org/jira/browse/CASSANDRA-3172
Project: Cassandra
Issue Type: Improvement
Components: API, Core
Reporter: Mark Guzman
Priority: Minor
Currently we provide CL.LOCAL_QUORUM and CL.EACH_QUORUM. CL.ANY_QUORUM would
operate like CL.LOCAL_QUORUM if a local quorum is possible, if it is not the
coordinator would use its knowledge to select the fastest/closest node in
another datacenter to attempt another LOCAL_QUORUM in. This would allow for
simple reliable cross datacenter failover without putting the intelligence in
the client. The client is intrinsically at a disadvantage since it doesn't
have a current full picture of the rings.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3172) Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover
[ https://issues.apache.org/jira/browse/CASSANDRA-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-3172. --- Resolution: Won't Fix ANY_QUORUM is far from likely to be (entirely) consistent since as soon as enough local nodes recover, reads will prefer that instead. More fundamentally, you're overcomplicating things. If you're okay with reads occasionally not being 100% (locally) consistent, then use CL.ONE (or TWO if you want to guarantee redundancy on writes). If you're not, then stick with LOCAL_QUORUM. Add CL.ANY_QUORUM to support quorum requests with cross datacenter failover --- Key: CASSANDRA-3172 URL: https://issues.apache.org/jira/browse/CASSANDRA-3172 Project: Cassandra Issue Type: Improvement Components: API, Core Reporter: Mark Guzman Priority: Minor Currently we provide CL.LOCAL_QUORUM and CL.EACH_QUORUM. CL.ANY_QUORUM would operate like CL.LOCAL_QUORUM if a local quorum is possible, if it is not the coordinator would use its knowledge to select the fastest/closest node in another datacenter to attempt another LOCAL_QUORUM in. This would allow for simple reliable cross datacenter failover without putting the intelligence in the client. The client is intrinsically at a disadvantage since it doesn't have a current full picture of the rings. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
