Page MenuHomePhabricator

[services] Backup - Add server reactor base classes - bidi reactor
ClosedPublic

Authored by karol on Mar 21 2022, 2:38 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Nov 23, 3:41 PM
Unknown Object (File)
Sat, Nov 23, 3:16 PM
Unknown Object (File)
Sat, Nov 23, 3:09 PM
Unknown Object (File)
Sat, Nov 23, 3:08 PM
Unknown Object (File)
Sat, Nov 23, 3:00 PM
Unknown Object (File)
Sat, Nov 23, 2:55 PM
Unknown Object (File)
Sat, Nov 23, 2:27 PM
Unknown Object (File)
Sat, Nov 23, 2:18 PM

Details

Summary

Depends on D3463

This class is moved and renamed for a better folder structure.
As we need to add client reactors in order to be able to connect to the blob service, we need to distinguish server reactors from client reactors.

Test Plan
cd services
yarn run-backup-service

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Harbormaster returned this revision to the author for changes because remote builds failed.Mar 21 2022, 2:49 AM
Harbormaster failed remote builds in B7485: Diff 10540!
karol retitled this revision from [services] Backup - Add server reactor base classes to [draft] [services] Backup - Add server reactor base classes.Mar 21 2022, 3:09 AM
tomek requested changes to this revision.Mar 22 2022, 5:36 AM

A lot is happening in this diff: 1. ServerBidiReactorBase is introduced 2. ServerWriteReactorBase and ServerReadReactorBase are modified and 3. new reactors are used in BackupServiceImpl. Could you split this diff so that it's easier to review it?
Also, in 1. it looks like some parts of the code was moved. When moving the code, we should prefer to not modify it. We sometimes can modify it to make it compile, but there should be an explanation what we're doing.

This revision now requires changes to proceed.Mar 22 2022, 5:36 AM
karol retitled this revision from [draft] [services] Backup - Add server reactor base classes to [draft] [services] Backup - Add server reactor base classes - bidi reactor.Mar 24 2022, 1:55 AM
karol edited the summary of this revision. (Show Details)
tomek requested changes to this revision.Mar 24 2022, 5:19 AM

Thanks for splitting the diff - it's a lot better now.

Is there a way to avoid sendLastResponse flag? It makes it rally hard to be sure that terminate works correctly. Can we e.g. pass it as a parameter to some functions?

services/backup/docker-server/contents/server/src/Reactors/server/base-reactors/ServerBidiReactorBase.h
65

Not sure about the correctness of the logic here: so when !ok and sendLastResponse we're going to StartWriteAndFinish in terminate which sounds like a mistake. I feel like we don't need sendLastResponse flag - there should be some other ways of achieving the desired result without it, but I don't have a good understanding of the whole logic.

This revision now requires changes to proceed.Mar 24 2022, 5:19 AM

back to your queue, curious for your thoughts.

services/backup/docker-server/contents/server/src/Reactors/server/base-reactors/ServerBidiReactorBase.h
65

I'm not sure if that's possible, but I may be missing something.
Here's what we need:
Once we return a non-null status from the handleRequest function, we want to have the ability to send one final message to the client before terminating the connection. A case for that was letting the client know that the data already exists in the blob so we want to abandon sending it again (D3521).
What happens is, the response is being reset this->response = Response(); before this call this->handleRequest (this->request, &this->response);. I think it would be sufficient to recognize whether there were any changes made to the response field. If so, we'd send the last response, if not, we would not (before the connection terminates).
Setting a field like sendLastResponse is not perfect (a little bit unintuitive) but I couldn't figure out a better solution. We could make the response a unique ptr for example but then it would be a lot less handy to use inside of the handleRqeuest function.

tomek requested changes to this revision.Mar 25 2022, 7:57 AM
tomek added inline comments.
services/backup/docker-server/contents/server/src/Reactors/server/base-reactors/ServerBidiReactorBase.h
65

Looking at D3521 it seems like we can handle this case by introducing a new status. The status could consist of two fields, e.g. sendLastResponse and grpcStatus and if sendLastResponse is true, then we would call StartWriteAndFinish in terminate. Could that solution work?

This revision now requires changes to proceed.Mar 25 2022, 7:57 AM
services/backup/docker-server/contents/server/src/Reactors/server/base-reactors/ServerBidiReactorBase.h
65

This solution will probably work alright, it's worth mentioning though that it has some inconsistency included (we don't return a grpc::Status like everywhere else).

All in all, I don't see a better approach to this at this point. Thanks for the idea, I'm going to implement this.

tomek requested changes to this revision.Mar 28 2022, 5:16 AM
tomek added inline comments.
services/backup/docker-server/contents/server/src/Reactors/server/base-reactors/ServerBidiReactorBase.h
63 ↗(On Diff #10722)

It doesn't look like we need to keep the status in this

75 ↗(On Diff #10722)

We set this value but never check it - do we really need it? Maybe we can do something similar to sendLastResponse and avoid storing it in this?

This revision now requires changes to proceed.Mar 28 2022, 5:16 AM
services/backup/docker-server/contents/server/src/Reactors/server/base-reactors/ServerBidiReactorBase.h
63 ↗(On Diff #10722)

we may want to use it in the doneCallback

75 ↗(On Diff #10722)

This can also be used in doneCallback and was created for doing this. I make use of this in PutReactor

tomek added inline comments.
services/backup/docker-server/contents/server/src/Reactors/server/base-reactors/ServerBidiReactorBase.h
63 ↗(On Diff #10722)

Ah, ok, that makes sense

This revision is now accepted and ready to land.Mar 28 2022, 9:01 AM
karol retitled this revision from [draft] [services] Backup - Add server reactor base classes - bidi reactor to [services] Backup - Add server reactor base classes - bidi reactor.

It is accepted as a draft so I removed the draft label and I'm requesting changes once again to keep the appropriate order of events.

tomek requested changes to this revision.Mar 29 2022, 8:13 AM
tomek added inline comments.
services/backup/docker-server/contents/server/src/Reactors/server/base-reactors/ServerBidiReactorBase.h
74–100 ↗(On Diff #10722)

In OnReadDone when !ok we call terminate. Why in OnWriteDone we don't do the same?

This revision now requires changes to proceed.Mar 29 2022, 8:13 AM
services/backup/docker-server/contents/server/src/Reactors/server/base-reactors/ServerBidiReactorBase.h
74–100 ↗(On Diff #10722)

Right, thanks

This revision is now accepted and ready to land.Mar 31 2022, 7:00 AM