All:
I'm working on an independent server, which should be able to talk to the Mesos master&client via HTTP POST requests.
I setup a Jersey REST server. My initial plan is to use JSON/XML to map Entities, as this is widely used.
However, I find some communication compatibility issues,
I generate the Java classes from the *.proto files. I try to create an Event.Offers object via a REST (with JSON) call, but get some data stream deserializing errors. I think this is because of the complex structure of the generated classes. They are not POJO's, e.g. they don't have public constructors.
"src/cli/execute.cpp" sets "ContentType" to "PROTOBUF".
I think in most cases, Mesos internally uses "PROTOBUF", not JSON.
So, given the above issues,
Should I implement my server with ProtocolBuffer, is this a better approach? I think this will be fully compatible with Mesos...
Or should I try to convert PROTOBUF to JSON inside Mesos?
Could anyone kindly give some suggestions? I become confused on this point.
Thanks very much
You should use protobuf.
Protobuf is only a way Mesos defines its API. Mesos can handle binary serialized protobuf requests or JSONs. Mesos uses protobuf in version 2 (there will be an upgrade to 3) and there is no standard serialization from protobuf v2 to JSON and Mesos does not fully support v3 JSON mapping, see MESOS-5995. In theory you can create JSON manually but using protobuf guarantee you will use proper version of API and handle serialization for you.
In documentation there are examples how communication looks like. Without proper headers Mesos will refuse requests.
Similar to the Scheduler and Executor HTTP APIs, the operator endpoints only accept HTTP POST requests. The request body should be encoded in JSON (
Content-Type: application/json
) or Protobuf (Content-Type: application/x-protobuf
).
Here you can find sample libraries for communication with Mesos in different use cases: scheduler, executor, operator.
Here you can find my educational purpose scheduler that is using JSONs. It's written in Go and tries to keep everything in one place with only one dependency to Protobuf.