Here's the limitations of this approach, as well as some of the implementation itself
This is the model behind the AM. Data is pre
Slider as a Service. Owning app is only client allowed to talk to AM API (ensures it is in charge and nothing happens behind its back).Slider manages everything as if it was standalone.
Bonded is something we are thinking of, but haven't started to implement yet. Here the components are told to talk directly to the owning appSlider's role reduced to one of managing the #of instances of each componentApp has to implement slider agent heartbeat operation, send commands back -plan: make callback code reusable lib.Allows: more commands to maybe go into to components, monitoring hookups, …
The global section defines global values, individual components can override any -otherwise they inherit the global values
JMX port binding & publishing of portweb port rolling restart of NM/RMAM retry logicTesting: chaos monkey for YARNLogging: running Samza without HDFS -costs of ops & latency. Are only running Samza clusters w/ YARN. YARN puts logs into HDFS by default, so without HDFS you are stuffed.-rollover of stdout & stderr -have the NM implement the rolling. -Samza could log from log4j to append to Kafka; need a way to pull out and view. Adds 15 min YARN can use http: URLs to pull in local resourceSamza can handle outages of a few minutes, but for other services rolling restart/upgadeno classic scheduling; assume full code can run or buy more hardware-RM to tell AM when request cant be satisfied