gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lewis John McGibbney (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GORA-167) Make Cassandra keyspace consistency configurable within gora.properties
Date Fri, 12 Apr 2013 21:20:16 GMT

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

Lewis John McGibbney commented on GORA-167:
-------------------------------------------

Hey Roland. Thank you for reviewing :)

{bq} "Unless explicitly turned off, Hadoop by default specifies two resources, loaded in-order
from the classpath: "?! {bq}
I actually have no idea where I got this one from! This is unlike me? Maybe I was hung over
or something that day!

{bq} "Applications may add additional resources, which are loaded subsequent to these resources
in the order they are added" {bq}
ditto!!!

I can add the <p> syntax, this is not a problem. Thank you for your attention to detail.

I wonder if you tried changing the keyspace consistency? Please correct me if I am wrong,
but I think you mentioned previously that your applications which write Gora data to Cassandra
are not living the in the same data centre and communicate across network? Are you able to
change the consistency and describe your findings?

                
> Make Cassandra keyspace consistency configurable within gora.properties
> -----------------------------------------------------------------------
>
>                 Key: GORA-167
>                 URL: https://issues.apache.org/jira/browse/GORA-167
>             Project: Apache Gora
>          Issue Type: Improvement
>          Components: gora-cassandra
>    Affects Versions: 0.2.1
>            Reporter: Lewis John McGibbney
>            Assignee: Lewis John McGibbney
>            Priority: Minor
>             Fix For: 0.3
>
>         Attachments: GORA-167.patch
>
>
> Current in CassandraClient#checkKeyspace() consistency is hard coded such that consistency
level is .ONE which permits consistency to wait until one replica has responded. This could
be improved to enable users to specify other consistency profiles e.g. 
>         ANY: Wait until some replica has responded.
>         ONE: Wait until one replica has responded.
>         TWO: Wait until two replicas have responded.
>         THREE: Wait until three replicas have responded.
>         LOCAL_QUORUM: Wait for quorum on the datacenter the connection was stablished.
>         EACH_QUORUM: Wait for quorum on each datacenter.
>         QUORUM: Wait for a quorum of replicas (no matter which datacenter).
>         ALL: Blocks for all the replicas before returning to the client.
> Configuration should be made available through gora.properties

--
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

Mime
View raw message