-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
boltdb panic when defragmenting in functional-tester #7526
Labels
Milestone
Comments
This is probably from the lock breaking patch; different from #7322 since the backend isn't closed. |
Easy repro: // TestV3MaintenanceDefragInflightRange ensures inflight range requests
// while defrag is running does not panic the mvcc backend.
func TestV3MaintenanceDefragInflight(t *testing.T) {
defer testutil.AfterTest(t)
clus := NewClusterV3(t, &ClusterConfig{Size: 1})
defer clus.Terminate(t)
cli := clus.RandClient()
kvc := toGRPC(cli).KV
if _, err := kvc.Put(context.Background(), &pb.PutRequest{Key: []byte("foo"), Value: []byte("bar")}, grpc.FailFast(false)); err != nil {
t.Fatal(err)
}
ctx, cancel := context.WithTimeout(context.Background(), time.Second)
donec := make(chan struct{})
go func() {
defer close(donec)
kvc.Range(ctx, &pb.RangeRequest{Key: []byte("foo")}, grpc.FailFast(false))
}()
mvc := toGRPC(cli).Maintenance
mvc.Defragment(context.Background(), &pb.DefragmentRequest{}, grpc.FailFast(false))
cancel()
<-donec
} |
gyuho
added a commit
to gyuho/etcd
that referenced
this issue
Mar 22, 2017
Fix etcd-io#7526. Signed-off-by: Gyu-Ho Lee <[email protected]>
gyuho
added a commit
to gyuho/etcd
that referenced
this issue
Mar 23, 2017
etcd panic-ed, so defrag response just blocked for "days" when the actual 'v3rpc' path never returned. We should catch this earlier. ref. etcd-io#7526 Signed-off-by: Gyu-Ho Lee <[email protected]>
gyuho
added a commit
to gyuho/etcd
that referenced
this issue
Mar 23, 2017
etcd panic-ed, so defrag response just blocked for "days" when the actual 'v3rpc' path never returned. We should catch this earlier. ref. etcd-io#7526 Signed-off-by: Gyu-Ho Lee <[email protected]>
gyuho
added a commit
to gyuho/etcd
that referenced
this issue
Mar 23, 2017
etcd panic-ed, so defrag response just blocked for "days" when the actual 'v3rpc' path never returned. We should catch this earlier. ref. etcd-io#7526 Signed-off-by: Gyu-Ho Lee <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
etcd-tester: grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 10.240.0.2:2379: getsockopt: connection refused"; Reconnecting to {10.240.0.2:2379 <nil>}
)Server panic
Related #7322
The text was updated successfully, but these errors were encountered: