[ 
https://issues.apache.org/jira/browse/MESOS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14148458#comment-14148458
 ] 

Niklas Quarfot Nielsen commented on MESOS-1330:
-----------------------------------------------

[~tstclair] [~bmahler] [~vi...@twitter.com] I would love your input on the 
approach/abstraction before moving forward.
Joris work cut process.cpp in half (!) and it just let us contain, tool around 
and instrument libev and experiment with different transports libevent, asio, 
libuv. Or for example speed things up with off-loading I/O in various ways pin 
to CPU / accelerate with kernel modules etc.

The API in the proof-of-concept can be found here: 
https://github.com/mesosphere/mesos/blob/abstract-event-manager/3rdparty/libprocess/src/event_manager.hpp#L13
It is still a bit rough, but we will follow up with more docs on the different 
calls and where/how it is used.

> Introduce connection/transport abstraction to stout
> ---------------------------------------------------
>
>                 Key: MESOS-1330
>                 URL: https://issues.apache.org/jira/browse/MESOS-1330
>             Project: Mesos
>          Issue Type: Improvement
>          Components: general, libprocess
>            Reporter: Niklas Quarfot Nielsen
>              Labels: libprocess, network
>
> I think it makes sense to think in terms of different low or middle layer 
> transports (which can accommodate channels like SSL). We could capture 
> connection life-cycles and network send/receive primitives in a much explicit 
> manner than currently in libprocess.
> I have a proof of concept transport / connection abstraction ready and which 
> we can use to iterate a design.
> Notably, there are opportunities to change the current SocketManager/Socket 
> abstractions to explicit ConnectionManager/Connection, which allow several 
> and composeable communication layers.
> I am proposing to own this ticket and am looking for a shepherd to 
> (thoroughly) go over design considerations before jumping into an actual 
> implementation.



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

Reply via email to