Skip to content

kv: consolidate RangeInfos in RPC responses#51168

Merged
craig[bot] merged 2 commits intocockroachdb:masterfrom
andreimatei:range-cache.consolidate-range-infos
Jul 10, 2020
Merged

kv: consolidate RangeInfos in RPC responses#51168
craig[bot] merged 2 commits intocockroachdb:masterfrom
andreimatei:range-cache.consolidate-range-infos

Conversation

@andreimatei
Copy link
Copy Markdown
Contributor

The kvclient can request information from the server about the
descriptor and lease of the range evaluating a request. This is
requested by setting a bit on the batch's header. The server was then
replying with information in every single request's header (as opposed
to the BatchResponse's header). For all the requests that hadn't been
split by the DistSender, the responses were the same.

This patch moves the responses to the BatchResponse's header - so, for
one RPC, there's gonna be exactly one response although the DistSender
will combine multiple of them. For backwards compatibility with 20.1,
new servers still populate the old location, and new clients copy from
the old location to the new one (subject to a cluster version gate).

The patch also removes the latching of a range's descriptor and lease
keys when requests will return range information. The latching was not
necessary - the respective keys are not actually read from the database
(in-memory caches are used) and clients don't care about any particular
consistency guarantees. In order to do away with this latching cleanly,
the server-side code that populates the range info is lifted from the
lower levels of request evaluation to a high-level.

This patch is motivated by upcoming changes which will make returning
range info more common. As such, both the latching and the duplication
of returned data become problems.

Release note: None

@andreimatei andreimatei requested a review from nvb July 8, 2020 18:37
@cockroach-teamcity
Copy link
Copy Markdown
Member

This change is Reviewable

Copy link
Copy Markdown
Contributor

@nvb nvb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like where this is going.

Reviewed 2 of 2 files at r1, 14 of 14 files at r2.
Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @andreimatei)


pkg/kv/kvclient/kvcoord/dist_sender.go, line 1488 at r2 (raw file):

				len(reply.RangeInfos) == 0 &&
				!ds.st.Version.IsActive(ctx, clusterversion.VersionClientRangeInfosOnBatchResponse) {
				if ba.ReturnRangeInfo && len(reply.RangeInfos) == 0 {

Are we checking this condition twice?


pkg/kv/kvserver/replica_send.go, line 123 at r2 (raw file):

	// and a pErr here. Also, some errors (e.g. NotLeaseholderError) have custom
	// ways of returning range info.
	if ba.ReturnRangeInfo && pErr == nil {

Let's move this into a helper function to avoid cluttering this method.


pkg/kv/kvserver/replica_send.go, line 125 at r2 (raw file):

	if ba.ReturnRangeInfo && pErr == nil {
		lease, _ := r.GetLease()
		desc := r.Desc()

Didn't you just add an accessor to atomically grab both of these?


pkg/kv/kvserver/replica_send.go, line 139 at r2 (raw file):

				reply := r.GetInner()
				header := reply.Header()
				header.DeprecatedRangeInfos = []roachpb.RangeInfo{

nit: header.DeprecatedRangeInfos = br.RangeInfos


pkg/roachpb/api.go, line 465 at r2 (raw file):

			continue
		}
		h.RangeInfos = append(h.RangeInfos[:i], append([]RangeInfo{ri}, h.RangeInfos[i:]...)...)

This will result in wasted allocations. How abound something like:

h.RangeInfos = append(h.RangeInfos, roachpb.RangeInfo{})
copy(h.RangeInfos[i+1:], h.RangeInfos[i:])
h.RangeInfos[i] = ri

@andreimatei andreimatei force-pushed the range-cache.consolidate-range-infos branch from d798fd4 to 9254366 Compare July 10, 2020 21:31
Copy link
Copy Markdown
Contributor Author

@andreimatei andreimatei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @nvanbenschoten)


pkg/kv/kvclient/kvcoord/dist_sender.go, line 1488 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

Are we checking this condition twice?

done


pkg/kv/kvserver/replica_send.go, line 123 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

Let's move this into a helper function to avoid cluttering this method.

done


pkg/kv/kvserver/replica_send.go, line 125 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

Didn't you just add an accessor to atomically grab both of these?

done


pkg/kv/kvserver/replica_send.go, line 139 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

nit: header.DeprecatedRangeInfos = br.RangeInfos

done


pkg/roachpb/api.go, line 465 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

This will result in wasted allocations. How abound something like:

h.RangeInfos = append(h.RangeInfos, roachpb.RangeInfo{})
copy(h.RangeInfos[i+1:], h.RangeInfos[i:])
h.RangeInfos[i] = ri

done

The kvclient can request information from the server about the
descriptor and lease of the range evaluating a request. This is
requested by setting a bit on the batch's header. The server was then
replying with information in every single request's header (as opposed
to the BatchResponse's header). For all the requests that hadn't been
split by the DistSender, the responses were the same.

This patch moves the responses to the BatchResponse's header - so, for
one RPC, there's gonna be exactly one response although the DistSender
will combine multiple of them. For backwards compatibility with 20.1,
new servers still populate the old location, and new clients copy from
the old location to the new one (subject to a cluster version gate).

The patch also removes the latching of a range's descriptor and lease
keys when requests will return range information. The latching was not
necessary - the respective keys are not actually read from the database
(in-memory caches are used) and clients don't care about any particular
consistency guarantees. In order to do away with this latching cleanly,
the server-side code that populates the range info is lifted from the
lower levels of request evaluation to a high-level.

This patch is motivated by upcoming changes which will make returning
range info more common. As such, both the latching and the duplication
of returned data become problems.

Release note: None
@andreimatei andreimatei force-pushed the range-cache.consolidate-range-infos branch from 9254366 to d86e265 Compare July 10, 2020 21:57
Copy link
Copy Markdown
Contributor Author

@andreimatei andreimatei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bors r+

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @nvanbenschoten)

@craig
Copy link
Copy Markdown
Contributor

craig bot commented Jul 10, 2020

Build succeeded

@craig craig bot merged commit a9e9c9c into cockroachdb:master Jul 10, 2020
@andreimatei andreimatei deleted the range-cache.consolidate-range-infos branch July 13, 2020 16:51
nvb added a commit to nvb/cockroach that referenced this pull request Jan 25, 2021
This commit completes a series of migrations relating to RangeInfo state
and the client/server protocol for keeping the range descriptor cache up
to date. The migrations were started in cockroachdb#51168, cockroachdb#51378, cockroachdb#51437.

Concretely, this commit removes the following cluster versions:
- `ClientRangeInfosOnBatchResponse`
- `RangeStatsRespHasDesc`

It addresses 6 TODOs.

And it makes the following changes to the KV APi:
- makes `Header.ClientRangeInfo` non-nullable.
- deletes `Header.ReturnRangeInfo`.
- deletes `ResponseHeader.DeprecatedRangeInfos`.
- stops propagating `BatchResponse.RangeInfos` past `DistSender`.
- makes RangeStatsResponse.RangeInfo non-nullable.
nvb added a commit to nvb/cockroach that referenced this pull request Jan 26, 2021
This commit completes a series of migrations relating to RangeInfo state
and the client/server protocol for keeping the range descriptor cache up
to date. The migrations were started in cockroachdb#51168, cockroachdb#51378, cockroachdb#51437.

Concretely, this commit removes the following cluster versions:
- `ClientRangeInfosOnBatchResponse`
- `RangeStatsRespHasDesc`

It addresses 6 TODOs.

And it makes the following changes to the KV APi:
- makes `Header.ClientRangeInfo` non-nullable.
- deletes `Header.ReturnRangeInfo`.
- deletes `ResponseHeader.DeprecatedRangeInfos`.
- stops propagating `BatchResponse.RangeInfos` past `DistSender`.
- makes RangeStatsResponse.RangeInfo non-nullable.
craig bot pushed a commit that referenced this pull request Jan 26, 2021
59395: kv: complete client range info migrations r=nvanbenschoten a=nvanbenschoten

This commit completes a series of migrations relating to RangeInfo state
and the client/server protocol for keeping the range descriptor cache up
to date. The migrations were started in #51168, #51378, #51437.

Concretely, this commit removes the following cluster versions:
- `ClientRangeInfosOnBatchResponse`
- `RangeStatsRespHasDesc`

It addresses 6 TODOs.

And it makes the following changes to the KV APi:
- makes `Header.ClientRangeInfo` non-nullable.
- deletes `Header.ReturnRangeInfo`.
- deletes `ResponseHeader.DeprecatedRangeInfos`.
- stops propagating `BatchResponse.RangeInfos` past `DistSender`.
- makes RangeStatsResponse.RangeInfo non-nullable.

Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants