There is an example framework in the repo that creates some `sleep` tasks based on resource offers.
Regarding status there are still a number of items that require implementation from mesos before they can be supported by mesos-rxjava. * AuthN support for HTTP API: https://issues.apache.org/jira/browse/MESOS-3923 ** Required in order to be able to use persistent volumes or dynamic reservations (added in 0.25.0) * Master Redirection: https://issues.apache.org/jira/browse/MESOS-3832 Custom Executors still require the use of libmesos. The full set of JIRA issues for the HTTP APIs can be seen here: https://issues.apache.org/jira/browse/MESOS-3302 Regarding functionality, due to the new design of the Mesos HTTP API some things that libmesos took care of for the user before now have to be taken care of by the user. For example, reconnecting to the master if the connection is lost. Users have to ACK task status updates that have a specified UUID. One thing that only exists in the new HTTP API is the idea of inverse offers (https://issues.apache.org/jira/browse/MESOS-1474) to facilitate maintenance on mesos agents. I also don't yet have a jar published to maven central or sonatype (snapshot hopefully in the next week or so). The other change that isn't really about functionality is the paradigm change. The new HTTP APIs are modeled as an event stream rather than actor messages (translated to callbacks in the current libmesos api). Hope this answers your question. --Ben Whitehead On Thu, Dec 3, 2015 at 3:37 PM, Charles Allen <[email protected] > wrote: > @Ben : Is the status of the mesos-rxjava MORE or LESS functional than the > legacy mesos .jar with the native library? > > On Thu, Dec 3, 2015 at 12:05 PM Ben Whitehead <[email protected]> > wrote: > >> Hi John, >> >> If you're using Java there is already a prototype client atop the new >> Scheduler HTTP API using RxJava: >> https://github.com/mesosphere/mesos-rxjava Happy to provide more info if >> interested. >> >> --Ben Whitehead >> >> On Thu, Dec 3, 2015 at 11:52 AM, John Omernik <[email protected]> wrote: >> >>> Thank you! >>> >>> On Thu, Dec 3, 2015 at 1:40 PM, Vinod Kone <[email protected]> wrote: >>> >>>> Yes, that's the plan. >>>> >>>> Here are the related epics tracking the work: MESOS-2288 >>>> <https://issues.apache.org/jira/browse/MESOS-2288> and MESOS-3302 >>>> <https://issues.apache.org/jira/browse/MESOS-3302> >>>> >>>> The user doc for the scheduler API is >>>> https://github.com/apache/mesos/blob/master/docs/scheduler-http-api.md >>>> >>>> On Thu, Dec 3, 2015 at 11:34 AM, John Omernik <[email protected]> wrote: >>>> >>>>> Somewhere in the back of my brain I thought I read something about a >>>>> migration away from using the mesos native lib and going to a more generic >>>>> API approach to support better portability and less reliance on the lib. >>>>> >>>>> I read about this before I understood things well (or as well I do now >>>>> I should say). Am I misremembering reading about this? I can't find any >>>>> stories/documentation on this. If I am correct on this, can someone point >>>>> me to a JIRA or a discussion on how this is supposed to work? I.e. is the >>>>> goal to migrate all frameworks off the native library to deprecate it etc? >>>>> >>>>> Thanks, sorry for the weird questions. >>>>> >>>>> John >>>>> >>>> >>>> >>> >>
