> On Aug. 17, 2017, 6:11 a.m., Jie Yu wrote: > > src/resource_provider/http_connection.hpp > > Lines 321 (patched) > > <https://reviews.apache.org/r/61271/diff/5/?file=1797468#file1797468line321> > > > > This should be `UNREACHABLE` as well? > > Jan Schlicht wrote: > No, the instance may get destructed before it's connected. In that case > this switch will be called while in `State::CONNECTING`. > > Jie Yu wrote: > ah, when connect attempt fails. this will be called. Can you add a > command here?
The switch was moved to `detected` to fix the issue below. This slightly changes where it can be called, there isn't any state that we would consider `UNREACHABLE` in that case, because `detected` could be called in any state of the instance. > On Aug. 17, 2017, 6:11 a.m., Jie Yu wrote: > > src/resource_provider/http_connection.hpp > > Lines 407 (patched) > > <https://reviews.apache.org/r/61271/diff/5/?file=1797468#file1797468line407> > > > > scheduler? > > > > Also, who is going to initiate the retry? How does the resource > > provider using this driver notice a failed subscribe call? > > > > Is it based on timeout? That sounds super wierd given that we know it > > is an error. > > > > I am wondering if we should make the `send` method returns a > > `Future<Nothing>` or `Future<Response>`, rather than just printing a > > warning in the log. Based on the failure the user receives, it might choose > > to retry subscription, or do something else. Changed the driver to return a `Future<Nothing>`. - Jan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61271/#review183090 ----------------------------------------------------------- On Aug. 18, 2017, 12:18 p.m., Jan Schlicht wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/61271/ > ----------------------------------------------------------- > > (Updated Aug. 18, 2017, 12:18 p.m.) > > > Review request for mesos, Benjamin Bannier and Jie Yu. > > > Bugs: MESOS-7469 > https://issues.apache.org/jira/browse/MESOS-7469 > > > Repository: mesos > > > Description > ------- > > Similar to the existing HTTP connection handling of schedulers and > executors, the resource provider driver will create two connections > with the resource provider manager, one for streaming events and another > one for sending calls. This connection handling has been generalized as > a 'HttpConnectionProcess' and can be reused in other cases. > > > Diffs > ----- > > include/mesos/v1/resource_provider.hpp > 88b606212ea57fee1c1ea522d2dc7f8124a9adef > src/CMakeLists.txt 98ccaf41bf5e7d14164e1c8b6e49268ac865a52c > src/Makefile.am 68fff148f3d0c1710305bd9afcba62336d194b55 > src/resource_provider/detector.hpp PRE-CREATION > src/resource_provider/detector.cpp PRE-CREATION > src/resource_provider/driver.cpp 6778ec9c863022446f141ee88f70eb563178ea05 > src/resource_provider/http_connection.hpp PRE-CREATION > src/resource_provider/storage/provider.cpp > 4c39312be5e4a6d783df3d385a66be6b3dcf8603 > > > Diff: https://reviews.apache.org/r/61271/diff/6/ > > > Testing > ------- > > make check > > > Thanks, > > Jan Schlicht > >
