Not the Event/Call stuff but the 'libprocess-from' and '202 Accepted' reviews.
On Mon, Apr 14, 2014 at 10:40 AM, Kevin Sweeney <kevin.t.swee...@gmail.com>wrote: > Didn't see the Event/Call review so current version uses the undocumented > internal API. Should be straightforward to migrate though > > > On Monday, April 14, 2014, Benjamin Hindman <b...@eecs.berkeley.edu> > wrote: > >> Very cool Kevin. Was this using the patches on Review Board I linked? >> >> >> On Sun, Apr 13, 2014 at 11:28 PM, Kevin Sweeney < >> kevin.t.swee...@gmail.com> wrote: >> >> I've got the start of a JVM verson on github - it can currently register >> a framework and parse the response. Client-side I still need to figure out >> how to properly configure Keep-Alive. Servlet can dispatch messages to >> message handlers in a type-safe way and returns a 202 for messages it's >> going to handle. Code's a mess currently. >> >> https://github.com/kevints/mesos-framework-api >> >> >> On Fri, Apr 11, 2014 at 7:12 PM, Benjamin Hindman <b...@eecs.berkeley.edu >> > wrote: >> >> First, my apologies for getting to this party so late. It's great to see >> people interested in helping create native-language Mesos libraries. >> >> Vladimir: my presentation was definitely referring to the the low-level >> protocol between master, framework (scheduler), slave, and executors. I'll >> do my best here to clarify how the current protocol works and what we need >> to do to get it to the point where we can write native-language libraries. >> (Eventually it would be great to move some of this into documentation as >> necessary.) >> >> As Nikita pointed out, the protocol is currently "HTTP-like". As my >> presentation describes, think actors and one-way message passing when >> considering how the protocol works. >> >> To send a message an actor POSTs an HTTP request where the actor that is >> supposed to receive the message is the first component of the request path >> and the name of the message is the remaining part of the path. To >> distinguish one of these "messages" from a normal HTTP request we look to >> see if the 'User-Agent' is 'libprocess/...'. For example: >> >> POST /master/mesos.internal.RegisterFrameworkMessage HTTP/1.1 >> User-Agent: libprocess/scheduler(1)@10.0.1.7:53523 >> >> ... represents a message with the name >> 'mesos.internal.RegisterFrameworkMessage' destined for the actor 'master' >> coming from the actor 'scheduler(1)' at 10.0.1.7:53523. If the 'master' >> actor were to send a message back it would look something like this: >> >> POST /scheduler(1)/mesos.internal.FrameworkRegisteredMessage HTTP/1.1 >> User-Agent: libprocess/master@10.0.1.7:5050 >> >> So, one-way message passing via HTTP POST. >> >> The message data is captured as the body of the HTTP request (which can >> be specified using _either_ Content-Length or a Transfer-Encoding, and as >> Nikita points out we use chunked transfer encoding internally). The data is >> arbitrary and the actor ultimately decides how it wants to "parse" it. In >> Mesos, 99% of our messages use serialized protobufs, but we also send a few >> messages with just arbitrary data. All this really means is that knowing >> the actor and message name is not enough, you also need to know what the >> body type is supposed to be for that message. In the future we'll probably >> enable messages with either JSON or serialized protobuf[1] ... for now, >> just serialized protobuf. >> >> Okay, so where does this break down when trying to do this >> language-natively? I've had some of this in the works and this conversation >> has motivated me to publish some reviews addressing the issues: >> >> (1) We'll need to return a response if one plans to use a native HTTP >> library since it'll expect request/response. >> https://reviews.apache.org/r/20276 introduces responding with a '202 >> Accepted' for these messages (from the HTTP specification, a '202 >> Accepted': "The request has been accepted for processing, but the >> processing has not been completed. The request might or might not >> eventually be acted upon, as it might be disallowed when processing >> actually takes place. There is no facility for re-sending a status code >> from an asynchronous operation such as this."). >> >> (2) Most HTTP libraries will set their 'User-Agent' themselves >> >> > > -- > Sent from Gmail Mobile >
