You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Anand Mazumdar (JIRA)" <ji...@apache.org> on 2016/02/11 20:35:18 UTC

[jira] [Created] (MESOS-4658) process::Connection can lead to deadlock around execution in the same context.

Anand Mazumdar created MESOS-4658:
-------------------------------------

             Summary: process::Connection can lead to deadlock around execution in the same context.
                 Key: MESOS-4658
                 URL: https://issues.apache.org/jira/browse/MESOS-4658
             Project: Mesos
          Issue Type: Bug
          Components: HTTP API, libprocess
            Reporter: Anand Mazumdar


The {{Connection}} abstraction is prone to deadlocks arising from the object being destroyed inside the same execution context.

Consider this example:

{code}
Option<Connection> connection = process::http::connect(...);
connection.disconnected()
  .onAny(defer(self(), &SomeFunc, connection));

connection.disconnect();
connection = None();
{code}

In the above snippet, if the {{connection = None()}} gets executed first before the actual dispatch to {{ConnectionProcess}} happens. You might loose the only existing reference to {{Connection}} object inside {{ConnectionProcess::disconnect}}. This would lead to the destruction of the {{Connection}} object in the {{ConnectionProcess}} execution context.

We do have a snippet in our existing code that alludes to such occurrences happening: 
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/http.cpp#L1325

{code}
  // This is a one time request which will close the connection when
  // the response is received. Since 'Connection' is reference-counted,
  // we must keep a copy around until the disconnection occurs. Note
  // that in order to avoid a deadlock (Connection destruction occurring
  // from the ConnectionProcess execution context), we use 'async'.
{code}

AFAICT, for scenarios where we need to hold on to the {{Connection}} object for later, this approach does not suffice.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)