Cannot create executor-driver with expected initialization
Closed this issue · 4 comments
When attempting to create a mesomatic executor driver like so:
(require [clojure.core.async :as a]
[mesomatic.async.executor :as async-executor]
[mesomatic.executor :as executor])
(def ch (a/chan))
(def exctr (async-executor/executor ch))
(executor/executor-driver exctr)
the following error occurs:
IllegalArgumentException Don't know how to create ISeq from:
mesomatic.executor$wrap_executor$reify__9882
clojure.lang.RT.seqFrom (RT.java:542)
Double-checking this, I found that:
org.apache.mesos.MesosExecutorDriver.java
expects an instance oforg.apache.mesos.Executor
during initmesomatic.executor/executor-driver
seems to expect a map that- is then converted to protobuff data
- and passed to
MesosExectorDriver
's init
I don't have a complete understanding of mesomatic internals yet, and I'm not sure how closely its behaviours are aiming to match the Java lib's, but:
- it seems that instead of
ExecutorInfo
getting passed toMesosExectorDriver
- the result of (in the async case)
(async-executor/executor ch)
should get passed
I've just changed the mesomatic in my project's checkouts
dir to remove the conversion of the input to protobuffs ... in otherwords, following the same approach used by the Java lib:
(defn executor-driver
[executor]
(let [d (MesosExecutorDriver. executor)]
(reify ExecutorDriver
(abort! [this]
(pb->data (.abort d)))
(join! [this]
(pb->data (.join d)))
(run-driver! [this]
(pb->data (.run d)))
(send-framework-message! [this data]
(pb->data (.sendFrameworkMessage d data)))
(send-status-update! [this status]
(pb->data (.sendStatusUpdate d (data->pb status))))
(start! [this]
(pb->data (.start d)))
(stop! [this]
(pb->data (.stop d))))))
Using this in the REPL produced a successful driver creation:
(def ch (chan))
(def exctr (async-executor/executor ch))
(executor/executor-driver exctr)
#object[mesomatic.executor$executor_driver$reify__9890 0x6fe33722
"mesomatic.executor$executor_driver$reify__9890@6fe33722"]
However! I haven't tried to use this yet, and I have no idea if this change impacts anything else in this library (or projects using this library that might expect the existing behaviour). I will submit a PR for this small change which can get updated according to your feedback/corrections.
Quick note: such that it is, my sample command-line executor (using lein
) is now successfully completing (with this change in place) whereas before it was not. Still need to do more testing on the framework itself to further assess impact ...
The fix for this has been merged 😄