Uploaded image for project: 'Mesos'
  1. Mesos
  2. MESOS-2307

Dispatching to a non-existent Process should not return a pending future.

Details

    • Bug
    • Status: Accepted
    • Major
    • Resolution: Unresolved
    • None
    • None
    • libprocess
    • None
    • Mesosphere Sprint 23

    Description

      If the libprocess process is terminated, we can still dispatch calls to it as long as we have a UPID. In this case the future will be pending forever. Instead, it would be better to introduce a separate state for such case, e.g. Disconnected, Abandoned.

      Attachments

        Issue Links

          Activity

            This has come up before (example here and here), we were considering failing futures for dispatches to unknown processes. Any reason not to re-use Failure for this case?

            Are you seeing this in a specific place?

            bmahler Benjamin Mahler added a comment - This has come up before ( example here and here ), we were considering failing futures for dispatches to unknown processes. Any reason not to re-use Failure for this case? Are you seeing this in a specific place?

            I was thinking about introducing a new state to separate this case from all others, but we can re-use Failure. My specific use case is not relevant any more.

            alex-mesos Alexander Rukletsov (Inactive) added a comment - I was thinking about introducing a new state to separate this case from all others, but we can re-use Failure . My specific use case is not relevant any more.

            This behavior is known in literature as breaking a promise. In fact, C++ 11 futures will set the future to the std::future_exception with code broken_promise if they run in this situation.

            I feel that is akin to failing our futures when the futures are being destroyed and not set. I have a small patch which fixes the issue, but there is a comment there which I am not sure about, so once it is clear I will publish it.

            arojas Alexander Rojas added a comment - This behavior is known in literature as breaking a promise. In fact, C++ 11 futures will set the future to the std::future_exception with code broken_promise if they run in this situation. I feel that is akin to failing our futures when the futures are being destroyed and not set. I have a small patch which fixes the issue, but there is a comment there which I am not sure about, so once it is clear I will publish it.

            alexr I've updated the summary. I think with the recent changes that added the abandoned state, dispatching to a non-existent Process will result in an abandoned future. Shall we close this ticket?

            bmahler Benjamin Mahler added a comment - alexr I've updated the summary. I think with the recent changes that added the abandoned state, dispatching to a non-existent Process will result in an abandoned future. Shall we close this ticket?
            alexr Alex R added a comment -

            Abandoned makes sense to me.

            alexr Alex R added a comment - Abandoned makes sense to me.

            People

              Unassigned Unassigned
              alexr Alex R
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated: