cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ivan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1664) NetworkTopologyStrategy + DCQUORUM
Date Sat, 20 Nov 2010 02:07:14 GMT

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

ivan commented on CASSANDRA-1664:
---------------------------------

I think you are right Jonathan, there is some anomaly.

I think tmd.getWriteEndpoints shouldn't be modified.
It gets a list of natural (write) endpoints list and modifies list depending on pending ranges.
(getNaturalEnpoints(... write) result provided in argument and corrected with pending ranges).

bq. natural endpoints are the endpoints that the Strategy wants to place the replicas on,
and will be checked for reads
Writes are not modified by patch. Reads are modified by AbstractReplicationStrategy.getNaturalEndpoints.
(calculateNaturalEndpoints used in it which depends on ReplicationStrategy implementation
- Command provided to calculateNaturalEndpoint so that can provide proper result).

bq. write endpoints are the natural endpoints, with the addition of endpoints that are part
of "pending ranges" - nodes that will assume a range when a move or bootstrap completes
Writes are not modified by patch.  tmd.getWriteEndpoints gets a target list. That gives a
write endpoint list (provided by natural (write) endpoints) in StorageProxy mutate (getWriteEndpoint
is used in just mutate).

bq. hinted endpoints are write endpoints modified to remove nodes that are down and inform
StorageProxy what hints to tag to the live ones, if any
Writes are not modified by patch.  HintedEndpoints provided by AbstractReplicationStrategy.
Result depends on EndpointSnitch and given targets. (getHintedEndpoints used in just StorageProxy.mutate)

So I think circle closed. Endpoint list is contolled by AbstractReplicationStrategy and derived
implementations (methods used: getNaturalEndpoints, getHintedEndpoints and calculateEndpoints).

StorageProxy.Command is used in StorageService.getLiveNaturalEndpoint also which used in ReadVerbHandler
for read repair (Command.Write - maybe it can be Command.Read) and in StorageProxy for reads.

StorageProxy.Command is used in StorageService.findSuitableEndpoint also. Maybe findSuitable
should be renamed to findSuitableReadEndpoint.

What's your opinion?

Regards,
ivan


> NetworkTopologyStrategy + DCQUORUM
> ----------------------------------
>
>                 Key: CASSANDRA-1664
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1664
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7 beta 1
>         Environment: Linux 2.6.18
> JVM 6b11
>            Reporter: ivan
>             Fix For: 0.7.1
>
>         Attachments: 1664_v2.txt, ntrs.patch
>
>
> We experience TSocket: timed out reading expections randomly using DCQUORUM.
> In log we see that sometimes responses are not sent to client.
> Read requests are sent to all cluster members instead of member of a DC.
> Attached patch adds a new commandType argument to *NaturalEndpoint methods.
> It's needed to separate endpoint list for read and write commands, so for read requests
endpoint list will contain servers in local DC.
> For write requests endpoints provided in all DCs.
> In DatacenterQuorumResponseHandler.response signal is not sent in some cases.
> (In this case we experienced timed out reading exceptions.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message